[00:03] <wgrant> mars: Could you land that branch for me, please?
[00:05] <lifeless> wgrant: have you fixed the typo
[00:06] <wgrant> lifeless: See my reply...
[00:06] <wgrant> It was already fixed.
[00:06] <lifeless> hah
[00:06] <wgrant> It was in a removed line.
[00:06] <lifeless> ok
[00:07] <lifeless> see, jetlag :P
[00:07] <wgrant> Heh.
[00:07]  * wgrant -> uni
[00:07] <lifeless> its on its way
[00:07] <mars> thanks lifeless
[00:16] <mtaylor> lifeless: is there a way to track how many times a branch has been pulled
[00:21] <lifeless> do you perhaps mean
[00:21] <lifeless> 'is there a way for a branch owner to know its popularity' ?
[00:21] <lifeless> cause thats a very different question
[00:24] <mtaylor> 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] <thumper> mtaylor: nope
[00:25] <mtaylor> thumper: k. cool
[00:25] <thumper> mtaylor: subscriptions may indicate others interest though
[00:25] <thumper> mtaylor: if I'm really interested in a branch, I'll subscribe
[00:26] <thumper> mtaylor: but I often grab branches I've just a passing interest in
[00:26] <thumper> mtaylor: that isn't so useful to the branch owner
[00:27] <thumper> mtaylor: have you talked to sinzui about your CoC generalisation?
[00:27] <mtaylor> thumper: we spoke briefly a few months aog
[00:27] <mtaylor> ago
[00:32] <lifeless> mtaylor: so tracking pull is hard for a number of reasons
[00:32] <lifeless> mtaylor: only one of which 'its distributed, fool'
[00:33] <lifeless> 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] <mtaylor> lifeless: hrm. fair enough
[00:37] <lifeless> mtaylor: not impossible, just not done
[00:37] <lifeless> 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] <mtaylor> well yes
[00:57] <thumper> mwhudson: got a minute for a call?
[00:59] <mwhudson> thumper: not really :(
[00:59] <mwhudson> thumper: will do in a bit
[00:59] <thumper> after lunch maybe?
[01:00] <mwhudson> thumper: ok
[01:00] <lifeless> thumper: can I help ?
[01:01] <thumper> lifeless: no
[01:01] <lifeless> ok :)
[01:03] <thumper> lifeless: your biggest problem being that your aren't mwhudson :)
[01:03] <lifeless> thumper: heh - I wasn't offended or anything :).
[01:04] <thumper> lifeless: testr load finished with-> id: 1 tests: 8993 failures: 22 skips: 23
[01:04] <thumper> lifeless: but testr failing shows one failure
[01:04] <lifeless> 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] <lifeless> thumper: there is an unimplemented(shock, horror!) bit of testr that should detect deleted / renamed tests.
[01:05] <lifeless> 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] <lifeless> thumper: for now, rm .testrepository/failing
[01:05] <thumper> and reload?
[01:05] <lifeless> thumper: yup
[01:06] <lifeless> oh, hangon - see, this is me just getting off a plain :)
[01:06] <lifeless> 22 failures - that really should be reported by 'testr failing' :)
[01:06] <lifeless> this is from a ec2 land response ?
[01:06] <thumper> hmm...
[01:06] <thumper> yes
[01:06] <thumper> same result
[01:06] <lifeless> forward me the stream?
[01:06]  * thumper deletes .testrepository
[01:07] <thumper> same with a clean testr init
[01:07] <thumper> :(
[01:08] <lifeless> I'd like to look at the stream, if I may
[01:08] <lifeless> I'm not alert enough to do a sensible series-of-questions-to-debug
[01:08] <thumper> lifeless: email sent
[01:09]  * thumper thinks that perhaps devel is failing again :(
[01:09] <thumper> ERROR: lp.soyuz.browser.tests.test_archive_webservice (subunit.RemotedTestCase)
[01:10] <lifeless> thumper: its the same test every time
[01:10] <thumper> lifeless: yeah
[01:10] <thumper> I was just looking
[01:10] <lifeless> thumper: zcat ~/Desktop/Downloads/merge-directive-handling-no-request-mirror.log.gz | subunit-filter --no-passthrough --no-skip | subunit-ls | uniq
[01:16] <thumper> lifeless: added to .bashrc:
[01:16] <thumper> function lp-failing
[01:16] <thumper> {
[01:16] <thumper>   zcat $1 | subunit-filter --no-passthrough --no-skip | subunit-ls | uniq
[01:16] <thumper> }
[01:18] <lifeless> thumper: heh
[01:19] <lifeless> wgrant: what is 'lucille'
[01:20] <thumper> gah
[01:20] <thumper> WTF?
[01:23] <thumper> ✁☹
[01:23] <thumper> ✁☹
[01:23] <thumper> ✁☹
[01:23] <thumper> ✁☹
[01:23] <thumper> ✁☹
[01:24] <thumper> lifeless: that failing test assumes python 2.6
[01:24] <thumper> and doesn't import the with statement
[01:24] <thumper> which is why ec2 fails for it
[01:24] <thumper> but the builder passes
[01:24] <lifeless> noice
[01:24] <lifeless> by which I mean 'garh'
[01:26] <thumper> lifeless: rs from you to add the import?
[01:26] <thumper> lifeless: I'll land the "fix" now
[01:26] <lifeless> doit
[01:27] <lifeless> do we have a 'trivial' tag ?
[01:27] <thumper> lifeless: not any more
[01:27] <thumper> but rs (rubberstamp) is often considered good enough
[01:28] <thumper> we do expect to have more than one person look at things
[01:28] <thumper> even if just in concept
[01:28]  * thumper files a bug to make done
[01:28] <lifeless> hmmm
[01:28] <lifeless> we should really consider rolling that back
[01:29] <lifeless> peer review is an important thing for helping make things great, but something like this - bah
[01:32] <wgrant> lifeless: lucille was archivepublisher.
[01:48] <lifeless> hah
[01:48] <lifeless> we still call the db user lucille
[01:48] <wgrant> We do.
[01:48] <wgrant> And there's still lucilleconfig.
[01:49] <wgrant> I may one day unleash my fury on and destroy lucilleconfig.
[01:52] <lifeless> bbiab, post-travel fug is winning
[01:53]  * thumper -> lunch
[02:02] <mwhudson> thumper: i guess you don't want to chat then
[02:38] <thumper> mwhudson: I'm back now
[02:39] <mwhudson> thumper: how long is the call likely to take?
[02:39] <thumper> mwhudson: not long
[02:40] <mwhudson> thumper: i'll call your landline?
[02:40] <thumper> mwhudson: you have no skype?
[02:40] <mwhudson> thumper: i can see if that's still working
[02:41] <mwhudson> i'm in a cafe
[02:41] <thumper> ok
[02:41] <mwhudson> so a headset is probably actually a good ida
[04:08] <wgrant> lifeless: Ah, thanks, I didn't know you were ec2testing that.
[04:13] <wgrant> I wonder why buildd-manager doesn't log an OOPS and suspend builds when the dispatcher crashes.
[04:14] <lifeless> it just needs the same love I gave librarian, I suspect
[04:15] <wgrant> Also, universities need to die.
[04:15] <wgrant> Seriously.
[04:16] <spm> 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] <thumper> lifeless: still with us?
[04:55] <lifeless> ish
[04:55] <lifeless> 'sup ?
[04:55] <thumper> testr run --failing fails to identify that one of the failing ones is fixed
[04:56] <thumper> testr failing still shows it
[04:56] <lifeless> check that it is run - subunit-ls < .testrepository/$id | grep testname
[04:56] <lifeless> its possible the loader is doing something funky
[04:57] <thumper> $ testr run --failingrunning: xvfb-run ./bin/test --subunit --load-list /home/tim/src/launchpad/stop-mirroring-hosted/failing.list| testr load
[04:58] <thumper> $ testr failing --subunit | subunit-ls  -> now gives a shorter list
[04:58] <lifeless> check that it is run - subunit-ls < .testrepository/$id | grep testname
[04:58] <thumper> but it is still showing lp.soyuz.browser.tests.test_archive_webservice
[04:58] <thumper> lifeless: I don't grok your last comment
[04:58] <lifeless> each test run generates a new file .testrepository/ID
[04:59] <lifeless> where ID is printed at the end of the run
[04:59] <thumper> yes
[04:59] <lifeless> that has in it all the tests that were run
[04:59] <thumper> running: xvfb-run ./bin/test --subunit --load-list /home/tim/src/launchpad/stop-mirroring-hosted/failing.list| testr load
[04:59] <lifeless> 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] <thumper> that is what it says in response to testr run --failing
[04:59] <lifeless> yes
[04:59] <lifeless> then it should say
[04:59] <lifeless> id: FOO tests run: ....
[05:00] <thumper> id: 3 tests: 18 failures: 6 skips: 1
[05:00] <lifeless> right
[05:00] <lifeless> so
[05:00] <thumper> which I weirdly read as "18 failures" "6 skips"
[05:00] <lifeless> subunit-ls < .testrepository/3 | grep lp.soyuz.browser.tests.test_archive_webservice
[05:01] <thumper> not there
[05:01] <lifeless> si
[05:01] <lifeless> so
[05:01] <lifeless> its not being run
[05:01] <thumper> why is it telling me it is failing then?
[05:01] <lifeless> this suggests its not in your branch
[05:01] <thumper> testr failing ?
[05:01] <lifeless> testr keeps a record of all seen tests ever
[05:02] <thumper> but it is no longer failing
[05:02] <thumper> :(
[05:02] <lifeless> if you bzr switch or whatever between branches while a test is failing, and the test is not in the new branch
[05:02] <lifeless> then testr will still think its failing
[05:02] <lifeless> thumper: its *not being run*
[05:02] <lifeless> thumper: that means whether its failing or not is *unknown*
[05:03] <lifeless> thumper: my suggestion, when you bzr switch, nuke .testrepository
[05:03] <thumper> I don't switch
[05:03] <lifeless> thumper: try bin/test -t lp.soyuz.browser.tests.test_archive_webservice
[05:03] <thumper> that passes
[05:04] <lifeless> but does it run the test
[05:04] <lifeless> see
[05:04] <lifeless> that string looks like a module name to me
[05:04] <lifeless> and thats how zope reports a failed import
[05:04] <thumper> what happened was:
[05:04] <thumper> I loaded the repository with the output from ec2
[05:04] <thumper> my branch didn't have an up to date devel
[05:04] <thumper> so it didn't have the failing soyuz test
[05:05] <thumper> until I merged devel
[05:05] <lifeless> 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] <thumper> and committed
[05:05] <thumper> now it is stuct
[05:05] <thumper> but it is there now...
[05:05] <lifeless> right
[05:05] <lifeless> so ignore that one test until you've fixed all the issues
[05:05] <lifeless> then delete .testrepository/failing
[05:05]  * thumper looks skyward
[05:06] <lifeless> patches accepted; its a very raw tool. I, and others, find it very useful, but its still rraw.
[05:09] <lifeless> thumper: do you see what is going on ?
[05:09] <thumper> I think so
[05:21] <mtaylor> /msg lifeless oh, and hi, btw
[05:22] <mtaylor> heh. guess people know my secrect message to lifeless now
[05:22]  * wgrant puts it in the blackmail file.
[05:27] <mwhudson> scandal
[05:46] <poolie> hi mtaylor, mwhudson
[05:47] <mtaylor> hi poolie
[05:47] <poolie> lifeless, i worked on the flags thing on the plane, so now it only looks up scopes as needed
[05:47] <mwhudson> hi poolie
[08:33] <adeuring> oodmorning
[09:06] <wgrant> bigjools: Morning.
[09:06] <bigjools> morning
[09:06] <wgrant> Are you aware of the chaos this morning?
[09:06]  * bigjools sighs heavily
[09:06] <bigjools> no
[09:07] <wgrant> 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 <canonical-losa-lp> <Soyuz:New> <https://launchpad.net/bugs/610687>
[09:08] <wgrant> 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] <spm> 3 emails to be precise, but yes.
[09:08]  * bigjools sees why it happened and is very angry
[09:08] <spm> 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] <bigjools> spm who?
[09:10] <spm> hahaha
[09:12] <wgrant> (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] <bigjools> wgrant: don't let me stop you :)
[09:14] <wgrant> I need to fix it for ddeb copies, so it will be happening soon, yes.
[09:39] <wgrant> bigjools: Is cleanup just a matter of DELETEing the publications and builds, or did some stuff actually make it to disk?
[09:49] <bigjools> 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] <bigjools> it can wait if it's not breaking anything *right now* :)
[09:51] <wgrant> Well, as long as Brian doesn't reenable it.
[09:55] <bigjools> he's been warned no to
[09:55] <bigjools> not
[09:55] <wgrant> Ah, good.
[10:44]  * wgrant is tempted to take over the world, just to impose a global ban on shitty CS courses.
[10:51] <jelmer> heh
[10:51] <jelmer> wgrant: What are they having you do?
[10:59] <wgrant> 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] <wgrant> ... that someone could think it was even close to comparable with any of the others.
[10:59] <wgrant> So there goes any hope of some value in this course.
[10:59] <wgrant> Yay.
[10:59] <jelmer> :-/
[11:03] <jelmer> 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] <jelmer> The participation in a relatively large team was still quite educational though.
[11:04] <wgrant> There was a 10-12 person project at the end of the course, but that has been cut in the new version.
[11:05] <maxb> 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] <wgrant> Heh, yes.
[11:06] <jelmer> heh, indeed
[11:07] <mwhudson> i learnt stuff during my degree
[11:07] <mwhudson> my phd on the other hand...
[11:07] <mwhudson> (my degree wasn't in cos, that probably helped)
[11:07] <mwhudson> *cs
[11:07] <wgrant> 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] <wgrant> True, the few theoretical ones have been somewhat educational.
[11:16] <StevenK> wgrant: I learnt some useful things at uni. Most of which wasn't taught ...
[11:25] <wgrant> StevenK: Heh.
[11:27] <jelmer> EdwinGrubbs: Hi
[12:42] <henninge> Hi!
[12:43] <henninge> Did I miss the discussion on moving the registration slot between the title and the bread crumbs or was there no discussion?
[13:02] <maxb> It's a little jarring
[13:06] <wgrant> I like it for branches and some other stuff.
[13:06] <wgrant> But for projects it doesn't really work, because it's not important information.
[13:06] <wgrant> The old location wasn't good, though.
[13:27] <EdwinGrubbs> jelmer: hi
[15:35] <lifeless> morning all ye non-jetlaggers
[15:58] <bigjools> hello lifeless
[15:59] <lifeless> hi bigjools
[16:25] <jml> lifeless, hi
[16:25] <lifeless> hi
[16:28] <lifeless> henninge: ping
[16:29] <lifeless> 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] <mars> 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] <jml> mars, otp right now
[16:40] <mars> k
[16:40] <jml> mars, happy to in a little while
[16:40] <lifeless> mars: sure
[16:44] <henninge> lifeless: Hi
[16:45] <lifeless> 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] <lifeless> henninge: I'm just hoping we don't need to maintain code [and thus tests] for it
[16:45] <henninge> lifeless: I don't see how this could be done any other way in twisted
[16:46] <henninge> lifeless: It does not re-open logs on SIGUSR1 but rotates them (in its own way).
[16:47] <lifeless> henninge: just use a LogFile(foo, bar, rotateLength=0)
[16:47] <lifeless> ?
[16:47] <henninge> lifeless: that's what I do, don't I?
[16:47] <lifeless> hmm, let me re-read
[16:50] <lifeless> henninge: ok
[16:51] <lifeless> otp for a sec
[17:15] <rockstar> bigjools, dogfood fall down go boom.
[17:16] <bigjools> rockstar: will look later, OTP
[17:40] <henninge> lifeless: I'll be finishing off now. I replied on the MP. ;)
[17:40] <lifeless> yeah thanks
[17:56] <lifeless> ok, I think I'm going to pull on this librarian thing a bit, it should make a big difference
[19:06] <mtaylor> bac: ah... so perhaps it's because of the commercial subscription ?
[19:06] <bac> mtaylor: that's what i'm investigating
[19:06] <bac> if so, it should be easy to fix.  this problem has been infested with red herrings
[19:06] <mtaylor> hehe
[19:06] <mtaylor> fish are difficult to catch
[19:07] <bac> slippery
[19:07] <mtaylor> yup
[19:07] <bac> i'll let you know what i find
[19:12] <jml> thumper, are you guys planning on doing anything with https://code.edge.launchpad.net/~jml/launchpad/private-branch-lookup-bug-261609
[19:12] <thumper> yes
[19:13] <jml> thumper, it's been stale for a while now, and I'm really keen to get it off my branch list.
[19:13] <thumper> jml: I was finishing off another tech-debt branch, this is next
[19:13] <jml> thumper, cool, thanks.
[19:29] <james_w> 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] <james_w> it's raised in a get @classmethod on a Storm object
[19:33] <james_w> abentley: any idea? ^
[19:48] <abentley> james_w, I'm not aware of something that should be used instead.
[19:49] <james_w> 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] <abentley> 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] <lifeless> jml: am I on th eplanet ?
[19:52] <lifeless> jml: I don't think I am... can I be added ?
[19:54] <james_w> lifeless: is it a requirement to get a review from both you and stub for db patches?
[19:55] <lifeless> yes to deploy, no to merge
[19:55] <james_w> ok, good
[19:57] <jml> lifeless, sure. email mrevell.
[19:58] <lifeless> jml: you know, if lp knew about blogs, the planet could be auto maintained ;P
[19:59] <jml> lifeless, patches tolerated.
[19:59] <lifeless> haha
[19:59] <lifeless> I only get to code if I'm a *good boy*
[20:03] <lifeless> matsubara: hi
[20:04] <matsubara> lifeless, hey
[20:04] <lifeless> I put a patch up for getting bug numbers in the timeout section
[20:05] <lifeless> but I can't bootstrap properly to test it
[20:05] <lifeless> did you have any thoughts on it
[20:06] <matsubara> lifeless, I didn't get an email notification about  the merge proposal
[20:06] <lifeless> matsubara: I put it in the bug
[20:09] <matsubara> lifeless, looking
[20:11] <Ursinha> lifeless, bug 607776 is testable or not?
[20:11] <_mup_> Bug #607776: +filebug-show-similar FTI query timeouts <qa-needstesting> <timeout> <Launchpad Bugs:In Progress by lifeless> <https://launchpad.net/bugs/607776>
[20:11] <benji> 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] <lifeless> Ursinha: no
[20:12] <benji> unfortunately, having a bootstrap.py script in a buildout is an attractive nuisance
[20:12] <lifeless> Ursinha: I have a follow on branch that drops the time by ~ 75%
[20:13] <Ursinha> lifeless, cool
[20:13] <Ursinha> that's cool
[20:13] <lifeless> benji: it seems the oops tools want stuff that isn't in the dep cache
[20:13] <Ursinha> lifeless, will remove the qa-needstesting tag for now
[20:13] <lifeless> Ursinha: thanks, wasn't sure if I should / shouldn't
[20:13] <benji> can't help you there :)
[20:13] <lifeless> benji: :/
[20:13] <matsubara> lifeless, what's the error?
[20:13] <Ursinha> lifeless, that's the incremental change, if it's not testable, doesn't make sense to keep the tag there
[20:14] <lifeless> Ursinha: kk
[20:14] <lifeless> matsubara: bootstrapping?
[20:14] <benji> maybe you need to bzr up the dependencies (~/launchpad/lp-branches/devel/download-cache
[20:14] <benji> )
[20:14] <matsubara> 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] <matsubara> summaries/lpnet-2010-07-20.html#time-outs) was generated before the bug was linked to the oops
[20:15] <matsubara> lifeless, yes, what dependency oops-tools is asking that's not in the cache?
[20:15] <lifeless>   Getting distribution for 'zc.buildout==1.4.1'.
[20:15] <lifeless> Error: Couldn't find a distribution for 'zc.buildout==1.4.1'.
[20:16] <lifeless> matsubara: when I traced the code, it seemed like it was simply that the bug wasn't being set for the reporter
[20:16] <abentley> 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] <lifeless> matsubara: you could try it and see ;P
[20:17] <matsubara> lifeless, you want this cache: bzr+ssh://bazaar.launchpad.net/~launchpad/lazr-source-dependencies/download-cache/ not the LP one
[20:17] <benji> 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] <lifeless> matsubara: thanks
[20:18] <james_w> abentley: yeah, that would be a good idea
[20:18] <lifeless> pulling it
[20:18] <lifeless> matsubara: was that in README.txt and I was simply blind ?
[20:19] <abentley> james_w, in your bug, you seem inconsistent about whether the component should be included.
[20:20] <matsubara> 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] <james_w> abentley: bug number?
[20:20] <abentley> james_w, 603606
[20:20] <abentley> james_w, or what is RELEASE?  the pocket?
[20:21] <james_w> abentley: pocket, yes
[20:21] <abentley> james_w, and that's not listed in binary build email body, just subject.  I see.
[20:21] <james_w> 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] <lifeless> matsubara: my bad!
[20:22] <james_w> 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] <abentley> james_w, what about distroseries?
[20:23] <james_w> abentley: that's a requirement IMO, it's especially important with multi-series builds.
[20:23] <abentley> james_w, err, we don't have multi-series builds.
[20:24] <james_w> well, one recipe being dispatched to multiple series at the same time
[20:24] <james_w> 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] <abentley> james_w, well, you can click though and get all the information, and more.
[20:25] <abentley> james_w, but you didn't ask for distroseries.
[20:25] <abentley> james_w, do you prefer pocket and distroseries separate, or do you want "suite"?
[20:26] <james_w> abentley: the series is in the subject as well
[20:26] <james_w> abentley: I don't mind
[20:26] <james_w> I would prefer it was the same as binary builds
[20:27] <abentley> james_w, binary builds don't list the pocket or distroseries in the message body at all.
[20:27] <james_w> indeed
[20:27] <abentley> james_w, so you're saying it shouldn't be included?
[20:28] <james_w> abentley: I want it there somewhere. I don't have particularly strong preferences on where.
[20:28] <james_w> abentley: are you redesigning binary build failure messages too?
[20:29] <lifeless> matsubara: now it wants distribute 0.6.12
[20:29] <abentley> james_w, no, not my domain.
[20:29] <lifeless> matsubara: with that new cache
[20:30] <james_w> abentley: in that case, I would prefer that the recipe build failures just follow the binary build failures.
[20:30] <abentley> james_w, seems like a lowest-common-denominator approach to me.
[20:30] <james_w> abentley: why?
[20:31] <abentley> 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] <james_w> 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] <abentley> james_w, so you're basically asking me to make recipe build mails no better than binary build mails.
[20:34] <james_w> abentley: I'm asking you to make them equally as good, yes. I'd love for you to make them both excellent.
[20:35] <abentley> 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] <james_w> abentley: I don't see why it isn't your job
[20:36] <abentley> james_w, I am a member of the code team, not soyuz.
[20:36] <james_w> and I don't think that is an approach that has worked particularly well in the past
[20:36] <matsubara> 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] <abentley> 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] <james_w> 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] <james_w> I doubt anyone is particularly attached to the status quo
[20:39] <james_w> 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] <abentley> 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] <lifeless> matsubara: sure
[20:40] <james_w> abentley: then consult them?
[20:41] <bigjools> abentley: BFNs are crap, fee l free to fix them :)
[20:41] <abentley> 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] <mars> lifeless, ping, any chance you could point to some example code that uses testtools.clone_test_with_new_id() ?
[20:46] <lifeless> testscenarios
[20:46] <lifeless> (apt-get install python-testscenarios, or grab it from pypi, or lp:testscenarios)
[20:47] <mars> thanks, looking at the code now
[20:59] <lifeless> mars: start with the readme
[21:13] <mars> lifeless, hmm, I'm getting no text
[21:14] <lifeless> what do you mean ?
[21:14] <mars> http://bazaar.launchpad.net/~lifeless/testscenarios/trunk/annotate/head:/doc/example.py?file_id=lib-20090307095458-ntl18b730pwjf0qy-10 is empty
[21:14] <mars> for instance
[21:14] <mars> does that mean codebrowse is going to die? :(
[21:15] <lifeless> I don't know what it means
[21:15] <lifeless> http://bazaar.launchpad.net/~lifeless/testscenarios/trunk/revision/1#doc/example.py
[21:15] <lifeless> clicking on doc/example.py there worked
[21:16] <mars> lifeless, neat, that is a useful tool.  Parameterization made easy
[21:17] <lifeless> :)
[21:36] <mwhudson> morninh
[21:38] <mtaylor> morning lifeless
[21:48] <lifeless> hiya
[22:00] <bdmurray> I just got oops-1670ea4372 when reporting a bug and the traceback did not look to my untrained eye
[22:01] <lifeless> look what?
[22:01] <bdmurray> look good?
[22:12] <lifeless> https://lp-oops.canonical.com/oops.py/?oopsid=1670EA4372 looks sane (but sad) to me. otp for now, chat in a sec
[23:17] <lifeless> bdmurray: ok, off the call
[23:18] <lifeless> bdmurray: that timeout looks legit
[23:18]  * wgrant looks at the build queues with dismay.
[23:18] <wgrant> barry!!!!!!!!
[23:19] <wgrant> Oh, no, it's not all py27stack4
[23:19] <wgrant> Then what is it...
[23:19] <wgrant> .....
[23:20] <wgrant> py27stack5.
[23:20] <jelmer> 'evening
[23:21] <wgrant> Can we at lest score that archive down a few hundred points, or something like that?
[23:22] <mwhudson> jelmer: i wanted to ask you something a minute ago but now can't remember what :-)
[23:24] <poolie> hi lifeless, wgrant, mwhudson
[23:24] <poolie> thanks for the review lifeless
[23:24] <wgrant> Morning poolie.
[23:28] <lifeless> poolie: my pleasure
[23:28] <poolie> how should i write tests for the page macros?
[23:28] <poolie> preferably not as doctests
[23:28] <lifeless> you get a browser instance
[23:29] <lifeless> and use some template that uses the macros so you get a rendered view
[23:29]  * wgrant whispers 'really bad user experience', and points at #launchpad and the build queue which is currently being eaten by an unimportant rebuild.
[23:29] <lifeless> wgrant: the magic phrase is 'losa ping'
[23:29] <wgrant> Well, no, there are underlying issues.
[23:29] <poolie> wgrant: i was thinking about proposing an "i care about this" button that can only be pressed by a human (not in the api) that adds X to the build score
[23:30] <poolie> this will of course only work if people don't press it for everything
[23:30] <wgrant> The problem at the moment is that people do partial archive rebuilds without telling anyone, so they are scored like normal PPA builds.
[23:31] <wgrant> (well, that shouldn't be a problem, except our queue discipline is pathetic)
[23:31] <lifeless> perhaps subtract the queue length for a PPA from uploads to the PPA
[23:31] <bigjools> who is rebuilding?
[23:31] <wgrant> barry.
[23:31] <wgrant> I thought it was py27stack4.
[23:31]  * bigjools scores it down
[23:31] <wgrant> But I was wrong; there's only a few there.
[23:32] <wgrant> Now it's py27stack5.
[23:32] <bigjools> I asked him to use rebuild archives
[23:32] <wgrant> If he doesn't want to do that, he could at least get someone to add a score delta to the archive first.
[23:33] <wgrant> Scoring them down to <900 might be nice, otherwise recipe builds won't happen.
[23:33] <lifeless> whats a rebuild archive ?
[23:33] <bigjools> I scored everything -100
[23:33] <wgrant> Haha. Even better.
[23:33] <bigjools> that'll free the farm up
[23:33] <wgrant> Thanks.
[23:33] <bigjools> when I say -100 I mean a delta
[23:33] <bigjools> not absolute :)
[23:33] <wgrant> lifeless: ArchivePurpose.COPY. Doesn't accept source uploads, and has a forced build score of -10.
[23:34] <wgrant> Oh :(
[23:34] <wgrant> So recipe builds are screwed for the next couple of days. I guess that's not tooo bad.
[23:34] <bigjools> hmmm
[23:34] <wgrant> Also, will that affect existing builds?
[23:34] <bigjools> yes
[23:34] <bigjools> anything needsbuild
[23:34] <wgrant> But I thought queuebuilder didn't run any more.
[23:35] <bigjools> oh arse
[23:35] <bigjools> I need to manually rescore them
[23:36] <bigjools> well, it's only a 4 hour wait
[23:36] <wgrant> Assuming perfect efficiency.
[23:36] <bigjools> if it were days...
[23:36] <wgrant> It's lots of short builds.
[23:36] <wgrant> True.
[23:37] <wgrant> But it'll be more like 24 hours.
[23:37] <wgrant> Once you take into account the continuing pileup of builds, and the fact that they're short builds, which buildd-manager really doesn't handle well.
[23:38] <bigjools> it will, soon
[23:38] <wgrant> Indeed.
[23:38] <wgrant> That will be good.
[23:39] <bigjools> I should fix that score delta stuff so it applies the delta on the query
[23:40] <bigjools> then it'll work on existing builds
[23:40] <wgrant> That sounds confusing.
[23:40] <wgrant> But maybe better.
[23:41]  * bigjools shoos a fox away
[23:42] <bigjools> anyway it's seriously antisocial to upload 500+ packages for rebuild in a normal PPA
[23:50] <bigjools> g'night
[23:50] <wgrant> Night.
[23:53] <poolie> are developer docs in the tree ever built into web pages people can read?
[23:53] <poolie> like for bzr's?
[23:53] <lifeless> there is apidoc.launchpad.dev now
[23:53] <wgrant> How does one create code imports these days?
[23:54] <wgrant> I can't see a way to do it outside +setbranch.
[23:54] <jelmer> wgrant, some project code pages don't have a link, but https://code.launchpad.net/ has a link to create imports for all projects
[23:55] <wgrant> Ah, +new-import
[23:55] <wgrant> I was using +newimport :(
[23:55] <thumper> the theory was...
[23:55] <thumper> that we wouldn't show "new import" for a project that uses launchpad codehosting
[23:55] <thumper> however it seems its all gone to pot
[23:56] <wgrant> It seems to just not show the link if there is a dev focus.
[23:56] <wgrant> AFAICT.
[23:56] <jelmer> thumper: I can think of some (pehaps not common, but possible) situations where an import would be useful even if the trunk is hosted on Launchpad.
[23:56] <thumper> jelmer: like?
[23:57] <jelmer> thumper: dulwich is maintained in bzr, but I keep a mirror of it in git and some external contributors host their branches on github
[23:59] <jelmer> (I did emphasize it wasn't a common situation :-)