[07:37] <ppisati> moin
[08:39] <psino> Is there any fix equivalent to https://bugzilla.redhat.com/show_bug.cgi?id=914737 in the pipeline (or even already implemented?) for ubuntu?
[08:39] <ubot2> bugzilla.redhat.com bug 914737 in kernel "Fedora 18 on EC2 kernel panic due to cgroups" [Unspecified,On_qa]
[08:55] <smb> psino, When I look at the discussion on Xen-devel about the resulting patch it seems that at least the initial version got turned down. So right now that would mean no. Until there is an upstream fix for it and marked for stable.
[08:59] <apw> one assumes the 'final' version once available will make it to us via that route
[09:00] <smb> apw, Probably needs a reminder as that discussion was about a month ago...
[09:00] <apw> smb, yeah probabally ... have fun :)
[09:03] <psino> hmm. I heard there were at least one other patch proposed as a fix. if I recall correctly, it was turned down at least partly because it caused a minor performance regression on bare metal, but maybe other things as well.
[09:03] <psino> so I assume if I'm being hit pretty badly by that bug right now, the suggested route is to build my own kernel with that patch or a similar one and see if it works for me until an official version comes out?
[09:06] <smb> psino, Or even better try to make it working mostly with upstream changes and as soon as all parts are there make sure they go to upstream-stable. Probably also create a new lp bug for it since the one that is referenced in the redhat bugzilla seems closeed
[09:07]  * smb just pinged Konrad as well to find out in parallel
[14:12] <smb> psino, Are you still around?
[14:21] <psino> smb: yes, on and off :)
[14:23] <smb> psino, It sounds like upstream is waiting on someone to confirm that two patches will solve the issue you asked about. So I think either if you open a launchpad bug report and let me know, I could provide test kernels and we then can let them know. Or you could build your own and tell them directly
[14:25] <psino> where do I find the two patches? its probably better if it can be fixed upstream, as it will benefit more people. does it take long from patches being applied upstream to new official ubuntu kernel builds are available?
[14:27] <smb> psino, Oh, the feedback would go upstream in both cases. The main thread about it starts at: https://lkml.org/lkml/2013/2/28/568 one reply mentions the other part
[14:29] <smb> After it goes upstream (with cc stable) it depends a bit. Our kernels are updated in about a three weekly cycle.
[14:30] <psino> smb: ok, I'll have a look at the thread when I get some free time. thanks for your help so far :)
[14:30] <smb> psino, np :)
[16:23] <infinity> apw: Yo, vars.generic is uncleverly x86-specific.  Is there any point to abstracting to the point where one loses flexibility?
[17:09] <apw> infinity, sorry ?
[17:10] <apw> infinity, oh i see if we wanted to have an arm generic as well you mean
[17:10] <infinity> apw: Yeah.
[17:10] <infinity> apw: I think I've sort of sorted it with Paolo.
[17:11] <infinity> apw: By arch-specifying all those bootloader deps.
[17:11] <infinity> (ie: grub [i386 amd64 x32], flash-kernel [armhf arm64])
[17:11] <infinity> Untested, but if that's being substituted into a master control file, then parsed by dpkg-gencontrol at build time, it should DTRT.
[17:11] <apw> yeah i guess we have no choice other than to do that
[17:12] <apw> as (i assume) we cannot have two Package: linux-image-generic stanzas with different arches 
[17:12] <infinity> Definitely not.
[17:13] <apw> infinity, vile, but ...
[17:14] <infinity> Well, that's how debian/control and dpkg-gencontrol work.  Not all THAT vile, except that it sort of defeats the purpose of the vars.foo abstraction. :P
[17:14] <infinity> Maybe that would be saner if it was extended to var.foo.$arch and pulled the right one based on DEB_HOST_ARCH
[17:14] <infinity> Then the descriptions could actually change and such.
[17:15] <apw> yeah that would be the other way, but then the control on the source would be 'wronger' than it is now
[17:15] <apw> not that it is very right
[17:15] <apw> right now
[17:15] <infinity> Yeah, it's pretty wrong regardless.
[17:47] <jbaron> hi - how do i figure out the dependency of a specific kernel on the linux-firmware package?
[17:47] <jpds> jbaron: $ apt-cache rdepends linux-firmware
[17:59] <jbaron> hmmm...there no dependency listed there on linux-generic
[18:00] <jbaron> i think its really the other way around that I'm looking
[18:00] <jbaron> for
[18:00] <jbaron> i can do:
[18:00] <jbaron> s linux-generic 
[18:00] <jbaron> linux-generic
[18:00] <jbaron>   Depends: linux-image-generic
[18:00] <jbaron> sorry:
[18:00] <jbaron> $ apt-cache depends linux-generic 
[18:00] <jbaron> linux-generic
[18:00] <jbaron>   Depends: linux-image-generic
[18:00] <jbaron> $ apt-cache depends linux-image-generic
[18:00] <jbaron> linux-image-generic
[18:00] <jbaron>   Depends: linux-image-2.6.32-45-generic
[18:00] <jbaron>   Depends: linux-firmware
[18:01] <jbaron> and i think see that linux-generic depends on 'linux-firmware'
[18:01] <jbaron> but i don't see a specific version ?
[18:01] <jpds> jbaron: Does it need a specific version?
[18:02] <jbaron> i would think so
[18:02] <jbaron> maybe not - i'm not sure 
[18:02] <jbaron> if the drivers update in the kernel - they'll need specific firmware versions
[18:22] <infinity> jbaron: We don't force versions, no.
[18:22] <infinity> jbaron: firmware is more tightly coupled with hardware than drivers.
[18:22] <infinity> jbaron: Is there a specific problem you're trying to solve here, or just a curiosity?
[18:23] <jbaron> yeah - i'm trying to re-build the ubuntu kernel out of the git tree
[18:23] <jbaron> and i'm trying to figure out which firmware to include
[18:24] <jbaron> since the firmware is dropped from the git tree
[18:24] <infinity> apt-get install linux-firmware?
[18:24] <infinity> Like, I'm not sure what you mean here. :P
[18:24] <jbaron> right - but i want to make sure it matches up with the kernel I'm building
[18:24] <infinity> They don't "match".
[18:24] <jbaron> the drivers do request specific firmware files
[18:25] <infinity> If you want the newest, get the linux-firmware from raring.
[18:25] <jbaron> request_firmware()
[18:25] <infinity> https://launchpad.net/ubuntu/+source/linux-firmware/1.104
[18:26] <infinity> It's maintained outside the kernel tree.
[18:27] <jbaron> if you look at the request_firmware() call in the kernel it asks for specific firmware files:
[18:28] <jbaron> ie "BCM2033-FW.bin"
[18:28] <jbaron> so maybe the linux-firmware pkg for a release keeps all the old ones ? 
[18:28] <jbaron> (in the case the driver is updated)
[18:29] <infinity> Yes, I'm aware of what request_firmware does.  I'm saying that there is no "matching" firmware for any specific kernel.  We ship the latest, according to what we need, and what bugs get filed to include new things.
[18:30] <infinity> Some from linux-firmware.git, some from elsewhere occasionally.
[18:30] <bjf> jbaron, which kernel tree are you building ?
[18:32] <jbaron> quantal - I guess if i include all the firmware from linux-firmare i'll be safe
[18:32] <bjf> jbaron, do you have quantal installed and you are just building your own quantal kernel?
[18:33] <jbaron> yes
[18:33] <bjf> jbaron, if so, you probably don't need to worry about firmware, build your kernel and try running it
[18:33] <bjf> jbaron, the worse that can happen is that not everything works and you just boot up the previous kernel via grub
[18:34] <jbaron> ok, thanks
[18:34] <infinity> jbaron: I'm still not sure why you think you need to "include" firmware at all?
[18:35] <infinity> jbaron: If you're on quantal and you have linux-firmware installed, you have the firmware.  You don't need it AGAIN in your kernel build.
[18:38] <bjf> jbaron, if you don't mind me asking, why are you building your own kernel? just for the experience or for a particular issue?
[18:39] <jbaron> ok, thanks guys, I was just trying to better understand how firmware updates work
[19:41] <bryce> jsalisbury, #1156077 has a kernel patch from upstream that needs tested/integrated
[19:48] <apw> bug #1156077
[19:48] <ubot2> Launchpad bug 1156077 in linux (Ubuntu Raring) "Black screen when booting after a fresh install on chromebook" [High,In progress] https://launchpad.net/bugs/1156077
[19:51] <jsalisbury> bryce, ack