=== rsalveti` is now known as rsalveti
cjwatsonskaet: 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 cocoplum09:04
cjwatsonSRUs 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:04
cjwatsonOr anyone else, interested in thoughts on the practicality of this09:07
cjwatsonseb128: ^- you have strong views on freezes sometimes :)09:07
seb128cjwatson, freeze with auto accept seems like a no freeze from a maintainer perspective or I didn't understand what you suggest?09:09
cjwatsonWell, not auto, I'd like to run 'queue accept' (with the new queue API client) on everything basically09:12
cjwatsonBut there'd inevitably be some delay since that involves a human09:12
cjwatsonBasically trying to shake out things like timeouts, since once I remove the old queue script we won't have a fallback way to accept things09:12
seb128cjwatson, I've no issue with that, what I dislike is when we are frozen over 3 days because it starts creating practical issues09:13
seb128or when we unfreeze on friday because that's letting sometime an hundred packages hit the archive when everybody goes in eow mode09:14
seb128cjwatson, so +1 from me if the queue is dealt with on a daily basis during the freeze ;-)09:14
cjwatsonOh, right, yeah, I was thinking more like half-hourly modulo sleep :)09:15
babyface_daily iso test on quantal desktop ISOs didn't run, due to there is no new build today?  what's wrong?09:16
cjwatsonHave you checked the build logs?09:16
babyface_skaet,  ^^09:16
cjwatsonskaet won't be up yet09:16
babyface_cjwatson, not yet, I just checked the build time ,09:17
cjwatsonthe builds are still in progress09:18
cjwatsonwe 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 whie09:18
babyface_cjwatson, could you tell me where can I get this information?  --- the builds are still in progress09:19
babyface_cjwatson, I wanna have a look09:19
cjwatsonyou can't, I was looking at ps on nusakan09:19
cjwatsonyou 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/ yet09:20
cjwatsonthose were my first port of call09:20
babyface_cjwatson, ok, I see.   the desktop build will be late only for today? or for all the days after today?09:20
cjwatsonnot for ever, but not just for today either09:21
babyface_I'm very clear now, thanks for you help, cjwatson09:22
cjwatsonhttp://people.canonical.com/~ubuntu-archive/livefs-build-logs/quantal/ubuntu-omap4/20120712/livecd-20120712-armhf.out seems to be the current one in progress09:22
skaetcjwatson,  +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)13:36
ogra_infinity, not sure you saw my ping yesterday, could you give the mx5 images a smoketest ?14:02
stgraberogra_: not sure he's got the hardware at debconf14:04
ogra_oh, crap i forgot about debconf14:04
ogra_well, he is essentially the only person with that HW in the whole distro team14:05
ogra_so that has to wait14:05
ogra_du -hcs14:05
ogra_EFOCUS !14:05
=== Ursinha` is now known as Ursinha
gemacjwatson: jenkins seems to be up and happily running all its jobs again15:06
gemacjwatson: jamespage restarted it and now it is all fine again15:06
Laneyturning it off and on again is the solution to all problems15:07
cjwatsongema: cool, thanks15:32
bdmurrayso if a package has a micro release exception is every bug fixed by it still required to have test case and other SRU information15:36
cjwatsonstgraber: 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:37
cjwatsonskaet: I guess I could just start a discussion on -devel now15:46
ScottKbdmurray: 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:48
Laneythere's some info at the end there15:49
bdmurrayIt seems to be that a microrelease that fixes bugs should also have those fixes verified in addition to 'broad smoke tests'15:52
bdmurrayCertainly the package should not contain regressions but it should also really fix the bugs identified15:52
bdmurrayI guess there is this wording though 'it can generally be assumed that bugs claimed to be fixed have actually been fixed upstream'15:54
=== seb128_ is now known as seb128
cjwatson+    except Exception as message:16:21
cjwatson+        if message[0][:14] == "Could not find":16:21
cjwatsonScottK: ^- I think we could do better than parsing exception messages.  Perhaps those are reliably HTTPError with .code == 404?16:21
ScottKcjwatson: Dunno.  I looked and you were just catching an Exception in lputils.py.16:22
ScottKIf it were just up to me, I'd have subclassed Exception for those two errors and caught it based on the subclass.16:23
ScottKPackageMissing(Exception): or so.16:23
ScottKI wasn't entirely sure what that might affect though since lots of the scripts use lputils.16:23
cjwatsons/catching/raising/?  Oh yeah.  I would suggest just creating a new exception class for those.16:23
cjwatsonI was just being lazy.16:24
cjwatsonI wouldn't expect that to break anything.16:24
ScottKI can do that in a bit.16:24
ScottKThe message parsing was mostly about keeping the change contained to queue.16:25
ScottKerr, remove-package16:26
cjwatsonIt 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:26
ScottKThose functions show up in a few other scripts, so I'll look at them before I commit.16:29
infinityogra_: I can't, I'm in Nicaragua. :P16:56
infinityogra_: When I get home, perhaps, sure.16:56
ogra_infinity, yeah, got that from stephanes comment :)16:56
ogra_i simply missed the bit of you traveling ...16:57
infinityogra_: 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 ;)16:59
jdstrandcjwatson: fyi, bug #1023986. I'm not sure it is related to your work or not17:23
ubot2Launchpad bug 1023986 in launchpad ""Available diffs" are not accessible when publishing private packages via copyPackage() " [Undecided,New] https://launchpad.net/bugs/102398617:23
cjwatsonjdstrand: It's not something I broke, but it does seem to be a problem with PCJs.17:28
* cjwatson peers at the publishing history.17:29
cjwatsonYeah, as I thought, 5.3 was originally in the security PPA.17:29
jdstrandcjwatson: 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 bug17:39
jdstrand(both meaning today's update and the previous update)17:39
jdstrandanyhoo, it is filed, I'm moving on :)17:39
cjwatsonjdstrand: I'm actually pretty puzzled.17:43
cjwatsonCan't really spend any longer on it right now though; it's not a leak17:46
jdstrandand I didn't really intend for you to17:46
jdstrandI just thought it could potentially be related to your recent work is all17:47
cjwatsonWorrying though.17:47
jdstrandand you said it was not17:47
cjwatsonWell, I don't *think* so.17:47
cjwatsonBut it would be a regression in moving you to copyPackage.17:47
* jdstrand nods17:47
cjwatsonSo I do care about that even if it wasn't my fault.17:47
cjwatsonI wonder if it's actually the diff requested by PCJ.attemptCopy.  That would explain the difference between syncSource and copyPackage.17:50
cjwatsonI 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
cjwatsonIn 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:56
jdstrandI was wondering if what you just said related to that17:57
jdstrandthat has often been an annoyance17:57
jdstrandin fact...17:57
jdstrandbug #29488617:57
ubot2Launchpad bug 294886 in launchpad "security private PPA debdiff generator uses the wrong pocket" [High,Triaged] https://launchpad.net/bugs/29488617:57
cjwatsonIt is slightly related.17:59
jdstrandI guess this is more #23709217:59
jdstrandbug #23709217:59
ubot2Launchpad bug 237092 in launchpad "Package diffs should only be generated against previous releases within a distroseries" [High,Fix released] https://launchpad.net/bugs/23709217:59
cjwatsonThough more a demonstration of how not to do it.17:59
jdstrandoh, that is different18:00
cjwatsonjdstrand: 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
jdstrandcjwatson: awesome, thanks :)18:10
stgraberskaet: in case you're wondering thunderbird was a bit buggy, the two e-mails are identical :)22:07
skaetstgraber,  :)22:20

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!