[00:03] mars: Could you land that branch for me, please? [00:05] wgrant: have you fixed the typo [00:06] lifeless: See my reply... [00:06] It was already fixed. [00:06] hah [00:06] It was in a removed line. [00:06] ok [00:07] see, jetlag :P [00:07] Heh. [00:07] * wgrant -> uni [00:07] its on its way [00:07] thanks lifeless [00:16] lifeless: is there a way to track how many times a branch has been pulled [00:21] do you perhaps mean [00:21] 'is there a way for a branch owner to know its popularity' ? [00:21] cause thats a very different question [00:24] uh - I dunno... I was just asked "hey is there a way to track how many time a branch has been downloaded/pulled?" [00:24] mtaylor: nope [00:25] thumper: k. cool [00:25] mtaylor: subscriptions may indicate others interest though [00:25] mtaylor: if I'm really interested in a branch, I'll subscribe [00:26] mtaylor: but I often grab branches I've just a passing interest in [00:26] mtaylor: that isn't so useful to the branch owner [00:27] mtaylor: have you talked to sinzui about your CoC generalisation? [00:27] thumper: we spoke briefly a few months aog [00:27] ago [00:32] mtaylor: so tracking pull is hard for a number of reasons [00:32] mtaylor: only one of which 'its distributed, fool' [00:33] mtaylor: other reasons are - http gets != pulls, requests to a stacked-on don't indicate pulls but use the same network verbs, and so forth [00:34] lifeless: hrm. fair enough [00:37] mtaylor: not impossible, just not done [00:37] well, I mean - its not impossible to gather the specific data we /have/. Tracking consumers of a branch is impossible in the broader sense ;) [00:38] well yes [00:57] mwhudson: got a minute for a call? [00:59] thumper: not really :( [00:59] thumper: will do in a bit [00:59] after lunch maybe? [01:00] thumper: ok [01:00] thumper: can I help ? [01:01] lifeless: no [01:01] ok :) [01:03] lifeless: your biggest problem being that your aren't mwhudson :) [01:03] thumper: heh - I wasn't offended or anything :). [01:04] lifeless: testr load finished with-> id: 1 tests: 8993 failures: 22 skips: 23 [01:04] lifeless: but testr failing shows one failure [01:04] thumper: btw, if you want a weekly call with me or something-like-that, let me know. I'm inclined to just focus on good team wide dialogs fo rnow. [01:04] thumper: there is an unimplemented(shock, horror!) bit of testr that should detect deleted / renamed tests. [01:05] thumper: your test run 0 had the failure in it, and the failure is one for a test id not reported in your test run 1. [01:05] thumper: for now, rm .testrepository/failing [01:05] and reload? [01:05] thumper: yup [01:06] oh, hangon - see, this is me just getting off a plain :) [01:06] 22 failures - that really should be reported by 'testr failing' :) [01:06] this is from a ec2 land response ? [01:06] hmm... [01:06] yes [01:06] same result [01:06] forward me the stream? [01:06] * thumper deletes .testrepository [01:07] same with a clean testr init [01:07] :( [01:08] I'd like to look at the stream, if I may [01:08] I'm not alert enough to do a sensible series-of-questions-to-debug [01:08] lifeless: email sent [01:09] * thumper thinks that perhaps devel is failing again :( [01:09] ERROR: lp.soyuz.browser.tests.test_archive_webservice (subunit.RemotedTestCase) [01:10] thumper: its the same test every time [01:10] lifeless: yeah [01:10] I was just looking [01:10] thumper: zcat ~/Desktop/Downloads/merge-directive-handling-no-request-mirror.log.gz | subunit-filter --no-passthrough --no-skip | subunit-ls | uniq [01:16] lifeless: added to .bashrc: [01:16] function lp-failing [01:16] { [01:16] zcat $1 | subunit-filter --no-passthrough --no-skip | subunit-ls | uniq [01:16] } [01:18] thumper: heh [01:19] wgrant: what is 'lucille' [01:20] gah [01:20] WTF? [01:23] ✁☹ [01:23] ✁☹ [01:23] ✁☹ [01:23] ✁☹ [01:23] ✁☹ [01:24] lifeless: that failing test assumes python 2.6 [01:24] and doesn't import the with statement [01:24] which is why ec2 fails for it [01:24] but the builder passes [01:24] noice [01:24] by which I mean 'garh' [01:26] lifeless: rs from you to add the import? [01:26] lifeless: I'll land the "fix" now [01:26] doit [01:27] do we have a 'trivial' tag ? [01:27] lifeless: not any more [01:27] but rs (rubberstamp) is often considered good enough [01:28] we do expect to have more than one person look at things [01:28] even if just in concept [01:28] * thumper files a bug to make done [01:28] hmmm [01:28] we should really consider rolling that back [01:29] peer review is an important thing for helping make things great, but something like this - bah [01:32] lifeless: lucille was archivepublisher. [01:48] hah [01:48] we still call the db user lucille [01:48] We do. [01:48] And there's still lucilleconfig. [01:49] I may one day unleash my fury on and destroy lucilleconfig. [01:52] bbiab, post-travel fug is winning [01:53] * thumper -> lunch [02:02] thumper: i guess you don't want to chat then === Ursinha-afk is now known as Ursinha [02:38] mwhudson: I'm back now [02:39] thumper: how long is the call likely to take? [02:39] mwhudson: not long [02:40] thumper: i'll call your landline? [02:40] mwhudson: you have no skype? [02:40] thumper: i can see if that's still working [02:41] i'm in a cafe [02:41] ok [02:41] so a headset is probably actually a good ida [04:08] lifeless: Ah, thanks, I didn't know you were ec2testing that. [04:13] I wonder why buildd-manager doesn't log an OOPS and suspend builds when the dispatcher crashes. [04:14] it just needs the same love I gave librarian, I suspect [04:15] Also, universities need to die. [04:15] Seriously. [04:16] from the perspective of having been nearly 20 years since I got my degree, I'm inclined to agree. Although... The Qld Uni Great Court in Summer time... ahhh. memories. [04:55] lifeless: still with us? [04:55] ish [04:55] 'sup ? [04:55] testr run --failing fails to identify that one of the failing ones is fixed [04:56] testr failing still shows it [04:56] check that it is run - subunit-ls < .testrepository/$id | grep testname [04:56] its possible the loader is doing something funky [04:57] $ testr run --failingrunning: xvfb-run ./bin/test --subunit --load-list /home/tim/src/launchpad/stop-mirroring-hosted/failing.list| testr load [04:58] $ testr failing --subunit | subunit-ls -> now gives a shorter list [04:58] check that it is run - subunit-ls < .testrepository/$id | grep testname [04:58] but it is still showing lp.soyuz.browser.tests.test_archive_webservice [04:58] lifeless: I don't grok your last comment [04:58] each test run generates a new file .testrepository/ID [04:59] where ID is printed at the end of the run [04:59] yes [04:59] that has in it all the tests that were run [04:59] running: xvfb-run ./bin/test --subunit --load-list /home/tim/src/launchpad/stop-mirroring-hosted/failing.list| testr load [04:59] the most likely reason for testr run --failing to not see a failing test as fixed is if the test runner (zope.testing) did not run it. [04:59] that is what it says in response to testr run --failing [04:59] yes [04:59] then it should say [04:59] id: FOO tests run: .... [05:00] id: 3 tests: 18 failures: 6 skips: 1 [05:00] right [05:00] so [05:00] which I weirdly read as "18 failures" "6 skips" [05:00] subunit-ls < .testrepository/3 | grep lp.soyuz.browser.tests.test_archive_webservice [05:01] not there [05:01] si [05:01] so [05:01] its not being run [05:01] why is it telling me it is failing then? [05:01] this suggests its not in your branch [05:01] testr failing ? [05:01] testr keeps a record of all seen tests ever [05:02] but it is no longer failing [05:02] :( [05:02] if you bzr switch or whatever between branches while a test is failing, and the test is not in the new branch [05:02] then testr will still think its failing [05:02] thumper: its *not being run* [05:02] thumper: that means whether its failing or not is *unknown* [05:03] thumper: my suggestion, when you bzr switch, nuke .testrepository [05:03] I don't switch [05:03] thumper: try bin/test -t lp.soyuz.browser.tests.test_archive_webservice [05:03] that passes [05:04] but does it run the test [05:04] see [05:04] that string looks like a module name to me [05:04] and thats how zope reports a failed import [05:04] what happened was: [05:04] I loaded the repository with the output from ec2 [05:04] my branch didn't have an up to date devel [05:04] so it didn't have the failing soyuz test [05:05] until I merged devel [05:05] so as far as testr is concerned, a test has been deleted, which as I explained earlier, testr doesn't *yet* have a heuristic to guess at. [05:05] and committed [05:05] now it is stuct [05:05] but it is there now... [05:05] right [05:05] so ignore that one test until you've fixed all the issues [05:05] then delete .testrepository/failing [05:05] * thumper looks skyward [05:06] patches accepted; its a very raw tool. I, and others, find it very useful, but its still rraw. [05:09] thumper: do you see what is going on ? [05:09] I think so [05:21] /msg lifeless oh, and hi, btw [05:22] heh. guess people know my secrect message to lifeless now [05:22] * wgrant puts it in the blackmail file. [05:27] scandal [05:46] hi mtaylor, mwhudson [05:47] hi poolie [05:47] lifeless, i worked on the flags thing on the plane, so now it only looks up scopes as needed [05:47] hi poolie === almaisan-away is now known as al-maisan === zyga-afk is now known as zyga [08:33] oodmorning [09:06] bigjools: Morning. [09:06] morning [09:06] Are you aware of the chaos this morning? [09:06] * bigjools sighs heavily [09:06] no [09:07] Bug #610687 caused the build farm to grind to a halt for many hours. We've disabled the archive in question (I think you might have an email about that), but it needs manual cleanup before it can be reenabled. [09:07] <_mup_> Bug #610687: Delayed copies do not respect PPA component override [09:08] Basically, we had a build attempting to dispatch with a component of 'non-free'. This made things rather unhappy indeed. [09:08] * bigjools sees the email [09:08] 3 emails to be precise, but yes. [09:08] * bigjools sees why it happened and is very angry [09:08] wgrant: pls to be ware. bigjools has a '.procmailrc' - From: spm@c.c >> /dev/null, so emails can be a tad hit'n'miss [09:09] spm who? [09:10] hahaha [09:12] (somewhat amusingly, I was on Monday looking at the code throughout Soyuz that creates publications, and noting how badly factored it was. one of my planned cleanups would have accidentally fixed this...) [09:13] wgrant: don't let me stop you :) [09:14] I need to fix it for ddeb copies, so it will be happening soon, yes. [09:39] bigjools: Is cleanup just a matter of DELETEing the publications and builds, or did some stuff actually make it to disk? [09:49] wgrant: I've not analysed it yet, I've got a load of stuff to get done this morning before I can look. [09:49] it can wait if it's not breaking anything *right now* :) [09:51] Well, as long as Brian doesn't reenable it. [09:55] he's been warned no to [09:55] not [09:55] Ah, good. [10:44] * wgrant is tempted to take over the world, just to impose a global ban on shitty CS courses. [10:51] heh [10:51] wgrant: What are they having you do? [10:59] jelmer: Well, it's so far been an excellent waste of 2.5 years, though I held some hope that the final semester project (4-5 people per team, 12 weeks in length) might hold some interesting or at least vaguely challenging material. Today, project assignments came out: most of the other teams' projects have some interesting visualisation, data processing or HID components. We were landed with a basic Web 2.0 app, remarkable only in the fact ... [10:59] ... that someone could think it was even close to comparable with any of the others. [10:59] So there goes any hope of some value in this course. [10:59] Yay. [10:59] :-/ [11:03] That sounds quite familiar. We had a 8 to 10 person final semester project (though I did it before my final semester) and quite a few teams ended up doing simple web services too. [11:03] The participation in a relatively large team was still quite educational though. [11:04] There was a 10-12 person project at the end of the course, but that has been cut in the new version. [11:05] I think I learnt about 1 weeks worth of useful stuff from my uni course. And an immense amount from open source hacking whilst at uni :-) [11:05] Heh, yes. [11:06] heh, indeed [11:07] i learnt stuff during my degree [11:07] my phd on the other hand... [11:07] (my degree wasn't in cos, that probably helped) [11:07] *cs [11:07] The most useful thing I've learnt from the degree is to not do or trust degrees. [11:07] * jelmer thought some of the more theoretical CS courses were very useful [11:08] True, the few theoretical ones have been somewhat educational. [11:16] wgrant: I learnt some useful things at uni. Most of which wasn't taught ... [11:25] StevenK: Heh. [11:27] EdwinGrubbs: Hi === al-maisan is now known as almaisan-away [12:42] Hi! [12:43] Did I miss the discussion on moving the registration slot between the title and the bread crumbs or was there no discussion? [13:02] It's a little jarring [13:06] I like it for branches and some other stuff. [13:06] But for projects it doesn't really work, because it's not important information. [13:06] The old location wasn't good, though. [13:27] jelmer: hi === gary_poster_ is now known as gary_poster === almaisan-away is now known as al-maisan [15:35] morning all ye non-jetlaggers === matsubara is now known as matsubara-lunch [15:58] hello lifeless [15:59] hi bigjools === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [16:25] lifeless, hi [16:25] hi [16:28] henninge: ping [16:29] henninge: your buildd manager logging patch : upstream twisted's log class supports what you want directly; I'm confused why you seem to have reimplemented it : or am I missing something ? [16:39] jml or lifeless, around? Would either of you feel comfortable doing a Unix build system pre-implementation call? I am trying to figure out how much effort we should put into cleaning up the process tree [16:40] mars, otp right now [16:40] k [16:40] mars, happy to in a little while [16:40] mars: sure [16:44] lifeless: Hi [16:45] hi henninge; I'm really excited to see the twisted log rotation stuff getting fixed for us - we've a lot of daemons (buildd,librarian, codehosting) that all need it [16:45] henninge: I'm just hoping we don't need to maintain code [and thus tests] for it [16:45] lifeless: I don't see how this could be done any other way in twisted [16:46] lifeless: It does not re-open logs on SIGUSR1 but rotates them (in its own way). [16:47] henninge: just use a LogFile(foo, bar, rotateLength=0) [16:47] ? [16:47] lifeless: that's what I do, don't I? [16:47] hmm, let me re-read [16:50] henninge: ok [16:51] otp for a sec === beuno is now known as beuno-lunch === zyga is now known as zyga-afk [17:15] bigjools, dogfood fall down go boom. [17:16] rockstar: will look later, OTP === EdwinGrubbs is now known as Edwin-lunch [17:40] lifeless: I'll be finishing off now. I replied on the MP. ;) [17:40] yeah thanks === Ursinha_ is now known as Guest58336 === Guest58336 is now known as Ursula === Ursula is now known as Guest16602 === Guest16602 is now known as Ursula_ [17:56] ok, I think I'm going to pull on this librarian thing a bit, it should make a big difference === beuno-lunch is now known as beuno === al-maisan is now known as almaisan-away [19:06] bac: ah... so perhaps it's because of the commercial subscription ? [19:06] mtaylor: that's what i'm investigating [19:06] if so, it should be easy to fix. this problem has been infested with red herrings [19:06] hehe [19:06] fish are difficult to catch [19:07] slippery [19:07] yup [19:07] i'll let you know what i find [19:12] thumper, are you guys planning on doing anything with https://code.edge.launchpad.net/~jml/launchpad/private-branch-lookup-bug-261609 [19:12] yes [19:13] thumper, it's been stale for a while now, and I'm really keen to get it off my branch list. [19:13] jml: I was finishing off another tech-debt branch, this is next [19:13] thumper, cool, thanks. === Edwin-lunch is now known as EdwinGrubbs [19:29] the code users of the job system raise SQLObjectNotFound in a couple of places, is there something that should be used instead, or is this still the idiom? [19:30] it's raised in a get @classmethod on a Storm object [19:33] abentley: any idea? ^ [19:48] james_w, I'm not aware of something that should be used instead. [19:49] abentley: is get() raising an exception a required thing? It seems to me that the only callers convert the exception to None, so the work of converting None to the exception is not needed. [19:51] james_w, I don't know if it's a required thing, but I would expect that retrieving an object that doesn't exist is usually a serious error. [19:52] jml: am I on th eplanet ? [19:52] jml: I don't think I am... can I be added ? [19:54] lifeless: is it a requirement to get a review from both you and stub for db patches? [19:55] yes to deploy, no to merge [19:55] ok, good [19:57] lifeless, sure. email mrevell. [19:58] jml: you know, if lp knew about blogs, the planet could be auto maintained ;P [19:59] lifeless, patches tolerated. [19:59] haha [19:59] I only get to code if I'm a *good boy* [20:03] matsubara: hi [20:04] lifeless, hey [20:04] I put a patch up for getting bug numbers in the timeout section [20:05] but I can't bootstrap properly to test it [20:05] did you have any thoughts on it [20:06] lifeless, I didn't get an email notification about the merge proposal [20:06] matsubara: I put it in the bug [20:09] lifeless, looking [20:11] lifeless, bug 607776 is testable or not? [20:11] <_mup_> Bug #607776: +filebug-show-similar FTI query timeouts [20:11] lifeless: if you have a working buildout you can use it to bootstrap a new buildout cd path-to-new-project; path-to-working-project/bin/buildout bootstrap [20:12] Ursinha: no [20:12] unfortunately, having a bootstrap.py script in a buildout is an attractive nuisance [20:12] Ursinha: I have a follow on branch that drops the time by ~ 75% [20:13] lifeless, cool [20:13] that's cool [20:13] benji: it seems the oops tools want stuff that isn't in the dep cache [20:13] lifeless, will remove the qa-needstesting tag for now [20:13] Ursinha: thanks, wasn't sure if I should / shouldn't [20:13] can't help you there :) [20:13] benji: :/ [20:13] lifeless, what's the error? [20:13] lifeless, that's the incremental change, if it's not testable, doesn't make sense to keep the tag there [20:14] Ursinha: kk [20:14] matsubara: bootstrapping? [20:14] maybe you need to bzr up the dependencies (~/launchpad/lp-branches/devel/download-cache [20:14] ) [20:14] lifeless, I'm not sure the patch is going to do what you want. My initial impression to the bug report is that the static summary (https://devpad.canonical.com/~lpqateam/oops- [20:14] summaries/lpnet-2010-07-20.html#time-outs) was generated before the bug was linked to the oops [20:15] lifeless, yes, what dependency oops-tools is asking that's not in the cache? [20:15] Getting distribution for 'zc.buildout==1.4.1'. [20:15] Error: Couldn't find a distribution for 'zc.buildout==1.4.1'. [20:16] matsubara: when I traced the code, it seemed like it was simply that the bug wasn't being set for the reporter [20:16] james_w, I'm looking at the build emails, and the ordering of items looks like it could be improved. I'd put the buildstate high. [20:16] matsubara: you could try it and see ;P [20:17] lifeless, you want this cache: bzr+ssh://bazaar.launchpad.net/~launchpad/lazr-source-dependencies/download-cache/ not the LP one [20:17] indeed, zc.buildout 1.4.1 doesn't appear to be in the centrally-managed cache; I suspect 1.4.0 would work for you [20:18] matsubara: thanks [20:18] abentley: yeah, that would be a good idea [20:18] pulling it [20:18] matsubara: was that in README.txt and I was simply blind ? [20:19] james_w, in your bug, you seem inconsistent about whether the component should be included. [20:20] lifeless, yep, it's explained there and the make command should fetch the right cache. not sure why it didn't work for you [20:20] abentley: bug number? [20:20] james_w, 603606 [20:20] james_w, or what is RELEASE? the pocket? [20:21] abentley: pocket, yes [20:21] james_w, and that's not listed in binary build email body, just subject. I see. [20:21] abentley: the pocket will be important once it is possible to target non-release pockets, but for now there is only one choice, so I say put it in there [20:22] matsubara: my bad! [20:22] abentley: I'm not particularly keen on the binary build email, but it's better than what was there for recipes IMO, and I think they should at least be largely consistent. If you want to improve both, that would be even better [20:22] james_w, what about distroseries? [20:23] abentley: that's a requirement IMO, it's especially important with multi-series builds. [20:23] james_w, err, we don't have multi-series builds. [20:24] well, one recipe being dispatched to multiple series at the same time [20:24] if I wake up to a daily build failure, I want to be able to work out which series failed, without having to query them each in turn [20:25] james_w, well, you can click though and get all the information, and more. [20:25] james_w, but you didn't ask for distroseries. [20:25] james_w, do you prefer pocket and distroseries separate, or do you want "suite"? [20:26] abentley: the series is in the subject as well [20:26] abentley: I don't mind [20:26] I would prefer it was the same as binary builds [20:27] james_w, binary builds don't list the pocket or distroseries in the message body at all. [20:27] indeed [20:27] james_w, so you're saying it shouldn't be included? [20:28] abentley: I want it there somewhere. I don't have particularly strong preferences on where. [20:28] abentley: are you redesigning binary build failure messages too? [20:29] matsubara: now it wants distribute 0.6.12 [20:29] james_w, no, not my domain. [20:29] matsubara: with that new cache [20:30] abentley: in that case, I would prefer that the recipe build failures just follow the binary build failures. [20:30] james_w, seems like a lowest-common-denominator approach to me. [20:30] abentley: why? [20:31] james_w, because you don't especially like binary build mails, but you want me to make source build mails just as bad. [20:33] abentley: they are better than what we currently have for recipes, and I value consistency. If you see ways to improve the binary build mails then I encourage you to improve those as well. [20:34] james_w, so you're basically asking me to make recipe build mails no better than binary build mails. [20:34] abentley: I'm asking you to make them equally as good, yes. I'd love for you to make them both excellent. [20:35] james_w, It's not my job to make binary build mails better, but perhaps if I make recipe build mails better, soyuz will see and follow suit. [20:35] abentley: I don't see why it isn't your job [20:36] james_w, I am a member of the code team, not soyuz. [20:36] and I don't think that is an approach that has worked particularly well in the past [20:36] lifeless, hmm I think I saw that distribute problem before with gary_poster and was unable to reproduce locally. would you mind filing a bug on oops-tools so I can investigate this further later on? [20:38] james_w, I'm not going to go trampling though another team's code for no especially good reason. That will just upset them. [20:38] abentley: I think that characterisation isn't helpful. I would imagine the soyuz team would be overjoyed at someone looking at this area of the project and improving it. [20:38] I doubt anyone is particularly attached to the status quo [20:39] fwiw, upload acceptance emails were redesigned about a year ago, with great success. They are now for more readable and usable than before. [20:40] james_w, improvement is very much in the eye of the beholder. I would be very upset if someone made this kind of change to my code without consulting me. [20:40] matsubara: sure [20:40] abentley: then consult them? [20:41] abentley: BFNs are crap, fee l free to fix them :) [20:41] james_w, it's simpler to just ask them to do it instead. They have the experience with the code and the domain knowledge to do a better job. [20:46] lifeless, ping, any chance you could point to some example code that uses testtools.clone_test_with_new_id() ? [20:46] testscenarios [20:46] (apt-get install python-testscenarios, or grab it from pypi, or lp:testscenarios) [20:47] thanks, looking at the code now [20:59]