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


Channel log from 18 September 2018   (all times are UTC)

02:03adrianor1 is now known as adrianorg
05:02lucascastro has left IRC (lucascastro!~lucascast@177-185-139-186.isotelco.net.br, Remote host closed the connection)
05:55ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
09:37GodFather has left IRC (GodFather!~rcc@174-081-217-069.dhcp.chtrptr.net, Ping timeout: 272 seconds)
11:57GodFather has joined IRC (GodFather!~rcc@2603:3015:3507:1600:4585:3483:e3e7:f2cd)
11:59Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
12:04GodFather has left IRC (GodFather!~rcc@2603:3015:3507:1600:4585:3483:e3e7:f2cd, Ping timeout: 250 seconds)
12:20GodFather has joined IRC (GodFather!~rcc@2603:3015:3507:1600:4585:3483:e3e7:f2cd)
12:50GodFather has left IRC (GodFather!~rcc@2603:3015:3507:1600:4585:3483:e3e7:f2cd, Ping timeout: 252 seconds)
13:23GodFather has joined IRC (GodFather!~rcc@2603:3015:3507:1600:4585:3483:e3e7:f2cd)
14:06vagrantc 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:12lucascastro 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:23GodFather 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:45sutula 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:55Helenah 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:28Helenah has joined IRC (Helenah!~s98259@unaffiliated/iveeee)
17:09lucascastro has left IRC (lucascastro!~lucascast@177-185-139-186.isotelco.net.br, Remote host closed the connection)
17:31lucascastro has joined IRC (lucascastro!~lucascast@200.141.207.18)
17:48GodFather has joined IRC (GodFather!~rcc@174-081-217-069.dhcp.chtrptr.net)
18:08lucascastro has left IRC (lucascastro!~lucascast@200.141.207.18, Remote host closed the connection)
20:33Faith 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:13ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
21:28GodFather has left IRC (GodFather!~rcc@174-081-217-069.dhcp.chtrptr.net, Ping timeout: 245 seconds)