[05:46] <hyperair> is there a script i can use to fetch the abi files of the previously built kernel?
[05:46] <hyperair> or do i need to manually download the debs myself?
[06:06] <hyperair> aha, found it.
=== amitk is now known as amitk-lunch
[09:24]  * apw yawns
[09:35]  * cking offers apw a coffee
[09:36]  * smb thinks about another one
[09:37]  * apw drinks some tea, and reads scrolback on #ibm
[09:38] <smb> apw needs danger sensitive sunglases
[09:38]  * apw idly wonders why so many people are suddenly want non-pae kernels, given its been like 4 releases since we supported them
[09:39] <smb> apw, Because now it the next lts
[09:39] <apw> you still maintining your fork of that ?
[09:40] <smb> apw, No I never was
[09:40] <smb> Oh you mean last last lts... if that was this lucid thing
[09:40]  * cking wonders how old non-pae cpus are
[09:41] <apw> yeah weren't you building something for a via
[09:41] <smb> cking, still found in x86 embedded options
[09:41] <smb> cking, Like AMD's Geode
[09:41] <cking> oh, the Geode, bleah
[09:42] <smb> cking, Incidentally what I am currently running my firewall/router on
[09:44] <hyperair> apw: because phillw leveled up his bugging skills.
[09:45] <hyperair> i told him to just build a nonpae flavour, stick it in a PPA somewhere, and roll it out in a custom ISO
[09:45] <hyperair> for people with prehistoric hardware
[09:46] <apw> it is only like 3-4 options config wise for sure
=== amitk-lunch is now known as amitk
[13:05] <xnox> apw: hola! =) I have a fresh armhf-cross-toolchain-base at https://launchpad.net/ubuntu/+source/armhf-cross-toolchain-base/1.103 I've blocked in -proposed at the moment. Can it be tested at cross-compiling & booting kernels or some such?
[13:05] <xnox> it's a jump from eglibc 2.17 -> 2.18, compiled with gcc 4.8 instead of 4.7
[13:06] <xnox> i'll compile a few things here and check that they are roughly sensible, but more testing would be nicer, considering that kernel/armhf folks probably rely on it more.
[13:06] <xnox> arm64, powerpc, ppc64el are to follow.
[13:14] <apw> xnox, i am sure we can, will see what i can make up
[13:14] <xnox> apw: cheers. i'll be holding it in proposed, until some positive results.
[13:19] <xnox> rbasak: ^
[13:21] <rbasak> A cross-compile of the kernel is probably the best test I can think of. I'm not sure I can think of what else I can test that might be useful.
[13:57] <hyperair> apw: 3-4 options sounds simple enough, but to someone who is unfamiliar with building kernels, it's hardly easy.
[13:58] <hyperair> and i'm having trouble digging through the packaging stuff anyways
[13:58] <hyperair> https://launchpadlibrarian.net/160113188/buildlog_ubuntu-saucy-i386.linux_3.11.0-15.23%2Bhyper2_FAILEDTOBUILD.txt.gz <-- so after over 5 hours, it tells me EE: Missing modules (start begging for mercy)
[13:58] <hyperair> but it doesn't say which module is missing
[13:58]  * hyperair sighs
[13:58] <hyperair> fml
[13:59] <hyperair> i guess that means i now need to find 20GB of free space to test build this so i can do a proper post mortem
[14:00] <apw> hyperair, it should list them when it saysmissing modules, just above
[14:00] <hyperair>       read 4149 modules : new(0)  missing(1)
[14:01] <hyperair>       MISS: /home/hyperair/src/debian/linux/nonpae/ubuntu-saucy/abi-tmp-3.11.0-15.23/tmp
[14:01] <hyperair> this line?
[14:01] <apw> MISS: yeah, though the crap on the end of it, seems wrong
[14:01] <hyperair> oh yeah you're right
[14:01] <hyperair> O_o
[14:01] <hyperair> it shouldn't be /home/hyperair
[14:02] <hyperair> how did that line creep into the .modules files?
[14:02] <hyperair> =\
[14:04] <hyperair> apw: thanks
[16:02] <apw> xnox it occurs to me that i don't need this package to cross the kerenl, so i don't think it is a good test fo ryou
[16:03] <xnox> apw: oh, quite.
[16:03] <xnox> kernels are independant of the libc6 ;-)
[16:04] <xnox> sorry about that. In my world everything needs libc6 =)
[16:04] <apw> heh yeah ... doh should have thought of that before going and trying to do ti :)
[17:12] <imMute> so my kernel options include "console=ttyS0,115200n8" and even though I run "dmesg -n 7", KERN_DEBUG messages aren't printed to the console - I have to run dmesg to see them.  This is not the case on my other Linux machine - what is different about Ubuntu?
[17:46] <kdub> sforshee, i came up with a patch that fixes/robustifies powerd against the problem i was seeing... just for my understanding though, what is 'earlysuspend'?
[18:46] <yates> why am i getting such a long delay at line 831 here: http://ur1.ca/g7wwe -> http://paste.fedoraproject.org/62960/38739154
[19:16] <sforshee> kdub: earlysuspend is specific to android kernels. Essentially it's a state where some drivers have suspended their devices but the system hasn't fully suspended.
[19:16] <kdub> sforshee, is it more on older devices or new devices?
[19:16] <sforshee> android kernels will commonly suspend he display and touchscreen via this mechanism
[19:17] <sforshee> it's mostly older devices, I belive it's more-or-less deprecated
[19:17] <sforshee> but it's still common
[19:17] <sforshee> as far as kernels that I've looked at go I think only the nexus 10 wasn't using it
[19:19] <kdub> and when coming out of suspend, some devices will exit suspend before the system is fully active, i presume
[19:19] <sforshee> but as long as we wait on wait_for_fb_wake the display device _should_ be out of early suspend and ready to use
[19:19] <sforshee> the traditional suspend/resume mechanism resumes devices before thawing userspace tasks
[19:20] <sforshee> but earlysuspend doesn't
[19:21] <kdub> sforshee, thanks, good info
[20:44] <TooLmaN> Unique bootstrap question.  I'm trying to install Ubuntu Core on a Wyse thin client with a 1GB flash drive inside.  I have everything properly installed (rootfs, kernel files, etc) and syslinux'ed the drive.  On boot I just get "boot error" like it isn't seeing the drive.  I believe these TCs are setup as a SuperFloppy?  Any tips on getting it to boot?  Thanks
[20:45] <TooLmaN> oh, I setup a 100MB FAT partition and the rest Ext3
[20:49] <JanC_UEFI_test> TooLmaN: what CPU is in those?
[20:50] <TooLmaN> I believe x86.
[20:50] <TooLmaN> That's what the Live USB drive used
[20:50] <TooLmaN> I haven't tried to replicate the test in a VM yet
[20:52] <JanC_UEFI_test> TooLmaN: so, the live USB booted on the TC?
[20:52] <TooLmaN> yes, I used it to do all the work.  formatting, partitioning, copying files, etc.  It runs fine off the live usb
[20:53] <TooLmaN> I've used syslinux for years.  Just not sure what I'm missing here
[20:53] <TooLmaN> My goal is to get one TC working properly and image it to deploy to the other
[20:53] <TooLmaN> others*
[20:55] <JanC_UEFI_test> maybe check what possibly relevant drivers are loaded by the live USB and make sure those are available in initramfs?
[20:57] <JanC_UEFI_test> although, I guess the error you see might be earlier, in syslinux?
[20:58] <JanC_UEFI_test> also, drives might be numbered differently depending on which one you boot from in some BIOSes
[20:59] <JanC_UEFI_test> oh, and make sure the boot partition is marked as such
[21:00] <JanC_UEFI_test> IIRC I had to do that on some old WYSE TC
[21:01] <TooLmaN> JanC_UEFI_test, I'll check a few.  It's a syslinux-level error
[21:02] <TooLmaN> the BIOS sees the internal drive as a hard drive
[21:02] <TooLmaN> This is a wyse CL50 TC
[21:02] <TooLmaN> it shipped with Suse but I had 2X ThinClientOS on it
[21:03] <TooLmaN> wanting to make them simple web page display appliances running into screens around the plant
[21:04] <TooLmaN> I can do this with RPi's, and I have a couple up, but I don't want them going to waste
=== JanC is now known as Guest65015
=== JanC_ is now known as Guest61958
=== JanC__ is now known as JanC
=== JanC is now known as Guest31114
=== JanC__ is now known as JanC