=== jamalta-afk is now known as jamalta === matsubara is now known as matsubara-afk [01:13] rockstar: ping [01:13] * thumper does TZ math [01:13] thumper, hi [01:14] rockstar: it's getting late for you right? [01:14] rockstar: bug 527450 [01:14] Bug #527450: email unsubscribe link is fragile (broken-ish)

[01:14] rockstar: are you able to qa this? [01:14] thumper, I just got back from a bike ride. [01:14] thumper, I think I can. I have to get the imap mail thing working again, which is always a PITA. [01:14] rockstar: can you put qa onto your TODO list for tomorrow morning? [01:14] thumper, yessir. [01:15] rockstar: awesome, thanks [01:15] (sorry you had to remind me) [01:15] thumper, rockstar: can i beg a couple of reviews off you? [01:15] mwhudson: hit me [01:15] thumper: https://code.edge.launchpad.net/~mwhudson/launchpad/fewer-spurious-partial-code-imports-bug-532402/+merge/21416 [01:15] mwhudson, you can, but I'm upgrading to Lucid right so... [01:15] thumper: https://code.edge.launchpad.net/~mwhudson/launchpad/back-off-failing-imports-bug-413637/+merge/21411 [01:16] (jml already sort of half reviewed the last one) [01:34] thumper: ta [01:35] thumper: can you approve the merge proposals too? [01:35] or i can of course... [01:36] ²²±/16 [01:38] Ursinha: eh? [01:40] thumper: nevermind my irssi fail [01:40] Ursinha: you just had me confused [01:41] thumper: sorry [01:41] :) === jtv-zzz is now known as jtv === jamalta is now known as off [03:44] jtv: Has there been any further discussion about what to do about generalised builder histories? [03:44] (in particular, has there been any discussion about making the model suck less?) [03:44] wgrant: hi! apparently the thinking right now is "just implement buildbase somehow" [03:45] Maybe we should just start out by renaming BuildBase to BuildRecord and Build to PackageBuildRecord or something. [03:45] Hmmm. That seems silly. [03:45] BTW you said that the builder UI also stumbles over recipe builds, right? [03:46] It won't crash any more (they have a canonical URL as of a few days ago). [03:47] I had a little play around with remodeling the model to remove duplication and actually allow generalised histories to work. Some of the output is at http://people.ubuntu.com/~wgrant/launchpad/buildfarm/ [04:01] wgrant: so the idea is to split Build into "build attempt," "binary build," and "source package build"? [04:03] jtv: I'd like to store attempts, but others probably don't, so there's one without that too. [04:04] (at the moment if a build fails, clicking "Retry" will reset and obliterate the build's history. this can make things very opaque) [04:05] Oh, that's exactly the kind of situation where I'd have expected Build to be useful as an historical record. [04:05] We can't really create a new Build, I don't think. [04:07] Although that might work better [04:07] Hmm. [04:07] Excluding UI problems, I think the Soyuz model might actually cope with having duplicate Builds. [04:07] Why have a BinaryPackageBuild.buildstate and a SourcePackageRecipeBuild.build_state? [04:08] Because I haven't resolved the unresolved issue. [04:08] And I apparently forgot to rename the attributes that I copied from the original classes. [04:09] But the whole result thing needs to be rethough. SPRB and BPB can share them. I'm just not sure where to put it. [04:10] Another point is that what we are working on is not a "package" build. [04:10] "we"? [04:11] Do you refer to the template jobs? [04:13] Right. [04:14] I don't see any implication in the current model or my experiments that it is. [04:15] Well, none of PackageBuild would be applicable to us. [04:16] Okay, "job" would. :-) [04:16] wgrant: hey, do you have a pointer to the object served as the root over the API? I'm looking to export a new collection, it's in the wadl, but I need to serve the link to it in the root. [04:16] jtv: That's why it's not connected to any of the Translations bits. [04:17] wgrant: so if we wanted to keep history for the translations jobs as well, where would it fit into your model? [04:17] james_w: Which collection? [04:17] wgrant: code-imports [04:17] jtv: TTB [04:17] oh, I had been completely ignoring the lhs! [04:17] james_w: I don't think you should export that. Code imports exist under branches, and should be created from under productserieses. [04:17] I don't think exporting the root collection is useful. [04:18] wgrant: productserieses/distributionsourcepackage? [04:18] jtv: Heh. [04:18] wgrant: I now see why. [04:18] james_w: Hmmm. [04:18] wgrant: I don't see any meaningful difference between TTB and TranslationTemplatesBuildJob. [04:18] wgrant: what I want to achieve is to be able write a script that syncs Vcs-* with LP [04:19] james_w: Expose it on IBranchTarget or whatever it is, then. [04:19] ok [04:19] * james_w changes direction [04:19] jtv: TTBJ doesn't exist, does it? [04:19] wgrant: does too! [04:20] I thought it was just Branch<->BranchJob<->Job<->BuildQueue [04:20] In the database, yes. [04:20] In terms of storage, a TTBJ is just a BranchJob. [04:20] But it's also a BuildFarmJob. [04:20] james_w: Root collections should be avoided if at all possible. Both operations (retrieving and creating code imports) have logical parents, so they should be exposed there. [04:21] wgrant: right [04:21] jtv: OK, so the meaningful difference is probably that TTBJs die when the operation completes. [04:21] And the current model has too many duplicated classes, so I want to kill it. [04:21] wgrant: right, so the TTB would simply be a copy of the TTBJ [04:21] jtv: TTBJ ceases to exist. [04:21] wgrant: so, code imports should be retrieved by getting a subordinate URI of the branch they import to? [04:22] wgrant: TTBJ shares a table with all sorts of other jobs of different types, so I don't think we should dictate our lifetime semantics to it. [04:22] james_w: my understanding was that someone tried that and lazr.restful stabbed them [04:22] james_w: but noone's completely sure any more :-) [04:22] mwhudson: '@stepto("+code-import")'? [04:23] jtv: I mean, why does TTBJ need to exist if TTB does? [04:23] Is there any point in it sharing the table? [04:23] Same for Job itself. [04:23] mwhudson: I am equipped with a stab-proof vest, my naivety, and a glass of wine, I hope to prevail [04:23] wgrant: eh? [04:23] mwhudson: Do you recall what the problem was? [04:23] wgrant: no [04:23] It seems like one could just add @stepto("+code-import") to BranchNavigation, and it would have to work. [04:23] i don't think i ever knew [04:24] I recall I brought it up in Wellington one day, and nobody knew there either :( [04:24] Which is odd, since all of Code in recent memory was there. [04:24] something to do with having an entry as part of another entry rather than as part of a collection [04:24] james_w: please try, and if it fails, please explain what happens in the bug report [04:25] I know the API well from the client-side, but know little about implementing it server side, so this is partly a learning exercise [04:25] wgrant: wouldn't that mean that TTB represented a past, ongoing, or future build whereas the other Build types represent only past or ongoing ones? [04:25] jtv: The other Build types can never be removed. [04:26] the bug btw https://bugs.edge.launchpad.net/launchpad-code/+bug/366102 [04:26] Bug #366102: API for creating and managing code imports

