[05:36] <one> What keys does the in kernel keys hold ssl keys or something else?
[05:36] <one> Why is pappy shut down?
[07:39]  * apw yawns
[07:55] <one> Hi apw 
[08:33] <one> [D
[08:38] <one> ;5C
[10:19] <ppisati> ogra_: any reason why "link_in_boot = yes" in /etc/kernel-img.conf for ARM?
[10:19] <ppisati> infinity: ^
[10:20] <ogra_> define "for ARM" :P 
[10:20] <ogra_> i think we disabled it on the arches that didnt support it 
[10:20] <ppisati> ogra_: arm boards and servers (i checked on calxeda) have that variable set that way
[10:21] <apw> ogra_, does our installer/image side for ARM pre-create /etc/kernel-img.conf at all do you remember, i have a feeling it might
[10:21] <ogra_> well, depends how you set them up ... on pandas we always treated the uboot partition separately so it doesnt matter if there is a link in /boot or not ... on ac100 it was the same ... the fastboot partition was not mountable 
[10:22] <ogra_> if you actually want to mount a vfat under /boot instead of handling that bit via flash-kernel separately you need to modify that 
[10:22] <ogra_> (but we never defaulted to such nonsense)
[10:23] <ogra_> apw, i thought the kernel postinst does it ... 
[10:25] <apw> ogra_, it does, but doesn't appear to put the specific values ppisati finds in his
[10:26] <ogra_> hwo did ppisati install than ? 
[10:26] <ogra_> *then
[10:26] <ppisati> ogra_: i check an ubuntu-core+manual kernel installaion, an old panda installation and a calxeda server
[10:27] <apw> ppisati, did you find the file in ubuntu-core without the kernel?
[10:27] <apw> if not then it clearly must be us 
[10:27] <ogra_> well, whatever creates it needs to be depending on the fact if someone was crazy enough to mount a vfat under /boot ... 
[10:28] <ogra_> though the link wont break anyway ... simply because it breaks long before it can create it ... when unpacking the kernel package 
[10:28] <ppisati> ogra_: nope, ubuntu-core doesn't have it
[10:28] <ogra_> if flash-kernel is involved the setting is moot anyway btw ... it uses the full version string and wont use a link (unless that changed recently)
[10:28] <ppisati> right
[10:29] <ppisati> i'm playing around with the new uboot
[10:29] <ppisati> and they have two nice fatures:
[10:29] <ppisati> *features
[10:29] <ppisati> 1) they can read file from ext4 and can boot from regular zImage
[10:30] <ppisati> 2) a function that, given a couple of env cars, can detect which dtb this boards needs
[10:30] <ppisati> so, actually 3 features
[10:30] <ppisati> :)
[10:30] <ogra_> nice
[10:30] <ppisati> anyway
[10:30] <ppisati> i was able to put together a uEnv.txt that can exploit all those three
[10:31] <ppisati> and if we can make a symlink (that's where that variable came into play...) to the dtbs directory
[10:31] <ppisati> like:
[10:31] <ppisati> /lib/firmware/$kernel-version/device-tree/blabla -> /dtbs
[10:31] <ppisati> we can:
[10:32] <ppisati> 1) drop flash-kernel as a dependency when installing kernel (since we load the zImage directly)
[10:32] <ppisati> 2) always load the correct and most up to date dtb for the specific board
[10:32] <ppisati> e.g.:
[10:32] <ogra_> right 
[10:32] <ogra_> but only for platforms that fully support the new uboot 
[10:33] <ppisati> ogra_: yep, talking about arm boards here
[10:33] <ppisati> paste.ubuntu.com/7462048/
[10:33] <ogra_> and for platforms that dont use a dedicated flash partition (that would finally make flash-kernel again what you expect from its name :) )
[10:33] <ppisati> here is the uEnv
[10:34] <ppisati> dedicated flash partition?
[10:34] <ogra_> ppisati, well, there are still plenty arm boards that need/use mtd devices for their booting etc 
[10:34] <ppisati> all the boards i have: panda, beagle, beaglebone, exynos5, imx6, etc
[10:34] <ogra_> for these you will still need to use flash-kernel 
[10:34] <ppisati> we don't support them
[10:34] <ppisati> so it's not a problem
[10:35] <ppisati> even the exynos i received boot from sd
[10:35] <ppisati> first partition u-boot, etcetc
[10:35] <ppisati> anyway, my main point is that the board can choose which dtb to load
[10:35] <ppisati> using the findfdt() function that it has
[10:36] <ppisati> so i was trying to add a symlink (the /dtbs above)
[10:36] <ppisati> and that's when i notced that x86 do all the symlinks in /
[10:36] <ppisati> while arm does it in /boot
[10:37] <ogra_> right 
[10:46] <apw> is it because /boot is separate ?  is /boot separate ?
[10:47] <ppisati> apw: /boot has never been separated, they probably added that option to hanlde that case, but we never separated /boot
[10:48] <apw> not that then
[10:48] <ogra_> but if you use d-i you are allowed to 
[12:09] <rtg> apw, what dkms packages are missing for the transition to 3.15 ? Anything particularly important ?
[12:12] <apw> rtg, i think we are still waiting on actual testing of the two graphics ones, ie do they do anything
[12:12] <apw> rtg, otherwise i think the package set was there, but let me double check the testing results
[12:13] <apw> tseliot, did you get a chance to modprobe the graphics stacks yet ?
[12:13] <rtg> apw, ok, I think I can test nvidia at least, perhaps fglrx as well
[12:13] <apw> rtg, ack
[12:16] <rtg> apw, if those drivers basically work, then it feels like its time to introduce 3.15
[12:51] <apw> rtg, yeah i know what you mean, i assume we'll fork 3.16 onto unstable when it comes 
[12:52] <rtg> apw, or just drag our feet about uploading much like we've done with 3.15
[12:55] <apw> or that
[13:14] <tseliot> apw: no, I haven't tested those drivers yet
[13:55] <bjf> jsalisbury, can you see if the person that wrote comment #19 on bug 1305522 is willing to bisect?
[13:56] <jsalisbury> bjf, sure 
[13:56] <bjf> jsalisbury, thanks
[15:21] <tjaalton> so I need to provide a test kernel for an oem image build, but what version number to use that is newer than the next kernel and such that it builds? tested -26.48foo1 and it failed, now testing -26.48.1 but will it fail too?
[15:31] <apw> tjaalton, -26.48foo1 should work just fine, i use similar shapes often
[15:31] <apw> tjaalton, what was the failure
[15:36] <smagoun> bjf: Hi, I verified bug 1305133 - the fix does what's expected but it's not really complete. There is another related patch upstream but not in our kernel. Rather than fail verification of 1305133, I filed bug 1319457 as a follow-up. 1319457 has a link to the upstream patch we need
[15:38] <tjaalton> apw: II: Checking modules for generic...previous or current modules file missing!  /build/buildd/linux-3.13.0/debian.master/abi/3.13.0-26.48tja1/amd64/generic.modules  /build/buildd/linux-3.13.0/debian.master/abi/3.13.0-26.48/amd64/generic.modules
[15:39] <tjaalton> make: *** [module-check-generic] Error 1
[15:40] <apw> tjaalton, so did you add a new version on the top of the changelog ?
[15:40] <apw> if so you need to update the ABI files in those directories, or what most of us do
[15:40] <apw> is to just change the version of the latest entry rather than making a new one
[15:42] <tjaalton> d/r clean isn't enough?
[15:43] <tjaalton> I added a new entry after 3.13.0-26.48 yes
[15:50] <rtg> tseliot, apw: no joy with nvidia-304 and 3.15 kernel
[15:50] <rtg> does not compile
[15:51] <tseliot> rtg: ok, I'll have a look at it
[16:17] <apw> tjaalton, so best to just change the version of the last one, and then go for it
[16:42] <jsalisbury> bjf, Looks like we have an answer for bug 1305522 in comment #29.  It appears the two HID: rmi: SAUCE patches are what caused the touchscreen to regress.  Reverting them allows the touchscreen to work again.
[16:50] <infinity> ppisati / apw: link_in_boot = yes is the "right" setting for pretty much everyone who doesn't use lilo, IMO.  So, anyone !x86 !ia64, or x86 from the last decade.
[16:50] <infinity> ppisati / apw: The fact that it's probably still the inverse on default x86 installations doesn't mean ARM is wrong (why does anyone care, BTW?)
[16:52] <jsalisbury> rtg, if you have a chance, can you take a look at bug 1319471 ?  I'm not sure if I should ping the HWE folks about this?
[19:21] <lesshaste> hi.. how can you boot into single user mode in 14.04? It seems "sudo telinit 1" doesn't work and nor does adding "single" to "ro quiet splash $vt_handoff
[19:22] <lesshaste> in the grub options