[00:00] <c_smith> is there a log I could pull up that might help me?
[00:00] <kees> ogasawara: oh good, thank you! my ARM environment is ... slow :)
[00:01] <bandit5432> you can open log manager
[00:01] <c_smith> kk
[00:15] <c_smith> gah, I am having no luck finding anything.
[00:16] <bandit5432> then try running it with the 2 sticks and see if you have errors or crashes if it crashes look in the logs and see what the log said before the crash
[00:23] <c_smith> I haven't had a crash at all with 2 sticks. and it only started when the 3 stick was properly inserted (it wasn't in to where it would recognize it before, due to me not having messed with RAM before)
[00:24] <bandit5432> i would say its a ram or slot issue and go from there
[00:25] <c_smith> well, most of this PC is going to be replaced in the future, it's several years old, so not surprising.
[00:25] <c_smith> thanks for the help. :)
[00:25] <bandit5432> no problem
[01:59] <jcastro> jsalisbury, I think you got it dude
[01:59] <jcastro> this one works
[01:59] <jcastro> it's only been since you posted it but with the last kernel by now it'd be hosed.
[02:00] <jcastro> I'll leave it running overnight though
[02:07] <ogasawara> kees: kernel uploaded, I'll keep an eye on it and rev lbm and meta when it's ready, we should hopefully have enough time to make it before freeze
[03:25] <bandit3453> i need some help running git bisect any one around that can coach me?
[04:02] <bandit3453> is any one running the 3.3 kernel with ide optical drives and can check and see if they work?
[04:03] <bandit3453> cat /var/log/dmesg | egrep '(CD|DVD)'
[04:27] <infinity> apw, ogasawara: linux-ti-omap4 through NEW, if someone wants to to give me a new meta for that.
[06:59] <AceLan> bjf: hihi, should I attach logs for the bug if I only want to send a patch? # ex. bug 961880 and bug 961879
[06:59] <ubot2`> Launchpad bug 961880 in linux "[ET2012] Press Fn+F7 could not turn on/off display" [Undecided,Incomplete] https://launchpad.net/bugs/961880
[06:59] <ubot2`> Launchpad bug 961879 in linux "[ET2012I+ATI] Brightness control doesn't work." [Undecided,Incomplete] https://launchpad.net/bugs/961879
[07:47]  * cking yawns
[07:55] <smb> cking, What threw you out of bed?
[07:56] <cking> the sunshine did
[08:32]  * cking --> re-installs after breaking his box :-/
[08:38] <apw> infinity, ack
[08:40] <smb> apw, morning
[08:41] <jk-> hey smb & apw
[08:41] <smb> jk-, heya
[08:41] <smb> apw, Btw, this is a morning to closely read what apt is about to do
[08:47] <apw> smb, is that why cking's machine is dead ?
[08:47] <smb> apw, yup
[08:47] <smb> Think some of unity decided to part ways ...
[08:48] <smb> I stopped after reading it wanted to remove bzr... Ok, not bzr's best friend but I need it anyways from time to time
[08:51] <apw> infinity, all done
[08:57] <smb> cking, We can hear
[08:57] <smb> cking, yes
[08:58] <smb> you need to be killing pulseaudio harder... :-P
[08:58] <cking> i can't hear anyone in mumble though :-/
[08:59] <smb> cking, We stopped saying anything after you "ignored" us a few times... :)
[09:00] <cking> heh, that was a forced ignored caused by a re-install ;-)
[09:00] <smb> cking, I know, just let us know if you want us to say something again
[09:01] <smb> cking, yes we cna
[09:01] <smb> can
[09:01] <smb> cking, and I sayd something
[09:01] <smb> you still cannot hear
[09:01] <smb> ppisati, can hear me
[09:02] <cking> bah
[09:03] <ppisati> "yes i can!"
[09:03] <smb> cking, still no luck for you
[09:03] <cking> nope - /me applies hammer to pulseaudio
[09:18] <apw> smb, so did you get 'deleting everything' or is it ok now, mine loooooks ok ?
[09:18] <smb> apw, No, not everything. It was just 4 to be deleted
[09:19] <apw> Calculating upgrade... Done
[09:19] <apw> The following packages will be upgraded:
[09:19] <smb> But I did upgrade instead of dist-upfrade then
[09:19] <apw> nothing to be deleted for me
[09:20] <smb> The following packages will be REMOVED
[09:20] <smb>   gnome-shell gnome-tweak-tool
[09:20] <smb> 30 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
[09:20] <ppisati> mine is ok
[09:20] <smb> The count is going down... 
[09:20] <ppisati> 165pkgs dist-upgraded
[09:32] <infinity> apw: lbm and linux-meta should be good to go too.
[09:39] <apw> infinity, thanks
[09:39] <infinity> apw: Seed already changed, we can rev d-i as soon as you get that meta in. ;)
[09:39] <infinity> s/Seed/Seeds/
[09:39] <apw> infinity, ack
[09:40] <apw> if my machine would respond to the 'q' i sent it a while back i might make some progress ... sigh
[09:49] <apw> infinity, lbm in the pipe/b #kitchen
[09:49] <apw> bah
[09:50] <infinity> apw: Do me a favour and upload -meta in ~13 minutes (ie: after :04)
[09:51] <infinity> apw: I'll make sure they both get in together.
[09:51] <apw> infinity, is that safe with lbm not yet built ?
[09:51] <infinity> apw: It'll be built by then. :P
[09:51] <apw> infinity, ack will do :)  i was going to be watching it and uploading as soon as done
[10:08] <ppisati> guys, how do i check what a package "Provides" via apt-*?
[10:08] <ppisati> i know i can check debian/control for a given src package
[10:08] <ppisati> but what about a binary package?
[10:09] <smb> ppisati, would apt-cache show <package> contain something?
[10:09] <ppisati> nope
[10:09] <ppisati> i already tried that
[10:09] <ppisati> flag@panda:~$ apt-cache show linux-headers-omap4 | grep -i provide
[10:09] <ppisati> flag@panda:~$
[10:10] <ppisati> but debian/control of the kernel packages has the Provides line
[10:10] <smb> ppisati, that sounds like the meta package for the headers...
[10:10] <ppisati> yep
[10:11] <ppisati> the point is that linux-heades-omap4 doesn't "Provide" linux-headers
[10:11] <smb> Well it like does not
[10:11] <smb> It only depends on the binary package
[10:11] <smb> which provides the headers...
[10:12] <ppisati> i think i lost you here :)
[10:12] <smb> apt-cache show linux-headers-generic
[10:12] <smb> Depends: linux-headers-3.2.0-19-generic
[10:12] <ppisati> ok
[10:12] <smb> apt-cache show linux-headers-3.2.0-19-generic
[10:13] <smb> Provides: linux-headers, linux-headers-3.0
[10:13] <ppisati> ah
[10:13] <ppisati> so it's a problem in the *omap4 pkgs
[10:13] <ppisati> since they don't have any Provides:
[10:14] <ppisati> no wait, they do
[10:14] <ppisati> ok, now i see what you mean
[10:14] <ppisati> i was querying meta instead of the real pkg
[10:15] <smb> Right, apart from here where the meta seems to spew out its purely virtual
[10:18] <smb> but that could just be my setup missing the right pools
[10:18] <ppisati> ok, seems linux-ti-omap4-headers never provided linux-headers
[10:20] <ppisati> and since dkms depends on linux-headers it fetched linux-headers (that in turn fetched linux-headers-generic)
[10:22] <smb> ppisati, Hm, I never looked at what comes out of it but looking at debian.ti-omap/control.d/flavour-control.stub there seems to be a Provides in there...
[10:23] <smb> Probably needing overhaul... 
[10:23] <smb> Provides: SRCPKGNAME-headers, SRCPKGNAME-headers-2.6
[10:24] <smb> ppisati, ^ Isn't ti-omap at least 3.0?
[10:25] <ppisati> since O yes :)
[10:26] <smb> apw, Likewise, does not seem to cause issues but would not the headers for 3.2 provide linux-headers-3.2 not 3.0?
[10:27] <apw> smb, i think actually they should provide linux-headers-3 under the previous scheme
[10:27]  * apw will think about it
[10:27] <ppisati> yep, that's what generic does
[10:28] <smb> apw, Ah ok, yeah sounds better as well... just the way it is now feels confusing, now that I actually look at it
[10:29] <apw> yeah i think its broketed, but i can't remember if there is any consumers of the thing anyhow
[10:30] <smb> I am pretty sure there is not, otherwise there would be people all over us by now
[10:39] <ppisati> oh i see
[10:39] <ppisati> debian.ti-omap4/control.stub.in:
[10:39] <ppisati> Provides: SRCPKGNAME-headers
[10:39] <ppisati> and SRCPKGNAME = linux-ti-omap4
[11:07] <brendand> apw - did you get to check out our list of cert blockers this week?
[11:08] <apw> brenden i have had some feed back, i will look at the responses next and send something out
[11:47] <ericm_> tgardner, ping
[11:47] <ericm_> tgardner, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/714862
[11:47] <ubot2`> Launchpad bug 714862 in linux "Atheros AR3011 cannot be turned up/is not recognized." [High,In progress]
[11:47] <ericm_> tgardner, would like to hear from your feedback
[11:47] <tgardner> ericm_, looking...
[11:47] <ericm_> tgardner, so Atheros provided a firmware for this issue - and patch has been submitted (not accepted yet)
[11:48] <ericm_> tgardner, this firmware will fix many similar issues on LP
[11:48] <ericm_> tgardner, yet the problem is - the fix changes the firmware which is shared among several other devices
[11:49] <tgardner> ericm_, have you regression tested other devices ?
[11:49] <ericm_> tgardner, I can verify that the firmware works for this DW1702, VID/PID being 0x0cf3:3002
[11:49] <ericm_> tgardner, nope - that's the card I have _only_
[11:50] <ericm_> tgardner, however - contact from Atheros said they've verifed this firmware on other chips as well
[11:50] <tgardner> ericm_, well, we can always try it to see what breaks. sounds likle we ought to be OK
[11:50] <ericm_> tgardner, and by googling a bit - I believe this firmware will also fix the other devices
[11:50] <ericm_> tgardner, yeah that's what I'm thinking of
[11:51] <ericm_> tgardner, so will be good if I post the patch now?
[11:51] <tgardner> ericm_, it goes into linux-firmware, right ?
[11:51] <ericm_> tgardner, yes - or you can pick it directly from http://comments.gmane.org/gmane.linux.kernel/1262485
[11:52] <tgardner> ericm_, how about https://bugs.launchpad.net/ubuntu/+source/linux/+bug/714862/comments/44 ?
[11:52] <ubot2`> Launchpad bug 714862 in linux "Atheros AR3011 cannot be turned up/is not recognized." [High,In progress]
[11:52] <ericm_> tgardner, if we do something to make sure this applies _only_ to the device I verified, the kernel source will have to be changed
[11:52] <ericm_> tgardner, that would be the one
[11:52] <ericm_> tgardner, let me know the md5sum when you downloaded it
[11:52] <ericm_> tgardner, so I can confirm with my working version
[11:53] <tgardner> ericm_, if we do as you suggest (change the kernel), then none of the other devices get any goodness from this new firmware. If atheros _says_ it should work, then lets go with their opinion.
[11:54] <ericm_> tgardner, that's what I think, I share your great idea, I'm more than pleased :-)
[11:57] <ericm> tgardner, also I've sent out the patch just in case, whichever works for you easier
[12:07] <tgardner> ericm, Uploading linux-firmware_1.73.dsc: done.
[12:08] <ericm> tgardner, cool - I'll test it once it lands in -propose
[12:08] <ericm> tgardner, it will first go into -propose right?
[12:08] <ericm> tgardner, nah - this is precise, sorry
[12:08] <tgardner> ericm, not for precise. the archive is still under development
[12:17] <cooloney> ppisati: any clue about that headers package issue in ti-omap4, i got ping from rsalveti about this. and i think we copied that to our armadaxp configure.
[12:17] <ppisati> cooloney: just the a patch to ukml
[12:17] <ppisati> *sent
[12:18] <rsalveti> ppisati: cooloney: great, thanks
[12:19] <rsalveti> let me check
[12:29] <ogasawara> apw: thanks for uploading lbm and meta
[12:30] <apw> ogasawara, i think i thought you were off today, and you are welcome
[12:30] <ogasawara> apw: I am, but woke up to make sure those were done
[12:30]  * ogasawara goes back to sleeping in
[12:30] <apw> heh ... GOOD :)
[12:30]  * ppisati -> lunch
[12:30] <apw> ogasawara, i asume there is no release meeting this week
[12:31] <ogasawara> apw: there is, but I've already got the email prepped and ready to send out
[12:31] <ogasawara> apw: and I was planning to sit in on the meeting
[12:31] <apw> ogasawara, you are worse than me
[12:31] <tgardner> ogasawara, its 0530 where you are. go back to bed.
[12:32] <ogasawara> tgardner: habit I guess, I didn't even have the alarm set and still woke up
[12:32] <tgardner> ogasawara, its sucks, doesn't it :)
[12:33] <ogasawara> tgardner: there's a nice layer of snow outside my window, maybe it's a sign to hit the mountain today
[12:33] <tgardner> ogasawara, I had a great day Tuesday. 19" new
[12:34] <ogasawara> kees: kernel + lbm + meta all finished with plenty of time before the freeze
[12:35] <ogasawara> later dudes
[12:56]  * jsalisbury is jealous hearing about all this snow, when it's been 80F all week!  We normally should have snow :-(
[13:03] <cooloney> ppisati, rsalveti thanks, i will take care of this for linux-armadaxp
[13:05] <smb> jsalisbury, They talk about outside. ;-P Ok, only got 668 here but it feels warm enough...
[13:05]  * smb mean 68
[13:06] <jsalisbury> smb, :-)  I actually enjoy the warm weather, but we didn't get any snow this year except the freak Haloween storm.  Oh well.
[13:08] <smb> I believe we did not get much snow either imo. Still a bit ugly as it swings between 66-70 during the day and 34 at night.
[13:09] <ppisati> jsalisbury: 20C here, and probably this weekend i'll hit the beach, you wanna come? :)
[13:11] <jsalisbury> ppisati, sounds a little cold for swimming still :-)
[13:12] <ppisati> jsalisbury: well, but you can still enjoy the sea breeze, sunbath, etcetc :)
[13:12] <jsalisbury> ppisati, absolutly :-D  
[13:13] <smb> ppisati, Though if he really has 80F this beats your 20C ;)
[13:13] <jsalisbury> smb, ppisati, very odd for this time of year.  It should only be ~40F
[13:13]  * ppisati has problem with the Imperial <-> Metric conversion
[13:13] <ppisati> :)
[13:14] <smb> ppisati, Ask Mr. Google
[13:14] <ppisati> ~27C, holy crap
[13:16] <smb> jsalisbury, This really sounds quite wrong. Even with our lower temperatures I am quite suspicious it just wants to go back freezing as soon as you don't look
[13:16] <jsalisbury> smb, yeah, it's going to here, just in time for the weekend :-/
[13:18] <smb> Tease and freeze... bloody weather gods and theirs sense of humor... ;)
[14:02] <jsalisbury> cking, I installed the debug kernel: linux-image-3.2.0-19-generic-dbgsym  I rebooted and didn't see that kernel listed in grub, only linux-image-3.2.0-19-generic
[14:15] <diwic> jsalisbury, dbgsym packages are not special kernels AFAIK, they just provide additional info when you're running the current kernel.
[14:15] <jsalisbury> diwic, cool, thanks.  So as long as I'm running the same kernel version, it will pick up the debug symbols
[14:15] <diwic> yep, that's my understanding of it
[14:16] <jsalisbury> diwic, great, thanks.
[14:16] <diwic> that's the way it works with other dbgsym packages
[14:21] <cking> diwic, thanks for answering ;-) I was not looking at this channel
[14:55] <phatphoton> Hi all, I have a problem with my bluetooth autodisconnecting after auth for a mouse. I have an hcidump to help, could anybody help me on that feild?
[15:19] <jjohansen> tgardner, ogasawara: do you want the apparmor pull request based off of the security-next tree, or would you like to wait for linus to pull it into his tree
[15:19] <tgardner> jjohansen, I'd prefer from Linus' tree
[15:19] <tgardner> I thought it had already been merged ?
[15:20] <jjohansen> tgardner: hrmm, not last I checked, james sent the request, but I didn't see it in this mornings pull
[15:20]  * jjohansen repulls
[15:20] <tgardner> jjohansen, the email I forwarded _was_ the merge commit (I think)
[15:21] <jjohansen> tgardner: hrmm, /me is rechecking maybe I did the wrong branch
[15:24] <jjohansen> tgardner: hrmmm, okay it is there. I'll rework the pull request to linus.  You want me to do a straight up rebase dropping the sauce patches, or do you want the reverts, and you can do the rebase
[15:24] <tgardner> jjohansen, send the reverts and I'll take care of the cleanup
[15:24] <jjohansen> tgardner: ack
[15:27] <cking> mjg59, "pcie_aspm=force" seems to have regressed - it seems that in cases where the FADT declares the system doesn't support PCIe ASPM and force is used we now get ASPM disabled whereas before at least some were enabled (depending on the original firmware settings)
[15:28] <tgardner> cking, is this in reference to Bug #961482
[15:28] <ubot2`> Launchpad bug 961482 in linux "3.2.0-19 kernel fails to boot (-18 OK)" [Critical,Confirmed] https://launchpad.net/bugs/961482
[15:29] <cking> tgardner, nope, more like: http://ubuntuforums.org/showthread.php?t=1865577&page=130#post11771228
[15:29] <mjg59> cking: force is enabling ASPM even though we shouldn't be touching it. The FADT then asks us to clear the state.
[15:30] <mjg59> So I guess I can see that. I'd expect you to be able to change it via the policy setting afterwards, though?
[15:31] <cking> mjg59, urm, what do you mean by policy setting?
[15:31] <mjg59> powersave, performance and so on
[15:31] <cking> ah, I suspect so, I've not got any H/W to try this on, but it's worth giving that a spin - makes sense
[15:32] <cking> mjg59, so basically, this isn't a regression, the outcome is now that the kernel is doing what the firmware is telling it to do :-/
[15:33] <mjg59> It's a change in behaviour
[15:33] <mjg59> We could argue over whether it's a regression or not
[15:33] <cking> I suppose it depends on what the semantics of "force" really mean
[15:49] <cking> mjg59, perhaps there should be an extra pcie_aspm flag to forcefully override the FADT's suggestion to clear the state - since there are (many) occasions where the firmware gets this wrong. bah, BIOS vendors
[15:51] <lamont> smb: [   74.247504] Dropped by process_register_request@1251
[15:52] <lamont> very consistently
[15:53] <mjg59> cking: Ok, I guess pcie_clear_aspm could just have an if (aspm_force); return added to it
[15:54] <cking> mjg59, i.e.
[15:54] <cking> diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
[15:54] <cking> index 24f049e..4af8371 100644
[15:54] <cking> --- a/drivers/pci/pcie/aspm.c
[15:54] <cking> +++ b/drivers/pci/pcie/aspm.c
[15:54] <cking> @@ -783,6 +783,8 @@ void pcie_clear_aspm(struct pci_bus *bus)
[15:54] <cking>  {
[15:54] <cking>         struct pci_dev *child;
[15:54] <cking>  
[15:54] <cking> +       if (aspm_force)
[15:54] <cking> +               return;
[15:54] <cking>         /*
[15:54] <cking>          * Clear any ASPM setup that the firmware has carried out on this bus
[15:54] <cking>          */
[15:56] <cking> I tried this earlier with a user who was seeing this issue and they reckon'd it didn't help, which is not what I expected
[15:56] <mjg59> cking: Yeah
[15:56] <smb> lamont, Ok, that narrows down things quite a bit (and for me the range of code I need to understand). Still a bit fuzzy (not as straight forward as one would hope) but I think I can work on that. 
[15:57] <lamont> smb: any need for me to keep the test kernel, or can I roll forward to the now-current -20?
[15:57] <lamont> smb: it's also quite possible that I have misconfigured the phone into doing something stupidly abusive
[15:57] <mjg59> cking: Hm. Yeah, ok, it's not clear_aspm that's hte problem.
[15:57] <cking> mjg59, ..the fact this didn't apparently work made me wonder if I was missing something stupid
[15:57] <smb> lamont, You can roll on. If I needed more it would be a new kernel anyway.
[15:57] <mjg59> But I don't see what is, in that case
[15:58] <mjg59> The only time the FADT matters is if we got _OSC control
[15:58]  * cking nods
[15:58] <mjg59> I guess I could do with dmesg for the machine in question
[15:59] <smb> lamont, I hope to be able to tell you about that (misconfiguration or what else) at some point
[15:59] <cking> mjg59, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/962038/+attachment/2915461/+files/BootDmesg.txt
[15:59] <ubot2`> Launchpad bug 962038 in linux "ASPM doesn't work completely on Asus Zenbook (regression from 3.1)" [Medium,In progress]
[16:00] <brendand> smb - i have an interesting find on bug 960311
[16:00] <ubot2`> Launchpad bug 960311 in linux "Networking on Dell PowerEdge R300 with Broadcom Corporation NetXtreme BCM5722 Gigabit Ethernet PCI Express is not functional" [High,Incomplete] https://launchpad.net/bugs/960311
[16:00] <brendand> smb - if i reboot the system then the problem never occurs, it only happens on first boot...
[16:00] <cking> mjg59, which clearly has the FADT disabling PCIe ASPM
[16:01] <mjg59> cking: Yeah, so it must be going through the clear path
[16:01] <mjg59> cking: So I'd expect the return patch to work
[16:01] <tgardner> ppisati, which dkms package is having problems building on a ti-omap4 system ?
[16:02] <smb> brendand, Hm, ok. That somehow open up the possibilities about how long this problem exists. If the machine got only rebooted most of the time it could actually have been around for a while
[16:03] <tgardner> smb, firmware issue ?
[16:03] <lamont> 124 second boot times suck
[16:03] <brendand> smb - i think we will just update the firmware and if the problem still exists we'll have to take it from there
[16:03] <smb> tgardner, Probably. At least the kernel message points there. 
[16:04] <cking> mjg59, I'll double check with the user - I can't comprehend why its not working, I was falling back to the "maybe I missed something obvious" mode
[16:05] <smb> brendand, Ok. Just for safety: this is the only machine of that make and model in the lab? There is no twin?
[16:05] <tgardner> smb, hmm, I was thinking it was a bnx2x, but its tg3
[16:05] <brendand> smb - no. we might have something with the same nic though. i'll have a look
[16:08] <smb> tgardner, Right, and somehow it seems to be able to handle the pxeboot xfer but a few minutes after it is brought up it seems to vanish. There seemed some life sign of the second interface after that. Which I also noted in the bug. Not sure that is really alive and its only the first one on the bus
[16:08] <brendand> smb - yeah, seems like a common one
[16:08] <brendand> smb - second nic is a different make (intel)
[16:09] <smb> brendand, I believe to have seen two tg3 instances
[16:10] <bjf> ppisati: there are cross build instructions on: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
[16:10] <smb> tg3 0000:01:00.0: eth0: Tigon3 [partno(BCM95722) rev a200] (PCI Express) MAC address 00:26:b9:53:cb:71
[16:10] <smb> tg3 0000:02:00.0: eth1: Tigon3 [partno(BCM95722) rev a200] (PCI Express) MAC address 00:26:b9:53:cb:72
[16:10] <bjf> ppisati: if yours are more complete, i'd suggest just adding a pointer on that page to your writeup
[16:10] <brendand> smb, can the same component have two ports?
[16:11] <smb> brendand, rather two instances (the pci bus address is different too)
[16:12] <smb> but motherboards can have two builtin NICS
[16:13] <tgardner> brendand, the bug report needs an 'apport-collect 960311' so we can see exactly what is installed.
[16:14] <tgardner> ppisati, never mind. I'm reading the bug report.
[16:17] <henrix> tgardner: brendand: could this tg3 issue be related with bug #961239 ?
[16:17] <ubot2`> Launchpad bug 961239 in linux "Broadcom NIC (tg3) not working with DMA errors" [Medium,Incomplete] https://launchpad.net/bugs/961239
[16:17] <henrix> in this bug, there are also 2 tg3 cards + 1 usb
[16:23] <brendand> tgardner, is there a problem with apport-collect on servers?
[16:23] <cking> mjg59, user has verified it worked - they didn't test it correctly, I will pop that patch out today once I've unwound my TODO list
[16:23] <tgardner> brendand, heck if I know
[16:23] <brendand> things just hanging...
[16:24] <mjg59> cking: Great, thanks
[16:24] <ppisati> bjf: i'll add a pointer there too
[16:24] <tgardner> brendand, well, at least get the output of 'lspci -vvnn' attached.
[16:24] <bjf> ppisati: remove the duplication on that page as well
[16:25] <ppisati> bjf: which duplication?
[16:26] <bjf> ppisati: on the page i pointed you at. if you add a pointer to your new wiki page, remove the duplication on "BuildYourOwnKernel" dealing with the info on your new page
[16:27] <ppisati> k
[16:32] <brendand> tgardner, lspci is attached now
[16:32] <cking> bah, why does git garbage collection bite me when I least want it to
[16:44] <ppisati> tgardner: actually all the releases are affected by this problem
[16:44] <ppisati> tgardner: since no linux-headers pkg in the ARM case prvided linux-headers
[16:46] <tgardner> ppisati, I'm still trying to wrap my head around what Provides: means in this case.
[16:48] <ppisati> tgardner: i think it says 'we fulfill linux-headers' meta package
[16:52] <jjohansen> tgardner, apw: are we still build aufs for precise?
[16:53] <tgardner> jjohansen, yep
[16:54] <jjohansen> tgardner: okay, it has a conflict with the umode_t that 3.4 apparmor pulls in, I can either patch aufs, or the apparmor patches
[16:54] <tgardner> jjohansen, fix aufs. I'd rather AA was a close to upstream as possible
[16:55] <jjohansen> tgardner: okay
[17:20] <apw> jjohansen, right if aufs is wrong we should fix that, indeed if you get me a patch you think fixes it i'll check and see if aufs has it and we might update
[17:22] <jjohansen> apw: patch is in the pull-request I just sent, the failure is introduced by a patch that is pulled in as part of the 3.4 apparmor rebase.  aufs isn't wrong its just al viro changed the parameters to security_path_chmod a little bit
[17:22] <apw> jjohansen, sounds good
[17:33] <tgardner> apw, you gonna handle jjohansen's AA pull request?
[17:55] <kees> ogasawara: woohoo! thanks :)
[17:56] <bandit5432> any one having optical drive problems with 3.3?
[18:02] <apw> tgardner-lunch, yep will do
[18:12] <bjf> jjohansen: you going to uds?
[18:16] <jjohansen> bjf: yep
[18:17] <jjohansen> bjf: /me needs to book yet, just trying to get beta2 tasks out of the way first
[18:17] <bjf> jjohansen: ack, i have you down for roomie
[18:18] <jjohansen> bjf: sounds good
[18:38]  * apw bails for the pub
[18:52] <cking> jsalisbury, thanks for your testing - got me the data I required.
[19:24] <jsalisbury> cking, no problem.  Anytime ;-)
[19:30]  * cking -> EOD
[20:27] <jwi> jsalisbury: for bug 961482, have a look at 'PCI: ignore pre-1.1 ASPM quirking when ASPM is disabled'; https://lkml.org/lkml/2012/3/19/232
[20:27] <ubot2`> Launchpad bug 961482 in linux "3.2.0-19 kernel fails to boot (-18 OK)" [Critical,Confirmed] https://launchpad.net/bugs/961482
[20:29] <jsalisbury> jwi, thanks! I'll take a look
[20:30] <jsalisbury> jwi, hmm, interesting.
[20:30] <jsalisbury> jwi, I'll built a test kernel with that commit reverted
[21:01]  * tgardner is EOD
[22:15] <skaet> apw, ogasawara - https://blueprints.launchpad.net/ubuntu/+spec/hardware-p-kernel-boot is slated for beta-2,  is it done?
[23:23] <hggdh> msg sconklin there still?
[23:24] <sconklin> hggdh: yes
[23:24] <hggdh> heh
[23:24] <hggdh> sconklin: when you ran cobbler-ubuntu-import did you restart cobbler?
[23:25] <sconklin> no
[23:25] <hggdh> hum. I ran it on ours, and the TFTP directory was again permission-hosed
[23:26] <sconklin> well, yes I did, but I was able to bootstrap a system before I did. restarted it later for another reason
[23:26] <hggdh> OK, good enough -- it worked on the bootstrap. Weird
[23:26] <sconklin> hggdh: that's odd, I was able to build a system immediately after the import
[23:26] <hggdh> extremely odd
[23:28] <hggdh> sconklin: are you using the sytem's TFTP server, or Cobbler's?
[23:28] <sconklin> hggdh: I don't know, I didn;t install it
[23:30] <hggdh> oh, this is in magners. I will check
[23:33] <hggdh> darn! also using tftpd-hda