=== smb` is now known as smb
[07:34]  * apw yawns
[07:36] <cooloney> morning, folks
[07:40] <apw> cooloney, yo
[07:56]  * cking waves to cooloney
[07:56] <smb> cooloney, Morning
[07:56] <smb> cooloney, Hows the lxc tests thing going?
[07:56] <cooloney> smb: it got some testing error on both panda and my desktop
[07:57] <smb> Nice, problems with the test code or the containers? If you can already tell...
[07:57] <cooloney> smb: did you try that before?
[07:58] <cooloney> smb: the testcase form serge
[07:58] <cooloney> lp:~serge-hallyn/+junk/lxc-test
[07:58] <smb> cooloney, No, did not hear of them before UDS
[07:59] <smb> calling the ppa that way does not really give an impression of quality
[08:00] <cooloney> smb: yeah, did you get serge's email. 
[08:01] <cooloney> namespace attach (setns) patches
[08:01] <smb> cooloney, I believe that was to the mailing list so yes
[08:02] <smb> (not that I can remember the contents) But any way... it would be good to talk to Serge about it in some way. Given your distance from each other it may need to be email...
[08:03] <cooloney> smb: yeah, i plan to email out, heh
[08:03] <cooloney> smb: or maybe ping him later tonight
=== njin is now known as njin1
=== njin1 is now known as njin2
[08:03] <smb> cooloney, can you keep me on cc on any emails. then I can follow a bit along
=== njin2 is now known as njin
[08:04] <cooloney> smb: sure, np.
[08:05] <cooloney> smb: from serge's email, those ns patches from Eric is quite old but still out of mainline
[08:05] <smb> cooloney, Yeah he said he wanted to submit some for -next into 3.5. Though that sounded a bit over-optimistic
[08:07] <cooloney> smb: ok, got it. if they can 3.5, that's good for us
[08:07] <cooloney> ppisati: moring, man
[08:07] <apw> smb, bear in mind if its not in there already _now_ its too late
[08:07] <smb> cooloney, I would not hold my breath for it
[08:08] <apw> smb, as the merge window is already open and things coming in
[08:08] <smb> apw, I do bear that in mind a lot
[08:10] <cooloney> apw: yeah, after 2 weeks later, we will know the status of 3.5 
[08:10] <ppisati> cooloney: ciao :)
[08:18] <smb> cooloney, Hm, ok, there seem to be some patches for userns on linux-next right now...
[08:23] <cooloney> smb: that's good
[08:23] <cooloney> ppisati: any omap3/omap4 related bug, you need me to take a look?
[08:25] <ppisati> cooloney: well, nothing special
[08:25] <ppisati> cooloney: there's one bug that IMO is a user problem (either hw or power supply problem)
[08:26] <ppisati> cooloney: and then there's another one that's related to the cpu/freq scaling and if i would be in you, i would stay away from that
[08:29] <ppisati> bug 971091
[08:29] <ubot2> Launchpad bug 971091 in linux-ti-omap4 "Pandaboard ES freezes with the default CPU scaling governor ondemand" [Medium,Confirmed] https://launchpad.net/bugs/971091
[08:29] <ppisati> and
[08:29] <ppisati> bug 994368
[08:29] <ubot2> Launchpad bug 994368 in linux-ti-omap4 "linux-ti-omap4 kernel panics on pandaboard ES" [Undecided,Incomplete] https://launchpad.net/bugs/994368
[08:30] <ppisati> if you want to take a look
[08:30] <ppisati> cooloney: ^
[08:48] <cooloney> ppisati: thx, looks like it's a long story 
[09:06] <ppisati> cooloney: yep :)
=== yofel_ is now known as yofel
[10:01] <apw> apw@dm:~/git2/ubuntu-lucid$ cat /etc/dpkg/dpkg.cfg.d/multiarch
[10:01] <apw> foreign-architecture i386
[11:39] <ma1> Hi
[11:39] <ma1> #uname -r: 3.1.0-1282-omap4
[11:40] <ma1> I want to compile the ubuntu kernel for the above version on my pandaboard es
[11:40] <ma1> any step by step guide/tutorial available?
[11:43] <ppisati> ma1: https://wiki.ubuntu.com/KernelTeam/ARMKernelCrossCompile
[11:44] <ppisati> ma1: btw, that's not an ubuntu kernel
[11:45]  * ppisati -> lunch
[11:46] <ma1> ppisati: Thanks...but i want to build the kernel natively
[11:46] <ma1> http://www.omappedia.com/wiki/Ubuntu_kernel_for_OMAP4
[11:46] <ma1> what about this link???
[12:55]  * henrix is going out for a drink later today to enjoy the sun!!!
[13:11] <cking> henrix, that makes me feel thirsty
[13:12] <henrix> cking: i'm afraid there's only one thing to do...
[13:12] <cking> buy a beer?
[13:13] <henrix> :)
[13:13] <tgardner> you guys gotta stop talking like that. I've barely started my work day.
[13:13] <henrix> tgardner: heh! it's just that we *do* have sun here, which is something rather unusual :)
[13:14] <tgardner> my weather is gonna suck for the next few days, but it was nice yesterday.
[14:35] <tgardner> ogasawara, apw: I see  a new version of kernel-wedge just got uploaded. we'd better try a Quantal rebuild as soon as it propagates in the archive.
[14:35] <apw> tgardner, sigh
[14:35] <ogasawara> tgardner: ack
[14:37] <ogasawara> tgardner: I also uploaded meta, so we should be good to start also uploading to the backports PPA
[14:37] <tgardner> ogasawara, I saw that
[14:38] <tgardner> ogasawara, starting a precise backports meta package is on my todo list for the day
[14:38] <tgardner> or maybe just use the master package and add something...
[14:39] <ogasawara> hrm, armhf chroot problem.  I've never seen that error before...https://launchpadlibrarian.net/105801887/buildlog_ubuntu-quantal-armhf.linux-meta_3.4.0.3.3_CHROOTWAIT.txt.gz
[14:40]  * ogasawara will investigate more in 20min
[14:44] <tgardner> ppisati, just pushed Quantal ti-omap4 Ubuntu-3.4.0-201.2. Y'all should prolly have a look before I upload to make sure I didn't screw the pooch.
[14:44] <tgardner> perhaps build it and make it still boot.
[14:44] <tgardner> make sure it still boots*
[14:45] <jsalisbury> apw, Speaking of builds, is it possible to get the 3.4 and newer mainline builds to use the Quantal kernel config instead of Precise?  If it's something I can learn to do, I'd be more than happy to take it on.
[14:45] <jsalisbury> apw, it will help with bug 996075
[14:45] <ubot2> Launchpad bug 996075 in linux "Enable CONFIG_DVB_USB_AZ6007" [Medium,Confirmed] https://launchpad.net/bugs/996075
[14:46] <jsalisbury> apw, When I say mainline builds, I'm referring to the ones at: http://kernel.ubuntu.com/~kernel-ppa/mainline/
[14:53] <apw> jsalisbury, ahh yes, thats on my todo, perhaps now is a good time as any
[14:54] <jsalisbury> apw, no rush if your busy with other stuff
[14:57] <apw> jsalisbury, its an easy chan ge
[14:57] <apw> i presume we want to build everything p and later in precise chroots too
[14:58] <jsalisbury> apw, even q?  in precise chroots?
[14:59] <apw> we build l->o in lucid chroots cause you might want to test them back to there
[14:59] <apw> makes the deps simpler when shoveing them on to do bisects on older releases
[15:06] <apw> jsalisbury, probabally we should be making them actually in both the right release and the lts to which they apply too
[15:06] <jsalisbury> apw, ah oh.
[15:07] <jsalisbury> s/oh/ok/
[15:32] <apw> jsalisbury, ok i have just updated the mainline poop to do things 'right' for quantal (i hope), i have kicked a v3.4 off with the new quantal/precise combo to see what happens, you may wish to see if it resolves that bug when it pops out the other end
[15:33] <jsalisbury> apw, awesome.  thanks for the help, andy!
[15:36] <apw> jsalisbury, np
[15:36] <ogasawara> jsalisbury: for the meeting today, can we add back the section where I nag about work items :)
[15:37] <jsalisbury> ogasawara, ack
=== kentb_ is now known as kentb
[15:47] <jsalisbury> ogasawara, Is this the right page to add to the meeting agenda for work items:
[15:47] <jsalisbury> http://status.ubuntu.com/ubuntu-quantal/milestones.html
[15:48] <ogasawara> jsalisbury: I'd actually suggest status.ubuntu.com/ubuntu-quantal/canonical-kernel-distro-team
[15:48] <ogasawara> jsalisbury: it's more specific to our team
[15:48] <jsalisbury> ogasawara, ok, I'll make the change
[15:51] <jsalisbury> ogasawara, What would you like for the Quantal equivilent page for https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Precise
[15:51] <jsalisbury> ogasawara, this:
[15:51] <jsalisbury> https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Quantal
[15:51] <ogasawara> jsalisbury: yah use that, I'll make the page right now
[15:52] <jsalisbury> ogasawara, cool, thanks
[16:09] <kees> sweet, sweet API stability. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=259e5e6c75a910f3b5e656151dc602f53f9d7548 upstream PR_SET_NO_NEW_PRIVS will, in fact, continue to match what is in 12.04. *whew*
[16:12]  * ppisati -> brb
[16:28] <ogasawara> infinity: we're seeing buildd chroot problems with nihal, eg -> https://launchpad.net/ubuntu/+source/linux-ti-omap4/3.4.0-201.2/+build/3509520/+files/buildlog_ubuntu-quantal-armhf.linux-ti-omap4_3.4.0-201.2_CHROOTWAIT.txt.gz
[16:29] <ogasawara> infinity: we've seen this twice now
[16:43] <jsalisbury> https://bugs.launchpad.net/ubuntu/+source/linux/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&
[16:43] <jsalisbury> field.subscriber=&field.tag=quantal&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.upstream_target=&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_n
[16:43] <jsalisbury> o_blueprints=on
[16:54] <jsalisbury> **
[16:54] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[16:54] <jsalisbury> **
[17:08]  * ppisati run to the gym
[17:15] <ogasawara> smb: http://status.ubuntu.com/ubuntu-quantal/canonical-kernel-distro-team-quantal-alpha-1.html
[17:16] <cking> kinda handy to recall what I had to do :-)
=== jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues May 29th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
[17:17] <ogasawara> smb: I think I missed it when I did my copy and paste for the meeting
[17:17] <smb> cking, Yeah, exactly the reason I wanted to look at it
[17:18] <smb> ogasawara, Ah! /me already feared starting blindness
[17:18] <cking> burndown is hopefully not a synonym for burnout
[17:23] <cking> somtimes the only east way to fix a problem is with a screwdriver..
[17:24] <dantti> Hi, I've manually downloaded and installed 3.4 kernel from some mainline url, I have made a patch that went into rc7 but it's not working on the 3.4, is there better place to get new packaged kernels?
[17:26] <dantti> Iǜe also tried the xorg-edgers package but weirdly that doesn`t recognize any kind of hw I have even keyboard...
=== tgardner is now known as tgardner-lunch
[17:34] <dantti> ogasawara: hay you tried your last kernel update? built just finished I installed and nothing worked :P
[17:35] <ogasawara> dantti: can you be more specific?  I've got it running here just fine.
[17:35] <ogasawara> dantti: did you make sure you installed the extra's package?
[17:36] <dantti> ogasawara: hmm sorry, all I saw was some amd microcode errors.. should I install the extra package?
[17:37] <ogasawara> dantti: with the latest 3.4.0-3.7 upload, the extra's package is necessary 
[17:37] <dantti> I didn't installed those for the 3.4.0-2 package and it worked
[17:37] <dantti> ah right that's why the -2 worked
[17:37] <dantti> I'll install that then, thanks :)
[17:39]  * henrix is going to enjoy the sun for an hour or so. will be back later...
[17:39] <ogasawara> henrix: I think you should enjoy the sun for more than an hour and don't come back till tomorrow
[17:40] <henrix> ogasawara: yeah, but i have only an hour left of sunshine :)
[17:59]  * cking follows henrix idea
[18:07] <infinity> ogasawara: Thanks for the heads-up.
=== tgardner-lunch is now known as tgardner
[18:09] <ogasawara> infinity: wasn't sure if it was a known issue.  retrying the builds till they landed elsewhere seems to work around it.
[18:10] <infinity> ogasawara: It's a known issue.  Machine needs to be rebooted and tidied up.  Unsure precisely what's breaking it, and not keen on debugging it, since they're running natty...
[18:27] <dantti_laptop> ogasawara: using extra did make the boot detect stuff, but still my patch isn't available there  if I don't see HID_BATTERY_STRENGTH on the /boot/config it means it disabled?
[18:29] <ogasawara> dantti_laptop: which patch?  and yes, HID_BATTERY_STRENGTH looks to be disabled
[18:29] <ogasawara> ubuntu-quantal/debian.master/config$ grep -rn "HID_BATTERY_STRENGTH" *
[18:29] <ogasawara> config.common.ubuntu:2055:# CONFIG_HID_BATTERY_STRENGTH is not set
[18:29] <dantti_laptop> ogasawara: I've made a patch that probes the battery of hid devices it's upstream since 3.4-r7... can you enable it then?
[18:30] <dantti_laptop> I thought default would be y
[18:30] <ogasawara> dantti_laptop: can you file me a quick bug in lp for it and I'll get it on the todo list
[18:30] <dantti_laptop> ogasawara: ok, thanks :)
[18:31] <ogasawara> dantti_laptop: looks like the default was n
[18:31] <ogasawara> config HID_BATTERY_STRENGTH
[18:31] <ogasawara>         bool
[18:31] <ogasawara>         depends on HID && POWER_SUPPLY && HID = POWER_SUPPLY
[18:31] <ogasawara>         default n
[18:32] <dantti_laptop> hmm right, I'll poke people if it should be y
[18:32] <ogasawara> dantti_laptop: what's it provide exactly?  not much of a description in the Kconfig
[18:33] <dantti_laptop> ogasawara: well for example I have an Apple keyboar and magic track pad, both blue tooth and battery operated, this patch provides a power_supply interface to know the battery strength
[18:33] <dantti_laptop> it should work for all HID devices that conform to the HID standard, but we already have quirks :P
=== tgardner is now known as tgardner-afk
=== tgardner-afk is now known as tgardner
[19:13] <ogasawara> tgardner: hrm, I think we were a little too aggressive by completely removing the generic-pae meta package.  we still need it, but just need to have it redirect to the generic meta package.  without it we've completely orphaned generic-pae users in Precise from upgrading.
[19:20] <dantti_laptop> ogasawara: I'm always lost on launchpad, where do I report a new bug? :P
[19:21] <tgardner> ogasawara,  think thats where update-manager comes into play. we orphaned the -pae flavour on purpose.
[19:21] <tgardner> ogasawara, I'm still awaiting a response from Michael Vogt. I'll bug him on IRC in the morning.
[19:22] <ogasawara> tgardner: I though update-manager-core was only handling the package reaping?
[19:22] <tgardner> ogasawara, nope, the archive handles reaping. update-manager handles upgrades from release to release.
[19:23] <tgardner> ogasawara, now that you've uploaded the Quantal meta package I can experiment with upgrades from Precise to Quantal.
[19:23] <ogasawara> tgardner: ack
[19:23] <tgardner> using the upgrade-manager
[19:24] <ogasawara> dantti_laptop: run ubuntu-bug linux from a terminal, or alternatively bugs.launchpad.net/ubuntu/+source/linux/+filebug
[19:25] <ogasawara> dantti_laptop: that's for kernel specific bugs
[19:28] <dantti_laptop> thanks
[19:42] <dantti_laptop> ogasawara: done https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1003090
[19:42] <ubot2> Launchpad bug 1003090 in linux "Please enable HID_BATTERY_STRENGTH on xorg-edgers and quantal packages" [Undecided,New]
[19:43] <dantti_laptop> the cmd line tool complained about the package not being official...
=== Nafallo_ is now known as Nafallo
[19:53] <infinity> tgardner: We don't want logic like this in update-manager, if we can avoid it.
[19:53] <infinity> tgardner: generic-pae should depend on generic until the next LTS, IMO.
[19:54] <infinity> tgardner: Special logic in update manager should be seen as a way to work around packaging bugs, not an excuse to not have packages upgrade cleanly.
[19:55] <tgardner> infinity, what will change at the next LTS ? AFAICT the update-manager will (by default) install the default kernel in the installer iff there is no valid kernel choice.
[19:56] <infinity> tgardner: Nothing changes at the next LTS, except that we get to reset the upgrade paths we support.
[19:56] <tgardner> infinity, well, we still have to support LTS->LTS upgrades, and I'd still have the problem of upgrading generic-pae to generic.
[19:56] <infinity> tgardner: The goal should be for "apt-get dist-upgrade" to actually function.  update-manager/do-release-upgrade can have workarounds for when that's not true, but we shouldn't *expect* to clean up in update-manager when there's a perfectly viable solution at the packaging level.
[19:57] <tgardner> infinity, everything I've read suggests that the recommended upgrade mechanism is via the upgrade-manager
[19:57] <infinity> tgardner: Err, yes, which is why I said "until the next LTS".  As in, up to and including 14.04, generic-pae should depend on generic, for smooth upgrades.
[19:57] <infinity> tgardner: It's the recommended way to upgrade, that doesn't mean ignoring package relationships.
[19:58] <infinity> tgardner: The less smart update-manager needs to be, the better off we all are.
[19:58] <tgardner> infinity, lemme experiment with what it actually does.
[19:58] <infinity> tgardner: I'd rather you experiment with what apt-get does.
[19:58] <ohsix> upgrade-manager didn't account for the netbook remix upgrades on my netbook a few releases ago, and i only just realized last night that is why it's broken now :P
[19:59] <tgardner> infinity, I already know what apt-get does.
[19:59] <infinity> tgardner: Ultimately, update-manager is a thin wrapper around apt, with hacks and workaround for when we screw up.  If we don't screw up, we don't need workarounds.
[20:00] <infinity> Let me put it differently.  I'll ship a linux-generic-pae-meta myself to smooth the upgrade process if you don't. :P
[20:00] <infinity> Cause that's saner than upgrade hacks.
[20:01] <tgardner> infinity, there has to be an elegant way to orphan a package.
[20:01] <infinity> tgardner: Yes, and in our case, it's on LTS boundaries.
[20:01] <infinity> tgardner: The kernel isn't a special snowflake here.
[20:02] <infinity> (We did the same thing with openoffice->libreoffice, with metapackages that lived to upgrade from A to B until precise)
[20:02] <infinity> Besides, it's only a transitional meta package.  You *are* orphaning the actual kernels.
[20:02] <tgardner> infinity, I don't see what the LTS boundary has to do with it. I'm still stuck with generic-pae when 14.04 releases.
[20:03] <infinity> Eh?
[20:03] <tgardner> the generic-pae meta package still exists. I'm trying to reduce the number of them.
[20:03] <infinity> No, you have each of linux-*-generic-pae depending on linux-*-generic, and you make all the linux-generic-pae stuff be labelled as transitional packages.
[20:04] <infinity> You're no longer stuck with the kernel.  You might be stuck with an empty package, but that's a big who cares.
[20:04] <infinity> (We also have tools that can deal with this, including update-manager itself)
[20:05] <tgardner> infinity, well, lemme see how transitional works.
[20:07] <ohsix> from what i understand of how package names are changed, it's basically what infinity is saying, at least in debian
[20:08] <apw> infinity, a transitional package is just a normal meta type package deping on the replacement, with the text saying its transitional, right?  there is nothing speicial about them is there?
[20:08] <ohsix> right
[20:09] <ohsix> and it generally stays there for a "long" time, between the largest expected upgrade distance (like across one release or 3)
[20:10] <infinity> apw: That's it, yes.  And, in Debian (and we should pick up this convention), they also now live in Section: metapackages, I believe.
[20:10] <infinity> apw: The key is that they need to exist (in Debian) from stable to stable, and (in Ubuntu) from LTS to LTS.
[20:10] <infinity> Then you drop 'em like a hot potato, and no one cares.
[20:12] <infinity> apw: Oh, and the real reason I popped my head in here wasn't to have a hissy fit about metapackages.  It was to ask what's up with the weird diff for -24.39 in your PPA.
[20:12] <apw> infinity, point me at it
[20:12] <infinity> apw: AIUI, linux-3.2.0/drivers/ata/ata_piix.c is meant to be the only change, I'm trying to sort out if I should care about what the diff says about linux-3.2.0/arch/x86/kernel/reboot.c, or if that's just some bogon.
[20:12] <infinity> apw: https://launchpadlibrarian.net/105734948/linux_3.2.0-24.38_3.2.0-24.39.diff.gz
[20:13] <tgardner> infinity, so, if you have this transitional meta package in 14.04, how can you get away with orphaning it in 14.10? don't you create the same apt upgrade issue as we have currently ?
[20:13] <apw> infinity, i think we should be not expecting that diff indeed
[20:14]  * apw will poke as i didn't see it in the git diff
[20:14] <ohsix> in 14.04 it would install the other package, and in 14.10 it would cease to exist
[20:14] <infinity> tgardner: No, cause of linux-image-generic-pae depends on linux-image-generic (note, it's the meta depending on the meta), then dropping generic-pae post-14.04 harms nothing, the user is upgraded.
[20:14] <infinity> s/of/if/
[20:14] <apw> tgardner, by making linux-image-generic-pae depend on linux-image-generic, we know they have linux-image-generic on their system
[20:14] <apw> tgardner, so they are good going forward
[20:15] <tgardner> apw, doh. that makes sense
[20:15] <apw> tgardner, we likely can do something clever in 14.10 to make linux-image-generic-pae uninstall itself, a Conflicts: or something
[20:15] <tgardner> ok, I'll update Quantal meta
[20:16] <apw>  debian.master/changelog                            |   14 +
[20:16] <apw>  drivers/ata/ata_piix.c                             |    7 +
[20:16] <ohsix> you could do a conflict, but generally kernels are left behind (there are exclusions in aptitude and stuff for "important" base packages too)
[20:16] <infinity> apw: The conflict really isn't necessary, but you could do so, if the metapackage really offends you.
[20:16] <apw> infinity, ^^ ok thats the diff between the two at the git tag level ... wtf
[20:17] <infinity> apw: Weird.  Could just be debdiff doing something silly.  I can unpack source A and source B and compare the actual files.
[20:17] <apw> infinity, if you don't mind ... its very odd to my eye
[20:18] <infinity> (That said, we should have a certain amount of auto-tidying for things that claim to be transitional anyway.  And if that's not working, we should fix it... But either way, it's a few wasted bytes for a smooth upgrade, not a huge deal)
[20:19] <infinity> apw: Yeah, let me grab the original sources here and see if debdiff's just being brain-dead.
[20:19] <apw> interdiff impossible; taking evasive action
[20:20] <apw> any idea what the heck that means in the diff ^^ infinity 
[20:20] <infinity> Yeah.  Whatever "evasive action" means.
[20:20] <infinity> I'm as puzzled as you. ;)
[20:21] <apw> infinity, also does kernel-wedge use random hash order for the control file?  the diff there seems mad too
[20:21] <infinity> If I had to guess, I'd say maybe your origs don't match, which would mean your diffs don't either.  But I'd like to think you're more careful than that. ;)
[20:21]  * infinity is checking anyway.
[20:21] <apw> infinity, you can (no longer) upload with bad orig's can you ?
[20:21] <infinity> apw: k-w, the way you guys run it, ends up pretty system-dependent.
[20:22] <infinity> apw: Okay, so the origs are the same.  Weird.  Checking the sources now.
[20:22] <apw> infinity, i know we managed it in 2.6.24 but only there cause there really were two orig's in the launchpad database by then already
[20:22] <apw> infinity, and i know smoke poured out of several heads until they editied the db by hand to fix it
[20:23] <apw> but i thought now it was no longer possible, and we'd even tripped the error on it
[20:23] <infinity> apw: You can upload to a PPA with any orig you want.
[20:23] <infinity> apw: Which is where the PPA->archive thing can be a bit of a headache.
[20:24] <infinity> (In this case, though, it's the correct orig, so I dunno what debdiff is on about)
[20:24] <infinity> Has the same conniption locally, though.
[20:27]  * infinity falls asleep waiting for diff -urN.
[20:27] <infinity> apw: Okay, a proper diff is clean.  This is clearly a bug in debdiff. :P
[20:28] <apw> infinity, well spotted anyhow
[20:28] <infinity> apw: Crisis averted.  I'll be accepting this into -proposed for you in a bit, and seeing about fast-tracking the process.
[20:29] <infinity> apw: Oh, and someone went and created tracking bugs for rebasing derivatives.  That may not be necessary for, say, ARM machines that don't (I'd go so far as to say can't) use that driver. :P
[20:30] <infinity> s/bugs/tasks/
[20:30] <apw> infinity, indeed, the derivative people are meant to use their noggings and close them 'invalid' when its not needed
[20:30] <infinity> Oh.  I didn't realise you expected noggin use.  That's just crazy talk.
[20:30] <apw> ikepanhc, ppisati, you likely have rebase requests for precise which don't need doing, as its an x86 only fix ... do check before doing it
[20:47] <infinity> bjf: Let the QA machine roll on that precise SRU.  I'm prepared to fast-track it once some minimal verification and sanity checking is done; see the tracking bug.
[20:57] <tgardner> ogasawara, please review pushed ubuntu-quantal-meta. infinity convinced me I had my head up my ass.
[20:57] <ogasawara> tgardner: hehe, ack
[21:04] <vanhoof> apw: would these have hit armadaxp as well?
[21:09] <tgardner> ogasawara, I checked that all of the amd64 packages are installable. If you're happy then I think you should package up Quantal meta and upload.
[21:09] <bjf> apw, infinity would like confirmation that the one commit on the precise kernel in -proposed does indeed do what you expect (don't need to test it tonight)
[21:09] <ogasawara> tgardner: yep, it looks good here.  I'll get it uploaded.
[21:10] <infinity> tgardner: Except, weren't the changes to i386 packages? ;)
[21:10] <infinity> apw: bjf would like you to know that I'm incapable of talking to you directly (I didn't realise you'd be QAing your own upload)
[21:11] <tgardner> infinity, they were. I suppose I should do the whole test. grumble,
[21:11] <ogasawara> tgardner: I was gonna test for you.  but if you want to, I won't fight you over it :)
[21:11] <infinity> tgardner: Eh, if Leann says it looks sane, I believe her.  She's smarter than us.
[21:12] <tgardner> ogasawara, I;vev got it built. gimme 5 min
[21:12] <ogasawara> tgardner: ack
[21:22] <tgardner> ogasawara, tested i386 packages, packaged and uploaded. now I'm really EOD.
[21:23] <ogasawara> tgardner: sweet, thanks
[21:23] <apw> infinity, bjf, ok queued for first thing in the am
[21:23] <bjf> apw, thanks
=== bjf is now known as bjf[afk]