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


Channel log from 29 November 2019   (all times are UTC)

01:49Ark74 has left IRC (Ark74!~Luis@177.238.145.140, Remote host closed the connection)
02:10Ark74 has joined IRC (Ark74!~Luis@177.238.145.140)
02:14eu^nsg-static-01 has joined IRC (eu^nsg-static-01!b647e20a@182.71.226.10)
02:19eu^nsg-static-01 has left IRC (eu^nsg-static-01!b647e20a@182.71.226.10, Remote host closed the connection)
03:55Ark74 has left IRC (Ark74!~Luis@177.238.145.140, Remote host closed the connection)
04:26gdi2k_ has joined IRC (gdi2k_!~gdi2k@58.69.160.28)
04:34Ark74 has joined IRC (Ark74!~Luis@177.238.145.140)
04:46gdi2k_ has left IRC (gdi2k_!~gdi2k@58.69.160.28, Read error: Connection reset by peer)
06:03gdi2k has left IRC (gdi2k!~gdi2k@58.69.160.27, Read error: Connection reset by peer)
06:04gdi2k has joined IRC (gdi2k!~gdi2k@58.69.160.28)
07:10vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
07:32
<alkisg>
'morning vagrantc :)
07:33
https://qa.debian.org/excuses.php?package=ltsp doesn't mention ppc64el binaries anymore, but it does need that a manual unblock is needed
07:33
*does say
07:47
<vagrantc>
well, progress :)
07:47
<alkisg>
Do we need to "contact the d-i release manager" as it suggests?
07:47
<vagrantc>
yes, i can do that
07:48
<alkisg>
Great
07:48
<vagrantc>
which might get interesting, as we no longer ship a .udeb :)
07:48
<alkisg>
:D
07:48
<vagrantc>
might also need to pester ftp-masters...
07:49
which is great news, honestly ... the debian-installer integration was way out of date and i tired of the extra beurocracy to migrate to testing
07:49
<alkisg>
Yeah since we no longer favor chroots, that didn't make much sense to keep it around
07:50
<vagrantc>
yeah, i think it could be replaced by a debconf preseed with some shell calls
07:51
<alkisg>
Who is using that? I think debian-edu is trying to ship a minimal chroot with xfreerdp now, right?
07:51
<vagrantc>
debian-edu
07:51
dunno if anyone else is
07:51
<alkisg>
So if they're creating their own chroot, what we would be doing with the debconf preseed?
07:53
<vagrantc>
i was thinking of a documented install where it builds the "typical" ltsp chrootless build
07:54
<alkisg>
I haven't tried these parts of debian-installer so I'm missing some things. Is there an option in the debian install cd to install an ltsp server?
07:54
Or does that say "install a debian edu server"?
07:55
And if they select that menu, debian edu would build their minimal chroot, and we'd build a second chrootless image too?
07:59
<vagrantc>
debian-edu will do whatever debian-edu does ... i was thinking the ltsp-client-builder .udeb could be replaced by a little bit of documentation on the ltsp wiki
08:00
weather it's a chroot or chrootless or whatever
08:00
i think there's no menu option at the moment, just preseeded values.
08:01
for ltsp 5.x ... there's no such option for ltsp 19.x yet
08:01
<alkisg>
I guess what I'm asking is, "how do people actually use ltsp-client-builder.udeb?", and "what would that wiki page have, that would be different to the wiki installation page?"
08:01
They pass a preseed value that activates ltsp-client-builder and expect to have a chroot after installation?
08:02
And now we want to automate that somehow, without using an udeb?
08:04
<vagrantc>
yes, they pass a preseed value that activates ltsp-client-builder and it builds a chroot
08:04
basically just passing all the "apt install ltsp dnsmasq ... && ltsp ipxe && ltsp dnsmasq && ltsp ..." calls in a preseeding file should do the trick with chrootless
08:05
or we don't bother to document it and wait till someone needs it :)
08:05
and they can document it ... but i figured i'd try it sometime and document the process
08:06
<alkisg>
Does that phase run inside a /target chroot? I wonder if tmpfs/overlayfs handling will causing issues like it has with lxc...
08:06
<vagrantc>
making an ltsp chroot might take a bit more work
08:06
the chroot is a regular chroot and should have typical directories and permissions enabled
08:06
e.g. /proc /dev ..
08:07
<alkisg>
E.g. if the installer kernel is missing the overlay module, I'm not sure ltsp will be able to modprobe it
08:07
<vagrantc>
nor am i :)
08:08
this is all stuff i'd find out when i attempt it :)
08:08* alkisg thinks all this stuff would better belong in a post installation / first boot phase, like OEM setups work...
08:09
<vagrantc>
debian got rid of the first-boot phase ages ago
08:09
<alkisg>
But ok I guess people are used to it, no point in trying to change it
08:09
<vagrantc>
debian-installer
08:09
at this point, i'm mostly curious :)
08:09
<alkisg>
Sure
08:09
<vagrantc>
easier to test than speculate
08:10
although i'd like to try experimenting more with a live image installer, too ...
08:11
<alkisg>
My last two debian installations were done with the live installer
08:11
I do remember the last "non-live" installer producing a much smaller installation though
08:21
<vagrantc>
does the code handle fine if sshfs is missing out-of-the-box ?
08:22
<alkisg>
I think so; it then assumes NFS or local home is used
08:23
<vagrantc>
ok, the recommends is appropriate
08:23
although if they don't have NFS or local home?
08:23
there's a little bit of "you get to pick up the pieces" if recommends aren't isntalled, so i guess that's ok
08:24
<alkisg>
If there's a bug there, we can surely handle it
08:24
I think it would try to login with SSH, and then it would use /home/username in overlayfs
08:24
<vagrantc>
i guess it'd just have the homedir in the tmpfs overlay, effectively?
08:24
<alkisg>
Or maybe if NFS isn't set, it'll try with sshfs and fail with "not found"
08:25
Not sure, but whatever bugs are there, we can surely work them out with a couple of simple ifs
08:26
<vagrantc>
alkisg: so, everything you push to master is stuff you feel is "ready" for a release? should i get ready to release 19.12 sometime? or wait for 20.01 or 20.08? :)
08:26
i get the vague impression there are some issues with 19.11 that are fixed in master?
08:28
<alkisg>
vagrantc: yes I'm trying to keep master release-ready, mainly for 20.04, as for bullseye I'll have a lot of time later on and I think will get a fancier ltsp on time
08:28
There are indeed some fixes in master that are not there in 19.11
08:29
I definitely want an 20.x release for Ubuntu 20.04, as some people tried to make a new name out of ltsp19, so I don't want it to have 19 in the name
08:29
Now for ltsp 19.12, if you don't mind an additional release, sure, it should be releasable as it is now
08:29
<vagrantc>
make a new name?
08:30
<alkisg>
Yeah they even tried to make an ubuntultsp wiki namespace for ltsp19
08:30
https://help.ubuntu.com/community/UbuntuLTSP/LTSP19
08:30
<vagrantc>
won't be able to test till mid-december at the earliest ... but might have time before the end of the year
08:30
<alkisg>
I had to delete it :D
08:31
<vagrantc>
i guess before too long we'll just call it "ltsp" again
08:31
<alkisg>
I think it'd be easier for you if I did an 19.12 release and you just uploaded it to debian, if you want that
08:31
<vagrantc>
if you think it's worth it, sure
08:31
<alkisg>
OK; but maybe we need to wait for the testing migration issues to get resolved first
08:32
<vagrantc>
i just noticed you trying to limit your time commitment a bit and hoped i could take on some of it :)
08:32
yeah, definitely hope to get it to land in bullseye/testing before another upload ... guess i'm optimistic that will happen in under two weeks :)
08:32
<alkisg>
Thanks! Mostly I wanted to avoid the big flood of new features, we'd end up with an unstable ltsp due to my lack of time to properly review them
08:33
They send code that runs fine for their use case, but fails in 2-3 other cases, and I don't have time to test/correct it, thus we started a "staging" branch
08:33
<vagrantc>
and ideally, once it migrates to bullseye, future uploads will be less red tape :)
08:34
<alkisg>
vagrantc: I was thinking to maintain a testing VM, to be able to test things like the fuse3 issue that Mike reported
08:34
<vagrantc>
a little nervous how the staging stuff will go, but really glad to see a lot of new motivated contributors :)
08:34
<alkisg>
Testing is runnable in VMs, right?
08:34
<vagrantc>
don't want to see a bunch of unmergeable forks that people come to depend on
08:34
<alkisg>
I don't worry much about it
08:34
<vagrantc>
alkisg: debian testing? should be, sure.
08:34
<alkisg>
As I'll merge most of these forks next year
08:35
Nice, will do
08:35
<vagrantc>
yeah, if the forks only last under a year, no real problem and it's kind of how things are supposed to work :)
08:35
<alkisg>
It's just about this specific year that I'm trying to finish my phd
08:35
<vagrantc>
alkisg: if it's not runnable, i'm sure Debian would like to know :)
08:36
<alkisg>
After that I don't expect to have heavy time commitments outside of ltsp, so reviewing new features should be fine
08:36eu^8024982116 has joined IRC (eu^8024982116!50f95274@80.249.82.116)
08:36
<vagrantc>
but i think there's even automated debian-installer testing and various other testing done in virtual machines
08:36
<alkisg>
Nice
08:37
<vagrantc>
virtual machines get a lot more testing than real hardware, generally :)
08:37eu^8024982116 has left IRC (eu^8024982116!50f95274@80.249.82.116, Remote host closed the connection)
08:38
<alkisg>
Sure I mainly meant about the general stability of testing, not regarding the hardware/vm. E.g. I think that unstable breaks too often, and I wouldn't have time to solve/report all the bugs involved...
08:38
<vagrantc>
yeah, i usually test against debian's testing branch
08:47kjackal has joined IRC (kjackal!~quassel@2a02:587:3107:2e00:ad30:a95a:eb70:ed15)
09:52statler_ has joined IRC (statler_!~Georg@gwrz.lohn24.de)
11:21vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
11:53Faith has joined IRC (Faith!~Paty_@2001:12d0:2080::231:49)
12:06section1 has joined IRC (section1!~section1@178.33.109.106)
12:22adrianor1 has joined IRC (adrianor1!~adrianorg@177.156.229.19)
12:26adrianorg has left IRC (adrianorg!~adrianorg@177.156.61.76, Ping timeout: 268 seconds)
14:15spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut)
16:00kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:ad30:a95a:eb70:ed15, Ping timeout: 246 seconds)
16:06statler_ has left IRC (statler_!~Georg@gwrz.lohn24.de, Remote host closed the connection)
16:19kjackal has joined IRC (kjackal!~quassel@2a02:587:3107:2e00:146d:6f4f:2370:50e8)
16:24vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
17:12
<alkisg>
vagrantc: https://github.com/ltsp/ltsp/issues/99 solves https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945521, so it's a good reason for a 19.12 release in a few days :)
17:12
At which point do we delete old debian bugs, like e.g. ldm ones?
17:12
When buster goes oldoldstable?
17:14
<vagrantc>
they'll get closed when it gets removed from debian unstable ... which i was planning on changing the orphan bug to a removal bug sometime soon
17:14
maybe end-of-year?
17:14
<alkisg>
Great
17:21Nikoh77 has joined IRC (Nikoh77!~Nikoh77@79.9.135.148)
17:21kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:146d:6f4f:2370:50e8, Ping timeout: 276 seconds)
18:02Nikoh77 has left IRC (Nikoh77!~Nikoh77@79.9.135.148, Remote host closed the connection)
18:17vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
19:01kjackal has joined IRC (kjackal!~quassel@2a02:587:3107:2e00:146d:6f4f:2370:50e8)
19:48section1 has left IRC (section1!~section1@178.33.109.106, Remote host closed the connection)
20:41Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
21:44GodFather has left IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com, Ping timeout: 265 seconds)
22:18kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:146d:6f4f:2370:50e8, Ping timeout: 276 seconds)
23:32shored has left IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi, Read error: Connection reset by peer)
23:33shored has joined IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi)