IRC chat logs for #ltsp on irc.freenode.net (webchat)

Request log from specific day:

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)