[00:22] * thumper gets stuck into jobs [00:42] when I log in to ec2 during postmortem, where can I actually find the LP tree it is testing? [00:43] or am I misunderstanding how it works? [00:44] james_w: I expect that you should be able to find it, but I've never tried personally, perhaps mwhudson knows [00:46] james_w: /var/launchpad/test i think [00:46] thanks [00:46] yeah, that [00:47] I have some failures in the initial branch, so I'll squash them now [00:47] ok cool [00:51] mwhudson: quick sanity check [00:52] mwhudson: during my investigations I found a pile of stuff still in canonical/launchpad/event [00:52] mwhudson: worth making a new pipe to move them to lp.code.event? [00:53] mwhudson: or perhaps lp.code.interfaces.event [00:55] dammit, failures in pagetests [00:56] - The code import has been updated. [00:56] + There is 1 error. [00:56] + Enter the URL of a foreign VCS branch. [00:56] so something (the readonly change?) breaks +edit-import it seems [00:57] james_w: oh that's not so surprising [00:57] james_w: easy to fix though [00:57] thumper: err [00:57] care to enlighten me? [00:57] what's in canonical/launchpad/event ? [00:57] mwhudson: interfaces for events [00:57] yay two conversations [00:57] mwhudson: not a lot to be honest [00:58] thumper: oh, lp.code.interfaces.event then i guess [00:58] If the field is writable, why should it be readonly on the API? [00:58] wgrant: crack [00:58] of the 'updateFromData' kind [00:59] mwhudson: But the import URL should be editable by some, shouldn't it? [00:59] wgrant: yes, but it's not edited by going "import.url = foo" [00:59] Odd. [00:59] mwhudson: could we allow certain people to do that over the API? [01:00] james_w: this /should/ all be fixed to work like other objects [01:00] but it's quite a lot of work [01:00] right [01:00] millions of $units of tech debt [01:01] we can work towards that [01:01] james_w: anyway, to make the edit form work again, you need to edit the EditCodeImportForm schema in lp.code.browser.codeimport [01:01] for now I would like to fix the tests to make my work landable [01:03] I've got it open [01:03] james_w: to look like this: http://pastebin.ubuntu.com/396468/ [01:03] it's fairly opaque to me though [01:03] aha! [01:03] (warning: code typed directly into pastebin, probably right though) [01:04] that's what we have tests for [01:05] this is what i thought would break, btw [01:05] if nothing else is broken, that's pretty good :) [01:05] grar testfix mode grumble [01:05] the testsuite seems to have problems with email at the moment [01:06] KeyError: 'cvs_root' on import [01:06] james_w: oh haha [01:06] yah [01:06] s/IBranch/ICodeImport/ for the first three [01:06] yay for familiarity [01:07] beats me spending ages last night working why doctest was giving me syntax errors on [01:07] import = factory.makeCodeImport() [01:09] :) [01:11] What's the db-lp failure? [01:13] same failures with that change [01:13] james_w: s/read_only/readonly [01:15] thanks wgrant [01:15] wgrant: some crap involving sending mail and not having an interaction :/ [01:16] wgrant: http://pastebin.ubuntu.com/396471/ [01:17] That line is too long. [01:17] * wgrant tries to read. [01:17] wgrant: http://pastebin.ubuntu.com/396472/ better formatted [01:18] Ahh much better. [01:18] it's in "Failure in test testSimpleRun (lp.soyuz.scripts.tests.test_lpquerydistro.TestLpQueryDistroScript) [01:18] " [01:18] which i guess i could try running locally [01:18] That looks like there's no MTA running. [01:19] but on the whole launchpad tests don't actually send mail through an MTA do they? [01:20] Except for test-sampledata-setup.txt, they should not. [01:20] (well, it shouldn't either, but it does) [01:22] thumper: https://code.edge.launchpad.net/~james-w/launchpad/export-code-import/+merge/21472 updated to pass tests. Seeing as you approved it would you now submit it for me please? [01:23] james_w: I'll take a look [01:24] * james_w has https://code.edge.launchpad.net/~james-w/launchpad/register-code-import/+merge/21505 on the go too, any suggestions appreciated [01:24] * thumper goes to grab coffee [01:26] james_w: Why is IHasCodeImports separate from IBranchTarget? [01:26] wgrant: good question [01:27] wgrant: one good reason may be that code imports only support products so far [01:27] because for better or worse we don't support code imports for !product [01:27] wgrant: a less good reason is that I didn't know about IBranchTarget (though I now remember you mentioning it yesterday) [01:27] Why does a code import have any idea what it's on? [01:27] good question! [01:27] I want to fix that in a later branch, but perhaps it should be done earlier [01:27] i really hope nothing uses ICodeImport['product'] [01:28] * james_w sends a branch nuking all those things through ec2 to get an idea of the fallout [01:30] the only thing that might get in the way is ICodeImport['series'], as we can't really store that information on IBranch as far as I know [01:31] ah right [01:31] Is that information used for anything? [01:31] i doubt anything uses that either [01:31] i'd certainly entirely forgotten about it [01:31] It's potentially useful except not really. [01:31] I've never seen any hint that it's used. [01:31] it was probably used during the transition from the old to new system [01:33] I'm nuking owner, product and series so that we can get an idea of where they are used [01:34] james_w: oh, i was going to do that, but if you're on it already... [01:34] assuming that anything that uses .owner should use .branch.owner, .product should be .branch.{product,sourcepackage} [01:34] I believe .assignee is different? [01:34] assignee is just not used [01:34] remove it [01:34] ok, bye bye [01:37] Where does ICodeImport['series'] come from? I can't see it on the table. [01:37] * wgrant checks the code. [01:37] Oh. [01:38] It searches for the ProductSeries with the branch selected. [01:39] oh, so it only applies to focus branches? [01:39] Yes. [01:40] So it's not critical. [01:40] So you could always leave it alone and it will just be None, and not break anything. [01:40] But better to remove it entirely. [01:41] yes [01:41] if it' [01:41] s not used, kill it [02:10] error: (4, 'Interrupted system call') [02:10] oh, that's a great reason to error out from an ec2 test [02:31] tests finally running [02:32] I'll call it a day [02:32] thanks for your help team [02:32] james_w: did you get the chance to mail me about bzr-builder? [02:36] james_w: thanks for working on this! [03:18] lifeless: no, slipped my mind, sorry, pls to be mailing me then I will remember [03:18] k [03:20] thumper: what does 'reject' mean for the puller? [03:21] umm [03:21] what? [03:21] thumper: http://dev.launchpad.net/Code/RemoveHostedArea?action=diff&rev1=5&rev2=6 [03:21] mwhudson: more context? [03:21] sorry, not a very clear question [03:21] mwhudson: hmm, can we not catch this while the user is pushing? [03:22] i guess we need to be more careful about the way say codebrowse opens the branch [03:22] thumper: not really, certainly not until we turn the vfs off [03:22] mwhudson: oh yeah [03:22] hmm... [03:23] Branches aren't accessible over HTTPS at all, are they? [03:24] wgrant: no [03:24] Ah, good. [03:24] at least I hope not [03:24] wgrant: actually [03:24] kinda [03:24] Eep. [03:24] wgrant: from loggerhead anyway [03:25] what do you mean accessible? [03:25] branchable? [03:25] but that hopefully won't serve the files directly. [03:25] Since this will mean that bazaar.launchpad.net contains arbitrary user-generated files. [03:25] it will serve the content [03:25] And if that was HTTPS, then it could do horrible untold nasty things to the webapp and its cookies. [03:25] right [03:25] via the bzr smart protocol, not as files on disk, AIUI [03:26] well [03:26] loggerhead _can_ serve branches, both as dumb and smart http [03:26] anyhow, personally I'd keep the mirrored area and scale it out. [03:26] but it doesn't on launchpad [03:27] argh [03:27] mwhudson: yes? [03:28] given that it would be nice to serve bits of launchpad over http rather than https... [03:28] lifeless: what do you mean? [03:28] mwhudson: Don't worry, you would not be the first to be serving arbitrary files under launchpad.net. [03:28] It already happens, and worse. [03:28] mwhudson: the apache rewrite rules make anything not in .bzr go to loggerhead [03:29] mwhudson: although if someone put some random file in .bzr dir, it would be served [03:29] thumper: i'm getting a bit worried by the fact that if we eliminate the mirrored area, people will be able to get launchpad to serve arbitrary content over http [03:29] wgrant: yes? [03:29] mwhudson: yeah... [03:29] eg. bug #420292 [03:29] thumper: yes, but what if people put crap in .bzr ? [03:29] mwhudson: exactly [03:29] hmm... [03:29] currently what saves us here is the puller [03:30] I guess it comes down to "do we care enough?" [03:31] wgrant: heh, as soon as you mentioned the number, i thought "what about ..." and guessed the outcome [03:31] Can we add a 'bzr tidy' or similar that removes crap from .bzr directories that shouldn't be there, or is that too dangerous as users could be using plugins that store arbitrary stuff in there? [03:31] stub: sounds difficult to get right to me [03:31] I guess we could, as bzr tidy would just remove stuff that the mirror process skips already. [03:31] i think plugins do store stuff [03:32] mwhudson: there is a bzr concept right now of extra baggage (terminology may be wrong) [03:32] mwhudson: where push also pushes plugin extras [03:33] Is the goal of removing the mirror step to remove an unwanted copy, or to remove the time between upload and published? [03:33] stub: to save space [03:33] clearly what we need is a file system with cow snapshots at the directory level, you could make a clone of the directory on write access, then pull from the snapshot to the original then delete the snapshot [03:33] * mwhudson falls out of the blue sky [03:34] thumper: very much at the concept stage though, right? [03:34] So we could mirror, then replace the original with the mirrored copy [03:34] Which should just remove anything that shouldn't be there [03:35] stub: that sounds relatively sane [03:35] mwhudson: Could you abuse stacking to do something like that? [03:35] i guess that would reduce the time we're vulnerable for [03:35] wgrant: hnngh [03:36] wgrant: maybe [03:36] you could probably do it at the transport level too i guess [03:36] have writes go to one area, reads fall back to another [03:36] say, a fallback repository? [03:36] all sounds a bit crazy though [03:37] wgrant: i think the problem with doing at the stacking level is that you don't know whether a branch is going to be written to when its opened [03:37] True. [03:38] so you could present every branch over a writable transport as being stacked on the real branch, but that doesn't sound very sane [03:39] Overwriting the original branch with the mirrored copy also gives us an opportunity for other fun, like pushing revisions into the stacking target (saving two thirds of the disk space used to store Launchpad code perhaps). [03:39] True. [03:40] Hmm... 3/4... dev branch, devel, stable, db-devel is four copies of each revision [03:41] stub: You can save just about all of the space except for whatever is in db-stable. [03:41] (for non private branches with a public stacking root) [03:41] since almost every branch will end up in db-stable, so their branch data is entirely redundant. [03:41] Yes. [03:42] Most projects you would only save 50% though (dev branch -> trunk) [03:43] you could also do that in a garbo type job [03:43] probably fairly slow to do it for 200k branches though [03:43] mwhudson: But most will end up with no revs after the first run, so they needn't be touched. [03:43] Well... mirroring would become non-time critical so yes it could be done in batches rather than on-push [03:44] (on-push = stick branch in queue, garbo == mirror and pack stuff from the queue) [03:44] stub: i meant just anyway, independent of changing how mirroring worked [03:44] ok [03:44] wgrant: point [03:48] maybe i should just not worry too much about the arbitrary hosting thing and assume that sooner or later we'll be able to disable vfs-level access to branches [03:49] is that a valid assumption? [03:49] Hasn't it been happening reasonably soon for a long time now? [03:49] i don't know, but it's not /really/ a risk as long as the cookie is marked secure [03:49] Right. [03:53] and then write a branch opener that's suitably paranoid about stacking and so on and have everything use this [03:54] (this will be easier once the hosted area/mirrored area distinction has gone away i guess) [04:05] mwhudson: I mean simply that I'd keep the separation between 'mirrored and anything goes' and 'not mirrored owners only' [04:06] I think its a nice data cleansing step [04:06] and because the mirrored area doesn't need to worry about stuck clients or anything, its arguably easier to scale/mirror/replicate [04:07] lifeless: that does seem to imply using twice as much disk as we in some sense need though [04:08] mwhudson: we can probably save that several times over by doing a gc on stacked branches, encouraging deletes of merged branches, ... [04:09] lifeless: How much data is stored in a stacked branch with no revs of its own? [04:10] mwhudson: I mean, look at pg - we use several times the disk we need to there, as well :) [04:10] Deleting branches is bad. [04:10] lifeless: we use considerable more disk for branches than for postgres, i think [04:10] not as much as the librarian though [04:10] wgrant: it depends; a stacked branch that has been merged to trunk has all the data ever written to it still [04:10] lifeless: I mean after GC. [04:10] If that exists yet. [04:10] wgrant: deletion is a valid thing for users to do to their own data [04:11] lifeless: But it deletes MPs and invalidates recipes and blah blah, so it would be really nice to minimise it. [04:11] deleting implies deleting the merge proposal which is a bit lame [04:11] wgrant: oh, about 800 bytes or so, butprobably 25 allocation units [04:11] wgrant: uhm, I *want* to delete stuff I'm done with. Its cognitive overhead I no longer care about. [04:11] lifeless: Ew. [04:12] wgrant: I'd like to make deletion easier, not harder. [04:12] Why do you want to? [04:12] what's wrong if they're hidden, as they are now? [04:12] wgrant: because it has no value anymore. The history is in bzr [04:12] Keeping MP history is useful. [04:12] wgrant: sometimes. Its not an absolute. [04:13] wgrant: 'trivial fix: doit' is not valuable historical data. [04:13] wgrant: big debate about the right way, which noone ever looks at, is also not valuable historical data. [04:14] lifeless: It also doesn't consume a significant amount of space. [04:14] *if* someone looks at it, its a different matter [04:14] And if we delete it, it can never be looked at. [04:14] wgrant: nonzero cost, nonzero benefits. You can do the math. [04:14] Should we delete bugs too? [04:14] anyhow, gc doesn't exist yet. It should be able to zerg stuff back to nearly empty in principle. for merged branches. [04:15] Right. [04:15] wgrant: there are many I'd like to, yes. [04:15] the name 'bubba' is floating in my consciousness right now [04:15] Heh. [04:32] Ooh... its about to bucket down on the protestors outside. [04:33] * stub goes to switch on the TV [04:41] stub: the current government seems to have been in charge for quite a while this time [04:42] unless i've missed a revolution or two [04:42] mwhudson: blink and you miss 'em.... [04:42] I've lost track [04:45] Can I do something like foo[0] in TALES without resorting to python: ? [04:45] wgrant: no [04:46] :( [04:46] ugh, tests are failing again in buildbot [04:46] Same one? [04:47] basically yeah [04:47] Mine's the only untested rev, isn't it? [04:47] But it doesn't look at all relevant. [04:47] wgrant: not testing any of yours in this build [04:47] 10530-10532 [04:47] The db-lp failure a few hours ago had me in the blamelist. Is this something else? [04:47] Ah. [04:48] this is the other builder [04:49] i guess it's worth looking to see what these tests do [04:49] and, wow, i hadn't realised how much i used / to start a search in ff [04:49] Doesn't work in Chromium? [04:50] nope [04:50] Ick [04:52] ctrl-F [04:52] breaks my fingers all day atm [04:55] * StevenK hasn't found a compelling reason to switch [04:55] it is faster [04:55] more memory hungry though [04:56] And uses ugly widgets. [04:56] by faster, I mean lp bug pages don't feel like torture [04:56] StevenK: firefox started segfaulting continuously for me, i didn't want to switch [04:56] it seems mostly ok [04:56] lifeless: Surely you jest. [04:56] it handles multiple windows in a rather strange way [04:57] wgrant: no, I don't. The js is a huge component of bug page load times. [04:57] and chromium is a lot fast at js [04:57] Ah, yes, particularly for multi-tasked bugs. [04:57] I haven't yet done my 'open 20 tabs by ctrl-clicking on a search' thing in chromium yet [04:57] but on ff that used to take 4 or 5 minutes [04:57] lifeless: Right, but then I hear people complain about things that I do constantly in a browser and I push looking at chromium further down the list [05:03] mwhudson, wgrant: I think the db-devel and current devel failures are spurious [05:07] stub: hmm [05:07] stub: they're intermittent, and i suspect not directly related to the test cases that are failing [05:08] stub: but they've started happening every other run for the last week, so _something_ has changed [05:09] it's annoying because i have some kind of memory of looking at a checkin and going "ooh, i wonder if that's a good idea" in this sort of area [05:09] and now i can't find it :( [05:12] mwhudson: They seem Librarian related. The only change I could think of might have been BjornT's persistent-resources change to the test suite, making it possible to keep the Librarian and memcached running between test runs. [05:13] stub: it's email related, really [05:13] the librarian is just being a canary [05:14] Other branches were failing with Librarian issues anyway [05:14] In non-email sections [05:15] Looks to me that it is failing because the logging system is trying to upload the traceback into the Librarian and this is failing. [05:16] So we get a different error message than expected [05:18] the current lp builder is definitely failing in an email related way [05:41] * mwhudson grinds to a halt [05:43] night mwhudson [05:57] for the test failure, i reckon some test is putting things in the mail queue and then sometimes the mails are handled before that test process exits [05:57] and sometimes not [05:58] and then the next test to activate the queue processing thread blows up [05:58] maybe? [05:58] it' [05:58] s a guess anyway [08:33] good morning [09:06] Do I need a UI review for https://code.edge.launchpad.net/~wgrant/launchpad/show-package-sets-in-queue/+merge/21521? It's only used by a few people, and I have +1s from two of them. [09:12] Howdy [09:16] jelmer, take a look at https://code.edge.launchpad.net/~jml/launchpad/new-zope-testing/+merge/21539 [09:16] mrevell, hello [09:16] mrevell, I'm in Worcestershire! [09:16] hey mrevell [09:16] jml: looking [09:16] jml, Welcome to everything that is great about England. [09:16] :) [09:16] hey jelmer [09:17] How long are you chaps sprinting? [09:17] mrevell, just until Friday [09:18] jml: yuck, hardcoded subunit version in buildout.cfg ? [09:20] jelmer, I guess. I mean, we have hardcoded versions in versions.cfg [09:21] jml: yeah, but it'd be nice to only have a hardcoded version in one place so that it's easier to update [09:21] jelmer, I agree. I don't really know how to do that though. [09:22] jelmer, anyway, did I end up deleting your code? [09:22] jml: would it be possible to just use a checkout of a bzr tag rather than downloading the tarball? [09:22] jelmer, not w/ the cmmi recipe [09:22] jml: yep - around line 60 in the diff [09:23] jelmer, but it's hard to tell. the docs might be incomplete because J1m only cared about writing tests. [09:23] jelmer, do you want me to add your bit back? [09:24] jml: If possible :-) But I guess it'd have to go into zope.testing now? [09:25] jelmer, I _think_ it's equivalent to "if os.getenv("SUBUNIT_FORMATTER"): options.append('--subunit')" [09:25] jelmer, the idea is that if the env var is defined, we do subunit, right? [09:26] jml: Yep, and we pipe our subunit output into the command set in that variable [09:27] jelmer, I'll have a look [09:28] :\ [09:33] jml: Building new-zope-testing fails for me, after merging into a fresh devel branch. Specifically, it breaks during the cmmi bit for subunit. [09:34] allenap, can you paste the error please? [09:42] jml: I'm having trouble replicating it. [09:47] allenap, so it works now? [09:47] jml: Not sure. I was being a muppet when trying to replicate. Having another go now. [09:48] jml: http://paste.ubuntu.com/396612/ [09:48] allenap, I guess you don't have CHECK [09:48] allenap, I wonder if we can disable that [09:50] jml: Ah, "unit test framework for C"? [09:50] allenap, yeh [09:50] allenap, I guess that means I'd need to add that to deps or something [09:53] jml: Yes, guess so. I'm seeing if I'm missing any other deps now. [09:53] hello jml [09:53] poolie, hi [09:57] jml: cppunit is missing too. [09:59] Morning, all. [10:04] allenap, I see. Is that it? [10:04] deryck, good morning [10:04] mrevell, hi [10:04] hey jml [10:04] jml: Yep, it's building fine now (for me, anyway). [10:07] jml: Yes, built fine, and subunit.__file__ eventually resolves to parts/subunit/lib/python2.5/site-packages/subunit/__init__.py. [10:39] jml: In new-zope-testing, --save-list is gone. Do you know of a good alternative? `bin/test --list` does not produce a reusable list (it needs a fair bit of munging). [10:40] allenap, bin/test --subunit --list-tests | subunit-ls [10:49] bigjools, what do you think about me moving a bunch of stuff to lp.poppy? [11:02] jml: Oh, that's beautiful, thanks :) [11:05] I wonder what I need to do to get the check & cppunit stuff [11:07] jml: maxb seems to be the expert on that. [11:08] soyuz: Have you seen the test failures in buildbot? They don't seem to be transient, and they're in soyuz. [11:08] * bigjools looks [11:08] Is this the same as the db-lp failure ~10h ago? [11:09] wgrant: Possibly. testMissingAction and testSimpleRun? [11:10] this is the librarian issue again [11:10] allenap: Yeah. mwhudson was having a look at that. [11:10] it is probably not actually a Soyuz bug. [11:10] bigjools, wgrant: Okay, sorry for the noise. [11:12] the current devel one is a weird traceback because librarian_client.remoteAddFile(...) is raising an AttributeError, but the exception handling code that is trying to stuff the traceback into the Librarian only deals with an UploadError. [11:13] oh... hmm... there is a catchall there... [11:16] That code should die anyway - I don't think we have a valid use case for stuffing exceptions in the Librarian any more. OOPS reports exist now for a start. [11:17] It's handy for Soyuz. [11:17] Since the upload processor sucks at reporting errors. [11:17] Sometimes you have to look at the traceback. [11:19] allenap: hmm? [11:20] maxb: jml might need to add "check" and "libcppunit-dev" to lp-dev-dependencies. You seem to be an ace at packaging :) That's all. [11:21] wow, C code in launchpad? :-) [11:22] allenap, no. C code in our dependencies [11:22] maxb, allenap, maybe I should just manage subunit as a package dependency [11:23] works for me, but I have a somewhat jaded view of buildout/setuptools/distribute :-) [11:24] Maybe the librarian is a red herring there in the failure... the test seems to be expecting a single ERROR line but is getting two ERROR's (plus extra traceback cruft from the handler) [11:32] When did this start happening? [11:43] maxb, how would I add subunit as a dependency? [11:44] * jml has nfi [11:44] First, you run 'rmadison python-subunit' and decide if the versions packaged across hardy-lucid are sufficient for your needs [11:46] Then you'd backport packages as needed [11:46] and lastly depend on it in launchpad(-developer)-dependencies [11:48] maxb, ok, thanks. [11:49] maxb, so I need to backport to hardy :\ [11:49] maxb, it's just "subunit" fwiw. [11:49] which means I need to do more exploratory work [11:50] making changes to Launchpad is so frikking hard :( [11:54]