[00:02] <genii-around> marsfligth: Ubuntu support is in #ubuntu
[00:04] <marsfligth> genii-around: Thanks for the information ...
[07:20] <smb> morning
[07:28] <infinity> bjf: So, someone turned on ddeb support for your PPA, and that blew up the world for your precise builds when we tried to copy them to primary.
[07:29] <infinity> bjf: I've had webops turn that back off again, but the only solution is going to be to reupload linux and linux-ti-omap4 for precise (no-change upload, just rev the build number/changelog), so we get fresh builds without ddebs.
[07:31] <infinity> bjf: In related news, I copied all your pending kernels (except the two above that broke), but it's sleepy time, so if no one beats me to it, I'll fix all the overrides in the morning.
[07:31]  * smb certainly won't
[07:32] <smb> infinity, Good morning/night :)
[07:33] <infinity> smb: Oh hey, a kernel team dude.  Feel free to do the above two no-change reuploads to the PPA, so they build overnight! ;)
[07:33] <infinity> smb: Then I can clean up the mess in the morning.
[07:33] <infinity> smb: (If you do, make sure to -v the dpkg-buildpackage, so it includes the previous changelog entry).
[07:34] <smb> infinity, I will have a look. Yup. 
[07:35] <infinity> smb: Cheers.  If you do 'em, tell bjf about it, so he doesn't wake up to my pings and think he has to fix the world. ;)
[07:36] <smb> infinity, He probably will , err well he hopefully ready on to above and realizes he has not to (or at least checks), right bjf ? :)
[07:37] <smb> Now, if my fingers would start to type what I am thinking, maybe my sentences will start to make sense...
[07:38] <infinity> smb: Oh, and to be clear, -meta and -backports-modules and all that jazz is already fine and copied, so it's just linux/precise and linux-ti-omap4/precise that need the rebuilds.
[07:40] <smb> infinity, Ok, ack. I may consult with henrix if he comes up as I am not sure I always know what the formal requirements beside the brute git change and package are...
[07:40] <infinity> Mmkay.
[07:41] <infinity> (If I had git commit, I'd just commit the changelog and upload directly to -proposed at this point, since the whole point of the PPA test/copy cycle has kinda gone out the window right now anyway, but I can't commit, so... You're safe from my meddling)
[07:41] <infinity> For you, you're better off uploading to the PPA, since it bypassed archive admin approval. :)
[07:43] <smb> Heh, yeah. I mostly will do that, though the decision would be between opening a new rev in changelog with a bt of tweaking or just replace the old one
[07:43] <smb> And of course I had the problem with the archive admin approval which oyu don't :)
[07:56] <brendand> does anyone know what tigon/tg3_tso.bin is?
[07:57] <ppisati> btw, moin
[07:58] <smb> ppisati, moin
[07:59] <smb> brendand, what would the fact that it resides under /lib/firmware tell you? 
[08:00] <infinity> smb: That it's tasy, tasy candy?
[08:00] <infinity> tasty*
[08:01] <smb> infinity, Still not in bed? :) Yeah, well maybe rather 100% cacao chocolate... :-P
[08:02] <infinity> smb: I'm not very good at this sleeping thing.  I'll try harder.
[08:03]  * smb remembers old comic books suggesting a mix of hypnosis and a rubber hammer... Hm, probably owning those is illegal nowadays...
[08:06] <infinity> smb: They still haven't outlawed comic books here.
[08:06] <infinity> Anyhow, I see your henrix has shown up.  I'll go try to sleep more. :P
[08:07] <smb> infinity, hehe, see you then
[08:07] <henrix> infinity: hmm?
[08:07] <smb> henrix, Good morning :)
[08:07] <henrix> smb: hey!
[08:08]  * ppisati heards that vodka helps with sleep...
[08:08] <smb> henrix, Just was talking with he who tries to sleep that we need to re-upload precise linux and linux/ti-omap4 to the ppa
[08:08] <smb> Just /me is pondering about how to tweak the changelog
[08:09] <brendand> smb, yes i know it's firmware. for what kind of hardware?
[08:09] <henrix> smb: and what's the reason for that?
[08:09] <henrix> smb: any urgent patch?
[08:09] <smb> brendand, modinfo tg3
[08:10] <smb> henrix, No just PPA running full and somehow those probably went bad on build
[08:10] <smb> henrix, And now you cannot upload the same number again
[08:10] <brendand> smb, right so it's for ethernet, but despite that we don't install it the ethernet works fine
[08:11] <henrix> smb: yep, we would need to re-spin the kernels incrementing the minor number
[08:11] <smb> henrix, I think I convinced myself that the best way will be to just increment the version line without starting a new version (otherwise all the pain with abi change will hit)
[08:12] <smb> henrix, Maybe an additional comment in the "old" changelog about no-change upload is ok... Though I am not sure there may be formal processing rules requireing a different approach
[08:12] <smb> brendand, You sure you don't isntall them? Because here they come (precise) with the kernel.
[08:13] <brendand> smb - hmmm, why does the installer ask me to install them from removable media?
[08:14] <henrix> smb: how did you know about these kernels being damaged?
[08:14] <smb> henrix, He who sleeps told brad while I was in this channel too
[08:14] <smb> brendand, I do not know
[08:14] <henrix> ah, ok
[08:14]  * henrix goes check email
[08:14] <smb> henrix, irc 
[08:16] <brendand> smb, do you think it's worth a bug?
[08:17] <apw> infinity, turned off our ddebs?  we need those ...?
[08:17] <apw> (clearly i have missed some subtlety)
[08:20] <smb> brendand, Well maybe, if that is repeatable and if that is new and whatever release we are talking anyway?
[08:21] <brendand> smb, well it's been the whole time with precise
[08:21] <brendand> smb, very repeatable on one IBM server we have
[08:22] <brendand> smb, in linux-firmware? or d-i?
[08:26] <apw> which install media you using live or alternate
[08:27] <smb> brendand, since its linux package I put it into linux. What type of install ist that alternates, server, or desktop?
[08:28] <brendand> smb, server
[08:33] <infinity> apw: Do you?  Cause you never had them in the PPA before. :P
[08:33] <infinity> apw: So, define need, exactly...
[08:34] <apw> infinity, support need ddebs for every kernel, but they have been collecting them from ddebs.ubuntu.com and archiving them so they must have existed
[08:35] <infinity> Hrm.
[08:35] <infinity> smb: Don't go reuploading yet.  I need to dig deeper.
[08:36] <smb> infinity, Yeah, I was already holding as soon as while talking to apw this came into mention
[08:36] <apw> u
[08:37] <apw> infinity, if you look at ddeb.uubuntu.com we have -26.36 ddebs across the board (precise -updates kernel)
[08:38] <apw> infinity, perhaps that one didn't build right cause the PPA got full up, and the bug is with ddeb handling there
[08:39] <apw> infinity, oh ... hang on ...
[08:39] <apw> infinity, could this be we had ddeb's turned off on the PPA, but cause they are de-virtualised
[08:39] <infinity> apw: No, all ddeb-enabled PPA builds *can't* be copied to primary.
[08:39] <apw> infinity, they get left on the buildds as normal and found the normal backdoor, all by accident ?
[08:39] <infinity> apw: But with devirt PPAs, pitti's scripts copy them out when you do the backdoor trick.
[08:39] <infinity> apw: Right.
[08:39] <apw> jinx
[08:40] <infinity> apw: So, my disabling ddebs on the PPA fixes it back to how it was.
[08:40] <infinity> (ie: working)
[08:40] <apw> infinity, ok then that all makes sense ... and explains why we had to make it 2x as big yesterday :)
[08:40] <infinity> bjf / smb: Bad news, queuebot lied to me.  Looks like EVERYTHING except for hardy failed to copy, because they all had ddebs.
[08:41] <infinity> So, if you guys want to sort out no-change uploads of, well, everything that had ddebs. :/
[08:41] <apw> infinity, of course ... hardy does the old debug handling ... ie not using .ddeb
[08:41]  * infinity nods.
[08:41] <infinity> apw: If you want to help hammer these out, I'll love you forever.
[08:41] <apw> infinity, ok will get those sorted out ...
[08:42] <infinity> http://people.canonical.com/~ubuntu-archive/pending-sru.html
[08:42] <infinity> ^-- The kernel PPA section at the very bottom should be a good indicator of what needs reuploading.
[08:42] <infinity> (Except for the metas)
[08:43] <infinity> And that lum, that someone forgot to copy...
[08:43] <infinity> (I'll do that now)
[08:43] <apw> infinity, ack
[08:45] <apw> infinity, oh gawd this is going to blow poor shankbots mind
[08:46] <infinity> Shankbot, schmankbot, you're going to cripple the buildds for a day.
[08:46] <infinity> Enjoy.
[08:46] <infinity> Apparently, we get to blame james_w.
[08:46] <infinity> He thought you guys needed this turned on. :P
[08:52] <apw> infinity, heh ... always they way ... will get this sorted with herton shortly
[08:53] <infinity> apw: Danke.  I expect to see it all fixed when I wake up. ;)
[08:54] <apw> infinity, we are going to have utter chaos here until then, all our process monitoring will be in the grinder
[08:55] <infinity> apw: Bah. Change the titles of a few tracking bugs for the new version, commit some "oh god, rebuild, lolz" changelogs to git, reupload, profit?
[08:55] <infinity> apw: You people and your processes. ;)
[08:55] <infinity> (I'll leave you to it)
[08:55] <apw> its the damn abis which get me
[08:56] <infinity> You have the ABI files in the previous builds in the PPA.
[08:56] <infinity> You can just fetch 'em all and you're set.
[08:56] <apw> right ...
[08:56] <infinity> Shame that fetch-abis only scans the archive by default, so you get to download all the debs from the PPA by hand!
[08:57] <infinity> That's not the sound of me giggling like a schoolgirl.
[08:57] <infinity> No sir.
[08:57] <apw> infinity, no we fixed that yesterday :)
[08:57] <infinity> Oh, shiny.
[08:57] <smb> ther e is one for that
[08:57] <infinity> Good timing.
[08:57] <infinity> Almost like you knew you'd need it today!
[08:59] <apw> infinity, completely random or what
[09:08] <brendand> smb - btw, the issue also happens with quantal
[09:08] <brendand> smb, i would have to go back and check oneiric
[09:09] <henrix> manjo: ping
[09:09] <smb> brendand, sure likely the same tweak there (quantal) though oneric could be affected the same it is less likely that installer disks are re-spun...
[10:00]  * henrix reboots
[10:39] <brendand> cking, i think i probably mentioned this before, but nearly all our systems have a 'DMIInvalidHardwareEntry: Test 1, Unmatched Chassis Type SMBIOS Type 3 reports 11 ACPI
[10:39] <brendand> FACP reports 0' type of error
[10:39] <brendand> the numbers vary
[10:40] <cking> brendand, yes, can you report that in a bug report against fwts
[10:40] <brendand> cking, against fwts? so just one catch all bug then?
[10:40] <brendand> cking, i don't need to trudge through creating one for each system?
[10:42] <brendand> cking - there's one HP server with: http://paste.ubuntu.com/1077885/
[10:42] <cking> brendand, can your file a bug against fwts saying that this is happening an a wide range of machines, and an example of the log produced by fwts.  Then we can see if it is being too pedantic, or if it's a real firmware issue that needs attention
[10:43] <cking> brendand, yep, that last one is an issue with the firmware, the string index falls off the end, causing this error
[10:45] <brendand> cking, i'll file it seperately
[10:45] <cking> great
[10:51] <brendand> https://bugs.launchpad.net/fwts/+bug/1021674
[10:51] <ubot2> Ubuntu bug 1021674 in fwts "DMIInvalidHardwareEntry - Unmatched Chassis Type" [Undecided,New]
[11:05]  * ppisati -> out for lunch
[11:12] <cking> brendand, so ignore the DMIInvalidHardwareEntry - the check  wrong and we need to fix that in fwts
[11:13] <cking> s/check wrong/check is buggy/
[11:21] <brendand> cking, apport for fwts isn't very verbose
[11:22] <cking> brendand, apologies, but for that dmi test there has been a screw-up, I'm figuring out why it got that way and trying to work on a fix
[11:22]  * cking --> lunch
[11:43] <cooloney> apw: hey, man still around?
[11:43] <apw> cooloney, hi
[11:44] <cooloney> apw: i'm looking the configs, found CONFIG_DM_RAID45 is not existed in kernel
[11:44] <apw> cooloney, in which kernel
[11:45] <cooloney> apw: and we are using CONFIG_DM_RAID for a RAID 4/5/6, I think
[11:45] <smb> That is a ubuntu driver btw
[11:45] <cooloney> apw: in quantal
[11:45] <apw> debian.master/config/amd64/config.common.amd64:CONFIG_DM_RAID45=m
[11:45] <apw> seems to exist to me
[11:45] <cooloney> smb: oh, i forgot that
[11:45] <apw> its obviously only meaningful on x86 anyhow as its a BIOS bodge for there
[11:46] <smb> In a very loose meaning of BIOS bodge but yes
[11:46] <cooloney> apw: yeah, but looks like omap4 enabled it as module
[11:47] <cooloney> i will sent patch to disable it. 
[11:47] <apw> cooloney, i don't think it makes sense to be enabled indeed
[11:47]  * smb agrees
[11:47] <cooloney> apw: hmmm, so we can completely disable it for all flavours, right?
[11:48] <apw> cooloney, no, it makes sense on i386 and amd64
[11:48] <apw> cooloney, as it is only a BIOS on those machines which can need it
[11:48] <apw> smb, ^^ right?
[11:48] <cooloney> apw: sure, right now, only ti-omap4 enable it as module.
[11:49] <cooloney> apw: so i will send out patch to disable it, since no BIOS stuff on omap4 i believe
[11:49] <apw> right, any non-PC platform which has it enabled is silly
[11:49] <smb> apw, At least no bioses which define some raids and then would need dmraid. And other RAID container formats might be handled by mdadm, yso yes
[11:50] <cooloney> so what about the CONFIG_DM_RAID in upstream kernel tree
[11:50] <cooloney> from the description it supports the same thing as RAID45 from my quick review
[11:51] <apw> smb, you are my dmdraid45 expert :)
[11:51] <smb> cooloney, that is sort of a wrapper to use md from within dm
[11:51] <smb> You could use dm-raid45 as well on arm (manually) but without really an urgent need one does not want it
[11:52] <smb> cooloney, I would not disable those
[11:52] <smb> You still may want to define/create your software RAIDs on arm
[11:54] <smb> Not sure how many disks arm boards would have but for something like arm server one would think there will be more than one...
[11:54] <cooloney> smb: so we should make this as module for all flavours?
[11:54] <cooloney> smb: right, as ARM server is coming, software RADIs might be useful. 
[11:54] <smb> cooloney, I should not hurt to have those available as modules
[11:54] <cooloney> currently we enabled this in ti-omap4 and x86
[11:55] <smb> It
[11:56] <cooloney> actually the policy is (arch i386 amd64 &/ value m) | value n
[11:57] <cooloney> i don't think ti-omap4 will have many disks, since it has not SATA/PATA interface at all. but for highbank or armadaxp it should be useful
[12:02] <smb> Stuff in drivers/md is not really depending on SATA/PATA. You can as well mirror usb storage devices. Whether is makes sense or not... But at least those drivers are just taking block devices to create some "other" block devices
[12:06] <cooloney> smb: ok, i will leave it as =m for ti-omap4, maybe it will be useful sometime.
[12:38] <rtg> apw, ppisati: can one of you build 'git://kernel.ubuntu.com/rtg/ubuntu-quantal.git ti-omap4' and boot test it? Its a stable update to v3.4.4.
[12:41] <ppisati> rtg: why this update? anyway, i'll do as soon as i finish another omap3 installation
[12:41] <rtg> ppisati, why not this update ? lots of good USB stuff in there as well as some arm patches
[12:45] <apw> rtg, am un-f*ing our stable builds right now after someone in webops decided to enable ddebs in our ppa
[12:49] <cooloney> ppisati: after the commit 'UBUNTU: [Config] SND_OMAP_SOC, SND_OMAP_SOC_MCBSP and SND_OMAP_SOC_OMAP3_BEAGLE =y', if i run 'fdr updateconfigs', our script will revert your setting in config
[12:49] <cooloney> ppisati: is that an issue?
[12:50] <rtg> cooloney, hmm, I thought I _did_ do that.
[12:50] <cooloney> ppisati: i just update some other configs by 'fdr editconfigs' and it turns out got some changes about SND_OMAP_SOC every time 
[12:51] <cooloney> rtg: you mean you fixed that in master-next already?
[12:52] <rtg> cooloney, no, I meant that I thought I ran updateconfigs, but perhaps I didn't.
[13:04] <cooloney> rtg: i got this after running updateconfigs, http://pastebin.ubuntu.com/1077999/
[13:06] <rtg> cooloney, looks like it ends up doing the right thing, just sorted a bit different.
[13:06] <ppisati> do we need to run it twice to get it right?
[13:07] <rtg> ppisati, shouldn't have to
[13:09] <rtg> cooloney, ppisati: I'll just fold those changes back into that commit and repush.
[13:10] <cooloney> rtg: yeah, thanks
[13:10] <rtg> cooloney, ppisati: done (on master-next)
[13:12]  * rtg makes sure it still builds....
[13:19] <cooloney> rtg: yeah, got it. just pulled
[14:01] <cking> brendand, OK, I've got a fix for that fwts dmi table issue, I'll send it to the fwts-devel list and it should be incorporated into the next release sometime in the next few weeks
[14:02]  * cking --> pop out to pick son up from school, back shortly
[14:04] <apw> herton, ok i have pushed all the tags and masters, am about to rebase all the master-next branches, ok ?
[14:04] <herton> apw, ok
[14:08] <brendand> cking, thanks
[14:21] <ppisati> rtg: did anyone changed chroot in tangerine?
[14:21]  * cking <-- back again
[14:21] <ppisati> dpkg-checkbuilddeps: Unmet build dependencies: cpio libelf-dev libnewt-dev binutils-dev libdw-dev transfig sharutils
[14:21] <ppisati> (quantal-amd64)ppisati@tangerine:~/ubuntu-quantal$
[14:22] <ppisati> dpkg-buildpackage -us -uc -aarmhf
[14:22] <ppisati> brb
[14:32] <herton> apw, hmm, didn't noticed that the new lucid package had the new abi directory as debian.master/abi/2.6.32-41.912.6.32-41.92
[14:32] <rtg> ppisati, hmm, checking
[14:33] <herton> apw, ouch, natty has the same issue
[14:36] <apw> herton, how the hell
[14:37] <apw> herton, oh both have the same error because they are the same base package
[14:38]  * apw will had better fix his errorn
[14:39] <herton> apw, did you use an script to do them?
[14:40] <apw> herton, nope, somehow that is a manual error
[14:40] <apw> herton, well so much for me saving anyone any time
[14:41] <apw> herton, anyhow leave the disaster recovery disaster with me
[14:41] <herton> heh happens... ok. I also failed to see it, I did a diff of contents etc but didn't paid attention to the directory name
[14:42]  * apw is suspicious its his mouse actually stuttering on paste .... HMMM, time for a new mouse
[14:42] <smb> herton, apw, Speaking of those things... I think I saw an old abi dir dangling in precise...
[14:42] <herton> smb, yep, saw the same here
[14:42] <smb> But those were even before doing anything
[14:42] <herton> yep
[14:42] <herton> we can fix later
[14:42] <smb> right
[14:46] <rtg> jsalisbury, henrix, ppisati: lemme know when I can reboot tangerine. 
[14:46] <jsalisbury> rtg, now's ok with me
[14:47] <henrix> rtg: same here
[14:47] <rtg> arges, tangerine needs a reboot
[14:47] <arges> rtg, ok
[14:47] <arges> rtg, i'll rebuild on another machine
[14:47] <rtg> arges, ok, bouncing....
[14:48] <herton> apw, kteam-tools/maintscripts/verify-release-ready would catch the problem on lucid/natty, but you have to run it inside the ready git repo
[14:49] <apw> herton, yeah, if i'd done my job properly it'd have been right too.  as i said earlier its just not my day
[14:53] <herton> apw, np, not sure if you rememberd about the script. btw, we could have some documentation for the ddeb stuff and the ppa, what is involved, how it works (none of us knew about it), could be something for the sprint may be
[14:55] <apw> herton, yeah why not, add it to the agenda me thinks
[15:00]  * ppisati goes to pick my shirts from the laundry, brb
[15:04] <herton> ok, added a topic there. our agenda is pretty huge right now
[15:06] <jsalisbury> rtg, I just added bug 1018020 to the hot list, it's a webcam bug, but it seems like it might be affecting the Quantal A2 installer.
[15:06] <ubot2> Launchpad bug 1018020 in linux "Logitech webcam not working" [High,Confirmed] https://launchpad.net/bugs/1018020
[15:07] <jsalisbury> rtg, I can reproduce it here, so I'll try to bisect it.  I just wanted to get some extra eyes on it, in case it heats up
[15:11] <rtg> jsalisbury, ack, looks like you've got it well in hand.
[15:12] <jsalisbury> rtg, cool, just wanted to give a heads up
[15:12] <rtg> jsalisbury, gotta keep all those manager types happy. they wouldn't know how to act without their video crack.
[15:13] <jsalisbury> rtg, lol, exactly
[15:13] <jsalisbury> rtg, there just this USB bug that making it a pain to bisect, so I need to bisect that first to be able to properly test rc1 and rc2
[15:25]  * cking wonders where the week has gone
[15:30] <herton> smb, are you uploading ec2 or just making the branch ready? I saw you set the upload task as fix released
[15:30] <smb> herton, Yes, its in the ppa already
[15:31] <apw> i expect it will break too sigh, my fault
[15:31] <smb> apw, Nah, got my own abi version ;)
[15:31] <apw> thats something :)
[15:31] <herton> smb, ok, it should be in progress, the bot will set the upload task to fix released when build is done
[15:32] <smb> herton, Ah ok, sorry for that then
[15:32] <herton> smb, if there is no meta pacakge, the prepare pacakge meta task should be set to invalid though
[15:32] <herton> np
[15:32] <smb> herton, There is one this time
[15:32] <smb> I can prepare that, too if you want to
[15:34] <herton> smb, ok I'll do it. if prepare-package-meta stays new, the bot will just wait on that indefinitely. so either it is in progress (building in the ppa), or invalid (not needed) as well
[15:36] <smb> herton, So since you gonna do it I leave my fingers of that. This is time is a bit special since only ec2 bumps the abi due to that special change
[15:37] <rtg> cking, do you install the intel-microcode package on SandyBridge machines?
[15:37] <cking> rtg, I've not done so, but I have kit I can try it on
[15:37] <rtg> from the most recent changelog:   * Fixes precise-event based sampling (PEBS) on Sandy Bridge processors
[15:37] <rtg>     (http://lkml.org/lkml/2012/6/7/145)
[15:38] <rtg> I think I have some kit as well
[15:39] <ppisati> rtg: gomeisa chroots are screwed too
[15:39] <ppisati> rtg: trying precisse-amd64
[15:39] <ppisati> rtg: and it works
[15:39] <ppisati> (precise-amd64)ppisati@gomeisa:~/ubuntu-quantal$ dpkg-buildpackage -us -uc -aarmhf
[15:39] <ppisati> is ok
[15:40] <ppisati> quantal-amd64 -> http://paste.ubuntu.com/1078205/
[15:40] <ppisati> Unmet build dependencies: cpio libelf-dev binutils-dev libdw-dev transfig sharutils
[15:41] <ppisati> quantal-armhf is good too
[15:53] <rtg> herton, apw: Is this a result of the ddeb carnage ?
[15:53] <rtg> The following packages have been kept back:
[15:53] <rtg>   linux-headers-server linux-image-server linux-server linux-tools
[15:53] <herton> rtg, if you have proposed enabled, probably yes
[15:53] <herton> I noticed meta packages were copied, but mains failed
[15:53] <rtg> herton, I do, just like a good kernel developer should.
[15:54] <herton> sure :)
[15:54] <apw> rtg, this was triggered by the disaster, both were built so he hit copy both
[15:54] <apw> rtg and it only copied one of them
[15:58] <rtg> ppisati, so, it appears that only the cross compile is busted. its likely something to do with a dpkg update.
[16:01] <henrix> manjo: ping
[16:06]  * herton -> lunch
=== deffrag_ is now known as deffrag
[16:29] <cking> rtg, the microcode-20120606.tgz works fine on my i3 x220i and i5 x230
[16:30] <cking> ..Sandybridge + Ivybridge
[16:30] <rtg> cking, I think the errata that it was attempting to address involved ptrace
[16:30] <rtg> something to do with high precision measurements ?
[16:31] <cking> ah, /me looks at that
[16:31] <rtg> I didn't read the whole thread....
[16:38] <apw> herton, ok i've pushed the two i broke, and will monitor the builds ... 
[16:40] <jsalisbury> rtg, is it Ok to use tangerine, or are there further reboots needed?
[16:40] <rtg> jsalisbury, I'm still working on it. use gomeisa for now
[16:40] <jsalisbury> rtg, ack
[16:41]  * ppisati -> gym, back later
[16:48] <herton> apw, ack
[16:48] <apw> herton, i updated the titles of the two bugs to match, i believe the lts backport natty is ok, but if not will sort it when it goes bang
[16:49] <apw> (but as i386 has gone TICK i assume we are ok)
[16:49] <herton> apw, ok, if we notice anything we can fix the bug too, np
[16:50] <apw> herton, what a disaster :)  still a good reminder than anyone can screw the pooch
[16:50] <apw> that vigilance and even getting someone to check, you can still screw it up
[16:50] <herton> yep, happens sometimes
[16:51] <apw> yeah and its most annoying when it happens cause you are in a hurry and want to help people get ahead :/
[17:07] <manjo> henrix, pong
[17:08] <henrix> manjo: hi! just to let you know i've the output of usb-devices for your BT patch
[17:08] <henrix> manjo: take a look at bug #1010281
[17:08] <ubot2> Launchpad bug 1010281 in linux "[12.04] Broadcom Bluetooth device (Vendor=0a5c ProdID=21f4) not supported" [Medium,Confirmed] https://launchpad.net/bugs/1010281
[17:10] <manjo> henrix, do you want to respond to lkml with that info ? 
[17:10] <henrix> manjo: sure, i can do that. but maybe its easier just to resubmit the patch?
[17:16] <henrix> manjo: just let me know if you're planning to re-submit the patch or if you want me to just send this info in reply to your initial patch
[17:17] <manjo> henrix, I just sent a reply to Gustavo with the info that is on the bug, and also asked him if he wants me to resubmit ... 
[17:17] <henrix> manjo: cool, thanks!
[17:17] <manjo> henrix, thank you 
=== rtg is now known as rtg-lunch
[17:52] <cking> rtg-lunch, I'm having little luck in exercising the PEBS via perf on my machine, must be missing something but I can't figure it out and my day is nearly over :-/
=== rsalveti` is now known as rsalveti
=== rtg-lunch is now known as rtg
[18:11] <rtg> cking, no problem, go have a beer
[18:11]  * cking just sent my wife out to buy some actually ;-)
[18:11]  * cking --> EOD
[18:27]  * henrix --> EOD
[19:51]  * rtg --> EOW
[20:42] <hggdh> herton: the arm bug has been retagged qa-testing-passed
[20:45] <herton> hggdh, ok, thanks