IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 18 September 2018 (all times are UTC)
| 02:03 | adrianor1 is now known as adrianorg | |
| 05:02 | lucascastro has left IRC (lucascastro!~lucascast@177-185-139-186.isotelco.net.br, Remote host closed the connection) | |
| 05:55 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 09:37 | GodFather has left IRC (GodFather!~rcc@174-081-217-069.dhcp.chtrptr.net, Ping timeout: 272 seconds) | |
| 11:57 | GodFather has joined IRC (GodFather!~rcc@2603:3015:3507:1600:4585:3483:e3e7:f2cd) | |
| 11:59 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 12:04 | GodFather has left IRC (GodFather!~rcc@2603:3015:3507:1600:4585:3483:e3e7:f2cd, Ping timeout: 250 seconds) | |
| 12:20 | GodFather has joined IRC (GodFather!~rcc@2603:3015:3507:1600:4585:3483:e3e7:f2cd) | |
| 12:50 | GodFather has left IRC (GodFather!~rcc@2603:3015:3507:1600:4585:3483:e3e7:f2cd, Ping timeout: 252 seconds) | |
| 13:23 | GodFather has joined IRC (GodFather!~rcc@2603:3015:3507:1600:4585:3483:e3e7:f2cd) | |
| 14:06 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 14:07 | <alkisg> vagrantc: hi there
| |
| 14:07 | <vagrantc> alkisg: hey
| |
| 14:07 | <alkisg> I think it would be a good time to do that epoptes release.. what's your schedule like these days?
| |
| 14:08 | <vagrantc> alkisg: so flexible it's hard to do anything! :)
| |
| 14:08 | <alkisg> Haha
| |
| 14:08 | Want me to go ahead and do the release instead? I don't mind waiting, if it's a matter of a couple of months, but I can also do it, np
| |
| 14:09 | <vagrantc> i'm also guessing ltsp could use a new upload as well?
| |
| 14:10 | there was some ltsp-manager merge request for python3, too?
| |
| 14:10 | <alkisg> True, ltsp has stabilized as well
| |
| 14:10 | I don't know about ltsp manager, as I haven't updated it for recent distros
| |
| 14:11 | Someone here talked about maintaining it, but I don't know of its current state
| |
| 14:11 | !ldm-source
| |
| 14:11 | <ltsp> ldm-source: at https://code.launchpad.net/~ltsp-upstream/ltsp/+git/ldm
| |
| 14:12 | * vagrantc swears launchpad changes vcs URLs every alternating week | |
| 14:12 | <alkisg> !ltspfs
| |
| 14:12 | <ltsp> I do not know about 'ltspfs', but I do know about these similar topics: 'ltspfs-source'
| |
| 14:12 | <alkisg> !ltspfs-source
| |
| 14:12 | <ltsp> ltspfs-source: at https://code.launchpad.net/~ltsp-upstream/ltsp/+git/ltspfs
| |
| 14:12 | lucascastro has joined IRC (lucascastro!~lucascast@177-185-139-186.isotelco.net.br) | |
| 14:12 | <alkisg> Eh, those aren't really release-worthy
| |
| 14:12 | Only a couple of commits since last release
| |
| 14:13 | <vagrantc> alkisg: is epoptes upstream still github?
| |
| 14:18 | alkisg: fotis rejected the date-version thing?
| |
| 14:23 | GodFather has left IRC (GodFather!~rcc@2603:3015:3507:1600:4585:3483:e3e7:f2cd, Ping timeout: 250 seconds) | |
| 14:32 | <enaut[m]> vagrantc, alkisg: I did some adjustments so that ltsp-manager works well in the following git repository: https://code.launchpad.net/~ltsp-manager/ltsp-manager/+git/ltsp-manager/+ref/master
| |
| 14:34 | I tested this and use it in Ubuntu 18.04
| |
| 14:34 | <vagrantc> oh right, i emailed a reply but launchpad rejected the message
| |
| 14:34 | enaut[m]: very cool!
| |
| 14:35 | <enaut[m]> However as I'm usually a Fedora user and I never packaged anything it might have some issues...
| |
| 14:35 | <vagrantc> enaut[m]: my comments were merely logistical, and not on the code itself
| |
| 14:36 | e.g. fix committed is only appropriate when it hits the upstream branch, and assigning it to yourself means that you will do the next steps
| |
| 14:37 | enaut[m]: it looks like you created the ltsp-manager team, and none of the ltsp-manager upstream developers are part of it? ...
| |
| 14:38 | <alkisg> (05:13:23 μμ) vagrantc: alkisg: is epoptes upstream still github? (05:18:28 μμ) vagrantc: alkisg: fotis rejected the date-version thing?
| |
| 14:38 | Yup on both
| |
| 14:38 | enaut[m]: great
| |
| 14:38 | <vagrantc> enaut[m]: that aside, very happy to see python3 support :)
| |
| 14:39 | <enaut[m]> vagrantc: I don't know who is actually upstream as it sounded like this project is mostly abandoned I'll add everybody to the team who would like to help :)
| |
| 14:40 | - or whom I could help
| |
| 14:40 | or I could delete the team again as its not really used yes
| |
| 14:41 | <vagrantc> confusingly, there's https://launchpad.net/ltsp-manager and https://launchpad.net/~ltsp-manager now, which are entirely different
| |
| 14:41 | <enaut[m]> yep I know
| |
| 14:42 | and not really different, as they use the same git repository
| |
| 14:43 | <vagrantc> https://git.launchpad.net/ltsp-manager doesn't contain your python3 fixes, for example
| |
| 14:43 | <alkisg> The first is the project, the second is the team
| |
| 14:43 | <enaut[m]> vagrantc: so is there somebody who manages and maintains the ltsp-manager? If so I could prepare pullrequests.
| |
| 14:44 | I do not know how this works in launchpad though
| |
| 14:44 | <vagrantc> yeah, i find launchpad to have many confusing quirks
| |
| 14:45 | <alkisg> enaut[m]: no, you're the only one working on ltsp manager currently
| |
| 14:46 | My idea was that you do that for a period, and if you decide that you'll keep maintaining it, then you'd take the "keys" to all of upstream for it
| |
| 14:46 | <vagrantc> ah
| |
| 14:46 | alkisg: you're not using ltsp-manager anymore?
| |
| 14:47 | <alkisg> We're using its initial localized version, sch-scripts
| |
| 14:47 | <enaut[m]> that was the secret takeover plan ;)
| |
| 14:47 | <vagrantc> ah, so you've never migrated to it
| |
| 14:47 | <alkisg> As there wasn't much demand for it, so i found it easier to keep the greek-specific things that sch-scripts had
| |
| 14:48 | Also, in the 16.04 timeframe when the migration could have happened, there wasn't any funding, and now that there is some limited funding, there wasn't time to adjust ltsp-manager to the greek specific needs
| |
| 14:48 | (funding basically started in september)
| |
| 14:48 | <vagrantc> alkisg: glad to hear it's started up again
| |
| 14:48 | <alkisg> Eh, at least until December. Fingers crossed for after that.
| |
| 14:49 | <vagrantc> here's to hope
| |
| 14:49 | <alkisg> Finally, ltsp-manager is mostly a user manager, with only limited ltsp functionality, which, if everything goes well, should completely disappear in ltsp 6
| |
| 14:50 | <vagrantc> ok, so on my plate is ... tag epoptes release, upload to debian, tag ltsp release, upload to debian ...
| |
| 14:50 | with some testing in-between
| |
| 14:50 | <alkisg> enaut[m]: so for example... if next year we release "the new ltsp6", and ltsp-manager no longer needs ltsp-specific bits, would you be interested in keeping it maintained only as a user manager?
| |
| 14:51 | vagrantc: sounds great
| |
| 14:51 | <vagrantc> alkisg: there's another round of outreachy ... any interest in co-mentoring some LTSP projects?
| |
| 14:52 | <alkisg> vagrantc: I'd mostly be interested in applying as a student in a gsoc project to implement ltsp6, to be honest
| |
| 14:52 | But we'd need a mentor for that one :)
| |
| 14:53 | I think that's what the community (and greek schools) need more at this point
| |
| 14:53 | <vagrantc> i thought you could only GSoC once
| |
| 14:53 | <alkisg> No, twice is allowed
| |
| 14:53 | <vagrantc> oh
| |
| 14:55 | <alkisg> With wayland just around the corner, I don't think we can delay ltsp6 a lot more...
| |
| 14:56 | So the gsoc project basis would be, a new ltsp that has some of the old ltsp functionality, runs fat clients with wayland, and integrates ltsp-pam
| |
| 14:56 | <enaut[m]> alkisg: what will there be in ltsp 6? relevant to ltsp-manager
| |
| 14:56 | * vagrantc really needs to get involved in some real-world LTSP deployment again... | |
| 14:56 | <alkisg> That would be enough for ltsp upstream to pick up its maintenance
| |
| 14:57 | <vagrantc> yeah, i was thinking of the pam stuff for outreachy
| |
| 14:57 | as one concrete piece that could be worked on
| |
| 14:57 | <alkisg> I'm not sure it can be separated from "ltsp 6"
| |
| 14:58 | <vagrantc> enaut[m]: ltsp6 would basically get rid of an ltsp-specific display manager (ldm) ... and just use gdm/kdm/*dm
| |
| 14:58 | <alkisg> enaut[m]: well, which of the parts of ltsp-manager are ltsp-specific? Just the "server" menu. How much funtionality is actually there currently? Minimal...
| |
| 14:58 | And drop ltsp-build-client, and drop ltspfs, and drop thin clients...
| |
| 14:59 | It's a chance to get rid of a whole lot of unmaintained code, e.g. altlinux and lots of other distro specific things
| |
| 14:59 | <vagrantc> ltsp-manager is basically a frontend to ltsp-config and ltsp-update-image, with a user manager
| |
| 14:59 | <alkisg> Right, the user manager is more than 90% of its code base
| |
| 14:59 | <vagrantc> heh
| |
| 15:00 | <alkisg> It's extra useful for schools though; how else can you create 500 user accounts separated in groups, with shared folders etc
| |
| 15:00 | <vagrantc> ah, the shared folder stuff too
| |
| 15:00 | <alkisg> Initially, epoptes was part of sch-scripts, but we extracted its functionality out and internationalized it
| |
| 15:00 | <enaut[m]> ok - but there will still be things that can be configured using a graphical interface but the signup server might be hard to do then
| |
| 15:01 | <alkisg> I think the same thing should happen now with ltsp-manager, it should become a user manager that can work with or without ltsp...
| |
| 15:01 | libpam-sshauth could work without ltsp as well
| |
| 15:01 | <enaut[m]> without ldm...
| |
| 15:01 | <vagrantc> someone is actually using libpam-sshauth in the wild
| |
| 15:02 | <alkisg> So in that case, the user manager along with libpam-sshauth would allow a teacher to centrally maintain accounts without using ldap. And without involving netbooting.
| |
| 15:02 | <vagrantc> https://qa.debian.org/popcon.php?package=libpam-sshauth suggests three people have used it in the last week!
| |
| 15:02 | <alkisg> Hehe
| |
| 15:02 | <vagrantc> and that's the C version, not sure on the python version
| |
| 15:03 | * alkisg wonders why they don't show the package download stats instead of popcon :) | |
| 15:03 | <enaut[m]> Ok that sounds great and I think I'm up to the task of maintaining ltsp-manager
| |
| 15:04 | <alkisg> enaut[m]: great! So maybe it's an idea to actually change its name and take full ownership of it, like "enaut-user-manager", giving more focus on the user manager part and less on ltsp
| |
| 15:04 | <vagrantc> alkisg: impossible to actually show download stats
| |
| 15:04 | alkisg: most debian mirrors aren't administered by debian
| |
| 15:04 | <alkisg> I'm sure that the main download stats, without counting the mirrors, would be way more and way more accurate than the popcon results
| |
| 15:05 | How many enable popcon, like 1 out of 1000?
| |
| 15:05 | <vagrantc> alkisg: in this case, 3 actually used it in the last week, as opposed to how many people download it and never used it
| |
| 15:05 | <alkisg> And that's biased, they only reveal the packages of a certain type of users that know enough to enable popcon and care to do it
| |
| 15:06 | How do you know they've used it? Popcon has hooks for binaries?
| |
| 15:06 | <vagrantc> alkisg: popcon checks for atime used on files in the package
| |
| 15:07 | <alkisg> Isn't relatime the default nowadays, which doesn't update atime?
| |
| 15:07 | <vagrantc> that's what the "vote" category is
| |
| 15:07 | alkisg: relatime updates the atime approximately once per day
| |
| 15:07 | <alkisg> Also, wouldn't that be triggered by just `cp -a`?
| |
| 15:07 | <vagrantc> there are all sorts of ways to trigger it, sure.
| |
| 15:09 | basically, any access of any of the files in the package will trigger it ... but that's far more interesting than download stats to me
| |
| 15:10 | anyways ... i'll see if i can get epoptes and ltsp updated
| |
| 15:12 | <enaut[m]> vagrantc: so I removed the ltsp-manager team and moved my git repository back to me... I'll port the ltsp-manager to a general user-manager... and see how it is accepted.
| |
| 15:12 | <alkisg> Sounds great to me
| |
| 15:13 | <vagrantc> enaut[m]: i could update ltsp-manager in debian experimental with just your fixes, too ... there are other bugs in the packaging that should be touched up
| |
| 15:14 | <enaut[m]> has anyone used the ltsp-cluster-accountmanager?
| |
| 15:14 | <vagrantc> far as i know all the ltsp-cluster stuff is unmaintained for quite a few years
| |
| 15:15 | <alkisg> Yeah another of the things to remove in ltsp6
| |
| 15:15 | <enaut[m]> vagrantc: you could cherrypick or use the whole git master branch... I started to use meson as build system - but that is not really done yet.
| |
| 15:16 | Also if you spot any problem I'll be happy to learn about it as I'm learning learning how to do it right ;)
| |
| 15:20 | <vagrantc> enaut[m]: thanks for taking the initiative :)
| |
| 15:25 | alkisg: well, i pulled in master + your packaging branch and it builds on debian sid ... so that's promising :)
| |
| 15:25 | alkisg: epoptes, that is
| |
| 15:45 | sutula has joined IRC (sutula!~sutula@207-118-149-102.dyn.centurytel.net) | |
| 15:45 | <sutula> My Ubuntu 16.x LTSP server has been whining that 18.04.1 LTS is now available. Is that currently a recommended LTSP platform? Future work?
| |
| 15:47 | <||cw> sutula: yes, new work is mostly being done on 18.04
| |
| 15:47 | <vagrantc> but plain 18.04 doesn't support ltsp all that well
| |
| 15:48 | you basically need the ppa
| |
| 15:48 | !ppa
| |
| 15:48 | <ltsp> I do not know about 'ppa', but I do know about these similar topics: 'sbalneav-ppa', 'greek-schools-ppa'
| |
| 15:48 | <||cw> right
| |
| 15:48 | <vagrantc> !greek-schools-ppa
| |
| 15:48 | <ltsp> greek-schools-ppa: https://launchpad.net/~ts.sch.gr/+archive/ppa/ supports LTS Ubuntu releases with newer LTSP versions, bug fixes etc
| |
| 15:48 | <||cw> !wiki
| |
| 15:48 | <ltsp> wiki: The LTSP wiki can be found at http://server.ltsp.org/mediawiki/index.php/LTSPedia
| |
| 15:48 | <||cw> hm, that's not accurate, is it?
| |
| 15:48 | !install
| |
| 15:48 | <ltsp> install: http://wiki.ltsp.org/wiki/Installation/Ubuntu for Ubuntu, or http://wiki.ltsp.org/wiki/Installation for other distributions
| |
| 15:48 | <||cw> there it is.
| |
| 15:48 | sutula: ^
| |
| 15:50 | <sutula> ||cw: Is it likely that simply allowing the 16.x machine to upgrade will work? Perhaps with the addition of the right ppa?
| |
| 15:50 | <||cw> ¯\_(ツ)_/¯
| |
| 15:51 | I've not actually tried an ltsp in place upgrade. you'd need extra down time because you need to upgrade or recreate the clients
| |
| 15:51 | I've always just stood up a new VM and moved clients over as they reboot
| |
| 15:51 | <sutula> Seems safer, I suppose
| |
| 15:52 | <||cw> lets you clean up older cruft
| |
| 15:52 | and also learn the new 18.04 pitfalls
| |
| 15:53 | <sutula> All my clients are fat but PXE boot, so simply recreating the image after the upgrade might work...or not :0D
| |
| 15:53 | <||cw> like if you have a windows AD handling DHCP
| |
| 15:53 | * sutula doesn't, thankfully | |
| 15:53 | <alkisg> (06:25:20 μμ) vagrantc: alkisg: well, i pulled in master + your packaging branch and it builds on debian sid ... so that's promising :) => yey!
| |
| 15:53 | vagrantc:I'll be happy to fix any issues that you see
| |
| 15:53 | <||cw> or any dhcp doens't handle the new client identifier crap
| |
| 15:54 | <alkisg> (06:50:18 μμ) sutula: ||cw: Is it likely that simply allowing the 16.x machine to upgrade will work? Perhaps with the addition of the right ppa? => it should, but of course you'd need to recreate your chroots
| |
| 15:54 | sutula: if you're using chroots instead of chrootless/ltsp-pnp, make sure you put the ppa to the chroot as well, otherwise it'll malfunction
| |
| 15:55 | (ltsp will malfunction, that is; the 18.04 stock version is very out of date)
| |
| 15:55 | * sutula nods | |
| 15:55 | Helenah has left IRC (Helenah!~s98259@unaffiliated/iveeee, Ping timeout: 252 seconds) | |
| 16:02 | <vagrantc> alkisg: just following up with some minor fixes to the packaging, and then i'll start testing ... hopefully i have a working test environment :)
| |
| 16:28 | Helenah has joined IRC (Helenah!~s98259@unaffiliated/iveeee) | |
| 17:09 | lucascastro has left IRC (lucascastro!~lucascast@177-185-139-186.isotelco.net.br, Remote host closed the connection) | |
| 17:31 | lucascastro has joined IRC (lucascastro!~lucascast@200.141.207.18) | |
| 17:48 | GodFather has joined IRC (GodFather!~rcc@174-081-217-069.dhcp.chtrptr.net) | |
| 18:08 | lucascastro has left IRC (lucascastro!~lucascast@200.141.207.18, Remote host closed the connection) | |
| 20:33 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving) | |
| 21:01 | <vagrantc> alkisg: well, no surprise, epoptes appears to be working quite nicely :)
| |
| 21:02 | alkisg: so i guess i just tag 1.0.0 ?
| |
| 21:02 | there's nothing to commit with the tag, either?
| |
| 21:13 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 21:28 | GodFather has left IRC (GodFather!~rcc@174-081-217-069.dhcp.chtrptr.net, Ping timeout: 245 seconds) | |
| 22:10 | <vagrantc> alkisg: i just noticed you have some commits in launchpad's epoptes master branch that are not on the github master branch ... was that an accident?
| |
| 22:11 | alkisg: well, those fixes didn't make it into 1.0.0, apparently :)
| |
| 22:11 | * vagrantc tagged 1.0.0 and uploaded to debian | |
| 22:13 | <vagrantc> alkisg: i've already got a minor packaging update, so a quick 1.0.1 wouldn't be a bad thing if we wanted to pull in your fixes. :)
| |
| 22:50 | adrianorg has left IRC (adrianorg!~adrianorg@177.18.103.213, Ping timeout: 245 seconds) | |
| 23:03 | namespac3 has left IRC (namespac3!~ksoze@69.31.187.145, Ping timeout: 268 seconds) | |
| 23:22 | adrianorg has joined IRC (adrianorg!~adrianorg@177.18.103.213) | |
| 23:30 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 252 seconds) | |