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


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

00:02map7_ has joined IRC (map7_!~map7@ppp59-167-194-79.static.internode.on.net)
00:20bennabiy has left IRC (bennabiy!~bennabiy@unaffiliated/bennabiy, Remote host closed the connection)
00:42map7_ has left IRC (map7_!~map7@ppp59-167-194-79.static.internode.on.net, Quit: Leaving)
00:46telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
00:48telex has joined IRC (telex!teletype@freeshell.de)
01:30n0ps has left IRC (n0ps!3aa5e1dd@gateway/web/freenode/ip.58.165.225.221, Quit: Page closed)
01:44
<roasted>
muppis: yeah - that's why we just went the straight ubuntu install with puppet. Works out well. I just miss LTSP, what can I say. :P
02:02freedomrun has left IRC (freedomrun!~quassel@unaffiliated/freedomrun, Read error: Connection reset by peer)
03:19AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-owpzhwriyfxjckht, Quit: Connection closed for inactivity)
04:36FGXR6 has joined IRC (FGXR6!~phantom@ppp121-44-250-198.lns20.syd7.internode.on.net)
04:37F-GT has left IRC (F-GT!~phantom@ppp121-44-225-191.lns20.syd7.internode.on.net, Ping timeout: 264 seconds)
04:51vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
04:51
<vagrantc>
arg!
04:52
the kernel version sorting in ltsp 5.5.4 is borked in Debian :(
04:52
went to test what i needed to fix for the 486 -> 586 switch, and it's all kinds of borked.
04:53andygraybeal has joined IRC (andygraybeal!~andy@h211.204.213.151.dynamic.ip.windstream.net)
05:07NeonLicht has left IRC (NeonLicht!~NeonLicht@darwin.ugr.es, Ping timeout: 265 seconds)
05:14
<vagrantc>
well, figured out a one-line that's using the debian-specific linux-version tool...
05:14
at least, i think i've got it...
05:23
work_alkisg: definitely struggling with the kernel sorting code again...
05:23
linux-versions isn't 32/pae/64 aware, of course...
06:27adrianorg has left IRC (adrianorg!~adrianorg@179.179.72.236, Ping timeout: 240 seconds)
06:30adrianorg has joined IRC (adrianorg!~adrianorg@179.179.72.236)
06:30elias_a has joined IRC (elias_a!elias@hilla.kapsi.fi)
06:37zamba has left IRC (zamba!marius@flage.org, *.net *.split)
06:37elias_a_ has left IRC (elias_a_!elias@hilla.kapsi.fi, *.net *.split)
06:39zamba has joined IRC (zamba!marius@flage.org)
07:34mealstrom has joined IRC (mealstrom!~Thunderbi@46.63.63.163)
07:43mealstrom has left IRC (mealstrom!~Thunderbi@46.63.63.163, Ping timeout: 264 seconds)
08:15mealstrom has joined IRC (mealstrom!~Thunderbi@46.63.6.76)
08:23ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz)
08:30freedomrun has joined IRC (freedomrun!~quassel@unaffiliated/freedomrun)
08:36work_alkisg is now known as alkisg
08:36* alkisg waves to vagrantc
08:36* vagrantc waves
08:36
<alkisg>
What's the new kernel name like?
08:37
<vagrantc>
well, i was thinking about upgrades, and it turns out the old ones always showed up first
08:37
so i tested with a full set of real-world package names ...
08:38
<alkisg>
We want to sort like this: "least capable cpu, newer kernel version" > "least capable cpu, older kernel version" > "most capable cpu, newer kernel version" > "most capable cpu, older kernel version"
08:38
<vagrantc>
3.2.0-4-486, 3.16-4-486, 3.16.0-4-586, 3.16-0.bpo.3-486, 3.17-1-486, 3.17.0-trunk-586
08:38
<alkisg>
And it happened so that natural sorting was good enough at the time we wrote it
08:39
<vagrantc>
alkisg: well, it got rewritten significantly since wheezy
08:39
the version in wheezy is *more* reliable, but still has issues
08:39
<alkisg>
Wait, the last code is the one with the sed line, isn't it?
08:39
That separates the kernel name, version etc?
08:40
<vagrantc>
yeah, and the separate functions for kernel_split, kernel_versions, kernel_variants ?
08:40
if it split the upstream version from the abi, it might be possible to make more reliable.
08:41
<alkisg>
# A sed expression that matches all kernels and returns $FILE $NAME $VERSION $FLAVOR
08:41
# Example: ls /boot | sed -n "$KERNEL_NAMES" | sort -V -k 4,4 | sort -r -k 3,3
08:41
KERNEL_NAMES='s/\(vmlinu[xz]-\)\([^-]*-[^-]*-\)\(.*\)/& \1 \2 \3/p'
08:41
So, what do we want in the examples you pasted above?
08:42
To sort 486 first, and 586 last?
08:42
<vagrantc>
well, strictly speaking, 586 is just a more accurate name in debian... it hasn't supported genuine 486s for quite some time
08:43
what i don't want is on upgrade to jessie, you find you're still running the wheezy kernel
08:43
i also think between wheezy and jessie the sorting rules got flip-flopped ... it seems to consistantly put the oldest kernel first, no matter what
08:43
<alkisg>
But can you say that in a form of a rule?
08:44
<vagrantc>
gah, i shut down the machine i was testing on ...
08:44
<alkisg>
Otherwise, we'd need a function with special cases depending on the specific names, and when those change, to update the function ...
08:45
Is there a use case where someone upgrading from wheezy => jessie would need to keep the 486 kernel?
08:45
Maybe it should be solved with a Conflicts/Replaces somewhere?
08:45
<vagrantc>
i think in theory, adding 586 to the KERNEL_LIST_32 would be fine ... except the overall sorting function is borked
08:45
no, conflicts is a bad idea.
08:46
<alkisg>
Let's phrase the function first, and check it after that
08:47
What I proposed and thought that I implemented, was: "sort FLAVOR in an increasing order, and VERSION in decreasing"
08:47
<vagrantc>
https://paste.debian.net/134159/
08:47
<alkisg>
I.e. that a random client would boot with 486 if you had both 486 and 586 installed
08:49
<vagrantc>
the logic has gotten messy with the evolution of these names...
08:50
<alkisg>
If I install jessie and then install 486, then that's still what I want
08:50
The logic didn't cover "left over kernels"
08:50
<vagrantc>
here's the one that messes with my mind:
08:50
https://paste.debian.net/134160/
08:51
<alkisg>
vagrantc: give me a paste of ls /boot to test with
08:51
The sorting there in your paste is wrong though
08:51
It's not decreasing within the same flavor
08:52
<vagrantc>
https://paste.debian.net/134162/
08:52
<alkisg>
ty
08:53
<vagrantc>
thanks for taking a look at it ... i keep thinking i understand this bit of code, and then my head starts spinning again
08:55
<alkisg>
The 2 sorts at the end seem broken, they don't work like they're supposed to
08:55
sed -n 's/\(vmlinu[xz]-\)\([^-]*-[^-]*-\)\(.*\)/& \1 \2 \3/p' | sort -V -k 4,4 ==> sorts OK with flavor
08:56
Ah, sort -r should be numeric, -rn or somethin
08:56
g
08:56
<vagrantc>
i think the following sort breaks it
08:56
i.e. the first sort sorts one way, but then scrambles the previous sort
08:58
ls /opt/ltsp/i386/boot/ | sed -n 's/\(vmlinu[xz]-\)\([^-]*-[^-]*-\)\(.*\)/& \1 \2 \3/p' | sort -V -k 4,4 -k 3,3
08:58
that seems better
08:58
<alkisg>
It needs -r
08:59
"sort FLAVOR in an increasing order, and VERSION in decreasing"
09:00
<vagrantc>
but i think calling two sorts undoes the second sort entirely
09:00
<alkisg>
Well, we could temporarily merge $FLAVOR$VERSION in order to do it, but let's see if `sort` can do it without that trick...
09:01
I thought that sort didn't change the order of the lines that had the same value in "key"
09:07
<vagrantc>
KERNEL_LIST_32="586 486 686" ... maybe that's what i'll want on upgrade ...
09:07
686 is ancient legacy
09:09
<alkisg>
vagrantc: sed -n 's/\(vmlinu[xz]-\)\([^-]*-[^-]*-\)\(.*\)/& \1 \2 \3/p' | sort -k 4,4V -k 3,3rV
09:09
That was what I intented to do, sorry for the bug
09:09
But now with 586 you're saying it doesn't fit anymore
09:10
<vagrantc>
won't that be fixed with KERNEL_LIST_32 ?
09:11
is that sorting only working because 486 < 586 < 686-pae ?
09:11
< amd64
09:12
<alkisg>
Yes
09:13
<vagrantc>
it's certainly better than what we've got, but will fail with 3.2.0-4-486 and 3.16.0-4-586 on upgrade...
09:14
<alkisg>
I don't consider that a failure
09:15
If I install jessie with 586 and after that install 486, don't I end up in the same use case, but prefer 486 there?
09:15
The logic is "I prefer my clients to have the oldest flavor that I currenty have installed" - it doesn't check about how they got installed
09:16
Is 486 available in jessie?
09:16
Or completely gone?
09:16
<vagrantc>
alkisg: but if you upgrade a chroot, that won't remove the kernel.
09:16
<alkisg>
That's a problem with the upgrade, not with our logic
09:17
When I upgrade from 12.04 to 14.04 I still have the 3.2 kernel
09:17
<vagrantc>
or even without a chroot
09:17
<alkisg>
...and xorg doesn't work there
09:17
But ltsp would correctly prefer the 3.2 kernel for the clients
09:17
It's still a problem with the upgrade, it should have removed the older kernel
09:18
<vagrantc>
well, other boot loaders just boot the highest available kernel
09:18
and leaving the old kernels around is a non-issue
09:18
granted, we have a more complicated use-case...
09:19
i guess i'm second guessing the logic of preferring an older kernel in any case
09:19
<alkisg>
Not older kernel, older flavor
09:20
sed -n 's/\(vmlinu[xz]-\)\([^-]*-[^-]*-\)\(.*\)/& \1 \2 \3/p' | sort -k 4,4rV -k 3,3rV
09:20
That would sort both flavor and version in decreasing order
09:21
...but my clients wouldn't boot with amd64 first
09:21* vagrantc installs a few more kernels for comparison
09:22
<alkisg>
Btw, ubuntu doesn't have a non-pae kernel currently
09:22
(after 12.04.1)
09:22
<vagrantc>
so using "sort -k 4,4V -k 3,3rV" resulted in the correct "default" of 3.17.0-trunk-586 ... but then also selected that for pae and 64-bit
09:23
yeah, so thanks for drudging through a debian-specific featre :)
09:23
<alkisg>
And the package name is the same, "generic", in both 32 and 64 bit
09:24
So the ifcpu64 detection code would have to be very smart to work correctly
09:24
"I see an ubuntu chroot... and it has 3.12 generic.. let me check `$CHROOT dpkg --print-architecture` to decide if it's 32 or 64 bit..." :P
09:25
vagrantc: so, an idea for the future, is to create symlinks for each variant like we do now, e.g. vmlinuz-pae, vmlinuz-486 etc,
09:25
<vagrantc>
yeah
09:25
<alkisg>
and when someone wants ifcpu64, he can do it himself using the symlinks
09:25
I.e. to strip all our ifcpu64 code
09:26
<vagrantc>
hrm. now it always picks the amd64 variant for everything
09:26
<alkisg>
vagrantc: forget the code, let's first agree on what we want
09:27
I'm still voting for "sort FLAVOR in an increasing order, and VERSION in decreasing", but I can find workaround if you want something else, like "always decreasing"
09:28
<vagrantc>
i have a hard time abstracting this
09:29
the flavor increasing order is essentially by luck with the current set of known kernel names?
09:29
<alkisg>
Currently the only case where I need multiple kernels is when someone has non-pae client, there he installs a kernel from debian, either -486 or now maybe -586, that should be preferred over ubuntu's "generic"
09:29
well, 386<486<586 etc isn't completely luck
09:29
But 586 < amd64 is luck, yeah
09:30
<vagrantc>
and this is x86 specific code, sure.
09:30
<alkisg>
arm32 < arm64
09:30
<vagrantc>
though if the -k6 or -k7 variants ever come back, or something liek that
09:30
<alkisg>
It might get lucky on other cases too
09:30
<vagrantc>
armmp > arm64
09:30
<alkisg>
What is armmp?
09:30
<vagrantc>
the other arches aren't really sortable without knowing the sort order
09:31
<alkisg>
multiprosessor/
09:31
?
09:31
<vagrantc>
yeah
09:31
er, multiplatform
09:31
for armhf, 32-bit
09:31
<alkisg>
...doesn't 64 bit also get multiplatform?
09:31
<vagrantc>
in armhf on debian, there are only two kernels, armmp and armmp-lpae
09:31
and in arm64 so far there's only arm64
09:32
<alkisg>
No need to compare between kernels that will never refer to the same image
09:32
But anyway, what's the alternative for a default sort? Always decreasing?
09:32
<vagrantc>
(and arm64-dbg)
09:33
<alkisg>
I don't think "always decreasing" has a clear benefit either, it's even worse
09:33
<vagrantc>
sure
09:33
<alkisg>
A distro can always special-case whatever it needs, we're only talking about the default here
09:34
But e.g. hardcoding 586 in ubuntu doesn't make sense...
09:34
<vagrantc>
so yeah, overall your assertion holds reasonably well. it's a bit awkward for upgrades.
09:34
i guess which gets sorted first also matters
09:35
e.g. sorting so that VERSION always appears first, and flavor as a secondary consideration... as long as you can refine it based on preferred flavors.
09:36
basically, i want to be able to say "give me the newest kernel that matches flavors x, y, z"
09:36
<alkisg>
Where would you say that?
09:36
In update-kernels.conf?
09:36
And, how would you update update-kernels.conf when needed?
09:36
<vagrantc>
in the code
09:36
<alkisg>
OK, so instead of having a postinst that takes care of upgrades, you'd have "if wheezy... else if jessie..." inside the code
09:37
<vagrantc>
ugh. irc-question-response disarray.
09:37
<alkisg>
If I step back for a moment and look at the big picture there, that sounds broken
09:37
<vagrantc>
i don't say anything like that at all.
09:37
the current code has lists of flavors for certain categories (32, pae, 64)
09:38
so i'd like to be able to get the list of newest kernels that meet the 32-bit criteria
09:38
<alkisg>
(11:38:08 πμ) vagrantc: the current code has lists of flavors for certain categories (32, pae, 64) ==> in update-kernels.conf, right?
09:38
LIST_KERNELS_32="486 586 686"
09:38
<vagrantc>
right
09:39
<alkisg>
(11:36:37 πμ) alkisg: In update-kernels.conf?
09:39
(11:36:46 πμ) alkisg: And, how would you update update-kernels.conf when needed?
09:39
<vagrantc>
i'm torn between trying to describe what i want without referring to the code ...
09:39
<alkisg>
So, suppose you do a conffile update in jessie
09:39
And remove 486 from there
09:39
Is that ok with you then/
09:39
<vagrantc>
alkisg: same way we do now ... ship a new default update-kernels.conf in the package, and users may edit them
09:40
i don't see removing it as valid, necessarily
09:40
<alkisg>
Or "586 486 686"
09:40
<vagrantc>
right, that seems more the right direction
09:41
<alkisg>
I do think that conffiles are the correct way to handle distro-specific names
09:41
But unfortunately I don't think we use LIST_KERNELS_32 as you want it now
09:41
<vagrantc>
it used to work the way i want it to
09:42
the code in wheezy works for that, with my quick tests
09:42
<alkisg>
But that logic doesn't apply anymore to distros like ubuntu
09:42
That's why it was changed
09:42
So we still need to find another logic. Yet another time :)
09:42
We can't use 32/pae/64 logic in ubuntu anymore, it doesn't apply
09:43
Let me describe an idea...
09:43* vagrantc just needs to fix a lingering RC bug in ltsp in jessie, which leaves the user at an ancient kernel on upgrade
09:44
<alkisg>
We already create symlinks with the latest version of every flavor
09:44
We can write those (the symlinks) in default/ltsp in increasing order
09:45
and generate a submenu there in default/ltsp with specific versions of them, sorted in "FLAVOR in an increasing order, and VERSION in decreasing"
09:46
The new idea here is that we'll also support a LIST_FLAVORS="" variable,
09:46
which can be used to override the default "FLAVOR in increasing order", and possibly limit the FLAVORS shown
09:47
That's the smallest diff that I can think of to do what you're asking...
09:48
<vagrantc>
i don't see how it even does what i'm asking
09:48
<alkisg>
LIST_FLAVORS="586 486 686"
09:48
<vagrantc>
ah, got it
09:49
my head is still fuzzy thinking this over.
09:49
for some reason i always find this overwhelming, which is why i'm staring down another release cycle having not really fixed it yet
09:53
the recent switch of 486 to 586 made me think i'd need to look at it ... didn't realize what exactly that meant
10:02
i think i can just add an entry for 32 bit, pae, 64 bit by default, and not add the entry if no kernel matches...
10:03
and have 32 bit at the top
10:03
i think that's simpler than what i've been trying to do...
10:05
but that still doesn't solve the issue for arm ...
10:08
i'll have to give this a go tomorrow when i've had some rest
10:09
oh-ho!
10:10
i had some linger linux-version calls in my code that might have ben mesing this up...
10:15
<alkisg>
back
10:22
<vagrantc>
alkisg: well, i'm not much more use on this issue at the moment ... thanks for putting some effort into it!
10:22* vagrantc sleeps
10:23
<alkisg>
Good night :)
10:25vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
10:27khildin has joined IRC (khildin!~khildin@ip-213-49-116-173.dsl.scarlet.be)
10:30alkisg is now known as work_alkisg
10:41andygraybeal has left IRC (andygraybeal!~andy@h211.204.213.151.dynamic.ip.windstream.net, Ping timeout: 255 seconds)
11:06AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-ukrvsdjrrmlatwsc)
11:53adrianorg has left IRC (adrianorg!~adrianorg@179.179.72.236, Ping timeout: 240 seconds)
11:55adrianorg has joined IRC (adrianorg!~adrianorg@177.204.159.248.dynamic.adsl.gvt.net.br)
13:21khildin has left IRC (khildin!~khildin@ip-213-49-116-173.dsl.scarlet.be, Quit: I'm gone, bye bye)
13:23david007co has joined IRC (david007co!~androirc@190.26.48.102)
13:47telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
13:48telex has joined IRC (telex!teletype@freeshell.de)
14:50david007co2 has joined IRC (david007co2!~androirc@190.24.160.36)
14:54david007co has left IRC (david007co!~androirc@190.26.48.102, Ping timeout: 250 seconds)
15:10mealstrom has left IRC (mealstrom!~Thunderbi@46.63.6.76, Ping timeout: 264 seconds)
15:16
<david007co2>
Is it always necessary to have a Linux server in order to pxe clients that run windows via rdp(ts)?
15:17
And 1 pc that provides users to the clients. .
15:21
(Being that one the "server")
15:51mealstrom has joined IRC (mealstrom!~Thunderbi@46.63.63.163)
15:57mealstrom has left IRC (mealstrom!~Thunderbi@46.63.63.163, Read error: No route to host)
16:02mealstrom has joined IRC (mealstrom!~Thunderbi@46.63.63.163)
16:18david007co2 has left IRC (david007co2!~androirc@190.24.160.36, Ping timeout: 240 seconds)
16:35david007co2 has joined IRC (david007co2!~androirc@190.26.48.102)
16:56david007co2 has left IRC (david007co2!~androirc@190.26.48.102, Ping timeout: 250 seconds)
16:58adrianorg has left IRC (adrianorg!~adrianorg@177.204.159.248.dynamic.adsl.gvt.net.br, Quit: leaving)
17:01david007co2 has joined IRC (david007co2!~androirc@190.24.160.36)
17:09Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net)
17:12vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
17:15
<vagrantc>
work_alkisg: i think i've got code that's good enough now
17:15
work_alkisg: but it may not work the way you want it
17:17
http://paste.debian.net/134205/
17:18
essentially, it returns the listed kernels for the preferred variants first
17:18
the risk is if you have a newer version PAE or 64-bit kernel, you'll still be stuck with a 586 kernel
17:19
stuck with an older 586 kernel
17:20
hrm. seems to have some unintended consequences, though
17:21
it seems to be producing fewer pxelinux.cfg/ files
17:30david007co2 has left IRC (david007co2!~androirc@190.24.160.36, Ping timeout: 256 seconds)
17:39
<vagrantc>
eesh. globbing
17:56
so i think passing LIST_KERNELS="foo bar *" kernel_versions has been broken for some time, as * gets expanded
17:57david007co2 has joined IRC (david007co2!~androirc@186.85.184.182)
18:19Grembler has left IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net, Quit: I Leave)
18:19ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat)
18:48adrianorg has joined IRC (adrianorg!~adrianorg@177.204.159.248.dynamic.adsl.gvt.net.br)
18:58
<vagrantc>
work_alkisg: ok, i think i have it working, have a moment to review?
18:58david007co2 has left IRC (david007co2!~androirc@186.85.184.182, Ping timeout: 245 seconds)
19:05
<vagrantc>
work_alkisg: http://paste.debian.net/134224/
19:05
then i just need to set LIST_KERNELS_32="586 486 686" and it works at least on upgrades to jessie.
19:10
erm. i should've looked that you already committed some code... gah.
19:12
at, rebased fine...
19:19* vagrantc pushes
19:23david007co2 has joined IRC (david007co2!~androirc@190.26.48.102)
21:28mealstrom1 has joined IRC (mealstrom1!~Thunderbi@46.63.63.163)
21:30mealstrom has left IRC (mealstrom!~Thunderbi@46.63.63.163, Ping timeout: 256 seconds)
21:50david007co2 has left IRC (david007co2!~androirc@190.26.48.102, Ping timeout: 272 seconds)
22:20mealstrom1 has left IRC (mealstrom1!~Thunderbi@46.63.63.163, Ping timeout: 255 seconds)
22:21mealstrom has joined IRC (mealstrom!~Thunderbi@46.63.63.163)
22:30freedomrun has left IRC (freedomrun!~quassel@unaffiliated/freedomrun, Read error: Connection reset by peer)
22:30freedomrun has joined IRC (freedomrun!~quassel@unaffiliated/freedomrun)
22:44mealstrom has left IRC (mealstrom!~Thunderbi@46.63.63.163, Ping timeout: 258 seconds)
22:49effenberg has left IRC (effenberg!~chlu@ec2-46-51-181-111.eu-west-1.compute.amazonaws.com, Ping timeout: 240 seconds)
22:52telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
22:54telex has joined IRC (telex!teletype@freeshell.de)
22:55david007co2 has joined IRC (david007co2!~androirc@186.85.184.182)