=== rsalveti` is now known as rsalveti
[09:04] <cjwatson> skaet: Do you think it might be possible to have an experimental freeze at some point, since we're not really doing it for milestones any more?  I'm not actually talking about freezing for real - I would like to just accept all uploads that land in unapproved - but I need a real-world stress-test of the new queue client before I remove the old script on cocoplum
[09:04] <cjwatson> SRUs aren't sufficient for this because they don't tend to close quite such large numbers of bugs at once (aside from kernel uploads, but they go through their own special path and don't count)
[09:07] <cjwatson> Or anyone else, interested in thoughts on the practicality of this
[09:07] <cjwatson> seb128: ^- you have strong views on freezes sometimes :)
[09:09] <seb128> cjwatson, freeze with auto accept seems like a no freeze from a maintainer perspective or I didn't understand what you suggest?
[09:12] <cjwatson> Well, not auto, I'd like to run 'queue accept' (with the new queue API client) on everything basically
[09:12] <cjwatson> But there'd inevitably be some delay since that involves a human
[09:12] <cjwatson> Basically trying to shake out things like timeouts, since once I remove the old queue script we won't have a fallback way to accept things
[09:13] <seb128> cjwatson, I've no issue with that, what I dislike is when we are frozen over 3 days because it starts creating practical issues
[09:14] <seb128> or when we unfreeze on friday because that's letting sometime an hundred packages hit the archive when everybody goes in eow mode
[09:14] <seb128> cjwatson, so +1 from me if the queue is dealt with on a daily basis during the freeze ;-)
[09:15] <cjwatson> Oh, right, yeah, I was thinking more like half-hourly modulo sleep :)
[09:16] <babyface_> daily iso test on quantal desktop ISOs didn't run, due to there is no new build today?  what's wrong?
[09:16] <cjwatson> Have you checked the build logs?
[09:16] <babyface_> skaet,  ^^
[09:16] <cjwatson> skaet won't be up yet
[09:17] <babyface_> cjwatson, not yet, I just checked the build time ,
[09:18] <cjwatson> the builds are still in progress
[09:18] <cjwatson> we need to sort out arm builders; at the moment there are a number of arm live builds that happen in succession, so you can expect the daily Ubuntu desktop builds to arrive a bit later than usual for a whie
[09:18] <cjwatson> *while
[09:19] <babyface_> cjwatson, could you tell me where can I get this information?  --- the builds are still in progress
[09:19] <babyface_> cjwatson, I wanna have a look
[09:19] <cjwatson> you can't, I was looking at ps on nusakan
[09:20] <cjwatson> you could possibly infer it from the fact that http://people.canonical.com/~ubuntu-archive/livefs-build-logs/quantal/ubuntu/20120712/livecd-20120712-i386.out completed successfully but there's no daily-live entry for today on http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/quantal/ yet
[09:20] <cjwatson> those were my first port of call
[09:20] <babyface_> cjwatson, ok, I see.   the desktop build will be late only for today? or for all the days after today?
[09:21] <cjwatson> not for ever, but not just for today either
[09:22] <babyface_> I'm very clear now, thanks for you help, cjwatson
[09:22] <cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/quantal/ubuntu-omap4/20120712/livecd-20120712-armhf.out seems to be the current one in progress
[13:36] <skaet> cjwatson,  +1 from me on a real world stress test.   How about we raise it at tomorrow's meeting,  and if no one has an issue,  pick a day or two early next week, and try it then?  (with suitable emails out to ubuntu-devel to warn what's going on)
[14:02] <ogra_> infinity, not sure you saw my ping yesterday, could you give the mx5 images a smoketest ?
[14:04] <stgraber> ogra_: not sure he's got the hardware at debconf
[14:04] <ogra_> oh, crap i forgot about debconf
[14:05] <ogra_> well, he is essentially the only person with that HW in the whole distro team
[14:05] <ogra_> so that has to wait
[14:05] <ogra_> du -hcs
[14:05] <ogra_> EFOCUS !
=== Ursinha` is now known as Ursinha
[15:06] <gema> cjwatson: jenkins seems to be up and happily running all its jobs again
[15:06] <gema> cjwatson: jamespage restarted it and now it is all fine again
[15:07] <Laney> turning it off and on again is the solution to all problems
[15:32] <cjwatson> gema: cool, thanks
[15:36] <bdmurray> so if a package has a micro release exception is every bug fixed by it still required to have test case and other SRU information
[15:37] <cjwatson> stgraber: On queuebot API stuff (#ubuntu-meeting), I haven't yet exported any way to find the uploader of a PackageUpload, but it probably wouldn't be desperately hard to do (worst case ~15 lines plus tests, I think)
[15:46] <cjwatson> skaet: I guess I could just start a discussion on -devel now
[15:48] <ScottK> bdmurray: I think not.  On the MRE's I've asked for, I've always said what we'd do to verify the package, so hopefully there is documentation somewhere (that I guess ought to be mentioned in the bug).
[15:49] <Laney> https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
[15:49] <Laney> there's some info at the end there
[15:52] <bdmurray> It seems to be that a microrelease that fixes bugs should also have those fixes verified in addition to 'broad smoke tests'
[15:52] <bdmurray> Certainly the package should not contain regressions but it should also really fix the bugs identified
[15:54] <bdmurray> I guess there is this wording though 'it can generally be assumed that bugs claimed to be fixed have actually been fixed upstream'
=== seb128_ is now known as seb128
[16:21] <cjwatson> +    except Exception as message:
[16:21] <cjwatson> +        if message[0][:14] == "Could not find":
[16:21] <cjwatson> ScottK: ^- I think we could do better than parsing exception messages.  Perhaps those are reliably HTTPError with .code == 404?
[16:22] <ScottK> cjwatson: Dunno.  I looked and you were just catching an Exception in lputils.py.
[16:23] <ScottK> If it were just up to me, I'd have subclassed Exception for those two errors and caught it based on the subclass.
[16:23] <ScottK> PackageMissing(Exception): or so.
[16:23] <ScottK> I wasn't entirely sure what that might affect though since lots of the scripts use lputils.
[16:23] <cjwatson> s/catching/raising/?  Oh yeah.  I would suggest just creating a new exception class for those.
[16:24] <cjwatson> I was just being lazy.
[16:24] <cjwatson> I wouldn't expect that to break anything.
[16:24] <ScottK> OK.
[16:24] <ScottK> I can do that in a bit.
[16:24] <cjwatson> Ta.
[16:25] <ScottK> The message parsing was mostly about keeping the change contained to queue.
[16:26] <ScottK> err, remove-package
[16:26] <cjwatson> It seems like a sensible change in general, although it makes sense to do the except/exit at the top level rather than in lputils.
[16:29] <ScottK> Those functions show up in a few other scripts, so I'll look at them before I commit.
[16:56] <infinity> ogra_: I can't, I'm in Nicaragua. :P
[16:56] <infinity> ogra_: When I get home, perhaps, sure.
[16:56] <ogra_> infinity, yeah, got that from stephanes comment :)
[16:57] <ogra_> i simply missed the bit of you traveling ...
[16:59] <infinity> ogra_: Jani has an mx5 too, borrow him. ;)
[16:59] <ogra_> well, i need him for ac100 kernel work first, i dont want to exhaust him ;)
[17:23] <jdstrand> cjwatson: fyi, bug #1023986. I'm not sure it is related to your work or not
[17:23] <ubot2> Launchpad bug 1023986 in launchpad ""Available diffs" are not accessible when publishing private packages via copyPackage() " [Undecided,New] https://launchpad.net/bugs/1023986
[17:28] <cjwatson> jdstrand: It's not something I broke, but it does seem to be a problem with PCJs.
[17:29]  * cjwatson peers at the publishing history.
[17:29] <cjwatson> Yeah, as I thought, 5.3 was originally in the security PPA.
[17:39] <jdstrand> cjwatson: interesting-- Marc's puppet update today used syncSource and the diff was generated by having both come from the security ppa. I added that detail to the bug
[17:39] <jdstrand> (both meaning today's update and the previous update)
[17:39] <jdstrand> anyhoo, it is filed, I'm moving on :)
[17:43] <cjwatson> jdstrand: I'm actually pretty puzzled.
[17:46] <cjwatson> Can't really spend any longer on it right now though; it's not a leak
[17:46] <jdstrand> no
[17:46] <jdstrand> and I didn't really intend for you to
[17:47] <jdstrand> I just thought it could potentially be related to your recent work is all
[17:47] <cjwatson> Worrying though.
[17:47] <jdstrand> and you said it was not
[17:47] <cjwatson> Well, I don't *think* so.
[17:47] <cjwatson> But it would be a regression in moving you to copyPackage.
[17:47]  * jdstrand nods
[17:47] <cjwatson> So I do care about that even if it wasn't my fault.
[17:50] <cjwatson> I wonder if it's actually the diff requested by PCJ.attemptCopy.  That would explain the difference between syncSource and copyPackage.
[17:53] <cjwatson> I notice that delayed copies (which syncSource still uses) don't bother requesting a new diff for the target archive.  (Which is arguably differently wrong.)
[17:53] <jdstrand> huh
[17:56] <cjwatson> In fact you can kind of see that in your rhythmbox case.  Surely it ought to have a diff against 2.90.1~20110908-0ubuntu1.3.
[17:57] <jdstrand> I was wondering if what you just said related to that
[17:57] <jdstrand> that has often been an annoyance
[17:57] <jdstrand> in fact...
[17:57] <jdstrand> bug #294886
[17:57] <ubot2> Launchpad bug 294886 in launchpad "security private PPA debdiff generator uses the wrong pocket" [High,Triaged] https://launchpad.net/bugs/294886
[17:59] <cjwatson> It is slightly related.
[17:59] <jdstrand> I guess this is more #237092
[17:59] <jdstrand> bug #237092
[17:59] <ubot2> Launchpad bug 237092 in launchpad "Package diffs should only be generated against previous releases within a distroseries" [High,Fix released] https://launchpad.net/bugs/237092
[17:59] <cjwatson> Though more a demonstration of how not to do it.
[18:00] <jdstrand> oh, that is different
[18:10] <cjwatson> jdstrand: I've put a better analysis in the bug now.  I'd need to turn that into a test case to be certain of it, but if I'm right then it's easy to fix.
[18:10] <jdstrand> cjwatson: awesome, thanks :)
[22:07] <stgraber> skaet: in case you're wondering thunderbird was a bit buggy, the two e-mails are identical :)
[22:20] <skaet> stgraber,  :)