[06:27] <tkamppeter> When will the kernel SRU for Oneiric be ready, for example to fix bug 872711 which prevents half of the USB printers not being detected?
[06:27] <ubot2> Launchpad bug 872711 in linux "Kernel does not report some USB printers correctly, making them not being detected by CUPS" [High,Fix committed] https://launchpad.net/bugs/872711
[07:39] <smb> morning .+
[07:41] <abogani> smb: morning
[07:44]  * apw yawns
[07:46] <apw> tkamppeter, i would expect it to be uploaded very soon though that is now in the hands of the stable team and their cycles
[08:02]  * apw has to reboot ...
[09:30] <gentoo_drummer> anyone here?
[09:33] <gentoo_drummer> has anyone tried ubuntu 11.10 command line installation under vbox? i get to a blinking underscore screen forever
[09:35] <smb> gentoo_drummer, Have not tried vbox. But done an alternate installation under kvm and xen...
[09:36] <smb> gentoo_drummer, you got past the syslinux boot screen I assume? Or when does it get stuck?
[09:38] <gentoo_drummer> smb: i get past the ubuntu 11.10 splash screen and then it stays on the underscore forever
[09:38] <gentoo_drummer> 10.10 works though
[09:38] <gentoo_drummer> how do i do a distupgrade to oneiric?
[09:38] <gentoo_drummer> just put oneiric-ocelot in apt.sources and then dist-upgrade?
[09:39] <TeTeT> gentoo_drummer: sudo do-release-upgrade
[09:39] <smb> gentoo_drummer, You could try to remove the quiet and splash words from the opetions and see what happens then
[09:39] <TeTeT> gentoo_drummer: or, from GUI, update-manager
[09:39] <smb> or do as TeTeT said for updating, will take you through 11.04 though
[09:40] <gentoo_drummer> how can i get to verbose through grub boot screen?
[09:41] <smb> gentoo_drummer, When you boot from cd, there is one key for options (f6 or so but not sure), then escape and edit the line. It has "quiet splash" which when removed gives you verbose
[09:42] <gentoo_drummer> smb: i mean when pressing "c" to get to the grub boot screen
[09:43] <gentoo_drummer> is there a command to boot in verbose from there?
[09:43] <apw> gentoo_drummer, sadly not, you have to jump through several hoops
[09:44] <gentoo_drummer> gosh
[09:44] <apw> you have to change the =$foo bit to =text
[09:44] <smb> gentoo_drummer, for the kernel you want to boot its e
[09:44] <apw> then on the command line remove quiet and splash and add debug
[09:44] <smb> then edit the line there to remove the quiet and splash
[09:44] <smb> and then ctrl-x to boot it
[10:54] <Kano> apw: is rc10 building now? was tagged 6h ago?
[10:54] <Kano> or same problem like with daily?
[10:54] <apw> we only check at 9am UTC so it would have started about then if it was ready by then
[10:55] <Kano> well it was tagged before 9 utc
[10:56] <apw> then its in the build queue, looks like there was another stable release too which gets done first
[10:56] <Kano> ah which one?
[10:56] <apw> v3.0.7
[10:56] <Kano> ah
[10:56] <Kano> with dvb fixes?
[10:57] <apw> if they are in mainline
[10:57] <Kano> you didnt add the 3 patches i showed you, did you?
[10:58] <apw> to the mainline builds, no, they are what they say they are, virgin unchanged mainline builds
[10:58] <apw> for them to have random patches on top would not make any sense for our use case
[10:58] <Kano> no for your o release ernel
[10:59] <apw> the release kernel no, it was frozen already
[11:00] <Kano> 3.0.7 misses em too as i see
[11:00] <apw> upstream stable isn't being fed very well it seems
[11:01] <Kano> do you intend to base a kernel on 3.0.7?
[11:02] <apw> yep, most likey we'll upload a 3.0.6 plus fixes shortly, and then the next cycle will have 3.0.6
[11:02] <apw> 7
[11:02] <Kano> why dont skip 3.0.6?
[11:03] <apw> cause what we have has had some time to settle and there is always a new one on the horizon
[11:03] <apw> not that it is my call at the end of the day, but there is little point in rushing out stuff
[11:04] <apw> as they normally find problems in one update and produce a fix for it
[11:04] <Kano> ok, any estimate for 3.0.7?
[11:07] <apw> a couple of weeks or so
[11:08] <apw> herton, hey ... has anyone formally handed over the oneiric kernel to you in stable ?
[11:08] <herton> apw: yep, steve talked to leann yesterday
[11:09] <apw> herton, ok good ... we need to keep in mind there is an lts-backport for it too which needs uploading as well
[11:10] <apw> herton, where are we in the cycle for stable, we likely should push the update for oneiric sooner than later as there is already a heap of stable on there
[11:12] <Kano> apw: whats the reason that rc kernels are not written as ~rc
[11:12] <herton> apw: the first oneiric update is in progress now (bug 876701), will take care of lts-backport as well
[11:12] <ubot2> Launchpad bug 876701 in linux "linux: 3.0.0-13.21 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/876701
[11:12] <Kano> in the version
[11:12] <Kano> rc is always newer than first release kernel with mainline builds
[11:12] <apw> herton, you are a star -- thanks a lot
[11:13] <apw> Kano, never thought about it, the names are only meant to be unique as they are 'install, test and remove' kernels not intended for longterm use nor do we provide any updateable sources
[11:14] <Kano> well maybe kanotix users test more of our mainline build than yours ;)
[11:14] <apw> maybe, maybe
[11:16] <Kano> i basically like pure kernels, custom patches needed to fix something is always annoying
[13:31] <ogasawara> apw: I suspect we'll only have a handful of specs for UDS which need an actual meeting slot, I wonder if we should spread them out over the week rather than monopolizing a single day
[13:32] <apw> ogasawara, other than the version flavours discussion i suspect they can float forward
[13:32] <apw> i think the plan with putting them together was to allow the rest of the week for us to go to things
[13:33] <apw> but actually that really doesn't make any difference where they are
[13:33] <apw> friday afternoons is often prep for party time as well
[13:34] <ogasawara> apw: I'm guessing we're only going to have 4 (config, delta, version, stable), so was thinking to just schedule 1 per day
[13:34] <apw> can't see anything wrong with that
[13:35] <ogasawara> herton: I assume you or bjf will be having a stable kernel blueprint for UDS? or are you guys pretty much just turning the crank now and don't need to work out further details?
[13:37] <apw> i am sure there will be people wanting to input on it
[13:37] <herton> yes, probably will be good to have at least one session
[13:42] <herton> ogasawara: I'll wait bjf to show up and see with him
[13:42] <ogasawara> herton: ack
[13:48] <bjf> oh mistress of the dark, i hear you have questions
[13:50] <ogasawara> hehe
[13:50] <ogasawara> bjf: was just assuming you and herton would want to have a stable kernel session at UDS?
[13:50] <bjf> ogasawara: blueprint wise .. though we are just turning the crank i think we are expected to do a uds session so that people can have somewhere to whine
[13:51] <ogasawara> bjf: heh was assuming it would be more of a bitch session
[13:51] <bjf> ogasawara: we'll nod and tell everyone we will take their input seriously .. and then do what we want
[13:51] <smb> bjf, Will you play some annoying music as well?
[13:51] <bjf> ogasawara: just the usual
[13:52] <bjf> smb, i'll put that on the list
[13:52] <ogasawara> bjf: ok, I'll throw a stub blueprint together for you guys to fill in later and throw it in the schedule
[13:52] <smb> Cool, then we feel just as with any support line... :)
[13:52] <bjf> ograsawara, "state of the cadence" kind of thing
[13:57] <bjf> ogasawara: are we "other-p-kernel-*" ?
[13:57] <ogasawara> bjf: "hardware-p-kernel-*"
[13:58] <bjf> ogasawara: nice that there is a "kernel" track which we are not allowed to use :-)
[13:58] <bjf> i guess only linaro has kernel issues
[13:59] <ogasawara> bjf: you want me to assign you or bjf to this blueprint
[13:59] <ogasawara> bjf: heh, you or herton
[14:00] <bjf> ogasawara: me please
[14:01] <ogasawara> bjf: https://blueprints.launchpad.net/ubuntu/+spec/hardware-p-kernel-sru-cadence
[14:02] <bjf> ogasawara: i'll be sure and thank you properly at uds
[14:02] <bjf> :-)
[14:23]  * ogasawara back in 20
[14:30]  * apw notes it makes as muh sense for us to be foundations-kernel as hardware-
[14:33] <bjf> beer-p-kernel 
[14:33] <bjf> kind of "flows" eh?
[14:39] <gema> apw, bjf: don't complain, we are other-p...
[14:39] <apw> bjf, nice lets go for that
[14:39] <apw> bjf, actually or .... poolbar-p-kernel
[14:39] <bjf> gema, it's in my contract "required to complain, bitch, whine"
[14:40] <apw> "like a grumpy old man"
[14:40]  * gema goes to check her contract, being QA she expect to have even more rights than bjf...
[14:42] <gema> btw, bjf do you guys run any kind of static code analyser on the kernel?
[14:42] <bjf> hahaha ha ha HA!
[14:42] <gema> I will take that as a no :D
[14:43] <smb> not us as such, but isn't that coccinelle thing somehting like that?
[14:43] <apw> that more happens upstream yes, on the raw kernel
[14:43] <bjf> gema: actually, i do think there are static analyzers that upstream does
[14:44] <gema> smb, apw, bjf: but if they are run upstream, we don't benefit from then in our specific bits of the kernel, right?
[14:45] <bjf> gema: our kernel differences are very minor in reality
[14:45] <smb> no, thats why we try to keep our bits as small as possible (amongst other)
[14:45]  * bjf not sure he likes the implication that the kernel team has tiny bits
[14:46] <gema> bjf, smb: thanks! 
[14:46] <smb> bjf, aren't we always told size does not matter? ;-P
[14:46] <bjf> smb, they just tell us that to make us feel better, but they lie
[14:48] <bjf> gema: http://lwn.net/Articles/208312/
[14:49] <bjf> gema, i knew linux had written one
[14:49] <gema> bjf: thanks!
[15:06]  * herton -> lunch
[15:07] <apw> BAH unity just stopped updating my laptop screen like it was hung
[15:07] <apw> only cause i could see my external monitor could i tell it was actually just that screen
[15:11] <apw> ogasawara, are you ready for precise kernels to be uploaded to pre-proposed ?
[15:11] <ogasawara> apw: just about, I want to make a quick tweak to the VIRTIO bits you pointed out (ie disable except for -virtual), and I want to rebase to -rc10
[15:12] <apw> ogasawara, so i can add them for tommorrow 
[15:12] <ogasawara> apw: yep
[15:45] <jsalisbury> ogasawara, bjf, I'm seeing lots of new possible duplicates for bug 836250 and many people are reporting as affecting them ( /me included ;-) ) 
[15:45] <ubot2> Launchpad bug 836250 in network-manager "[Oneiric] Intel Corporation Centrino Ultimate-N 6300 poor networking, packet loss and very slow Lenovo X201 and T500 laptops" [High,Confirmed] https://launchpad.net/bugs/836250
[15:49] <ogasawara> jsalisbury: so are you able to test a few things, like boot back into a Natty kernel and confirm it's not an issue?
[15:50] <jsalisbury> ogasawara, I could give that a try, but I may have to do it later since its my primary laptop
[15:51] <jsalisbury> ogasawara, I can also ask others affected by this to try Natty
[15:51] <ogasawara> jsalisbury: ack.  I also thought tgardner did some extensive wifi testing but he wasn't able to reproduce a lot of these issues.
[15:51] <jsalisbury> ogasawara, yes, I did see that thread
[15:52] <DBO> jjohansen, so I am still running into issues with the rtl8192ce module. I found that if I do ips=0 that *seems* to fix it (hard to tell). Should I report this any further or just modify my machine and move on?
[15:52]  * apw notes they are lenovo's ... they are always troublesome
[15:53] <jjohansen> DBO: it would be good if you could file a bug, and add that information
[15:53]  * jjohansen is going to have to try that as well, and see if it works for me
[15:53] <DBO> so now I have to ask a somewhat silly question
[15:53] <DBO> how can I make this permanent (rather than just use modprobe)
[15:54] <apw> /etc/modprobe.d contains various files which have examples, you could make a new file there in a similar form
[15:55] <herton> ppisati: bug 877497 is the correct one to be worked on linux-ti-omap4 update for oneiric, the other ones I already closed (should be ignored)
[15:55] <ubot2> Launchpad bug 877497 in linux-ti-omap4 "linux-ti-omap4: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/877497
[16:05] <DBO> jjohansen, 20 minutes and no disconnects so far, this is pretty much a record for me
[16:05] <DBO> :)
[16:05] <DBO> still replacing the card... but no rush nwo :)
[16:05] <jjohansen> DBO: nice
[16:10] <ppisati> herton: yep, saw it
[16:13] <ogasawara> bjf: I assume you're aware the daily bug report email is stuck on Friday Oct 14
[16:13] <bjf> ogasawara: no, will look into it though
[16:32] <DBO> jjohansen, false alarm, it might have improved it for a bit, but it just did it again :/
[16:32] <jjohansen> DBO: :(
[16:33] <DBO> jjohansen, https://bugzilla.redhat.com/show_bug.cgi?id=729618
[16:33] <DBO> that looks interesting
[16:35] <ubot2> bugzilla.redhat.com bug 729618 in kernel "rtl8192ce reloads firmware all the time" [High,New]
[16:39] <jjohansen> DBO: hrmm, interesting
[16:40] <apw>  DBO reference that in the ubuntu bug you make
[16:40] <DBO> yeah
[16:42] <DBO> it looks liek the driver stops receiving beacons...
[16:53] <cking> is there a kt meeting this week?
[16:54]  * smb thinks not until after the big meeting called uds
[16:54] <bjf> cking: no further irc meetings until post uds
[16:54] <cking> ah, usual pattern
[19:25] <Q-FUNK> ogasawara: I'm not involved on the kernel list, but I would have one simple request:  if the team decides to keep distinct server and desktop kernels, please rename -generic to -desktop.
[19:38] <bjf> bug #873119
[19:43] <t3_> Greetings. I'm having a problem with KVM in 2.6.38-11-server and was wondering what problems I might run into if I use 2.6.38-12-generic (bug seems to be fixed there)? I'm using standard HW...
[19:50] <bjf> t3_, have you tried the 2.6.38-12-server ?
[19:53] <t3_> That would make a lot of sense... I must have missed it.
[19:55] <t3_> I'm not seeing that in the list of kernels, what repo is it in?
[19:55] <bjf> t3_: it's in -proposed right now
[19:58] <t3_> bjf, thanks.  I'll grab that one instead and see if it fixes the issue.
[19:59] <bjf> t3_: cool, let us know if it doesn't
[20:00] <t3_> bjf: will do, ttyl
[23:03] <twb> I'm a bit confused; I git cloned the lucid kernel repo, copied the .config from /boot of a lucid box, did a "make deb-pkg", installed it, did a "update-initramfs -c -k xxx".  The resulting ramdisk was 71MB where it should've been more like 13MB
[23:03] <twb> I noticed that the -Os option was off in .config, but AFAIK it was like that already; I didn't mess with it.
[23:06] <twb> I suppose the other likely thing I did different, was compiling on hardy
[23:26] <twb> Building it with -Os doesn't help; the resulting ramdisk is 68MB
[23:26] <twb> WTF, man.
[23:27] <twb> I'll try building it inside a lucid chroot (hence gcc 4.4 or so)
[23:30] <jjohansen> twb: did you strip it?
[23:31] <twb> Not explicitly, but IME make deb-pkg does that for me
[23:31] <twb> I'll check
[23:31] <twb> Ah, good catch
[23:36] <twb> So why didn't it strip them?  Is it just that the 2.6.32 kernel predates that feature in the deb-pkg approach?