[00:20] <christine> hey folks, I wanted to point out that in USN-1431-1, the description for CVE-2011-4086 is wrong
[00:20] <ubot2> christine: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4086)
[00:20] <christine> that CVE is jbd-related, not ext4-related
=== bdmurray_ is now known as bdmurray
[02:06] <infinity> ogasawara: New kernel's through NEW finally, if you had a meta to follow it up with.
[02:16] <akgraner> ogasawara, congrats!
[03:59] <Q-FUNK> was the non-PAE kernel dropped starting from Quantal?
[04:07] <Q-FUNK> I know that the eventuality of this happening had been discussed many times, but I haven't seen any press releases or such that would indicate a suitable upgrade path for those affected.
=== Amoz_ is now known as Amoz
[06:36] <ppisati> moin
=== dupondje_ is now known as dupondje
=== smb` is now known as smb
[07:16] <smb> morning
[07:27]  * apw yawns
[07:27] <RAOF> Bring in the bees!
[07:38] <ppisati> apw: for when you are awake - bug 951043
[07:38] <ubot2> Launchpad bug 951043 in linux-ti-omap4 "Port OOM changes into do_page_fault for arm" [Medium,Confirmed] https://launchpad.net/bugs/951043
[07:38] <ppisati> apw: weren't you porting this to master?
[07:40] <apw> ppisati, i don't recall at all, but it sounds like we'd want that on omap* indeed
[07:41] <ppisati> apw: ok, then i'm wrong
=== mthaddon` is now known as mthaddon
[07:41] <ppisati> apw: i'll do
[07:42] <apw> ppisati, thanks sounds good; and you may be right, i just don't recall anymore
=== Guest77193 is now known as yofel
=== yofel is now known as Guest53016
=== Guest53016 is now known as yofel_
=== lool- is now known as lool
=== ikonia_ is now known as ikonia
=== chuck_ is now known as zul
[12:26]  * apw has to get some keys done ... back in a bit
[13:25] <ogasawara> tgardner: I'm gonna fix up meta to transition -generic to -generic-pae before uploading, or did you already have something?
[13:26] <tgardner> ogasawara, I didn't, but I'm not sure thats the right thing to do. folks that chose -generic likely have a CPU that _can't_ run PAE
[13:28] <ogasawara> tgardner: so should we remove the generic flavor completely from meta?  Otherwise it points to a non-existent kernel
[13:28] <tgardner> ogasawara, for Quantal. Precise is the end of the line for non-PAE
[13:28] <tgardner> there is no upgrade path
[13:29] <ogasawara> tgardner: so what happens if they do try to upgrade?  they remain on the Precise 3.2.0 kernel?
[13:30] <tgardner> ogasawara, I guess. you sure don't wanna upgrade them to an unbootable kernel
[13:31] <tgardner> ogasawara, surely Debian has encountered this issue before. perhaps we should ask slangasek
[13:31] <ogasawara> tgardner: I'm gonna hold off on the upload for now, till we get it sorted.  Since this will be the first upload for linux-meta I want to make sure we get it right.
[13:32] <tgardner> ogasawara, so I've already removed the non-PAE meta package, right? the worst that can happen is that we add them back, but point them at something uninstallable.
[13:36] <ogasawara> tgardner: yep, they're removed.  so my thinking is we remove the generic flavor from meta and users will remain with the precise kernel if they upgrade (at least for now).
[13:36] <ogasawara> tgardner: and like you said, we can add it back later if needed
[13:36] <tgardner> ogasawara, agreed
[13:36] <ogasawara> tgardner: I'll throw it on to our version and flavors discussion for UDS
[13:37] <tgardner> ogasawara, we do need to figure out how to make the upgrade beyond Precise _very_ difficult so that the average user can't bork their system without trying really hard.
[13:40] <apw_> tgardner: how does regulatory work with passive scan? 
[13:40] <tgardner> apw: not as well as you'd think. sforshee` has encountered some issues with it.
[13:41] <tgardner> apw: it is somewhat driver and HW dependent
[13:41] <apw_> tgardner: have a public ap here on 13 an illegal channel here, sshouldnt i still see it under passive?
[13:41] <apw_> bust with brcm me thinks
[13:42] <tgardner> apw: not necessarily. if the EPROM on your wifi device thinks is US born, then no channel 13
[13:42] <apw_> but that makes no,sense when somewhere elsr
[13:42] <tgardner> apw: I think you can override that using 'iw'
[13:43] <apw_> and this is uk laptop, but think as you suggest a us thinking chip
[13:43] <apw_> overridden to gb it sees the ap
[13:43] <tgardner> well then, bob's your uncle
[13:43] <apw_> but all outgoingg packets look to be dropped
[13:44] <apw_> must setup a test for this at home
[13:44] <apw_> i hate brcm
[13:45] <tgardner> so, you must be in a coffee shop where only Brits (with Brit local wifi adapters) get to surf :)
[13:53] <sforshee`> apw, if it's brcmsmac the regulatory is pretty broken
[13:53] <apw_> it is ... indeed
[13:53] <sforshee`> I haven't tried channel 13 though
[13:53] <apw_> no good here.
[13:54] <sforshee`> apw_, is it precise?
[13:54] <apw_> tgardner: was indeed
[13:54] <apw_> sforshee`: yep
[13:54] <sforshee`> there was a patch that might help, not sure if we got it in precise
[13:54]  * sforshee` looks
[13:55] <tgardner> sforshee`, I don't think we did yet
[13:55] <sforshee`> badc4f07622f0f7093a201638f45e85765f1b5e4 is the upstream commit, and it was cc stable
[13:57] <tgardner> sforshee`, I'm not seeing it in precise
[13:57] <sforshee`> tgardner, me neither
[13:58] <sforshee`> apw_, you can't see the channel at all? that patch won't help then
[13:59] <sforshee`> apw_, what does 'iw reg get' say?
[13:59] <tgardner> perhaps herton should be pouring patches into 3.2 stable on the mailing list
[13:59] <apw_> i can see yhe channel if i move to gb, it says us by default
[13:59] <sforshee`> US? I would have expected 00
[14:00] <sforshee`> unless the card has US in its rom
[14:01] <herton> tgardner, I can send, I expect Ben to pick it up though
[14:02] <herton> since it's marked for stable
[14:02] <tgardner> herton, well, we could do some of the legwork for him
[14:03] <tgardner> herton, perhaps prep a branch with everything from 3.3.y that applies and makes sense. maybe even do some smoke testing.
=== sforshee` is now known as sforshee
[14:19] <apw_> sforshee: must be card that thinks us indeed ... is world before that
[14:29] <tgardner> ogasawara, are you done building in the tangerine quantal chroot for awhile ?
[14:29] <ogasawara> tgardner: nope
[14:29] <tgardner> ogasawara, lemme know when you're done
[14:29] <ogasawara> tgardner: bah, I meant nope I'm not building in it
[14:29] <tgardner> need to regen the chroots
[14:29] <tgardner> ogasawara, ack
[14:34] <slangasek> tgardner: Debian certainly has dealt with dropping support for older machines in kernel flavors before, but I can't say as I remember what was done with the metapackages
[14:35] <tgardner> slangasek, maybe I'll drop a note on ubuntu-devel and solicit some opinions
[14:37]  * ogasawara back in 20
[14:37] <apw> tgardner, i think 'we' should be indeed sending in tested combinations for him, and asking him for branches to test aganinst
[14:37] <apw> tgardner, as soon as he has them i'll get them building in our autobits
[14:38] <apw> tgardner, actually where do tehy hang out so i can ask
[14:38] <tgardner> apwthe royal "we", as in herton ?
[14:39] <tgardner> apw: ^^
[14:39] <apw> tgardner, indeed that 'we'
[14:39] <tgardner> apw: I think thas an excellent idea
[14:39] <cking>   
[14:48] <smb> (no comment)
[14:51] <mdeslaur> herton: think you can get me a 3.4rc5 kernel with the upstream patch from here? https://bugs.freedesktop.org/show_bug.cgi?id=40172#c17
[14:51] <mdeslaur> herton: it's for LP: #814325
[14:51] <ubot2> Freedesktop bug 40172 in DRM/Intel "[arrandale] Fuzzy screen after dpms cycles on lenovo t510 [bisected, 3.0+]" [Normal,Needinfo: ]
[14:52] <herton> mdeslaur, I can built one, precise?
[14:52] <herton> *build
=== cmagina_ is now known as cmagina
[14:53] <mdeslaur> herton: yes, please...this one: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-rc5-precise/
[14:54] <dileks> http://womble.decadent.org.uk/blog/upcoming-changes-in-debian-linux-packages-for-i386.html
[14:55] <dileks> about 486/686-pae
[14:58] <jsalisbury> apw, if you have a chance, can you take a look at bug 987679  I'm  not sure if this is an upstream issue or not.
[14:58] <ubot2> Launchpad bug 987679 in linux "/tools/hv/hv_kvp_daemon.8 missing" [Medium,Confirmed] https://launchpad.net/bugs/987679
[15:00] <tgardner> jsalisbury, thats a man page
[15:00] <tgardner> jsalisbury, there does not appear to be one in the upstream repo
[15:01] <jsalisbury> tgardner, interesting, so it must be an upstream bug as well.
[15:02] <tgardner> jsalisbury, I doubt if upstream really cares. they'll say something like, RTFS if you want to know how this daemon works.
[15:02] <jsalisbury> tgardner, yeah, right.
[15:02] <tgardner> jsalisbury, its definitely a "won't fix" on our part.
[15:03] <jsalisbury> tgardner, understood.  Thanks for the info.
[15:03] <apw> jsalisbury, its definatly and upstream issue, but i'd expect us to be hitting it in quantal ... hrm
[15:03] <apw> oh hrm, or did i write it
[15:03]  * apw looks
[15:04] <apw> jsalisbury, ahh i did indeed.  i'll add that to my upstreaming list
[15:04] <tgardner> apw: ineed, _we_ have a man page
[15:21] <jsalisbury> First Quantal kernel bug, bug 992968
[15:21] <ubot2> Launchpad bug 992968 in linux "Large file transfer to Sandisk Cruzer 8GB USB hangs for a long time" [Medium,New] https://launchpad.net/bugs/992968
[15:22] <ogasawara> jsalisbury: is that really with the 3.4 kernel?
[15:22] <apw> jsalisbury, that is most likely just a lie
[15:22] <apw> jsalisbury, he copies the files on and confirms they are 'on there' via the memory cache
[15:22] <jsalisbury> ogasawara, apw, no 3.2.0-24 kernel
[15:22] <apw> jsalisbury, if the stick is slow then that would still be syncing the data to the stick
[15:23] <jsalisbury> ogasawara, apw, DistroRelease reads 12.10 though 
[15:23] <apw> jsalisbury, but the system would correctly see them on there, in its cached world
[15:23] <apw> UpgradeStatus: Upgraded to quantal on 2012-04-06 (25 days ago)
[15:23] <apw> that is somewhat unlikely
=== _bjf is now known as bjf
[15:24] <jsalisbury> apw, yeah, not sure how that happened
[15:25] <apw> jsalisbury, i am asking pitti now on #ubuntu-devel
[15:25] <apw> jsalisbury, and i think we need find out if the device has an acticity light, also ask him to type sync at hte point the files "are all there" and see how long that takes
[15:25] <tgardner> apw, maybe the user's time of day is scrogged
[15:26] <apw> perhaps
[15:28] <tgardner> jsalisbury, regardless of the date, there was no Quantal kernel until about an hour ago
[15:28] <jsalisbury> tgardner, ok, so I guess this isn't the first kernel bug for quantal then :-(
[15:29] <tgardner> dpkg -l|grep linux-image
[15:29] <tgardner> doh
[15:29] <apw> tgardner, :)
[15:30] <tgardner> apw, at least it wasn't my password.
[15:30] <apw> tgardner, heh at least that
[15:31] <apw> tgardner, or you are being very clever and covering the fact that that _is_ your password
[15:31] <ogasawara> heheh
[15:32] <ogasawara> apw: you'd made some human_arch changes a while back so that our package descriptions could be more accurate.  However, something is a bit off -> https://launchpad.net/ubuntu/precise/i386/linux-image-3.2.0-24-generic/3.2.0-24.37
[15:32] <ogasawara> apw: I'm having trouble reproducing it, any thoughts how the 64bit description is getting generated for the i386 package?
[15:33] <apw> ogasawara, looking
[15:33] <tgardner> i386 v.s. 64 bit
[15:33] <apw> ogasawara, urgle
[15:34] <apw> ogasawara, leave it with me /me gets the hammer out
[15:34] <ogasawara> apw: ack, thanks
[15:37] <apw> ogasawara, there is something off here, as if the descriptions are from the wrong place ... will investigate
[15:38] <ogasawara> apw: indeed.  And I tried to reproduce in a precise-i386 chroot but it generated the correct control file, so I am confused
[15:39] <apw> ogasawara, i am suspicious we are using the descriptions in the source package perhaps
[15:39] <apw> ogasawara, whihc might mean it depends on the arch in which we built the src ... asking now
[15:43] <henrix> apw: about that issue, it looks like it happens on i386 and omap images, but not on the ppc
[15:43] <apw> henrix, yep, would do as they are always the same there
[15:44] <henrix> apw: not sure if i understand what you mean. why wouldn't the issue happen on the powerpc then?
[15:45] <apw> henrix, nope cause there is only one powerpc architecture
[15:45] <apw> henrix, and it has non-overlapping arch names
[15:45] <henrix> apw: right, but on the omap image you get: "TI OMAP3-based 64 bit x86 systems." :)
[15:46] <apw> henrix, heh lovely indeed
[15:46] <apw> henrix, /me is investigating
[15:53] <dileks> some docs around howto unpack/add-nifty-software/repack an existing iso?
[15:54]  * dileks would add his linux-image with overlayfs and test that
[15:55] <htorque> hi all! should 'apparmor_status' return 'apparmor module is loaded.' when booting with 'apparmor=0'? i'm trying to figure out why i cannot run systemtap as user and maybe it's connected to apparmor.
[15:55] <herton> mdeslaur, kernel with that patch available here: http://people.canonical.com/~herton/lp814325/mainline1/
[15:56] <mdeslaur> herton: awesome, thanks!
[15:58] <ogasawara> dileks: I've used https://help.ubuntu.com/community/LiveCDCustomization in the past
[16:00] <dileks> hmm, aufs
[16:00] <dileks> http://live.debian.net/gitweb?p=live-boot.git;a=commitdiff;h=b981b862888aa4b345e6af8a1af65253378919b7
[16:01] <dileks> I will combine that
[16:03]  * dileks -> lunch
=== cnd` is now known as cnd
[16:29]  * ppisati -> gym/workout
[16:30] <apw> ogasawara, herton, ok i know why it happens, now to fix it
[16:30] <ogasawara> apw: cool, care to share?
[16:31] <tgardner> perhaps in the form of  a patch :)
[16:31] <apw> ogasawara, control.stub is in the source pacakge, and is the arch you built the source package on
[16:31] <apw> tgardner, :) indeed
[16:31] <ogasawara> apw: I thought it's then regenerated upon the buildd?  apparently not
[16:31] <apw> ogasawara, oh we intend that behaviour, but ... its not
[16:32] <henrix> apw: ah, makes sense
[16:32]  * apw fixes
[16:32] <tgardner> I see some debian/rules dependency changes forthcoming
[16:32] <apw> yep :)
[16:33] <henrix> apw: can't we just prevent control.stub to be in the src pkg? (no idea how to do that atm)
[16:33] <apw> henrix, i think i can just remove the stub dependancy and be happy
[16:33] <ogasawara> henrix: indeed, was curious if we just omit it from the packaging what fun sort of fun breakage we'd incur
[16:36] <apw> ogasawara, it would be fine to omit it as we would then just rebuild it anyhow
[16:36] <apw> ogasawara, but ... its not real anyhow
[16:38] <ogasawara> apw: fyi, it's bug 992414 if you needed a BugLink for the SRU
[16:38] <ubot2> Launchpad bug 992414 in linux "linux-image-generic tells it is 64-bit even for 32-bit" [Medium,Confirmed] https://launchpad.net/bugs/992414
[16:39] <apw> ogasawara, thanks
[16:39] <apw> ogasawara, when we uploading quantal next ?
[16:39] <apw> ogasawara, i'd like to confirm this fixes it in there
[16:39] <ogasawara> apw: we can upload anytime
[16:39] <apw> ogasawara, any shiney new rebases yet?
[16:39] <ogasawara> apw: I haven't seen any
[16:40] <tgardner> apw, buildd's are free, right ?
[16:40] <apw> ok this looks much better... and a very simple change
[16:40] <apw> tgardner, heh yep
[16:40] <apw> ogasawara, so i can see from the history you build in amd64 and i in i386 chroots :)
[16:40] <ogasawara> apw: hehehe
[16:41] <ogasawara> apw: and that explains why when I checked the generic-pae build on quantal it was showing the correct text
[16:42] <apw> ogasawara, indeed, thats the reason, the amd64 is wrong there
[16:44]  * ogasawara fixes getabi's in quantal to not fetch -generic
[16:45] <tgardner> ogasawara, oops
[16:45] <ogasawara> tgardner: eh, doesn't really hurt anything.  just a split second of wtf when I see FAILED.
[16:48] <apw> ogasawara, ok fix pushed to quantal
[16:49] <ogasawara> apw: cool, will get it uploaded
[16:49] <apw> herton, we are only seeing this in precise right ?
[16:49] <apw> s/this/the wrong architecture strings/
[16:49] <herton> henrix ^
[16:49] <apw> :)
[16:50]  * apw suggests one of you needs a new first letter
[16:50] <henrix> apw: yep, i believe so
[16:50] <herton> yep :)
[16:50]  * henrix goes confirm this
[16:53] <apw> herton, remind me of where i can find the SRU template for bugs
[16:55] <herton> apw, a bit lost on all wiki pages, the justification is listed here https://wiki.ubuntu.com/KernelTeam/StableHandbook/StableProcess
[16:55] <herton> number 4 on "Workflow for SRU Patches"
[16:56] <henrix> apw: yep, oneiric seems to be ok
[16:58] <apw> herton, thanks
[16:58] <apw> henrix, thanks
[16:58] <apw> ogasawara, t
[16:58] <apw> ogasawara, tgardner, patch on the list
[16:58] <ogasawara> apw: ack
[17:00] <tgardner> apw, quantal looks good
[17:01] <apw> tgardner, yeah nice and simple once you know what it is ... near lost my remaining hair there
=== yofel_ is now known as yofel
=== tgardner is now known as tgardner-afk
=== tgardner-afk is now known as tgardner
[19:24] <jsalisbury> henrix, Should bug 984387 be fixed in precise as well as oneiric?  I've see some reports that the bug(Or a similar issue) still exists in precise.  For example, bug 989677
[19:24] <ubot2> Launchpad bug 984387 in linux "[Dell Studio XPS 1340,Alienware m17x] Kernel panic with 3.0.0-19 and 3.2.0-18 on boot" [Medium,Confirmed] https://launchpad.net/bugs/984387
[19:24] <ubot2> Launchpad bug 989677 in linux "kernel panic with ubuntu 12.04 install" [High,Confirmed] https://launchpad.net/bugs/989677
[19:33] <tgardner> jsalisbury, its already applied to precise
[19:34] <jsalisbury> tgardner, hmm, that's why I wanted to ask.  The backtrace in bug 984387 looks very similar, but he's running the latest precise kernel.
[19:34] <ubot2> Launchpad bug 984387 in linux "[Dell Studio XPS 1340,Alienware m17x] Kernel panic with 3.0.0-19 and 3.2.0-18 on boot" [Medium,Confirmed] https://launchpad.net/bugs/984387
[19:34] <jsalisbury> whoops I meant bug 989677
[19:34] <ubot2> Launchpad bug 989677 in linux "kernel panic with ubuntu 12.04 install" [High,Confirmed] https://launchpad.net/bugs/989677
[19:36] <jsalisbury> tgardner, looks like ite_cir in that bug as well
[19:36] <ogasawara> jsalisbury: it was only fixed in precise in the day-0 kernel, ie when using the LiveCD they'll need the workaround
[19:36] <jsalisbury> ogasawara, ahh, ok.  Understood
[19:38] <tgardner> ogasawara, the last guy says he's using Ubuntu-3.2.0-24.37, but he also says his bug is fixed. I'm a bit confused
[19:40] <tgardner> these definitely look like the same bug
[19:42] <jsalisbury> tgardner, ogasawara So this bug should be fixed in Ubuntu-3.2.0-24.37 - without the workaround?  If so, I'll ask all the bug reporters to confirm that is the case, since there are a few of them.
[19:42] <tgardner> jsalisbury, correct
[19:42] <ogasawara> jsalisbury: yes, should be fixed without needing the workaround
[19:43] <jsalisbury> tgardner, ogasawara, ok, I'll ask for confirmation then.
[20:16] <henrix> jsalisbury: sorry for the delay. i was away (dinner time)
[20:16] <henrix> jsalisbury: but i guess its sorted out now :)
[20:21] <jsalisbury> henrix, yes, thanks and sorry to interrupt your dinner ;-)
[20:22] <henrix> jsalisbury: no worries, you didn't! that's why i haven't replied earlier :)
[20:22] <jsalisbury> henrix, cool, thanks
[20:34]  * tgardner -> EOD
[21:29] <jsalisbury> jsalisbury@salisbury:~$ uname -a
[21:29] <jsalisbury> Linux salisbury 3.4.0-1-generic #3 SMP Wed May 2 19:09:18 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[21:29] <jsalisbury> :-D