[00:00] <wgrant> lifeless: Do we know how many clients are using edge still?
[00:03] <jml> fourth time lucky
[00:08] <lifeless> wgrant: no, though if we slightly-unfold the edge ppr we could tell total hits
[00:11] <jml> for Christmas, I would like tighter feedback loops
[00:12] <wgrant> I'm getting tighter feedback loops for Christmas.
[00:12] <jml> lucky :(
[00:14] <jml> sixth time, perhaps
[00:15] <thumper> jml: I think I've found the problem
[00:15] <jml> thumper: what is it?
[00:15] <jml> (I've spent 45 minutes waiting for computers to do things)
[00:16] <thumper> factory.getUniqueDate() :(
[00:16] <thumper> it adds a getUniqueInteger to an epoch
[00:16] <thumper> the initial counter is intialized randomly
[00:16] <thumper> the problem occurs when the bmp is created after NOW
[00:17] <thumper> HORRIBLE
[00:17] <jml> thumper: ugh, well spotted
[00:17] <thumper> well debugged you mean
[00:18] <jml> thumper: indeed I do.
[00:18] <thumper> cause it wasn't initially spottable
[00:18] <jml> thumper: I feel this is an opportune moment to point out that lp/testing/tests/test_factory.py exists.
[00:19] <thumper> yes, but the factory is doing the right thing
[00:19] <thumper> the test isn't
[00:19] <thumper> it doesn't need a random date
[00:19] <thumper> it needs to make sure the date is in the past
[00:19] <jml> ahh ok
[00:23] <jml> yay successful detach
[00:24]  * jml flees
[00:24] <jml> (maybe database-apocalypse will pass tests and land while we aren't in testfix mode and then pass on the buildbot and get pulled into stable before I wake up)
[00:27] <wgrant> ROFL
[00:27] <poolie> lifeless: mkanat tells me codebrowse is now behind a loadbalancer, with multiple instances?
[00:27] <poolie> that's great
[00:28] <thumper> testfix submitted
[00:34]  * thumper is grumpy that it took two hours
[00:37] <thumper> wallyworld: wanna chat?
[00:37] <wallyworld> thumper: give me 5 mins
[00:38] <thumper> ack
[00:44] <poolie> thumper: wallyworld: anyone, are we now running multiple codebrowse processes?
[00:44] <thumper> poolie: I believe so
[00:45] <poolie> so that should help with stability and performance?
[00:45] <poolie> do you want to nominate any other bugs for max to do next?
[00:49]  * thumper thinks
[00:50] <thumper> we will likely have something to do with bzr-history later
[00:50] <thumper> but we were wanting some work done on the LP side first
[00:51] <thumper> poolie: how about the default file render to show the text at that revision rather than an annotated view?
[00:54] <wallyworld> thumper: mumble?
[01:22] <lifeless> poolie: yes it is, part of the nodowntime effort
[01:22] <lifeless> poolie: each loggerhead instance is still internally threaded
[01:23] <poolie> excellent
[01:23] <lifeless> poolie: I'm not really here today - am on a swap day
[01:23] <poolie> i was asking max to push it but if it's already done that's great
[01:23] <lifeless> poolie: single-threading the backends still needs to be done
[01:24] <lifeless> but its not something I'm directly pushing for loggerhead [yet] because there are still some easier bigger fish to fry
[01:24] <LPCIBot> Project devel build (209): STILL FAILING in 3 hr 40 min: https://hudson.wedontsleep.org/job/devel/209/
[01:24] <thumper> lifeless: aren't you on leave?
[01:24] <lifeless> yes
[01:25] <lifeless> but IRC highlights still highlight
[01:26] <poolie> so my suggestions to him were: make a stable branch; turn off annotate by default; allow http caching; profile cpu and memory for serving single pages
[02:25] <wallyworld> poolie: spiv: the bzr upgrade just got merged in as rev 11902
[02:25] <poolie> yay!
[02:35] <spiv> wallyworld: hurrah!
[02:36] <spiv> wallyworld: meanwhile, mkanat on #bzr just bumped into bug 668176, so you'll be wanting to do a bzr upgrade again fairly soon ;)
[02:36] <wallyworld> sorry about the delay. the code was ready days ago. it took a while to find a window where we weren't in textfix mode :-(
[02:37] <wallyworld> spiv: np. i assume you mean 2.2.2. ping me on the 18th when it is released :-)
[02:38] <spiv> wallyworld: well, I personally don't care if it's 2.2.2 final or just tip of lp:bzr/2.2 or just 2.2.1 with that one tiny fix backported.   But yes :)
[02:39] <wallyworld> spiv: 2.2.2 final is only a week away. can it wait till then?
[02:39] <lifeless> wallyworld: remember that we have a scheduled downtime our thursday
[02:39] <lifeless> wallyworld: so waiting a week means waiting a month
[02:40] <lifeless> wallyworld: or scheduling extra downtime
[02:40]  * lifeless runs away
[02:41] <wallyworld> spiv: assuming 2.2.2 final codebase is complete by mid next week, i could take tip of lp:bzr2.2 and do it before the downtime?
[02:41] <lifeless> wallyworld: you can't
[02:41] <lifeless> wallyworld: we select the revision early in the week
[02:41] <lifeless> wallyworld: trying to slide things in at the last minute is a guaranteed nightmare.
[02:42] <lifeless> wallyworld: remember you need time to qa on qastaging/staging, deal with testfix, possible test failures trying to land it.
[02:42] <wallyworld> lifeless: ok. i'll do it tomorrow. now fcuk off and enjoy your day off
[02:42] <lifeless> lol ok
[02:43] <lifeless> I guess what I'm trying to say is 'either do it now, or decide to (wait a month | schedule extra downtime)
[02:43] <lifeless> ciao
[02:45] <thumper> WHY?
[02:45]  * thumper looks to the sky
[02:46] <ajmitch> thumper: it's clearing up now, just a short bit of rain :)
[02:46]  * thumper is referring to soyuz factory generated crap that won't render
[02:46] <ajmitch> heh :)
[02:55]  * thumper sighs some more
[03:56] <lifeless> StevenK: please tell me you didn't land something without using ec2land ?
[03:58]  * thumper just saw the failure
[03:59] <thumper> I thought it was a general failure so forced it, but on reading the error it looks like StevenK
[03:59]  * thumper pulls trunk
[04:00] <lifeless> StevenK: (of course, it could be the known race condition with ec2 - and I am very curious which it is)
[04:14] <thumper> lifeless: I get the same error trying to make devel
[04:15]  * thumper testfixes
[04:25] <thumper> done
[04:25]  * thumper EODs
[04:40] <LPCIBot> Yippie, build fixed!
[04:40] <LPCIBot> Project devel build (210): FIXED in 3 hr 16 min: https://hudson.wedontsleep.org/job/devel/210/
[04:40] <LPCIBot> Launchpad Patch Queue Manager: [testfix][r=mwhudson] Upcall correctly,
[04:40] <LPCIBot> actually do the assertion in the test, fix the assertion.
[05:04] <LPCIBot> Project devel build (211): FAILURE in 23 min: https://hudson.wedontsleep.org/job/devel/211/
[05:06] <LPCIBot> Project devel build (212): STILL FAILING in 1 min 49 sec: https://hudson.wedontsleep.org/job/devel/212/
[05:40] <Maha2> Hi frnds anybody hav black money?
[07:33] <wgrant> Wow.
[07:33] <wgrant> c.l.i and c.l.d are empty.
[07:49] <lifeless> things are moving
[07:50] <wgrant> Aren't you not here?
[07:56] <lifeless> I'm hacking on testtools
[07:57] <lifeless> lp:~lifeless/testtools/matchers if you're interested
[07:57] <lifeless> personal time
[08:24] <adeuring> good morning
[08:55] <LPCIBot> Project devel build (213): STILL FAILING in 3 hr 39 min: https://hudson.wedontsleep.org/job/devel/213/
[08:55] <LPCIBot> Launchpad Patch Queue Manager: [testfix][rs=thumper] Fix the PPACreationError import in
[08:55] <LPCIBot> lib/lp/registry/interfaces/webservice.py.
[09:16] <mrevell> Hey up
[09:17] <bigjools> helleau
[09:20] <henninge> bigjools: It's "Hellau!" actually but not for another 50 minutes or so...
[09:20] <bigjools> henninge: it's actually whatever I want it to be :)
[09:20] <henninge> ;)
[09:21] <henninge> Carneval season starts at 11:11 today in some parts of Germany
[09:21] <bigjools> what's that?
[09:23] <wgrant> bigjools: Hi.
[09:24] <bigjools> hi
[09:24] <wgrant> bigjools: https://launchpad.net/ubuntu/jaunty/+source/xserver-xorg-video-geode/2.11.10-1~jaunty1
[09:25] <bigjools> :/
[09:25] <henninge> Just to correct myself, it's "Helau"
[09:25] <henninge> lifeless: Hi, still around?
[09:26] <wgrant> bigjools: Someone accidentally uploaded it (was meant for a PPA)... and the Release pocket check is only for CURRENT/SUPPORTED, not OBSOLETE.
[09:26] <bigjools> wgrant: how did that get there?
[09:26] <bigjools> ah
[09:26] <bigjools> crepe
[09:28] <wgrant> bigjools: I think we should probably reject all uploads to an obsolete series (it would fix a PPA-related bug too).
[09:28] <wgrant> But that needs to be checked with people.
[09:28] <bigjools> wgrant: we can't do that - PPAs need to remain active
[09:28] <bigjools> but obsolete distros, totally
[09:29] <wgrant> bigjools: Hmm, why?
[09:29] <wgrant> In the past the virtualisation flag has been turned off upon obsolescence.
[09:29] <wgrant> Although not yet for Jaunty, it seems.
[09:29] <bigjools> because some crazy people want to carry on using them
[09:30] <bigjools> so I'd rather it was a switch than a lock :)
[09:30] <wgrant> :(
[09:30] <wgrant> I guess we'd best just extend the current/supported check to obsolete.
[09:30] <bigjools> yeah
[09:30] <wgrant> I had a look at the upload checking code.
[09:30] <wgrant> Those pockets are hardcoded in a few places.
[09:30] <wgrant> :(
[09:30] <wgrant> Also, the archive permission API is.......
[09:30] <bigjools> this surprises you ...
[09:31] <bigjools> well if you dislike the API then feel free to be constructive
[09:32] <wgrant> Yeah, I had a look at redesigning it yesterday.
[09:32] <wgrant> (I need to change it to allow pockets for queue admins)
[09:41] <wgrant> bigjools: There's just one thing blocking my lucilleconfig extermination: germanium's publisher's temp directory. The existing code uses the distro's lucilleconfig root (/srv/launchpad.net/ubuntu-archive/ubuntu-temp), which seems more than mildly insane for PPAs. The new code will use archivepublisher.root, which isn't set by germanium's config, so it will be /var/tmp/archive/ubuntu-temp.
[09:42] <wgrant> Easy fix is to set archivepublisher.root in the ppa config.
[09:42] <wgrant> But I wonder if we want the temp directory to be in a less insane place on germanium anyway.
[09:43] <bigjools> I can't remember what it uses the temp dir for
[09:43] <wgrant> It writes out Packages and Sources there, so it can atomically rename them into the real archive.
[09:43] <wgrant> So it needs to be on the same FS.
[09:44] <bigjools> right
[09:44] <bigjools> /var/tmp is not useful then
[09:44] <wgrant> No.
[09:45] <wgrant> So it needs to be fixed.
[09:45] <wgrant> But I think it should be fixed to something other than a lie.
[09:45] <wgrant> ('ubuntu-archive' is the lie)
[09:47] <lifeless> jml: ping
[09:52] <lifeless> henninge: no, not around at all.
[09:52] <lifeless> whats up?
[09:57] <henninge> lifeless: two questions
[09:58] <henninge> lifeless: what's the state of bug 672371?
[09:58] <_mup_> Bug #672371: Archive:+packages timeouts <ppa> <regression> <timeout> <Soyuz:Triaged by lifeless> <https://launchpad.net/bugs/672371>
[09:58] <henninge> lifeless: Are you working on that?
[09:59] <lifeless> no, I'm on leave
[09:59] <lifeless> the mailing list thread covers the current status
[09:59] <henninge> right, ok
[09:59] <lifeless> which is that a fix is landed, pending qa on qastaging, and deployments are blocked until the fix is qaed (and everything leading up to it)
[10:00] <jml> lifeless: hi
[10:00] <lifeless> jml: you might like https://code.launchpad.net/~lifeless/testtools/matchers/+merge/40606
[10:00] <jml> lifeless: not as much as I like: "Test results: database-apocalypse => devel: SUCCESS"
[10:00] <jml> lifeless: but I'll take a look
[10:00] <henninge> lifeless: thanks
[10:01] <henninge> second question: I see that a lot of revisions have landed on stable which have not been processed by the QA bot.
[10:01] <henninge> no qa tags, no fix committed.
[10:01] <henninge> Is the bot on hold because of the blockage?
[10:02] <henninge> Or could it be broken or just slow?
[10:02] <henninge> lifeless: ^
[10:03] <jml> lifeless: actually, looking, I need coffee first. won't be a jiffy
[10:03] <lifeless> henninge: no idea
[10:03] <henninge> who could I ask about the bot?
[10:04] <lifeless> henninge: jml/stub/flacoste/gary/urshina/mars/diogo/me
[10:04] <lifeless> except I'm not here.
[10:04] <henninge> ;-)
[10:04] <lifeless> its in a service account that those folk (maybe more) have access too
[10:04] <henninge> lifeless: thanks a lot, enjoy your leave ;)
[10:05] <lifeless> de nada
[10:05] <stub> losa, urshina or diogo I think. I don't know where or how the bot works.
[10:05] <lifeless> right
[10:05] <lifeless> access doesn't imply knowledge
[10:05] <lifeless> stub: lookin the lpqateam crontab if you want to chase pointers.
[10:05] <lifeless> henninge: qastaging is down
[10:05] <lifeless> henninge: that will break the bot
[10:06] <henninge> Oh!
[10:06] <lifeless> I don't know why its down - on leave + no losa : not going to dig in myself ;)
[10:07] <henninge> No, I'll have to wait for Chex .... :(
[10:07] <henninge> thanks again
[10:07] <bigjools> henninge: ask a GSA
[10:07] <bigjools> it's too important to be left down
[10:07] <henninge> on #is
[10:07] <henninge> ?
[10:07] <bigjools> yes
[10:07] <henninge> will do
[10:14] <thumper> \o/
[10:14] <thumper> my testfixes worked
[10:14]  * thumper heads to bed
[10:17] <matsubara> hi henninge
[10:17] <matsubara> do you still need help with the qa bot?
[10:17] <henninge> matsubara: Hi!
[10:18] <henninge> I already found out that qastaging is running its update script atm.
[10:18] <henninge> Would that stop the qa bot?
[10:19] <lifeless> henninge: its been down for hours
[10:19] <lifeless> henninge: whatever its doing is going to fail
[10:20] <lifeless> and yes it will interfere
[10:20] <lifeless> the bot reads the active revno from the qastaging and staging web uis
[10:21] <henninge> IS just told me that the qastaging-update script started only 21 minutes ago ...
[10:21] <lifeless> yes
[10:21] <lifeless> Nonetheless, its been down for hours
[10:22] <matsubara> henninge, lifeless: yes, that's it: https://devpad.canonical.com/~lpqateam/qa_reports/logs/output-launchpad-stable.log
[10:22] <henninge> lifeless: is "it" the bot or qastaging?
[10:22] <lifeless> qastaging
[10:23] <matsubara> sorry, still waking up. lifeless is right. qastaging is down then the bot can't do its job
[10:33] <lifeless> henninge: jml: I've mailed the list the fragment from the backtrace ng dug up.
[10:33] <jml> lifeless: I saw.
[10:33] <lifeless> henninge: could you perhaps file an RT that that log location isn't documented/visible to us?
[10:33] <henninge> lifeless: yes saw that. thanks
[10:33] <jml> lifeless: has the problem been fixed? do you need help fixing it?
[10:33] <henninge> lifeless: good idea
[10:33] <lifeless> henninge: we should have knowledge and visibility to diagnose things like this
[10:33] <lifeless> jml: I'm on leave.
[10:34] <henninge> jml: I will fix it
[10:34] <henninge> and come back to you if I need help ;)
[10:34] <jml> henninge: thanks
[10:34] <jml> henninge: it should be a simple matter of importing things from the right place
[10:34] <henninge> yes, I expect
[10:35] <lifeless> jml: so what did you think of the testtools patch ?
[10:35] <jml> henninge: my worry is that lpnet has a similar zcml file
[10:36] <lifeless> jml: I'm sure henninge will sed the entire production-configs ;)
[10:36] <lifeless> there will be 40 or so files to change
[10:36] <henninge> easy!
[10:36] <henninge> ;)
[10:40] <henninge> jml: no, I think we are safe. No reference to canonical.launchpad.interfaces in the production configs.
[10:40] <jml> henninge: other than the qastaging reference, surely?
[10:41] <lifeless> huh, perhaps its entirely in tree as it is
[10:41] <henninge> jml: not even there
[10:41] <henninge> lifeless: that's what I think
[10:41] <jml> henninge: so where's the broken code?
[10:41] <henninge> guys, give me time to figure it out ... ;)
[10:43] <LPCIBot> Project db-devel build (132): FAILURE in 4 hr 2 min: https://hudson.wedontsleep.org/job/db-devel/132/
[10:46] <henninge> jml: in ./scripts.zcml http://paste.ubuntu.com/529912/
[10:46] <henninge> So, where are those files maintained?
[10:55] <jml> lifeless: replied
[10:55] <jml> lifeless: sorry it took so long. multitasking is ... SQUIRREL! ... what was I saying, oh yeah, multitasking is hard.
[10:55] <lifeless> :)
[10:55] <jml> lifeless: basically, two things
[10:56] <jml> lifeless: why not 'Raises(FooError)'
[10:56] <jml> lifeless: and the other is "%s/raises_value/raises_value_error/g"
[10:56] <lifeless> jml: separation of concerns
[10:57] <lifeless> jml: we could have a helper that curries the two together
[10:57] <lifeless> MatchesException is trivially adaptable for use on Failures
[10:57] <lifeless> Raises isn't
[10:57] <jml> lifeless: I'm happy to have MatchesException be separate
[10:57] <jml> lifeless: I just reckon Raises could construct one itself
[10:58] <jml> lifeless: or, as you say, we could have a third class / helper that curries them. If so, I'd argue that the helper ought to be called Raises, since that's the prime real estate and almost all of the time everyone will want to be asserting that something raises an exception.
[10:59] <jml> rather than, say, an exc_info tuple that is less than something else
[11:00] <jml> gasp!
[11:02] <lifeless> jml: I have mixed feelings
[11:03] <lifeless> jml: I don't particularly like argument inspection
[11:03] <lifeless> jml: type inspection I mean
[11:03] <lifeless> jml: but we could add it
[11:03] <jml> lifeless: you mean, have the instructor take a matcher or an exception class?
[11:03] <jml> constructor
[11:04] <lifeless> yeah
[11:04] <lifeless> taking a matcher is an important use case
[11:04] <jml> lifeless: got an example?
[11:05] <lifeless> in test_runtest
[11:05] <lifeless>  Raises(MatchesException(Exception("foo"))))
[11:05] <lifeless> its checking that the actual exception is passed on rather than some arbitrary exception
[11:05] <lifeless> a small improvement that was easy to do here
[11:05] <jml> well, that's not really passing in a matcher
[11:05] <jml> you could, in theory, take whatever is passed to Raises() and pass that to MatchesException.
[11:06] <lifeless> you could
[11:06] <lifeless> if you want to bind the two together
[11:06] <jml> well, it's not symmetric. MatchesException doesn't lose its independence.
[11:06] <henninge> lifeless, jml: It seems to be an untracked file outside our tree and outside the configs. I'll have to talk to the losas to find out if it's really not maintined anywhere.
[11:06] <lifeless> that makes it harder to do exact checks (vs subclass) without changing the core
[11:07] <henninge> I'll see that I get it patched now, though.
[11:07] <lifeless> henninge: thank you
[11:07] <jml> lifeless: so, rather than type checking, I would rather, def __init__(self, exc_type=None, matcher=None): style shenanigans
[11:07] <jml> lifeless: I would rather a helper than that.
[11:08] <lifeless> jml: I think we're only seeing the thin edge of the wedge; once we open up things we'll start to see more sophisticated checks and usage.
[11:08] <jml> lifeless: I don't :)
[11:08] <lifeless> jml: We can add a helper (say 'raises') later, I don't feel one is really needed right now.
[11:08] <spiv> lifeless: WHUI (yet)
[11:09] <lifeless> spiv: that also applied to getDetails, but its taken off (e.g. see soupmatchers)
[11:09] <spiv> I do strongly believe in making known common use cases convenient.
[11:10] <spiv> But I also believe in sleeping :)
[11:10] <jml> lifeless: it's not enough to block the landing, I'll grant, since we can add one later. But it is needed right now, because there's already stacks of Raises(MatchesException(FooError)) in testtools
[11:10] <jml> spiv: :)
[11:10] <spiv> So I'll look forward to reading the results of this discussion some time later.
[11:10] <lifeless> jml: tell you what
[11:10] <lifeless> jml: I've done the other variable rename and pushed while we chatted
[11:10] <jml> lifeless: yay
[11:10] <lifeless> jml: i leave it to you to land, in whatever shape you think best ;)
[11:10] <jml> lifeless: did you do the MANUAL change?
[11:10] <jml> I forgot to mention in IRC
[11:11] <lifeless> jml: no, lp hadn't forwarded your mail
[11:11] <jml> np
[11:12] <jml> lifeless: anyway, it's a deal.
[11:12] <lifeless> cool. Have a good day.
[11:12] <lifeless> gnight jml, spiv, et al
[11:26] <henninge> qastaging is back!
[11:30] <jml> henninge: cool.
[11:30] <jml> henninge: what was the problem?
[11:31] <henninge> There is a zcml file out side the tree that referenced canonical.launchpad.interfaces.
[11:32] <henninge> I still don't know where it is maintained (it should be!) but Ng patched it for me.
[11:36] <henninge> jml: looks like this: https://pastebin.canonical.com/39629/
[11:37] <jml> henninge: ok, makes sense
[11:38] <henninge> jml: I think it should be put into the production configs branch.
[11:38] <jml> henninge: that sounds sensible to me.
[11:38] <jml> henninge: perhaps follow this up with a losa?
[11:39] <henninge> that's my plan as soon as Chex wakes up. ;)
[11:41] <jml> henninge: good good :)
[11:51] <jml> ahh yes, conflict
[11:51] <jml> I had forgotten in the dizzy excitement of email processing.
[12:00] <jml> can someone help me QA https://bugs.launchpad.net/soyuz/+bug/673015 ?
[12:00] <_mup_> Bug #673015: Code of Conduct requirement for PPA upload rights is unnecessary <ppa> <qa-needstesting> <Soyuz:Fix Committed by jml> <https://launchpad.net/bugs/673015>
[12:00] <bigjools> jml: what sort of help do you need?
[12:01] <jml> bigjools: well, I guess I need to try uploading without the CoC signed
[12:01] <deryck> Morning, all.
[12:01] <bigjools> jml: ok I can make that very easy for you
[12:01] <jml> bigjools: of course, I've already signed it, so I need to figure what to do there
[12:01] <bigjools> jml: make a new user
[12:01] <jml> bigjools: and I don't really know how to upload to a PPA :)
[12:01] <bigjools> and put your gpg key on it
[12:02] <jml> bigjools: ok.
[12:02] <bigjools> jml: the other option is that I hack your account on DF to remove the CoC :)
[12:02] <jml> hmm
[12:02] <jml> so I can't really test this on qastaging?
[12:02] <bigjools> no
[12:02] <jml> has to be DF?
[12:02] <bigjools> yes
[12:02] <jml> harumph
[12:03] <jml> bigjools: do I have to do something special to get the right version of code onto DF?
[12:03] <bigjools> jml: make a new user on DF - its emails go to the staging inbox
[12:03] <bigjools> jml: yes - ask me :)
[12:03] <jelmer> bigjools: fwiw I updated dogfood this morning
[12:03] <jml> oh heavens
[12:03] <bigjools> it runs db-devel, what revno was it in?
[12:03] <bigjools> jml: I noticed
[12:03] <bigjools> jelmer: I noticed
[12:03] <wgrant> (you can also deactivate a CoC sig)
[12:03] <jml> I'd forgotten about staging inboxes
[12:04] <jml> bigjools: I'm not sure if it's made its way to db-devel. checking now.
[12:04] <bigjools> jml: I can merge a devel revno if you want
[12:05] <jml> bigjools: r11894 of stable. Not on db-devel yet.
[12:06] <jml> will be once my conflict resolution branch gets through PQM.
[12:06] <bigjools> jml: ok just ping me when it's ready then and I'll update DF's code
[12:06] <jml> bigjools: will do. thanks.
[12:07] <bigjools> can you believe that the existing code that downloads builder files has no code to deal with errors ...
[12:07] <jml> readily
[12:08] <jml> I really need to make an inventory tracker thingy for Launchpad.
[12:09] <jml> jelmer: hi
[12:10] <jml> jelmer: did you ever get around to testing opening 'o' and 'p' series?
[12:10] <jelmer> jml: hellø
[12:10] <jelmer> jml: No, but I do that on dogfood now or after you've QA'ed your change.
[12:10] <jml> jelmer: super. thanks.
[12:10] <jelmer> jml: Are you QA'ing now?
[12:11] <jml> jelmer: no, waiting for db-devel to have the new goodness to test
[12:11] <jml> jelmer: so you could go ahead right now :)
[12:11] <jelmer> ok, great
[12:17] <Ursinha-afk> henninge, hi
[12:17] <Ursinha-afk> which bugs?
[12:17] <henninge> Ursinha: Hi!
[12:17] <henninge> which bugs?
[12:17] <henninge> :-P
[12:19] <bigjools> Ursinha: hi, I want to request a feature on the qa bot so that I can set something as previously QAed before it lands.
[12:20] <jml> weird. just got a gpg validation rejection from pqm
[12:21] <bigjools> oh - nobody told you?
[12:22] <Ursinha> henninge, that weren't processed by the qa-tagger :)
[12:22] <henninge> Ursinha: Oh, those ;)
[12:22] <Ursinha> bigjools, I'd ask you to file a bug and I'll triage it :)
[12:22] <bigjools> Ursinha: no worries - my next question was where to file it? :)
[12:23] <Ursinha> bigjools, https://launchpad.net/qa-tagger
[12:23] <bigjools> cheers
[12:23] <Ursinha> :)
[12:24] <jml> bigjools: nobody told me. Have I been sacked?
[12:24] <bigjools> :)
[12:26] <bigjools> Ursinha: done!
[12:27] <henninge> stub: Hey!
[12:28] <henninge> stub: I am trying to reproduce and OOPS I am getting from the poimport script.
[12:29] <Ursinha> bigjools, thanks :)
[12:29] <henninge> stub: but I don't see any. Could it be that they get ignored locally?
[12:33] <LPCIBot> Yippie, build fixed!
[12:33] <LPCIBot> Project devel build (214): FIXED in 3 hr 37 min: https://hudson.wedontsleep.org/job/devel/214/
[12:33] <LPCIBot> Launchpad Patch Queue Manager: [r=lifeless][ui=none][bug=673874] Improve memcache caching of some
[12:33] <LPCIBot> bugs pages
[12:38] <stub> henninge: No - should be no difference with OOPS reports between local and production
[12:38] <stub> henninge: If you get a WARNING or above, you should get an OOPS
[12:38] <deryck> gmb, hi.  still not having much luck getting a clean test run with js upgrade branch.
[12:39] <henninge> stub: yes, that's what I am trying to fix because we have too many WARNINGS. I just cannot find where the script issues the warning (which then becomes an  OOPS).
[12:39] <henninge> And I don't see a warning in the log output when I run it loally.
[12:41] <henninge> jml: I marked th bugs for your c.l.interfaces branch as qa-bad to prevent that revision from being deployed.
[12:41] <stub> henninge: Ahh. If you want, there is more information available to the logger. You can set a breakpoint in canonical.launchpad.scripts.logger
[12:42] <gmb> deryck: Okay. K
[12:42] <gmb> ... er
[12:42] <gmb> deryck: I mean: I'm still tied up with other bugs at the moment anyway, so not a big worry there. Can I help at all?
[12:42] <stub> henninge: Oh.. no warning == ignore me.
[12:43]  * henninge ignores stub
[12:43] <jml> henninge: why does it need to be prevented from being deployed. I thought the issue was fixed?
[12:43] <deryck> gmb, I don't think so, but thanks!  I've got a couple more ideas to try and if those prove unfruitful, then I'll cast about for more help.
[12:43] <henninge> jml: on qastaging and staging but not on production.
[12:43] <gmb> deryck: Okay.
[12:43]  * gmb lunches
[12:43] <henninge> I want to talk to a losa before I touch that.
[12:44] <jml> henninge: ok. so I can I rely on you to change it back to qa-ok when prod is fixed?
[12:44] <henninge> yes, you can ;)
[12:44] <jml> henninge: thanks.
[12:44] <stub> henninge: Doesn't the traceback in the OOPS tell you where the script issues the warning?
[12:45] <henninge> I think not, let me try to see
[12:45] <stub> Oh.... no traceback because it isn't in an exception handler.
[12:45] <henninge> yes, I think that's it.
[12:46] <stub> If you are bored of hitting your head against this wall, consider refactoring OopsHandler in c.l.scripts.logger -- you should be able to extract a lot more information from the log record in the emit() method and add it to the OOPS report, such as the line number and file name.
[12:48] <henninge> stub: I'll do that when I get bored.
[12:48]  * henninge is not bored today ...
[12:49] <henninge> but now for some lunch, first
[12:49] <henninge> thanks stub!
[13:01] <jml> I hope the PQM submission that's running now fails
[13:01] <jml> otherwise we'll be in a pickle
[13:04] <deryck> allenap, I think checkwatches is running again.  https://lpstats.canonical.com/graphs/BugWatchUncheckedOutdated/
[13:05] <deryck> allenap, did you find out anything about this?  Or just happened to run again?
[13:07] <jml> le sigh
[13:37] <allenap> deryck: Chex sorted it out last night. Hung process, don't know why though.
[13:37] <deryck> allenap, ok, cool.  At least we got it going again.  Thanks!
[13:37] <deryck> And thanks Chex!
[13:51] <gmb> allenap, deryck: Sometimes it gets stuck. I'd file a bug about it but the problem is so vague as to be unhelpful without some serious debugging in a production environment.
[13:51] <deryck> yeah
[13:54] <allenap> gmb: Do we run it multi-threaded at all, or was that turned off?
[13:55] <gmb> allenap: I think we turned that off because it was doing something unsavoury to either our servers or someone else's. I could be wrong.
[14:04] <jelmer> jml: So, having an O and a P series seems to work
[14:04] <jml> jelmer: sweet.
[14:05] <jml> jelmer: uploads to them are forbidden?
[14:05] <jelmer> jml: Yeah, I haven't enabled any of that.
[14:05] <jml> jelmer: I mean, have you tested that uploads to them are forbidden?
[14:07] <jelmer> jml: Also, I had to name them o-series and p-series as "o" and "p" are too short. I haven't tried whether renaming the series works.
[14:07] <jelmer> jml: Yes, although I now realize that it gave me a "Unknown distroseries" error, which seems weird.
[14:08] <jml> jelmer: that's a bug, but probably not enough to block opening them.
[14:08] <jml> jelmer: could you try a rename?
[14:10] <jelmer> jml: yup
[14:15] <jml> jelmer: ta
[14:51] <jml> jelmer: how did renames work out?
[14:53] <jelmer> jml: Still on it.
[15:16] <jelmer> jml: It seems to be working (though I'm not entirely sure what I should be testing that might break): https://dogfood.launchpad.net/ubuntu/obvious
[15:20] <jml> jelmer: it doesn't redirect. I wonder if that'll be a problem.
[15:24] <bigjools> jml: can you join our mumble channel
[15:26] <jelmer> jml: Redirect in what way?
[15:43] <bigjools> there has to be a decent way of getting the trial TestCase and TestCaseWithFactory to co-exist
[15:48] <jml> bigjools: yeah, there is
[15:48] <jml> bigjools: but the branch where I do it has about eight failing tests.
[15:56] <jelmer> hmm, mumble fail?
[15:56] <bigjools> so I have a test that uses TestCase.makeTemporaryDirectory() but I need to change it to use the trial TestCase
[15:57] <bigjools> should I wait for your branch or haxor something?
[15:58] <henninge> So, the +packages timeouts seem not to be fixed. Any ideas what to do next?
[16:00] <jml> bigjools: trial has something for that
[16:01] <jml> bigjools: it's in the api docs
[16:01] <bigjools> ok ta
[16:01] <bigjools> jml: mktemp?
[16:01] <jml> bigjools: yeah, that's it
[16:02] <bigjools> it's not quite the same thing but I can fiddle
[16:02] <jml> bigjools: fair enough.
[16:02] <bigjools> jml: thanks for the pointer
[16:02] <jml> I'll get my act in gear and land this testtools branch sometime soon
[16:03] <deryck> mrevell, ping
[16:03] <bigjools> is "act" a euphemism?
[16:03] <mrevell> Hello deryck!
[16:03] <jml> bigjools: yes. it's short for "arse".
[16:09] <jelmer> jml: Just confirmed that targetting bugs works.
[16:10] <jml> jelmer: thanks.
[16:11] <jml> jelmer, bigjools: btw, could one of you please update dogfood to db-devel r9960 or later?
[16:11] <jelmer> jml: sure
[16:11] <jml> jelmer: thanks.
[16:55] <jelmer> jml: dogfood should be on 9961 now
[16:59] <bigjools> jml: can I pick your brains about Twisted again?
[17:01] <jml> bigjools: sure
[17:01] <bigjools> jml: so I am hoping there's a Twisted pattern for something
[17:02] <bigjools> when we're fetching files from the builder it's currently a simple "for" loop
[17:02] <bigjools> but if that's async then it needs changing - is there anything in Twisted that can help?
[17:02] <jml> bigjools: uhh...
[17:02] <jml> bigjools: what are you trying to do?
[17:03] <jml> bigjools: fetch one file, then fetch a second file, then fetch... etc?
[17:03] <bigjools> so it loops over all the files synchronously fetching them
[17:03] <jml> bigjools: or are you fetching many files and you don't care about the order
[17:03] <bigjools> ah good point
[17:03] <bigjools> I can just request them all at once
[17:03] <bigjools> dunno if that will make the builder barf
[17:03] <jml> dl = gatherResults([fetchFileAsync(filename) for filename in filenames])
[17:04] <bigjools> rejoice :)
[17:04] <jml> dl.addCallback(when_all_files_are_gotten)
[17:04] <jml> assuming fetchFileAsync returns a Deferred
[17:04] <bigjools> it does
[17:04] <jml> there are some quirks with error handling
[17:04] <jml> specifically, it's not quite as obvious as when it's synchronous
[17:04] <bigjools> well given I said there is no error handling at all right now ...
[17:05] <jml> heh
[17:05] <bigjools> out of interest if I did want to do them one at a time, is there another pattern?
[17:06] <jml> hmm.
[17:06] <jml> perhaps a DeferredSemaphore(1)
[17:07] <jml> it's not very convenient though
[17:08] <jml> bigjools: I reckon BuilderSlave could probably grow a method that takes a list of files and does this download. Makes it one step closer to putting a multi-file method on the slave itself
[17:09] <bigjools> quite probably
[17:09] <bigjools> It needs some careful thinking because there's a bunch of checking done one file names
[17:09] <bigjools> s/one/on/
[17:11] <jml> bigjools: not on the client side
[17:11] <bigjools> jml: au contraire
[17:12] <bigjools> it checks each file to make sure it's not going to write where it's not allowed to
[17:12] <jml> bigjools: which of these three methods is doing checking on filenames? http://paste.ubuntu.com/530111/
[17:12] <bigjools> jml: you're looking at the wrong thing there
[17:13] <bigjools> you need to look at where we get files off the builder
[17:13] <LPCIBot> Yippie, build fixed!
[17:13] <LPCIBot> Project db-devel build (133): FIXED in 4 hr 2 min: https://hudson.wedontsleep.org/job/db-devel/133/
[17:13] <jml> bigjools: oh right, you mean this instead: http://paste.ubuntu.com/530112/
[17:13] <bigjools> jml: that's the bottom of the stack, but yes
[17:14] <bigjools> the checking is done in _handleStatus_OK
[17:14] <bigjools> for filename in filemap:
[17:14] <bigjools> etc
[17:15] <jml> bigjools: how is it any more complicated than finishing that loop and then having a list of known-good filenames to fetch?
[17:16] <bigjools> jml: it's slighly more but not much
[17:44] <jml> yay
[17:44] <jml> there's a global state bug in my testtools-experiment branch
[17:57] <mrevell> sinzui, I *think* I've removed the troublesome ACL from the Feedback page. I've also updated the page with a link to the SSO help. Could you please try editing the page to confirm the ACL removal has worked?
[18:08]  * jml off
[18:44] <cody-somerville> How would I go about trying out recipe builds?
[18:53] <wgrant> cody-somerville: https://help.launchpad.net/Packaging/SourceBuilds/Recipes
[20:34] <rockstar> abentley, is the standup in ~45ish?
[20:35] <abentley> rockstar: yes.
[20:35] <rockstar> abentley, thank you sir.
[20:35] <abentley> rockstar: no problem.  Will you be joining us?
[20:38] <rockstar> abentley, indeed I will.  I just got home.
[20:39] <abentley> rockstar: welcome back.
[21:11] <thumper> rockstar, abentley: mumble
[21:11] <rockstar> thumper, on my way
[21:26] <thumper> rockstar: https://bugs.edge.launchpad.net/launchpad-code/+bug/664234 needs qa
[21:26] <_mup_> Bug #664234: Export the branch merge queue data through the API <qa-needstesting> <Launchpad Bazaar Integration:Fix Committed by rockstar> <https://launchpad.net/bugs/664234>
[21:58] <thumper> wallyworld: mumble again?
[21:58] <wallyworld> thumper: ok
[23:12] <lifeless> wgrant: hi
[23:17] <wgrant> lifeless: Hi.