[00:50] <xnox> does MoM have some kind of blacklist? autofs package is not shown on the main.html
[00:55] <slangasek> I thought it was using the sync blacklist these days; if it's not it should be
[00:56]  * xnox goes to find blacklist.
[00:56] <slangasek> lp:~ubuntu-archive/+junk/sync-blacklist/, and yes autofs is listed
[00:56] <xnox> slangasek: please remove autofs from the blacklist?
[00:57] <xnox> history: we renamed it to autofs5, then debian followed, and then debian made autofs5 -> autofs name change. So it's now back to it's original name using the latest code.
[00:57] <slangasek> xnox: do you know what "manual intervention" cjwatson was referring to in the commit log?
[00:58] <xnox> oh that's what happened, and I guess that's what he means. We packaged autofs5 (source package), while debian had autofs (the 4 series, source package).
[00:58] <xnox> and at that time we did not want autofs any more. Now we do =)
[00:59] <xnox> hmm...
[00:59]  * xnox needs to think about our LTS->LTS transition.
[00:59] <ScottK> For that, only binaries matter.
[01:00] <slangasek> xnox: well, it was blacklisted in June, right before you did the merge into quantal.  I can un-blacklist it regardless, and just trust you to pick up the pieces :)
[01:00] <xnox> ok. I got it.
[01:00] <slangasek> xnox: since there's now a source package in Ubuntu, we don't have to worry about it auto-syncing anyway
[01:00] <slangasek> fwiw, you could always do a UDD merge here and not wait for MoM
[01:00] <xnox> slangasek: yeah, correct. it was just before i merged it =) and that's when the blacklist was needed.
[01:01] <xnox> slangasek: thanks. I will be picking up the pieces.
[01:01] <slangasek> xnox: also, upstart 1.5 is in unstable, so feel free to push that upstart job to Debian. :)
[01:02] <xnox> slangasek: well that's what I do anyway. It's just that merges.ubuntu.com is my preffered overview of my merges todo + list of "interesting" merges.
[01:02] <cjwatson> slangasek: there was a clash in Ubuntu-versioned binaries which needed somebody to figure out whether the patches needed to be carried over
[01:02] <xnox> Yeah! =) about upstart =)
[01:02] <slangasek> ah, ok
[01:02] <slangasek> cjwatson: yep, seems to be done now for this package
[01:03] <phillw> a real quick question guys... bug 1057022 as it works in 'R' and fixes PCManFM, what work is needed for a SRU? Does it fall under https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases ?
[01:03] <ubot2> Launchpad bug 1057022 in gvfs "PCManFM lists all partitions and devices twice" [Medium,Confirmed] https://launchpad.net/bugs/1057022
[01:03] <cjwatson> slangasek: so yeah, feel free to unblacklist
[01:03] <slangasek> but I guess we should maybe try to do some systematic review of the other entries in that blacklist
[01:04] <slangasek> (done)
[01:05] <xnox> slangasek: thanks.
[01:05] <ScottK> phillw: Upstream micro-release SRUs are only for those packages that have approval from the technical board.
[01:05] <xnox> slangasek: a systematic review would be possible, if there was any sensible way to indicate what condition / actions need to change/complete for unblacklisting.
[01:06] <xnox> e.g. remove blacklist, if this package is also removed in Debian.
[01:06] <slangasek> phillw: gvfs 1.14.2 would be covered by the GNOME MRE
[01:06] <slangasek> ScottK: ^^
[01:06] <xnox> e.g. remove blacklist, if this package is properly merged with the debian edition.
[01:06] <xnox> etc.
[01:06] <ScottK> OK.  MIs-read the package name.
[01:07] <slangasek> xnox: ah, well, we generally try to make sure it's documented, but YMMV :)
[01:08] <phillw> slangasek: you'll have to excuse me, I'm really new to filing an SRU, but there is a 1st time for everything. Can you tell me which part of the wiki page I need to follow for gvfs?
[01:09] <slangasek> phillw: "all of them", and if something doesn't make sense ask and we should fix the wiki page
[01:09] <slangasek> phillw: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
[01:09] <phillw> slangasek: thanks, I'll have a good read through.
[09:54] <ogra_> infinity, bah, linux-nexus7 is still in NEW :(
[09:54] <infinity> ogra_: I'll clear it out in the morning.  I was fixing other ARM things yesterday. :P
[09:54] <ogra_> ok
[09:55] <ogra_> hmm, celbalrai is still dead as well
[10:11] <cjwatson> ogra_: Has there been an MIR for android-tools?
[10:12]  * cjwatson fixes the linux-signed-image-* component-mismatch that caused Ubuntu desktop amd64 to fail to build this morning
[10:12] <ogra_> cjwatson, not sure we need one, does live-build not use universe during build ?
[10:12] <ogra_> the images will be built from universe packages, i was hoping the chroot will use that as well then
[10:13] <cjwatson> ogra_: component-mismatches is to be kept clean
[10:13] <ogra_> k
[10:13] <cjwatson> ogra_: Yes, technically it does not break live builds
[10:13] <cjwatson> But if we're using it in our builds, it really should be MIRed
[10:13] <ogra_> oh, and we'll need fastboot for the installer, so that definitely needs to go to main
[10:13] <ogra_> yep, i'll write up a MIR
[10:14] <cjwatson> Kubuntu daily-live failed transiently; rebuilding
=== mmrazik is now known as mmrazik|lunch
[11:03] <ev> so I had an upload of activity-log-manager 0.9.4-0ubuntu3.1 uploaded to precise rejected a while back. I believe this was because the same version had been uploaded, but I can't seem to find anything later than 0.9.4-0ubuntu3 in precise{,-*}
[11:04] <ev> and indeed, there's nothing in the precise-changes ML for it
[11:05] <cjwatson> As far as I can see it was manually rejected
[11:06] <cjwatson> I have no way to tell why
[11:06] <cjwatson> Did you get an e-mail from any archive admin explaining?
[11:13] <cjwatson> ev: Oh, there we go, there's an explanation in bug 993056 comment 10
[11:13] <ubot2> Launchpad bug 993056 in activity-log-manager (Ubuntu Quantal) ""Privacy" > "Diagnostics" > "Send error reports" can't be turned on or off" [High,Triaged] https://launchpad.net/bugs/993056
[11:14] <cjwatson> ev: Upload a matching change to quantal-proposed and I'll be happy to review it
[11:14] <ev> ohhhh
[11:14] <ev> cjwatson: thanks, I totally missed that
[11:14] <ev> isn't there a "rejected reason" field in the archive admin toolset?
[11:14] <cjwatson> ev: Bug 31750
[11:14] <ubot2> Launchpad bug 31750 in Launchpad itself "rejects should allow (and require) reasons" [Low,Triaged] https://launchpad.net/bugs/31750
[11:15] <ev> :D
[11:15] <ev> you have that number memorised, don't you?
[11:15] <cjwatson> My firefox URL bar does
[11:15] <ev> lol
[11:18]  * cjwatson rebuilds the amd64 desktop daily now that the signed kernel should be installable again
[11:52] <ogra-cb_> hmm, i tought i saw a livecd-rootfs upload from BenC yesterday ... neither the source package nor the bzr tree seem to have any though
[11:52] <ogra-cb_> *any changes
[11:56] <cjwatson> There's an MP
[11:56] <cjwatson> I'll review it at some point today
[11:56] <ev> yikes - can someone reject the upload of activity-log-manager I just made to raring?
[11:56] <ogra-cb_> ah, well, i thought i saw an upload too
[11:56] <ev> I forgot the control changes
[11:56] <ogra-cb_> oh, wait, my deb-src should probably point to proposed for that
[11:57] <cjwatson> ev: No, raring isn't frozen so no opportunity to reject
[11:57] <ev> eep
[11:57] <cjwatson> ev: Just upload a new version quick :)
[11:57] <ev> yup
[11:57] <ev> on it :)
[11:57] <cjwatson> ev: What's the broken version number?  I can block it in raring-proposed
[11:58] <ev> 0.9.4-0ubuntu5
[11:59] <cjwatson> blocked
[11:59] <cjwatson> this -proposed business means we have a decent window for such things
[12:00] <ev> wooohoo
[12:00] <ev> thanks cjwatson
[12:00] <ev> and 6 is uploaded
=== ogra-cb_ is now known as ogra-cb
[12:12] <seb128> cjwatson, I got 4 emails "[ubuntu/raring] indicator-power 12.10.5-0ubuntu1 (Accepted)" at 11:59 UTC, just pointing it because I don't know if that's normal
[12:13] <seb128> it was already accepted at 11:05 a first time
[12:14] <cjwatson> Odd but probably not a problem and I don't know if there's much I can do to debug right now
[12:14] <seb128> ok, no worry, I just wanted to mention it in case it's an useful info ;-)
[12:15] <cjwatson> Ah, I see, it seems to be copying the binaries
[12:15] <cjwatson> But I think this is because of a launchpadlib crash that's confused britney
[12:16] <cjwatson> I've nuked the cache, should clear thing
[12:16] <cjwatson> *this
[12:16] <seb128> good
[12:16] <cjwatson> The mails are a bug in themselves but minor by comparison :)
[12:17] <Laney> I kind of like getting them
[12:17] <cjwatson> Well, no, they're a bug because the binaries were already there
[12:17] <cjwatson> There should have been no notification of a no-op
[12:18] <Laney> ok, not the copying mails per se
[12:18] <cjwatson> (This was a partial duplicate copy)
[12:18] <cjwatson> The lplib cache corruption caused us to update proposed-migration's Sources but not Packages, so it was confused about the state of the world
[12:21]  * cjwatson installs a workaround to avoid this particular manifestation of that problem in future
=== mmrazik|lunch is now known as mmrazik
[15:06]  * Riddell removes the "tentative" from alphas on release schedule since kubuntu does want them
=== peterm-ubuntu is now known as Peter_phone
[15:14] <Riddell> skaet, persia et al: should the work items from http://summit.ubuntu.com/uds-r/meeting/21542/foundations-r-flavor-pm-mtg/ be rescued and put on https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-flavor-pm-mtg ?
[15:15] <Riddell> ScottK, pgraner ^^
[15:26] <pgraner> Riddell, thanks, its on my todo list just haven't made it that far... Ubuflu took me out for the better part of last week
[15:26] <pgraner> Riddell, I'll get it caught up by the end of the week
[15:30] <Riddell> groovy
[15:45] <bdmurray> cjwatson: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/global-ignored-commenters/+merge/134317
[15:50] <cjwatson> bdmurray: merged, thanks
[15:51] <stgraber> cjwatson: had a chance to look at mine or got scared by the diff (quite a bunch of isotracker changes)? :)
[15:52] <cjwatson> Oh, I saw it last thing last night and then forgot about it
[15:53] <cjwatson> Do we have anything on lillypilly that uses it?
[15:53] <cjwatson> *any of those scripts
[15:53] <cjwatson> I'll try to review that gradually today ...
[15:55] <cjwatson> I tend to feel actually changing the #! to python3 in ubuntu-archive-tools is a bit of a timebomb until such time as we have a python3-launchpadlib, even if it works for a given script
[15:55] <cjwatson> (because we might well want to use launchpadlib in them later)
[15:55] <cjwatson> making them py3-compatible is clearly a good thing
[15:57] <stgraber> AFAIK the only script used in the DC is post-image-to-tracker which I kept as python2, the rest are usually run on developer machines
[15:57] <cjwatson> OK, but still, if we have to add launchpadlib to something then we'll have to revert it to Python 2, which will be awkward if it's been running with python3 and we've accidentally used 3-only features
[15:58] <cjwatson> Also I want to migrate publish-image-set to nusakan this cycle
[15:59] <stgraber> cjwatson: ok, pushed a change reverting the two scripts to python2
[16:02] <cjwatson> stgraber: righto, merged now, thanks
[16:09] <ScottK> Riddell: Yes.
[16:26] <stgraber> micahg: thanks!
[16:26] <micahg> stgraber: you're welcome, I'll finish with it a bit later
[16:26] <xnox> micahg: so do backports end up in the unapproved queue or not?
[16:27] <skaet> Riddell,  yup,  those work items should be moved.
[16:27] <micahg> xnox: if it's not NEW, yes
[16:27] <xnox> micahg: from mere mortals.
[16:27] <xnox> micahg: ah that's good then.
[16:27] <micahg> xnox: yes, if you have upload rights for the package
[16:27] <xnox> ack.
[16:28] <Laney> xnox is joining the backporters?
[16:29] <xnox> Laney: nah, sponsoring uploads.
[16:29] <xnox> =))))
[16:29] <Laney> into backports?
[16:30] <Laney> that sounds weird
[16:30] <xnox> Laney: tell me about it ;-)
[16:30] <xnox> Laney: you'll see....
[16:30] <Laney> like, if it's been approved (which it must be before you upload), why didn't the approver upload the backport?
[16:32] <xnox> Laney: define "approved". I have upload rights and if I do the bug paper work, I can upload right?
[16:32] <Laney> no, a backporter needs to do it
[17:09] <Riddell> what's the current protocol on SRUs?  can I accept them as an archive admin into -proposed or do I need to wait for ~ubuntu-sru approval?
[17:13] <ScottK> Riddell: ubuntu-sru approval.
=== doko_ is now known as doko
[18:10] <bdmurray> Riddell: is there something you need looked at?
[18:11] <bdmurray> infinity, slangasek, cjwatson: could you have a look at the needs more testing or it will be removed from -proposed comment?
[18:11] <bdmurray> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/589063/comments/20
[18:11] <ubot2> Launchpad bug 589063 in seabios (Ubuntu Lucid) "Windows Server 2008 won't boot with more than 4 vCPUs" [Undecided,Fix committed]
[18:13] <Riddell> bdmurray: not any more thanks, ScottK got onto it
[18:15] <infinity> bdmurray: Does this also get mailed to the uploader, or just a bug comment currently?
[18:15] <bdmurray> infinity: just a comment
[18:15] <infinity> Didn't we discuss the former in the session?
[18:16] <infinity> (Though, that depends on the APIification of the sru-processing tool)
[18:16] <bdmurray> I recall emailing uploader when rejecting, not when bugs were still needing verification
[18:17] <infinity> Oh, I suppose it could wait until the actual reject, sure.
[18:17] <infinity> Err, s/reject/removal/, in this case.
[18:17] <infinity> And you're right, we were discussing queue rejection before.
[18:17] <infinity> I'm not all here today.
[18:18] <infinity> Still, telling the uploader on removal would also be good.  There's no decent indicator otherwise that it's gone.
[18:19] <bdmurray> infinity: so on removal not on warning would make sense?
[18:20] <infinity> Yeah.  Probably.  I think it's more about "by the way, your package is gone", rather than nagging the uploader to do something about it.
=== Ursinha-afk is now known as Ursinha
[18:48] <apw> anyone know who owns extras.ubuntu.com, seems to be missing raring and so borking update-manager updates
[18:49] <stgraber> apw: I know how to fix it but I don't think I can still do it myself, let me see
[18:50] <stgraber> apw: right, I can't do it myself as I'm not a member of the team anymore, but I can re-active my membership for the 5 minutes it'll take to fix this
[18:51] <stgraber> apw: should be fixed in a couple of hours (needs 2 PPA publisher runs + a mirror sync from IS)
[18:53] <apw> stgraber, thanks
[19:02] <slangasek> bdmurray: the "needs more testing" comment looks good to me; no opinion on emailing the uploader, for my part I only care about the bug nag and that looks good
[19:06] <bdmurray> Is there an undocumented micro release exception for quantum?
[19:07] <stgraber> apw: LP side of things is done, I now poked #is to trigger the mirror and update the mirror script if needed
[19:13] <apw> infinity, fyi we have separated -lowlatency off so it can transition independantly via britney
[19:20] <stgraber> apw: should be all fixed now
[19:30] <infinity> apw: As in, giving it its own headers?  Alrighty.
[19:47] <apw> infinity, yeah it has its own linux-lowlatency-headers-* common headers all of its own
[19:48] <infinity> apw: Cool.  Hopefully, this won't become an excuse to let it lag dreadfully behind on rebases. :/
[19:51] <apw> infinity, nope, just to not hold up the migrations
[20:00] <slangasek> bdmurray: there's no such thing as an "undocumented" MRE ;)
[20:04] <bdmurray> slangasek: great!  I'm in the loop then
[20:49] <infinity> Oh god, what have I done?
=== yofel_ is now known as yofel
[20:50] <infinity> bdmurray: Quick, can you go back in time and give sru-release a -q flag to suppress "this has been released, have a nice day" comment spam?
[20:50] <cjwatson> bdmurray: There were a few typos in that not-verified-yet comment - has somebody already proofread it?
[20:51] <infinity> https://launchpad.net/ubuntu/+source/linux-lowlatency/3.2.0-33.32 <-- Not the friendliest changelog ever.
[20:51] <infinity> cjwatson: Oh, BTW, the above should be a pretty fine test of your async bug closure business.  I don't think we'll ever do worse.
[20:51] <cjwatson> Pretty sure that's been tested to death now :)
[20:52] <infinity> Yeah, I know. :P
[20:52] <infinity> But this one beats 'em all.
[20:53] <cjwatson> Ahaha
[20:53] <cjwatson> Can't sru-release at least ignore bugs that don't have the right task?
[20:53] <cjwatson> (And this, kids, is why autogenerated changelogs are a tool of the devil.)
[20:54] <infinity> I should have just done a raw copy, I wasn't really thinking. :P
[20:54] <infinity> Soyuz, though, handled it admirably.  sru-release is still working on it. :P
[20:54] <cjwatson> (Because any human would have looked at that and thought "I'm not uploading that".)
[20:54] <cjwatson> Might be worth C-cing sru-release?
[20:54] <cjwatson> That looks like an awful lot of potential comment spam.
[20:55] <infinity> Perhaps.  The longer it took, the more I got curious about how long it would take.
[20:55]  * infinity Ctrl-Cs and does the copy to security manually.
[20:57] <bdmurray> cjwatson: no what typos?
[21:00] <infinity> Huh.  How does copy-package differ from sru-release, I wonder?  The former is timing out for me, while the latter was perfectly happy. :/
=== Ursinha is now known as Ursinha-afk
[22:06] <xnox> SpamapS: can you please, please promote https://launchpad.net/ubuntu/oneiric/+queue?queue_state=1&queue_text=grub2 to oneiric-proposed?
[22:06] <xnox> it's the same diff that has been applied & verified in precise & there are people waiting for it =)
[22:06] <SpamapS> xnox: I'll switch to oneiric and check it out, sure.
[22:06] <xnox> SpamapS: thanks a lot =))))
[22:13] <SpamapS> infinity: I notice you accepted a newer gccgo-4.7 in precise-proposed , should we reject 4.7.2-0ubuntu1 then?
[22:13] <SpamapS> xnox: accepted, not sure why queuebot hasn't seen it yet
[22:16] <infinity> SpamapS: Reject it how?
[22:16] <infinity> SpamapS: The new one will replace the old one.
[22:16] <infinity> SpamapS: Oh, there was an older one in the queue, right.
[22:16] <SpamapS> infinity: True, just making sure it needs to be rejected.
[22:16] <infinity> Not anymore :P
[22:17] <infinity> There must have been two of that older one in the queue, cause I'd already accepted one.
[22:18] <SpamapS> probably
[22:30] <RAOF> Huh. Why has nvidia-graphics-drivers-310 for precise-proposed landed in source NEW?
[22:31] <infinity> Because it's new, I assume?
[22:31] <infinity> (as in, never seen in precise)
[22:32] <RAOF> It's not seen in precise, but launchpad has provided the diff against the previous version in precise-updates.
[22:34] <RAOF> I guess that's a bug somewhere; some part of launchpad knows that it's not new, because it's generating the diff, but something else thinks its new.
[22:34] <infinity> Oh, it's in updates, but new in proposed?
[22:35] <RAOF> nvidia-graphics-drivers-experimental-310 | 310.14-0ubuntu0.1 | precise-updates/restricted | source
[22:36] <RAOF> But that 0ubuntu0.2 upload ended up in source NEW for some reason.
[22:36] <infinity> Maybe it hit the queue at some point when it didn't yet exist anywhere?  I dunno.
[22:37] <RAOF> I don't think so; it got uploaded after 0ubuntu0.1 had made it all the way through to precise-updates.
[22:37] <infinity> Strange.
[22:41] <infinity> Anyone have any objections to me filtering kernel packages out of pending-sru.html, since they're also represented (in a more readable fashion, IMO) in the kernel SRU report, which is linked from pending-sru?
[22:42] <xnox> infinity: as far as I can see on https://launchpad.net/ubuntu/+source/eglibc/2.15-0ubuntu10.3 both bug 956051 and 979003 are "fix released" for the precise task. Can I mark them as such?
[22:42] <ubot2> Launchpad bug 979003 in eglibc (Ubuntu Oneiric) "libc incorrectly detects AVX support" [High,Confirmed] https://launchpad.net/bugs/979003
[22:42] <ubot2> Launchpad bug 956051 in eglibc (Ubuntu Precise) "libc6 crash while running 'xm'" [High,Fix committed] https://launchpad.net/bugs/956051
[22:44] <infinity> xnox: Hrm, automated bug closures seem to have failed there.
[22:44] <infinity> xnox: Those won't be the only two affected.  Let me hunt them all down manually and close them.
[22:45] <slangasek> infinity: I think filtering the kernels out of the main body of the report would be nice, as long as you're sure you can fashion the exclusion rule accurately :)
[22:46] <xnox> infinity: hence the first link with the changelog entry ;-)
[22:46] <infinity> slangasek: Yeah, I planned to wildcard linux-meta-*, linux-lts-*, and linux-backports-modules-*, and then do the flavours (linux, linux-armadaxp, etc) individually, to avoid being overbroad with something that may start with "linux".
[22:46] <xnox> infinity: which has all the bugs "linkified" for you.
[22:46] <infinity> xnox: Cleaning up now, thanks for the heads-up.
[22:46] <slangasek> infinity: yep, sounds sane to me
[22:46] <xnox> infinity: it's just that those two bugs are more important, as stockachu wants to sru them further back in time.
[22:46] <xnox> ;)
[22:50] <infinity> xnox: The lucid hack is the same thing Debian's carrying for older glibc versions, it should work fine.  Were you planning on sponsoring that?  I can do it right now, if not (I'm in a glibc frame of mind today anyway).
[22:51] <xnox> infinity: please do =))))
[22:53] <infinity> (For some value of "work fine" that basically just means it violently disables some bits, rather than improving detection, but that's about the best we can do without a several thousand line backport from 2.16)
[22:54] <infinity> I still the the right answer for people running shiny new hardware is to tell them to run precise, but whatever.  This is easy enough.
[22:56] <infinity> s/still the/still think/
[22:57] <xnox> infinity: sure... but can a leopard change it's spots?
[22:57] <xnox> =)))))
[22:59] <infinity> With enough bleach.
[22:59]  * infinity notes the patch on that bug is incomplete, and does his own...
[23:00]  * xnox slowly backs away as infinity pours more bleach over the patch
[23:00] <xnox> infinity: thanks a lot =))))
=== Ursinha-afk is now known as Ursinha
[23:50] <cjwatson> bdmurray: "for the this bug"; "testing feeback"; also I would tend to suggest that the last sentence would be easier to read if there were a comma after "15 days from now"
[23:56] <bdmurray> cjwatson: fixed, thanks