[00:16] <infinity> phillw: A 486 kernel would do you no good, our userspace targets 686.
[00:17] <infinity> phillw: So, your kernel would boot and then nothing would run.
[00:17] <phillw> hiyas infinity so, can you see any way around 32 bit non-pae and a working kernel?
[00:18] <infinity> phillw: non-pae is an entirely different question than 486.
[00:18] <infinity> phillw: The answer to non-pae is to build your own kernel, we intentionally dropped the support, we won't pick it up again.
[00:19] <infinity> phillw: There are a few PPAs that rebuild the archive kernels as non-pae, if I recall.
[00:19] <infinity> (Sorry, don't know which PPAs, but Google or launchpad's search might know)
[00:19] <infinity> phillw: If you wanted it on your images, it would have to be in the archive, which means a lubuntu dev would need to commit to supporting it, because we won't.
[00:26] <phillw> infinity: could you have a look at http://packages.debian.org/cgi-bin/search_packages.pl?keywords=kernel-image and let me know if you spot a non-pae version? I spotted powerppc etc.
[00:34] <infinity> phillw: You don't want a Debian kernel, you want a fork of the Ubuntu kernel with CONFIG_PAE turned off.
[00:35] <infinity> phillw: And like I said, this would need to be something you'd need to get someone to commit to maintaining as a rebase, or you're doing your users a disservice.
[00:35] <infinity> (stable security support, etc)
[00:48] <phillw> infinity: it would be a one off respin for 13.10, then with 14.04 a respin for the .1, .2, .3. .... I'm just trying to get some ideas in my head. As these people have no other option, locking the kernel is the least of their security worries. Having ability to update the browsers is far more important. I do fully understand what you, from the kernel team say in terms of no security updates; but, when stuck between a rock and a hard place, would y
[00:54] <infinity> phillw: Being able to update their browser can be done with 12.04
[00:55] <phillw> infinity: lubuntu did not have an lts back then :) Tech Board prohibited it, for a start and we were still too young to ask :)
[00:55] <infinity> phillw: Not being an LTS doesn't mean your users somehow magically don't get the updates from the archive.
[00:56] <phillw> indeed not, but it does stop the browser updates, which are the most at risk.
[01:02] <phillw> infinity: "The package information was last updated 290 days ago" There are no updates to install.
[01:03] <phillw> infinity: can we swap to another channel, as this is off-topic for kernel? :)
[01:14] <phillw> infinity: a thousand apologies, the VM has just found a shed load of updates that it wants. ::SIGH:: I am really sorry.
[02:20] <phillw> infinity: after update of the 12.04 I have http://packages.debian.org/cgi-bin/search_packages.pl?keywords=kernel-image
[02:20] <phillw> grrrrrr....
[10:43] <ara> hello!
[10:43] <ara> 12.04.4 kernel freeze was scheduled for yesterday
[10:43] <ara> I would like to confirm that it actually happened
[10:43] <ara> thanks!
[13:03] <rtg> smb, cking: are you guys aware of any new grub issues ? I'm updating a kernel in Precise. Its been stuck here for 10 minutes:
[13:03] <rtg> 32503 pts/4    S+     0:00 /bin/sh /usr/lib/os-probes/50mounted-tests /dev/sda1
[13:03] <rtg> 32508 pts/4    D+     0:00 grub-mount /dev/sda1 /var/lib/os-prober/mount
[13:03] <rtg> 32541 ?        S      0:00 /sbin/udevd --daemon
[13:03] <rtg> 32672 ?        S      0:00 /sbin/udevd --daemon
[13:03] <cking> new one to me
[13:03] <rtg> ah, I have an outstanding nfs mount I'll bet
[13:03] <smb> Hm... not sure somehow os-prober stuck does ring a faint distant bell
[13:04] <rtg> how about this ? '[403127.854359] nfs: server 10.0.2.254 not responding, still trying'
[13:04] <rtg> that server is turned off
[13:05] <smb> Not really sure about the relation. Just that nagging feeling I have seen someone saying something about grub and stuck recently
[13:05] <smb> May have been on #ubuntu-devel or ... 
[13:06] <smb> But could be something smart thinking some OS might be on the nfs side
[18:08] <bjf> kamal, can you interpret bug 1163720 for me? as i read it the -proposed kernels do not fix the issue. 
[18:08] <ubot2> Launchpad bug 1163720 in Linux "Brightness control broken on XPS13 and 3.8.0-16, 3.8.0-22 and 3.11.0-12" [Medium,Incomplete] https://launchpad.net/bugs/1163720
[18:09]  * kamal reads the tea leaves
[18:10] <bjf> kamal, i can't tell what comment #81 is supposed to be telling me
[18:11] <kamal> bjf -- here's the scoop ...
[18:11] <bjf> this should be *good* :-P
[18:12] <kamal> no
[18:12] <kamal> its not
[18:12] <kamal> this problem still isn't fixed upstream and I got sick of waiting, so (see comment #76) I implemented a boot param ...
[18:13] <kamal> in comment #77, Dan from Dell confirmed that the boot param does resolve the problem (which only affects a small (?) number of XPS13 users, who opt to enable a particular UEFI configuration).
[18:14] <kamal> the boot param fix did get SRU'd for P through S ... that's about the best we're going to be able to do for this issue, until upstream fixes backlight "for good" (hahahaha!)
[18:14] <kamal> it looks to me like commenters #81, #82, #83 didn't try using the new boot param, so (not surprisingly) they saw no change in behavior.
[18:15] <kamal> I'll add a comment to the bug asking them to test that.
[18:15] <bjf> kamal, cool ... i'm good with that
[18:15] <kamal> bjf, you should just clear it from your list
[18:15] <bjf> kamal, i'm not going to give it another thought
[18:15] <kamal> bjf, wish I could say the same :-/
[18:16] <sforshee> the fact that we have so much trouble with friggin' backlights makes me want to weep
[18:18] <mjg59> Well, it doesn't help that people keep trying to fix them with boot parameters
[18:18] <mjg59> Or quirks
[18:23] <kamal> mjg59, I'm not happy about it either, but given the choice between quirk out *one* register set in i915, vs. making hundreds of users suffer another 12 months of broken backlight ...  well, I'll stick by my choice.
[18:25]  * rtg -> lunch
[18:44] <bjf> manjo, can you verify bug 1248233 is fixed?
[18:44] <ubot2> Launchpad bug 1248233 in linux (Ubuntu) "[saucy][armhf] No early printk because there's no defined device tree binding for earlyprintk UART" [Medium,Confirmed] https://launchpad.net/bugs/1248233
[18:45] <manjo> bjf, yes I did verify that it is fixed ... I can add a comment to that bug with more info 
[18:45] <manjo> bjf, give me 20mts 
[18:45] <bjf> manjo, just need the tags fixed
[18:45] <bjf> manjo, i'll take care of it
[18:46] <manjo> bjf, you don't need testing info there then ? 
[18:47] <bjf> manjo, i just need the tags fixed. that indicates you did the testing.
[18:49] <manjo> bjf, look like you already moved it to done .. thanks I also added some test data 
[18:50] <bjf> manjo, ack
[21:13]  * rtg -> EOD