/srv/irclogs.ubuntu.com/2012/05/02/#ubuntu-kernel.txt

christinehey folks, I wanted to point out that in USN-1431-1, the description for CVE-2011-4086 is wrong00:20
ubot2christine: ** 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
christinethat CVE is jbd-related, not ext4-related00:20
=== bdmurray_ is now known as bdmurray
infinityogasawara: New kernel's through NEW finally, if you had a meta to follow it up with.02:06
akgranerogasawara, congrats!02:16
Q-FUNKwas the non-PAE kernel dropped starting from Quantal?03:59
Q-FUNKI 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.04:07
=== Amoz_ is now known as Amoz
ppisatimoin06:36
=== dupondje_ is now known as dupondje
=== smb` is now known as smb
smbmorning07:16
* apw yawns07:27
RAOFBring in the bees!07:27
ppisatiapw: for when you are awake - bug 95104307:38
ubot2Launchpad bug 951043 in linux-ti-omap4 "Port OOM changes into do_page_fault for arm" [Medium,Confirmed] https://launchpad.net/bugs/95104307:38
ppisatiapw: weren't you porting this to master?07:38
apwppisati, i don't recall at all, but it sounds like we'd want that on omap* indeed07:40
ppisatiapw: ok, then i'm wrong07:41
=== mthaddon` is now known as mthaddon
ppisatiapw: i'll do07:41
apwppisati, thanks sounds good; and you may be right, i just don't recall anymore07:42
=== 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
* apw has to get some keys done ... back in a bit12:26
ogasawaratgardner: I'm gonna fix up meta to transition -generic to -generic-pae before uploading, or did you already have something?13:25
tgardnerogasawara, 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 PAE13:26
ogasawaratgardner: so should we remove the generic flavor completely from meta?  Otherwise it points to a non-existent kernel13:28
tgardnerogasawara, for Quantal. Precise is the end of the line for non-PAE13:28
tgardnerthere is no upgrade path13:28
ogasawaratgardner: so what happens if they do try to upgrade?  they remain on the Precise 3.2.0 kernel?13:29
tgardnerogasawara, I guess. you sure don't wanna upgrade them to an unbootable kernel13:30
tgardnerogasawara, surely Debian has encountered this issue before. perhaps we should ask slangasek13:31
ogasawaratgardner: 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:31
tgardnerogasawara, 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:32
ogasawaratgardner: 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
ogasawaratgardner: and like you said, we can add it back later if needed13:36
tgardnerogasawara, agreed13:36
ogasawaratgardner: I'll throw it on to our version and flavors discussion for UDS13:36
tgardnerogasawara, 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:37
apw_tgardner: how does regulatory work with passive scan? 13:40
tgardnerapw: not as well as you'd think. sforshee` has encountered some issues with it.13:40
tgardnerapw: it is somewhat driver and HW dependent13: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 thinks13:41
tgardnerapw: not necessarily. if the EPROM on your wifi device thinks is US born, then no channel 1313:42
apw_but that makes no,sense when somewhere elsr13:42
tgardnerapw: I think you can override that using 'iw'13:42
apw_and this is uk laptop, but think as you suggest a us thinking chip13:43
apw_overridden to gb it sees the ap13:43
tgardnerwell then, bob's your uncle13:43
apw_but all outgoingg packets look to be dropped13:43
apw_must setup a test for this at home13:44
apw_i hate brcm13:44
tgardnerso, you must be in a coffee shop where only Brits (with Brit local wifi adapters) get to surf :)13:45
sforshee`apw, if it's brcmsmac the regulatory is pretty broken13:53
apw_it is ... indeed13:53
sforshee`I haven't tried channel 13 though13:53
apw_no good here.13:53
sforshee`apw_, is it precise?13:54
apw_tgardner: was indeed13:54
apw_sforshee`: yep13:54
sforshee`there was a patch that might help, not sure if we got it in precise13:54
* sforshee` looks13:54
tgardnersforshee`, I don't think we did yet13:55
sforshee`badc4f07622f0f7093a201638f45e85765f1b5e4 is the upstream commit, and it was cc stable13:55
tgardnersforshee`, I'm not seeing it in precise13:57
sforshee`tgardner, me neither13:57
sforshee`apw_, you can't see the channel at all? that patch won't help then13:58
sforshee`apw_, what does 'iw reg get' say?13:59
tgardnerperhaps herton should be pouring patches into 3.2 stable on the mailing list13:59
apw_i can see yhe channel if i move to gb, it says us by default13:59
sforshee`US? I would have expected 0013:59
sforshee`unless the card has US in its rom14:00
hertontgardner, I can send, I expect Ben to pick it up though14:01
hertonsince it's marked for stable14:02
tgardnerherton, well, we could do some of the legwork for him14:02
tgardnerherton, perhaps prep a branch with everything from 3.3.y that applies and makes sense. maybe even do some smoke testing.14:03
=== sforshee` is now known as sforshee
apw_sforshee: must be card that thinks us indeed ... is world before that14:19
tgardnerogasawara, are you done building in the tangerine quantal chroot for awhile ?14:29
ogasawaratgardner: nope14:29
tgardnerogasawara, lemme know when you're done14:29
ogasawaratgardner: bah, I meant nope I'm not building in it14:29
tgardnerneed to regen the chroots14:29
tgardnerogasawara, ack14:29
slangasektgardner: 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 metapackages14:34
tgardnerslangasek, maybe I'll drop a note on ubuntu-devel and solicit some opinions14:35
* ogasawara back in 2014:37
apwtgardner, i think 'we' should be indeed sending in tested combinations for him, and asking him for branches to test aganinst14:37
apwtgardner, as soon as he has them i'll get them building in our autobits14:37
apwtgardner, actually where do tehy hang out so i can ask14:38
tgardnerapwthe royal "we", as in herton ?14:38
tgardnerapw: ^^14:39
apwtgardner, indeed that 'we'14:39
tgardnerapw: I think thas an excellent idea14:39
cking  14:39
smb(no comment)14:48
mdeslaurherton: think you can get me a 3.4rc5 kernel with the upstream patch from here? https://bugs.freedesktop.org/show_bug.cgi?id=40172#c1714:51
mdeslaurherton: it's for LP: #81432514:51
ubot2Freedesktop bug 40172 in DRM/Intel "[arrandale] Fuzzy screen after dpms cycles on lenovo t510 [bisected, 3.0+]" [Normal,Needinfo: ]14:51
hertonmdeslaur, I can built one, precise?14:52
herton*build14:52
=== cmagina_ is now known as cmagina
mdeslaurherton: yes, please...this one: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-rc5-precise/14:53
dilekshttp://womble.decadent.org.uk/blog/upcoming-changes-in-debian-linux-packages-for-i386.html14:54
dileksabout 486/686-pae14:55
jsalisburyapw, 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
ubot2Launchpad bug 987679 in linux "/tools/hv/hv_kvp_daemon.8 missing" [Medium,Confirmed] https://launchpad.net/bugs/98767914:58
tgardnerjsalisbury, thats a man page15:00
tgardnerjsalisbury, there does not appear to be one in the upstream repo15:00
jsalisburytgardner, interesting, so it must be an upstream bug as well.15:01
tgardnerjsalisbury, I doubt if upstream really cares. they'll say something like, RTFS if you want to know how this daemon works.15:02
jsalisburytgardner, yeah, right.15:02
tgardnerjsalisbury, its definitely a "won't fix" on our part.15:02
jsalisburytgardner, understood.  Thanks for the info.15:03
apwjsalisbury, its definatly and upstream issue, but i'd expect us to be hitting it in quantal ... hrm15:03
apwoh hrm, or did i write it15:03
* apw looks15:03
apwjsalisbury, ahh i did indeed.  i'll add that to my upstreaming list15:04
tgardnerapw: ineed, _we_ have a man page15:04
jsalisburyFirst Quantal kernel bug, bug 99296815:21
ubot2Launchpad bug 992968 in linux "Large file transfer to Sandisk Cruzer 8GB USB hangs for a long time" [Medium,New] https://launchpad.net/bugs/99296815:21
ogasawarajsalisbury: is that really with the 3.4 kernel?15:22
apwjsalisbury, that is most likely just a lie15:22
apwjsalisbury, he copies the files on and confirms they are 'on there' via the memory cache15:22
jsalisburyogasawara, apw, no 3.2.0-24 kernel15:22
apwjsalisbury, if the stick is slow then that would still be syncing the data to the stick15:22
jsalisburyogasawara, apw, DistroRelease reads 12.10 though 15:23
apwjsalisbury, but the system would correctly see them on there, in its cached world15:23
apwUpgradeStatus: Upgraded to quantal on 2012-04-06 (25 days ago)15:23
apwthat is somewhat unlikely15:23
=== _bjf is now known as bjf
jsalisburyapw, yeah, not sure how that happened15:24
apwjsalisbury, i am asking pitti now on #ubuntu-devel15:25
apwjsalisbury, 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 takes15:25
tgardnerapw, maybe the user's time of day is scrogged15:25
apwperhaps15:26
tgardnerjsalisbury, regardless of the date, there was no Quantal kernel until about an hour ago15:28
jsalisburytgardner, ok, so I guess this isn't the first kernel bug for quantal then :-(15:28
tgardnerdpkg -l|grep linux-image15:29
tgardnerdoh15:29
apwtgardner, :)15:29
tgardnerapw, at least it wasn't my password.15:30
apwtgardner, heh at least that15:30
apwtgardner, or you are being very clever and covering the fact that that _is_ your password15:31
ogasawaraheheh15:31
ogasawaraapw: 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.3715:32
ogasawaraapw: I'm having trouble reproducing it, any thoughts how the 64bit description is getting generated for the i386 package?15:32
apwogasawara, looking15:33
tgardneri386 v.s. 64 bit15:33
apwogasawara, urgle15:33
apwogasawara, leave it with me /me gets the hammer out15:34
ogasawaraapw: ack, thanks15:34
apwogasawara, there is something off here, as if the descriptions are from the wrong place ... will investigate15:37
ogasawaraapw: indeed.  And I tried to reproduce in a precise-i386 chroot but it generated the correct control file, so I am confused15:38
apwogasawara, i am suspicious we are using the descriptions in the source package perhaps15:39
apwogasawara, whihc might mean it depends on the arch in which we built the src ... asking now15:39
henrixapw: about that issue, it looks like it happens on i386 and omap images, but not on the ppc15:43
apwhenrix, yep, would do as they are always the same there15:43
henrixapw: not sure if i understand what you mean. why wouldn't the issue happen on the powerpc then?15:44
apwhenrix, nope cause there is only one powerpc architecture15:45
apwhenrix, and it has non-overlapping arch names15:45
henrixapw: right, but on the omap image you get: "TI OMAP3-based 64 bit x86 systems." :)15:45
apwhenrix, heh lovely indeed15:46
apwhenrix, /me is investigating15:46
dilekssome docs around howto unpack/add-nifty-software/repack an existing iso?15:53
* dileks would add his linux-image with overlayfs and test that15:54
htorquehi 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
hertonmdeslaur, kernel with that patch available here: http://people.canonical.com/~herton/lp814325/mainline1/15:55
mdeslaurherton: awesome, thanks!15:56
ogasawaradileks: I've used https://help.ubuntu.com/community/LiveCDCustomization in the past15:58
dilekshmm, aufs16:00
dilekshttp://live.debian.net/gitweb?p=live-boot.git;a=commitdiff;h=b981b862888aa4b345e6af8a1af65253378919b716:00
dileksI will combine that16:01
* dileks -> lunch16:03
=== cnd` is now known as cnd
* ppisati -> gym/workout16:29
apwogasawara, herton, ok i know why it happens, now to fix it16:30
ogasawaraapw: cool, care to share?16:30
tgardnerperhaps in the form of  a patch :)16:31
apwogasawara, control.stub is in the source pacakge, and is the arch you built the source package on16:31
apwtgardner, :) indeed16:31
ogasawaraapw: I thought it's then regenerated upon the buildd?  apparently not16:31
apwogasawara, oh we intend that behaviour, but ... its not16:31
henrixapw: ah, makes sense16:32
* apw fixes16:32
tgardnerI see some debian/rules dependency changes forthcoming16:32
apwyep :)16:32
henrixapw: can't we just prevent control.stub to be in the src pkg? (no idea how to do that atm)16:33
apwhenrix, i think i can just remove the stub dependancy and be happy16:33
ogasawarahenrix: indeed, was curious if we just omit it from the packaging what fun sort of fun breakage we'd incur16:33
apwogasawara, it would be fine to omit it as we would then just rebuild it anyhow16:36
apwogasawara, but ... its not real anyhow16:36
ogasawaraapw: fyi, it's bug 992414 if you needed a BugLink for the SRU16:38
ubot2Launchpad bug 992414 in linux "linux-image-generic tells it is 64-bit even for 32-bit" [Medium,Confirmed] https://launchpad.net/bugs/99241416:38
apwogasawara, thanks16:39
apwogasawara, when we uploading quantal next ?16:39
apwogasawara, i'd like to confirm this fixes it in there16:39
ogasawaraapw: we can upload anytime16:39
apwogasawara, any shiney new rebases yet?16:39
ogasawaraapw: I haven't seen any16:39
tgardnerapw, buildd's are free, right ?16:40
apwok this looks much better... and a very simple change16:40
apwtgardner, heh yep16:40
apwogasawara, so i can see from the history you build in amd64 and i in i386 chroots :)16:40
ogasawaraapw: hehehe16:40
ogasawaraapw: and that explains why when I checked the generic-pae build on quantal it was showing the correct text16:41
apwogasawara, indeed, thats the reason, the amd64 is wrong there16:42
* ogasawara fixes getabi's in quantal to not fetch -generic16:44
tgardnerogasawara, oops16:45
ogasawaratgardner: eh, doesn't really hurt anything.  just a split second of wtf when I see FAILED.16:45
apwogasawara, ok fix pushed to quantal16:48
ogasawaraapw: cool, will get it uploaded16:49
apwherton, we are only seeing this in precise right ?16:49
apws/this/the wrong architecture strings/16:49
hertonhenrix ^16:49
apw:)16:49
* apw suggests one of you needs a new first letter16:50
henrixapw: yep, i believe so16:50
hertonyep :)16:50
* henrix goes confirm this16:50
apwherton, remind me of where i can find the SRU template for bugs16:53
hertonapw, a bit lost on all wiki pages, the justification is listed here https://wiki.ubuntu.com/KernelTeam/StableHandbook/StableProcess16:55
hertonnumber 4 on "Workflow for SRU Patches"16:55
henrixapw: yep, oneiric seems to be ok16:56
apwherton, thanks16:58
apwhenrix, thanks16:58
apwogasawara, t16:58
apwogasawara, tgardner, patch on the list16:58
ogasawaraapw: ack16:58
tgardnerapw, quantal looks good17:00
apwtgardner, yeah nice and simple once you know what it is ... near lost my remaining hair there17:01
=== yofel_ is now known as yofel
=== tgardner is now known as tgardner-afk
=== tgardner-afk is now known as tgardner
jsalisburyhenrix, 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 98967719:24
ubot2Launchpad 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/98438719:24
ubot2Launchpad bug 989677 in linux "kernel panic with ubuntu 12.04 install" [High,Confirmed] https://launchpad.net/bugs/98967719:24
tgardnerjsalisbury, its already applied to precise19:33
jsalisburytgardner, 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
ubot2Launchpad 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/98438719:34
jsalisburywhoops I meant bug 98967719:34
ubot2Launchpad bug 989677 in linux "kernel panic with ubuntu 12.04 install" [High,Confirmed] https://launchpad.net/bugs/98967719:34
jsalisburytgardner, looks like ite_cir in that bug as well19:36
ogasawarajsalisbury: it was only fixed in precise in the day-0 kernel, ie when using the LiveCD they'll need the workaround19:36
jsalisburyogasawara, ahh, ok.  Understood19:36
tgardnerogasawara, 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 confused19:38
tgardnerthese definitely look like the same bug19:40
jsalisburytgardner, 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
tgardnerjsalisbury, correct19:42
ogasawarajsalisbury: yes, should be fixed without needing the workaround19:42
jsalisburytgardner, ogasawara, ok, I'll ask for confirmation then.19:43
henrixjsalisbury: sorry for the delay. i was away (dinner time)20:16
henrixjsalisbury: but i guess its sorted out now :)20:16
jsalisburyhenrix, yes, thanks and sorry to interrupt your dinner ;-)20:21
henrixjsalisbury: no worries, you didn't! that's why i haven't replied earlier :)20:22
jsalisburyhenrix, cool, thanks20:22
* tgardner -> EOD20:34
jsalisburyjsalisbury@salisbury:~$ uname -a21:29
jsalisburyLinux salisbury 3.4.0-1-generic #3 SMP Wed May 2 19:09:18 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux21:29
jsalisbury:-D21:29

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!