[04:26] If they succeed, they are deeply integrated into the terrible web that is the Soyuz data model. [04:26] They are never removed. [04:26] Oh, misread. [04:27] jtv: I don't see how the futureness is different. [04:27] A TTB will start to exist moments before it is queued. [04:27] SPRBs and BPBs do as well. [04:28] wgrant: I thought that was in the same transaction that also dispatched it. [04:28] jtv: No. They are created by any one of a number of processes on several different machines. [04:28] Does build candidate selection etc. use Build? [04:28] Yes. [04:28] I see. Then it's not really different. [04:28] Exactly. [04:30] No class in my non-current diagrams gets deleted. [04:30] (except when a branch gets deleted, but mrrhrhrrhrhr) [04:32] Whereas all the common classes in the old one do. [04:32] That's the kind of case where I'd be in favour of either cascading deletes or a denormalized history table—the latter being something we should do only if there is a proven need. [04:32] I think we should probably just ban branch deletes in some circumstances. [04:33] What happens if I try to delete a branch referenced by a recipe referenced by sourcepackagerecipebuilds with dozens of sourcepackagereleases in dozens of archives? [04:33] we have a kind of denormalized history for code imports [04:33] completely unused :/ [04:33] Heh. [04:34] wgrant: so what? If the recipe is basically there to service the branch, it should die. The SPRs don't depend on the recipebuilds, do they? [04:34] jtv: SPR references SPRB. [04:35] Deleting an SPRB removes all accountability information for any SPR built from it. [04:35] wgrant: and the reference from SPR to the branch does not go through the recipe? [04:35] Because if it does, well, cascading nulls solve it very nicely. :) [04:36] It does. But then you end up with a broken recipe. [04:36] grar [04:37] Hm? [04:37] i revoked ec2 lands oauth token and now it's broken [04:37] do i have to clear some cache somewhere? [04:37] Hah. [04:37] Try removing the launchpadlib cache, i guess... [04:38] * mwhudson finds /home/mwh/.launchpadlib/api.edge.launchpad.net/credentials/launchpad-branch-lander [04:38] jtv: Anyway, any more impressions of the model? [04:39] and a few other similarly named files [04:40] wgrant: contrary to all experience so far, emotionally I still have trouble believing that something so much simpler can work. :-) [04:41] Haha. [04:41] The current one has too many arrows. [04:41] It makes me sad. [04:41] oh what now [04:42] wgrant: mwhudson is from a place where every place where you might conceivably want to cross a street has a big arrow saying which direction to look in. [04:42] jtv: i think that's only london [04:43] mwhudson: oh, London stops somewhere before the coast? I never really noticed. [04:44] wgrant: the current one has enough arrows to scare us out of cleaning up. [04:44] True. [04:44] So I think it's a great thing you're doing, but it looks like one hell of a job. [04:44] mwhudson: I'm starting to see the issue [04:45] jtv: Well, we need to get some centralised permanent history table for builder history to work. [04:45] And it's not that much more work to fix the rest up. [04:45] james_w: :( [04:45] james_w: What's going wrong? [04:46] you want to export an entry that is subordinate to another entry, so lazr.restful dutifully tries to create a link for you [04:46] "create a link"? [04:46] oh no, I've confused myself [04:46] it seems that wine was not my ally on this adventure [04:46] Heh. [04:47] :) [04:47] I'm stuck trying to work out how to export() code_import on IBranch though [04:47] as it's just Attribute currently, apparently due to circular import issues. [04:47] code_import = exported(Reference(..., schema=Interface)) [04:47] I've seen workarounds for that elsewhere [04:47] Then patch it in _schema_circular_imports.py with the rest. [04:48] ah, I was wondering if it had to be a *Choice [04:49] I don't believe so. [04:49] I think ReferenceChoices are only used for fields editable in the UI. [04:51] ok [04:51] * wgrant heads trainward. [04:54] * mwhudson stops too [06:33] spm: How much RAM does crowberry have to be able to survive two >13GiB RSS processes!? The bug says 8GiB, but that can't be right... [06:37] hi al-maisan! Say, do you know of any pagetests for the access check on build logs? [06:38] Access check? [06:38] jtv: not off the top of my head .. [06:38] page tests that verify the access to build logs I assume..? [06:39] wgrant: yes, the bit that hides build logs when private. [06:41] jtv1: The build itself is hidden, and the log is accessed by a proxying view on Archive. I don't see how the latter is relevant to your work. [06:41] wgrant: there are more places that access the log, without going through archive. [06:41] Builder page. [06:42] jtv1: All build details are hidden from the builder page when the build is private. There's no special handling for the log. [06:43] Oh, unless you mean logtail? [06:45] Ddoes anyone know off hand how to run the test suite for gina? test_gina.py is being unhelpful. [06:47] StevenK: IIRC I've just 'bin/test -vvt gina' in the past. [06:47] * wgrant tries. [06:48] That looks like it's working. [06:49] I was trying bin/test -vvt test_gina, which just did nothing [06:49] Ah. [06:49] Most of them are doctests. [06:50] So that won't catch them. [06:50] You're fixing it too like multiple published versions of the same source? [06:50] Yeah [06:51] StevenK: Which archive admins use the queue web UI? [06:51] It's been requested that I fix it to show package sets, and I'm wondering who is likely to kill me if they disagree. [06:52] wgrant: The ones that don't have shell on cocoplum, so probably just ScottK [06:53] * persia has also seen folk with shell use non-shell for trivial tasks [06:53] * wgrant too. [06:53] wgrant: that's right, the logtail... I'm moving that check into security.py. [06:53] jtv1: Ah. Ew. [06:53] (good idea) [06:54] wgrant: the two opinions seem ill-matched. :) === jtv1 is now known as jtv [06:54] wgrant: You might check with infinity also, although I haven't seen much activity from him in a while. [06:54] jtv: The current status is ew. Fixing it properly is a good idea. [06:54] ah :) [06:54] persia: infinity has been gone for a long time now. [06:54] He's still listed as archive-admin though. [06:55] Hm. that seems odd. [06:55] And a member of ubuntu-cdimage [06:55] He's just no longer a buildd-admin [06:55] wgrant: I'm making the view use View permissions for IBuildFarmJob, which I newly defined & provided with checks for private builds & branches. [06:56] jtv: It's probably untested. [06:56] I can't see any tests for it. [06:56] And it was Soyuz until recently. [06:56] wgrant: oh well, then I guess I'll write some. [06:56] (grumble grumble bloody nuisance) [06:57] persia: He is still a buildd admin, though. [06:57] Ah. I thought he stopped being something. Maybe I was misinformed. [06:57] An admin, perhaps. [06:57] perhaps. [07:19] wgrant, al-maisan: xx-private-builds.txt tests for access. [07:19] jtv: thanks for the pointer! [07:19] I think I'll write up an MP now before I go mad with it all. :-) === jelmer_ is now known as jelmer [08:01] henninge: Thanks for landing those. [08:02] wgrant: you are welcome [08:02] good morning [08:04] intellectronica, gmb: Is there anything to guarantee that AportJob rows eventually get removed? I need to know if the Librarian garbage collector should not collect blobs linked to AportJob rows, or if it should delete the corresponding AportJob and Job rows in addition to the blob. [08:07] A branch I'm about to propose for review has new config keys and a new script that needs to be run regularly. What special stuff do I need to know? [09:07] morning [09:07] Morning. [09:12] stub: There's nothing pruning them at the moment. I can easily add something that does, though. [09:13] stub: But if that table's bloating you can probably delete anything more than a day old. [09:13] gmb: If it is simple (delete any apportjob and job rows linked to a blob older than a day or three) I can do that in the librariangc [09:14] gmb: Otherwise it should go in garbo.py, and possibly need to be cherry picked too to avoid the Librarian exploding. [09:14] stub: It is. Once the Job is completed the +filebug process will use the data stored in the ApportJobs json_data field, but after that it's never used again. Librarian gc should be sufficient [09:15] ok [09:15] Morning [10:00] Morning, all. [10:09] henninge: I got a little bit further with the FSM problem on the slave side: I think things go awry because the success code becomes None somehow. [10:11] jtv: is "None" supposed to mean "success" of "failure"? [10:11] henninge: neither. AFAICT it's not supposed to happen. [10:11] 0 means success. [10:11] jtv: I know that [10:12] jtv: what I mean is that anything != 0 is treated as a failure. [10:12] So the subprocess ends without a return code? [10:12] The code treats it as a failure; it explicitly compares to 0. [10:12] yes, looks like it [10:12] Huh [10:12] Or _somehow_ twisted feeds us a None. [10:12] jtv: which state was it again? [10:13] I'll double-check. [10:13] Oh, can't check that now. IIRC it was UNPACK. [10:13] jtv: I did notice that "None" in there but thought it was a sign of failure [10:13] (and it does not happen in our code ... ;) [10:13] Maybe it was. [10:14] Nope, that's what makes it so infuriating. [10:14] An early stage that's used by two other managers? Really? [10:14] wgrant: yup [10:14] Well, I'm sure we're _causing_ it somehow, but... [10:14] Does twisted get a timeout somewhere, after which it passes None? [10:14] jtv: you always feel guilty [10:14] ;-) [10:14] Does a recipe build work OK on the same machine? [10:14] henninge: sorry. [10:15] wgrant: I haven't tried that; is there documentation on how to test that? [10:15] jtv: Not really, no. But a binary build is well-documented on HowToUseSoyuzLocally, and just as useful. [10:17] james_w: did you do any QA on your fix for https://bugs.edge.launchpad.net/soyuz/+bug/89150 ? [10:17] Bug #89150: sync-source should not assume 0 is the lowest version number possible

