[00:00] lifeless: Do we know how many clients are using edge still? [00:03] fourth time lucky [00:08] wgrant: no, though if we slightly-unfold the edge ppr we could tell total hits [00:11] for Christmas, I would like tighter feedback loops [00:12] I'm getting tighter feedback loops for Christmas. [00:12] lucky :( [00:14] sixth time, perhaps [00:15] jml: I think I've found the problem [00:15] thumper: what is it? [00:15] (I've spent 45 minutes waiting for computers to do things) [00:16] factory.getUniqueDate() :( [00:16] it adds a getUniqueInteger to an epoch [00:16] the initial counter is intialized randomly [00:16] the problem occurs when the bmp is created after NOW [00:17] HORRIBLE [00:17] thumper: ugh, well spotted [00:17] well debugged you mean [00:18] thumper: indeed I do. [00:18] cause it wasn't initially spottable [00:18] thumper: I feel this is an opportune moment to point out that lp/testing/tests/test_factory.py exists. [00:19] yes, but the factory is doing the right thing [00:19] the test isn't [00:19] it doesn't need a random date [00:19] it needs to make sure the date is in the past [00:19] ahh ok [00:23] yay successful detach [00:24] * jml flees [00:24] (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] ROFL [00:27] lifeless: mkanat tells me codebrowse is now behind a loadbalancer, with multiple instances? [00:27] that's great [00:28] testfix submitted [00:34] * thumper is grumpy that it took two hours [00:37] wallyworld: wanna chat? [00:37] thumper: give me 5 mins [00:38] ack [00:44] thumper: wallyworld: anyone, are we now running multiple codebrowse processes? [00:44] poolie: I believe so [00:45] so that should help with stability and performance? [00:45] do you want to nominate any other bugs for max to do next? [00:49] * thumper thinks [00:50] we will likely have something to do with bzr-history later [00:50] but we were wanting some work done on the LP side first [00:51] poolie: how about the default file render to show the text at that revision rather than an annotated view? [00:54] thumper: mumble? === Ursinha is now known as Ursinha-afk [01:22] poolie: yes it is, part of the nodowntime effort [01:22] poolie: each loggerhead instance is still internally threaded [01:23] excellent [01:23] poolie: I'm not really here today - am on a swap day [01:23] i was asking max to push it but if it's already done that's great [01:23] poolie: single-threading the backends still needs to be done [01:24] but its not something I'm directly pushing for loggerhead [yet] because there are still some easier bigger fish to fry [01:24] Project devel build (209): STILL FAILING in 3 hr 40 min: https://hudson.wedontsleep.org/job/devel/209/ [01:24] lifeless: aren't you on leave? [01:24] yes [01:25] but IRC highlights still highlight [01:26] 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] poolie: spiv: the bzr upgrade just got merged in as rev 11902 [02:25] yay! [02:35] wallyworld: hurrah! [02:36] 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] 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] spiv: np. i assume you mean 2.2.2. ping me on the 18th when it is released :-) [02:38] 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] spiv: 2.2.2 final is only a week away. can it wait till then? [02:39] wallyworld: remember that we have a scheduled downtime our thursday [02:39] wallyworld: so waiting a week means waiting a month [02:40] wallyworld: or scheduling extra downtime [02:40] * lifeless runs away [02:41] 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] wallyworld: you can't [02:41] wallyworld: we select the revision early in the week [02:41] wallyworld: trying to slide things in at the last minute is a guaranteed nightmare. [02:42] wallyworld: remember you need time to qa on qastaging/staging, deal with testfix, possible test failures trying to land it. [02:42] lifeless: ok. i'll do it tomorrow. now fcuk off and enjoy your day off [02:42] lol ok [02:43] I guess what I'm trying to say is 'either do it now, or decide to (wait a month | schedule extra downtime) [02:43] ciao [02:45] WHY? [02:45] * thumper looks to the sky [02:46] 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] heh :) [02:55] * thumper sighs some more [03:56] StevenK: please tell me you didn't land something without using ec2land ? [03:58] * thumper just saw the failure [03:59] 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] StevenK: (of course, it could be the known race condition with ec2 - and I am very curious which it is) [04:14] lifeless: I get the same error trying to make devel [04:15] * thumper testfixes [04:25] done [04:25] * thumper EODs [04:40] Yippie, build fixed! [04:40] Project devel build (210): FIXED in 3 hr 16 min: https://hudson.wedontsleep.org/job/devel/210/ [04:40] Launchpad Patch Queue Manager: [testfix][r=mwhudson] Upcall correctly, [04:40] actually do the assertion in the test, fix the assertion. [05:04] Project devel build (211): FAILURE in 23 min: https://hudson.wedontsleep.org/job/devel/211/ [05:06] Project devel build (212): STILL FAILING in 1 min 49 sec: https://hudson.wedontsleep.org/job/devel/212/ [05:40] Hi frnds anybody hav black money? [07:33] Wow. [07:33] c.l.i and c.l.d are empty. [07:49] things are moving [07:50] Aren't you not here? [07:56] I'm hacking on testtools [07:57] lp:~lifeless/testtools/matchers if you're interested [07:57] personal time [08:24] good morning [08:55] Project devel build (213): STILL FAILING in 3 hr 39 min: https://hudson.wedontsleep.org/job/devel/213/ [08:55] Launchpad Patch Queue Manager: [testfix][rs=thumper] Fix the PPACreationError import in [08:55] lib/lp/registry/interfaces/webservice.py. === almaisan-away is now known as al-maisan [09:16] Hey up [09:17] helleau [09:20] bigjools: It's "Hellau!" actually but not for another 50 minutes or so... [09:20] henninge: it's actually whatever I want it to be :) [09:20] ;) [09:21] Carneval season starts at 11:11 today in some parts of Germany [09:21] what's that? [09:23] bigjools: Hi. [09:24] hi [09:24] bigjools: https://launchpad.net/ubuntu/jaunty/+source/xserver-xorg-video-geode/2.11.10-1~jaunty1 [09:25] :/ [09:25] Just to correct myself, it's "Helau" [09:25] lifeless: Hi, still around? [09:26] bigjools: Someone accidentally uploaded it (was meant for a PPA)... and the Release pocket check is only for CURRENT/SUPPORTED, not OBSOLETE. [09:26] wgrant: how did that get there? [09:26] ah [09:26] crepe [09:28] bigjools: I think we should probably reject all uploads to an obsolete series (it would fix a PPA-related bug too). [09:28] But that needs to be checked with people. [09:28] wgrant: we can't do that - PPAs need to remain active [09:28] but obsolete distros, totally [09:29] bigjools: Hmm, why? [09:29] In the past the virtualisation flag has been turned off upon obsolescence. [09:29] Although not yet for Jaunty, it seems. [09:29] because some crazy people want to carry on using them [09:30] so I'd rather it was a switch than a lock :) [09:30] :( [09:30] I guess we'd best just extend the current/supported check to obsolete. [09:30] yeah [09:30] I had a look at the upload checking code. [09:30] Those pockets are hardcoded in a few places. [09:30] :( [09:30] Also, the archive permission API is....... [09:30] this surprises you ... [09:31] well if you dislike the API then feel free to be constructive [09:32] Yeah, I had a look at redesigning it yesterday. [09:32] (I need to change it to allow pockets for queue admins) [09:41] 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] Easy fix is to set archivepublisher.root in the ppa config. [09:42] But I wonder if we want the temp directory to be in a less insane place on germanium anyway. [09:43] I can't remember what it uses the temp dir for [09:43] It writes out Packages and Sources there, so it can atomically rename them into the real archive. [09:43] So it needs to be on the same FS. [09:44] right [09:44] /var/tmp is not useful then [09:44] No. [09:45] So it needs to be fixed. [09:45] But I think it should be fixed to something other than a lie. [09:45] ('ubuntu-archive' is the lie) [09:47] jml: ping [09:52] henninge: no, not around at all. [09:52] whats up? [09:57] lifeless: two questions [09:58] lifeless: what's the state of bug 672371? [09:58] <_mup_> Bug #672371: Archive:+packages timeouts [09:58] lifeless: Are you working on that? [09:59] no, I'm on leave [09:59] the mailing list thread covers the current status [09:59] right, ok [09:59] 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] lifeless: hi [10:00] jml: you might like https://code.launchpad.net/~lifeless/testtools/matchers/+merge/40606 [10:00] lifeless: not as much as I like: "Test results: database-apocalypse => devel: SUCCESS" [10:00] lifeless: but I'll take a look [10:00] lifeless: thanks [10:01] second question: I see that a lot of revisions have landed on stable which have not been processed by the QA bot. [10:01] no qa tags, no fix committed. [10:01] Is the bot on hold because of the blockage? [10:02] Or could it be broken or just slow? [10:02] lifeless: ^ [10:03] lifeless: actually, looking, I need coffee first. won't be a jiffy [10:03] henninge: no idea [10:03] who could I ask about the bot? [10:04] henninge: jml/stub/flacoste/gary/urshina/mars/diogo/me [10:04] except I'm not here. [10:04] ;-) [10:04] its in a service account that those folk (maybe more) have access too [10:04] lifeless: thanks a lot, enjoy your leave ;) [10:05] de nada [10:05] losa, urshina or diogo I think. I don't know where or how the bot works. [10:05] right [10:05] access doesn't imply knowledge [10:05] stub: lookin the lpqateam crontab if you want to chase pointers. [10:05] henninge: qastaging is down [10:05] henninge: that will break the bot [10:06] Oh! [10:06] I don't know why its down - on leave + no losa : not going to dig in myself ;) [10:07] No, I'll have to wait for Chex .... :( [10:07] thanks again [10:07] henninge: ask a GSA [10:07] it's too important to be left down [10:07] on #is [10:07] ? [10:07] yes [10:07] will do [10:14] \o/ [10:14] my testfixes worked [10:14] * thumper heads to bed === matsubara-afk is now known as matsubara [10:17] hi henninge [10:17] do you still need help with the qa bot? [10:17] matsubara: Hi! [10:18] I already found out that qastaging is running its update script atm. [10:18] Would that stop the qa bot? [10:19] henninge: its been down for hours [10:19] henninge: whatever its doing is going to fail [10:20] and yes it will interfere [10:20] the bot reads the active revno from the qastaging and staging web uis [10:21] IS just told me that the qastaging-update script started only 21 minutes ago ... [10:21] yes [10:21] Nonetheless, its been down for hours [10:22] henninge, lifeless: yes, that's it: https://devpad.canonical.com/~lpqateam/qa_reports/logs/output-launchpad-stable.log [10:22] lifeless: is "it" the bot or qastaging? [10:22] qastaging [10:23] sorry, still waking up. lifeless is right. qastaging is down then the bot can't do its job [10:33] henninge: jml: I've mailed the list the fragment from the backtrace ng dug up. [10:33] lifeless: I saw. [10:33] henninge: could you perhaps file an RT that that log location isn't documented/visible to us? [10:33] lifeless: yes saw that. thanks [10:33] lifeless: has the problem been fixed? do you need help fixing it? [10:33] lifeless: good idea [10:33] henninge: we should have knowledge and visibility to diagnose things like this [10:33] jml: I'm on leave. [10:34] jml: I will fix it [10:34] and come back to you if I need help ;) [10:34] henninge: thanks [10:34] henninge: it should be a simple matter of importing things from the right place [10:34] yes, I expect [10:35] jml: so what did you think of the testtools patch ? [10:35] henninge: my worry is that lpnet has a similar zcml file [10:36] jml: I'm sure henninge will sed the entire production-configs ;) [10:36] there will be 40 or so files to change [10:36] easy! [10:36] ;) [10:40] jml: no, I think we are safe. No reference to canonical.launchpad.interfaces in the production configs. [10:40] henninge: other than the qastaging reference, surely? [10:41] huh, perhaps its entirely in tree as it is [10:41] jml: not even there [10:41] lifeless: that's what I think [10:41] henninge: so where's the broken code? [10:41] guys, give me time to figure it out ... ;) [10:43] Project db-devel build (132): FAILURE in 4 hr 2 min: https://hudson.wedontsleep.org/job/db-devel/132/ === al-maisan is now known as almaisan-away [10:46] jml: in ./scripts.zcml http://paste.ubuntu.com/529912/ [10:46] So, where are those files maintained? [10:55] lifeless: replied [10:55] lifeless: sorry it took so long. multitasking is ... SQUIRREL! ... what was I saying, oh yeah, multitasking is hard. [10:55] :) [10:55] lifeless: basically, two things [10:56] lifeless: why not 'Raises(FooError)' [10:56] lifeless: and the other is "%s/raises_value/raises_value_error/g" [10:56] jml: separation of concerns [10:57] jml: we could have a helper that curries the two together [10:57] MatchesException is trivially adaptable for use on Failures [10:57] Raises isn't [10:57] lifeless: I'm happy to have MatchesException be separate [10:57] lifeless: I just reckon Raises could construct one itself [10:58] 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] rather than, say, an exc_info tuple that is less than something else [11:00] gasp! === jml changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 3 of 10.11 | PQM is open | firefighting: stable->db-devel conflict, jml fixing; qastaging busted, henninge fixing | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting === matsubara is now known as matsubara-doctor [11:02] jml: I have mixed feelings [11:03] jml: I don't particularly like argument inspection [11:03] jml: type inspection I mean [11:03] jml: but we could add it [11:03] lifeless: you mean, have the instructor take a matcher or an exception class? [11:03] constructor [11:04] yeah [11:04] taking a matcher is an important use case [11:04] lifeless: got an example? [11:05] in test_runtest [11:05] Raises(MatchesException(Exception("foo")))) [11:05] its checking that the actual exception is passed on rather than some arbitrary exception [11:05] a small improvement that was easy to do here [11:05] well, that's not really passing in a matcher [11:05] you could, in theory, take whatever is passed to Raises() and pass that to MatchesException. [11:06] you could [11:06] if you want to bind the two together [11:06] well, it's not symmetric. MatchesException doesn't lose its independence. [11:06] 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] that makes it harder to do exact checks (vs subclass) without changing the core [11:07] I'll see that I get it patched now, though. [11:07] henninge: thank you [11:07] lifeless: so, rather than type checking, I would rather, def __init__(self, exc_type=None, matcher=None): style shenanigans [11:07] lifeless: I would rather a helper than that. [11:08] 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] lifeless: I don't :) [11:08] jml: We can add a helper (say 'raises') later, I don't feel one is really needed right now. [11:08] lifeless: WHUI (yet) [11:09] spiv: that also applied to getDetails, but its taken off (e.g. see soupmatchers) [11:09] I do strongly believe in making known common use cases convenient. [11:10] But I also believe in sleeping :) [11:10] 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] spiv: :) [11:10] So I'll look forward to reading the results of this discussion some time later. [11:10] jml: tell you what [11:10] jml: I've done the other variable rename and pushed while we chatted [11:10] lifeless: yay [11:10] jml: i leave it to you to land, in whatever shape you think best ;) [11:10] lifeless: did you do the MANUAL change? [11:10] I forgot to mention in IRC [11:11] jml: no, lp hadn't forwarded your mail [11:11] np [11:12] lifeless: anyway, it's a deal. [11:12] cool. Have a good day. [11:12] gnight jml, spiv, et al [11:26] qastaging is back! [11:30] henninge: cool. [11:30] henninge: what was the problem? [11:31] There is a zcml file out side the tree that referenced canonical.launchpad.interfaces. [11:32] I still don't know where it is maintained (it should be!) but Ng patched it for me. [11:36] jml: looks like this: https://pastebin.canonical.com/39629/ [11:37] henninge: ok, makes sense [11:38] jml: I think it should be put into the production configs branch. [11:38] henninge: that sounds sensible to me. [11:38] henninge: perhaps follow this up with a losa? [11:39] that's my plan as soon as Chex wakes up. ;) [11:41] henninge: good good :) [11:51] ahh yes, conflict [11:51] I had forgotten in the dizzy excitement of email processing. === almaisan-away is now known as al-maisan [12:00] 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

