IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 29 November 2014 (all times are UTC)
| 00:02 | map7_ has joined IRC (map7_!~map7@ppp59-167-194-79.static.internode.on.net) | |
| 00:20 | bennabiy has left IRC (bennabiy!~bennabiy@unaffiliated/bennabiy, Remote host closed the connection) | |
| 00:42 | map7_ has left IRC (map7_!~map7@ppp59-167-194-79.static.internode.on.net, Quit: Leaving) | |
| 00:46 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 00:48 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 01:30 | n0ps 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:02 | freedomrun has left IRC (freedomrun!~quassel@unaffiliated/freedomrun, Read error: Connection reset by peer) | |
| 03:19 | AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-owpzhwriyfxjckht, Quit: Connection closed for inactivity) | |
| 04:36 | FGXR6 has joined IRC (FGXR6!~phantom@ppp121-44-250-198.lns20.syd7.internode.on.net) | |
| 04:37 | F-GT has left IRC (F-GT!~phantom@ppp121-44-225-191.lns20.syd7.internode.on.net, Ping timeout: 264 seconds) | |
| 04:51 | vagrantc 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:53 | andygraybeal has joined IRC (andygraybeal!~andy@h211.204.213.151.dynamic.ip.windstream.net) | |
| 05:07 | NeonLicht 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:27 | adrianorg has left IRC (adrianorg!~adrianorg@179.179.72.236, Ping timeout: 240 seconds) | |
| 06:30 | adrianorg has joined IRC (adrianorg!~adrianorg@179.179.72.236) | |
| 06:30 | elias_a has joined IRC (elias_a!elias@hilla.kapsi.fi) | |
| 06:37 | zamba has left IRC (zamba!marius@flage.org, *.net *.split) | |
| 06:37 | elias_a_ has left IRC (elias_a_!elias@hilla.kapsi.fi, *.net *.split) | |
| 06:39 | zamba has joined IRC (zamba!marius@flage.org) | |
| 07:34 | mealstrom has joined IRC (mealstrom!~Thunderbi@46.63.63.163) | |
| 07:43 | mealstrom has left IRC (mealstrom!~Thunderbi@46.63.63.163, Ping timeout: 264 seconds) | |
| 08:15 | mealstrom has joined IRC (mealstrom!~Thunderbi@46.63.6.76) | |
| 08:23 | ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz) | |
| 08:30 | freedomrun has joined IRC (freedomrun!~quassel@unaffiliated/freedomrun) | |
| 08:36 | work_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:25 | vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving) | |
| 10:27 | khildin has joined IRC (khildin!~khildin@ip-213-49-116-173.dsl.scarlet.be) | |
| 10:30 | alkisg is now known as work_alkisg | |
| 10:41 | andygraybeal has left IRC (andygraybeal!~andy@h211.204.213.151.dynamic.ip.windstream.net, Ping timeout: 255 seconds) | |
| 11:06 | AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-ukrvsdjrrmlatwsc) | |
| 11:53 | adrianorg has left IRC (adrianorg!~adrianorg@179.179.72.236, Ping timeout: 240 seconds) | |
| 11:55 | adrianorg has joined IRC (adrianorg!~adrianorg@177.204.159.248.dynamic.adsl.gvt.net.br) | |
| 13:21 | khildin has left IRC (khildin!~khildin@ip-213-49-116-173.dsl.scarlet.be, Quit: I'm gone, bye bye) | |
| 13:23 | david007co has joined IRC (david007co!~androirc@190.26.48.102) | |
| 13:47 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 13:48 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 14:50 | david007co2 has joined IRC (david007co2!~androirc@190.24.160.36) | |
| 14:54 | david007co has left IRC (david007co!~androirc@190.26.48.102, Ping timeout: 250 seconds) | |
| 15:10 | mealstrom 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:51 | mealstrom has joined IRC (mealstrom!~Thunderbi@46.63.63.163) | |
| 15:57 | mealstrom has left IRC (mealstrom!~Thunderbi@46.63.63.163, Read error: No route to host) | |
| 16:02 | mealstrom has joined IRC (mealstrom!~Thunderbi@46.63.63.163) | |
| 16:18 | david007co2 has left IRC (david007co2!~androirc@190.24.160.36, Ping timeout: 240 seconds) | |
| 16:35 | david007co2 has joined IRC (david007co2!~androirc@190.26.48.102) | |
| 16:56 | david007co2 has left IRC (david007co2!~androirc@190.26.48.102, Ping timeout: 250 seconds) | |
| 16:58 | adrianorg has left IRC (adrianorg!~adrianorg@177.204.159.248.dynamic.adsl.gvt.net.br, Quit: leaving) | |
| 17:01 | david007co2 has joined IRC (david007co2!~androirc@190.24.160.36) | |
| 17:09 | Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net) | |
| 17:12 | vagrantc 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:30 | david007co2 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:57 | david007co2 has joined IRC (david007co2!~androirc@186.85.184.182) | |
| 18:19 | Grembler has left IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net, Quit: I Leave) | |
| 18:19 | ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat) | |
| 18:48 | adrianorg 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:58 | david007co2 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:23 | david007co2 has joined IRC (david007co2!~androirc@190.26.48.102) | |
| 21:28 | mealstrom1 has joined IRC (mealstrom1!~Thunderbi@46.63.63.163) | |
| 21:30 | mealstrom has left IRC (mealstrom!~Thunderbi@46.63.63.163, Ping timeout: 256 seconds) | |
| 21:50 | david007co2 has left IRC (david007co2!~androirc@190.26.48.102, Ping timeout: 272 seconds) | |
| 22:20 | mealstrom1 has left IRC (mealstrom1!~Thunderbi@46.63.63.163, Ping timeout: 255 seconds) | |
| 22:21 | mealstrom has joined IRC (mealstrom!~Thunderbi@46.63.63.163) | |
| 22:30 | freedomrun has left IRC (freedomrun!~quassel@unaffiliated/freedomrun, Read error: Connection reset by peer) | |
| 22:30 | freedomrun has joined IRC (freedomrun!~quassel@unaffiliated/freedomrun) | |
| 22:44 | mealstrom has left IRC (mealstrom!~Thunderbi@46.63.63.163, Ping timeout: 258 seconds) | |
| 22:49 | effenberg has left IRC (effenberg!~chlu@ec2-46-51-181-111.eu-west-1.compute.amazonaws.com, Ping timeout: 240 seconds) | |
| 22:52 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 22:54 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 22:55 | david007co2 has joined IRC (david007co2!~androirc@186.85.184.182) | |