[10:18] wgrant: the instructions don't say anything about signing, but dput complains that the package is not signed. I've had to look this up before, but what was the option again? [10:21] jtv: Give debuild '-kKEYID'. [10:21] jtv: Normally if the changelog matches your key it won't be necessary, though. [10:23] wgrant: I didn't have a changelog of my own handy [10:25] wgrant: wait... you're saying I need to rebuild the package for this? [10:25] I thought there was a way around that... [10:26] jtv: debsign blah.changes [10:27] nope, that's not it [10:27] that still complains when I'm not in the changelog. [10:28] ahhh, -u does it. === jelmer_ is now known as jelmer [10:30] gah, unable to find mandatory field 'files' in the changes file. [10:31] jtv: Insufficiently signed. [10:32] yeah that error sucks [10:33] okay, debsign -k _source.changes [10:33] debsign: Only a .changes, .dsc or .commands file is allowed as argument! [10:33] one gets so tired... [10:34] Actually, you might be able to use a policy that allows unsigned uploads now. When I started looking it forbade PPA uploads, but I might have fixed that... [10:34] ah, I had a space after the -k [10:34] -C absolutely-anything [10:34] bigjools: ? [10:34] Yeah, absolutely-anything will work now. [10:34] it's a policy for process-upload [10:35] jtv: If you give that to process-upload.py, it should not require a sig. [10:35] wgrant: as opposed to "anything" which is not anything! [10:35] Yep. [10:35] aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah! [10:35] and just when I got my changes file signed... [10:39] jtv: I made that policy explicitly for testing [10:40] see the comment on it :) [10:40] bigjools: and very welcome it is too... I've added it on the wiki page. [10:40] * wgrant fixed it a few months ago, but then forgot. [10:40] though I'd like to rename it to "anything" and rename the existing "anything" to what it really is [10:48] wgrant: not getting the slave to do much... says it's still idle. [10:49] maybe one of my failed attempts got in the way somehow. [10:49] Or I missed a step. [10:49] But it's definitely not getting to the point where the translations fsm is breaking. [10:54] jtv: The virtualisation setting matches between the PPA and builder? [10:54] wgrant: uhhh... I'll have a look. [10:56] wgrant: ppa does not require a virtualized builder; builder is virtualized. [10:56] jtv: Flip the PPA's flag. [10:56] 'Does not require a virtualized builder' means 'Requires a non-virtualized builder' [10:57] ah [11:03] $ ./scripts/process-upload.py /var/tmp/poppy -C absolutely-anything -vvv [11:04] 2010-03-16 11:01:45 INFO creating lockfile [11:04] 2010-03-16 11:01:49 DEBUG Initialising connection. [11:04] 2010-03-16 11:01:49 DEBUG Beginning processing [11:04] 2010-03-16 11:01:49 DEBUG Checked in /var/tmp/poppy/incoming, found [] [11:04] 2010-03-16 11:01:49 DEBUG Rolling back any remaining transactions. [11:04] 2010-03-16 11:01:49 DEBUG Removing lock file: /var/lock/process-upload-absolutely-anything.lock [11:04] wgrant: ^^^ doesn't look right, does it? [11:06] jtv: You've not uploaded it? [11:07] wgrant: I dput it, and dput said it was successful. What else do I need to do? [11:08] jtv: Try uploading it again, I guess (you'll probably need to give dput '-f'). [11:08] wgrant: did that several times [11:08] Unless poppy is being stupid... [11:08] with different changes files [11:09] Are you getting any errors in the terminal in which you started poppy? [11:09] why are you using poppy? [11:09] When it works it's a trivial way to get the directory structure right. [11:09] But since it doesn't seem to be working... [11:10] wgrant: I have a lot of output mixed together... when exactly should the poppy error happen? During dput? [11:11] jtv: Generally at the end of dput. [11:11] But as bigjools says, you could work out the directory structure and avoid poppy. [11:11] what is in /var/tmp/poppy? [11:11] one item (dir+file) in failed, one (dir+file) in rejected. [11:11] I dput rather more. [11:12] poppy is not putting stuff where you think it is then [11:12] Which generally means you're getting that client accept hook failure or whatever it is. [11:12] Which should be spewing tracebacks everywhere. [11:14] maybe it's in a different shell then... I have to stop now. [11:14] jtv: just mkdir -p /var/tmp/poppy/incoming/jtv [11:14] then copy your upload there [11:14] why jtv? [11:14] it doesn't matter [11:14] anything [11:15] ah ok [11:15] and my upload is the changes file, dsc file etc? [11:15] call it I_hump_donkeys [11:15] yes [11:15] Doesn't it need an upload path? [11:15] this is a PPA upload? [11:16] then yes [11:18] I'm afraid I really have to stop typing now [11:20] wtf https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1536EA471 [11:24] jml: foundations bug [11:24] they're working on it [11:24] oh good. [11:24] something to do with assuming all views are LPViews === daniloff is now known as danilos [11:42] heh heh [11:43] Unable to obtain lock lp-66556816:///~launchpad/lp-source-dependencies/trunk/.bzr/branch/lock [11:43] held by leonardr@bazaar.launchpad.net on host crowberry [process #5035] [11:43] jml: i'm committing right now [11:43] leonardr, so I gathered :) [11:43] jml: all done [11:43] * jml parties like its 1999 [11:44] * bigjools sighs at lucid bugs [11:58] lucid bugs? [12:05] laptop suspending at battery low instead of critical [12:05] laptop not resuming from suspend 50% of the time [12:05] fsck at boot freezing [12:06] henninge: I filed bug 539499 about my FSM problem. I'll go to my office tomorrow and see how things work out on a different machine. If you have any notes, please add them! [12:06] Bug #539499: Build-farm slave FSM fails early on [12:09] jtv, henninge: I ran a template job through from the master a few days back (just as one of henninge's branches was landing), and it went through fine (except for not actually generating a template tarball, since that wasn't implemented yet) [12:09] So it's either something broken on your machine, or something very recently broken. [12:12] wgrant: so intltool was actually run on your branch? [12:13] jtv: Yes. [12:13] It printed out the template paths and everything. [12:13] wgrant: that's great news, thanks. This was the Debian-based FSM, right? [12:13] jtv: Uh, not sure. I merged the henninge branch that you had linked to on the wiki page. [12:13] * wgrant will check logs tomorrow. [12:13] But... sleep. [12:14] thanks. yes. Very glad to hear this. [12:14] * jtv really buggers off [12:14] (it worked sufficiently that I could just push a branch, run 'make sync_branches', and it would print out the template names. [12:14] Night. [12:15] cool cool cool sweet dreams [12:16] wgrant: yes, printing out template names is success. cool! [12:16] g'night === matsubara-afk is now known as matsubara === mrevell is now known as mrevell-lunch === off is now known as jamalta [13:56] salgado: ping [13:56]