[12:00] jml: what sort of help do you need? [12:01] bigjools: well, I guess I need to try uploading without the CoC signed [12:01] Morning, all. [12:01] jml: ok I can make that very easy for you [12:01] bigjools: of course, I've already signed it, so I need to figure what to do there [12:01] jml: make a new user [12:01] bigjools: and I don't really know how to upload to a PPA :) [12:01] and put your gpg key on it [12:02] bigjools: ok. [12:02] jml: the other option is that I hack your account on DF to remove the CoC :) [12:02] hmm [12:02] so I can't really test this on qastaging? [12:02] no [12:02] has to be DF? [12:02] yes [12:02] harumph [12:03] bigjools: do I have to do something special to get the right version of code onto DF? [12:03] jml: make a new user on DF - its emails go to the staging inbox [12:03] jml: yes - ask me :) [12:03] bigjools: fwiw I updated dogfood this morning [12:03] oh heavens [12:03] it runs db-devel, what revno was it in? [12:03] jml: I noticed [12:03] jelmer: I noticed [12:03] (you can also deactivate a CoC sig) [12:03] I'd forgotten about staging inboxes [12:04] bigjools: I'm not sure if it's made its way to db-devel. checking now. [12:04] jml: I can merge a devel revno if you want [12:05] bigjools: r11894 of stable. Not on db-devel yet. [12:06] will be once my conflict resolution branch gets through PQM. [12:06] jml: ok just ping me when it's ready then and I'll update DF's code [12:06] bigjools: will do. thanks. [12:07] can you believe that the existing code that downloads builder files has no code to deal with errors ... [12:07] readily [12:08] I really need to make an inventory tracker thingy for Launchpad. [12:09] jelmer: hi [12:10] jelmer: did you ever get around to testing opening 'o' and 'p' series? [12:10] jml: hellø [12:10] jml: No, but I do that on dogfood now or after you've QA'ed your change. [12:10] jelmer: super. thanks. [12:10] jml: Are you QA'ing now? [12:11] jelmer: no, waiting for db-devel to have the new goodness to test [12:11] jelmer: so you could go ahead right now :) [12:11] ok, great [12:17] henninge, hi [12:17] which bugs? === Ursinha-afk is now known as Ursinha [12:17] Ursinha: Hi! [12:17] which bugs? [12:17] :-P [12:19] 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] weird. just got a gpg validation rejection from pqm [12:21] oh - nobody told you? [12:22] henninge, that weren't processed by the qa-tagger :) [12:22] Ursinha: Oh, those ;) [12:22] bigjools, I'd ask you to file a bug and I'll triage it :) [12:22] Ursinha: no worries - my next question was where to file it? :) [12:23] bigjools, https://launchpad.net/qa-tagger [12:23] cheers [12:23] :) [12:24] bigjools: nobody told me. Have I been sacked? [12:24] :) [12:26] Ursinha: done! [12:27] stub: Hey! [12:28] stub: I am trying to reproduce and OOPS I am getting from the poimport script. [12:29] bigjools, thanks :) [12:29] stub: but I don't see any. Could it be that they get ignored locally? === henninge changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 3 of 10.11 | PQM is open | firefighting: stable->db-devel conflict, jml fixing | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting [12:33] Yippie, build fixed! [12:33] Project devel build (214): FIXED in 3 hr 37 min: https://hudson.wedontsleep.org/job/devel/214/ [12:33] Launchpad Patch Queue Manager: [r=lifeless][ui=none][bug=673874] Improve memcache caching of some [12:33] bugs pages [12:38] henninge: No - should be no difference with OOPS reports between local and production [12:38] henninge: If you get a WARNING or above, you should get an OOPS [12:38] gmb, hi. still not having much luck getting a clean test run with js upgrade branch. [12:39] 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] And I don't see a warning in the log output when I run it loally. === brianchidester is now known as brianchid === matsubara-doctor is now known as matsubara [12:41]