[01:13] <thumper> rockstar: ping
[01:13]  * thumper does TZ math
[01:13] <rockstar> thumper, hi
[01:14] <thumper> rockstar: it's getting late for you right?
[01:14] <thumper> rockstar: bug 527450
[01:14] <mup> Bug #527450: email unsubscribe link is fragile (broken-ish) <email> <notification> <qa-needstesting> <trivial> <Launchpad Bazaar Integration:Fix Committed by rockstar> <https://launchpad.net/bugs/527450>
[01:14] <thumper> rockstar: are you able to qa this?
[01:14] <rockstar> thumper, I just got back from a bike ride.
[01:14] <rockstar> thumper, I think I can.  I have to get the imap mail thing working again, which is always a PITA.
[01:14] <thumper> rockstar: can you put qa onto your TODO list for tomorrow morning?
[01:14] <rockstar> thumper, yessir.
[01:15] <thumper> rockstar: awesome, thanks
[01:15] <rockstar> (sorry you had to remind me)
[01:15] <mwhudson> thumper, rockstar: can i beg a couple of reviews off you?
[01:15] <thumper> mwhudson: hit me
[01:15] <mwhudson> thumper: https://code.edge.launchpad.net/~mwhudson/launchpad/fewer-spurious-partial-code-imports-bug-532402/+merge/21416
[01:15] <rockstar> mwhudson, you can, but I'm upgrading to Lucid right so...
[01:15] <mwhudson> thumper: https://code.edge.launchpad.net/~mwhudson/launchpad/back-off-failing-imports-bug-413637/+merge/21411
[01:16] <mwhudson> (jml already sort of half reviewed the last one)
[01:34] <mwhudson> thumper: ta
[01:35] <mwhudson> thumper: can you approve the merge proposals too?
[01:35] <mwhudson> or i can of course...
[01:36] <Ursinha> ²²±/16
[01:38] <thumper> Ursinha: eh?
[01:40] <Ursinha> thumper: nevermind my irssi fail
[01:40] <thumper> Ursinha: you just had me confused
[01:41] <Ursinha> thumper: sorry
[01:41] <Ursinha> :)
[03:44] <wgrant> jtv: Has there been any further discussion about what to do about generalised builder histories?
[03:44] <wgrant> (in particular, has there been any discussion about making the model suck less?)
[03:44] <jtv> wgrant: hi!  apparently the thinking right now is "just implement buildbase somehow"
[03:45] <jtv> Maybe we should just start out by renaming BuildBase to BuildRecord and Build to PackageBuildRecord or something.
[03:45] <wgrant> Hmmm. That seems silly.
[03:45] <jtv> BTW you said that the builder UI also stumbles over recipe builds, right?
[03:46] <wgrant> It won't crash any more (they have a canonical URL as of a few days ago).
[03:47] <wgrant> 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] <jtv> wgrant: so the idea is to split Build into "build attempt," "binary build," and "source package build"?
[04:03] <wgrant> jtv: I'd like to store attempts, but others probably don't, so there's one without that too.
[04:04] <wgrant> (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] <jtv> Oh, that's exactly the kind of situation where I'd have expected Build to be useful as an historical record.
[04:05] <wgrant> We can't really create a new Build, I don't think.
[04:07] <wgrant> Although that might work better
[04:07] <wgrant> Hmm.
[04:07] <wgrant> Excluding UI problems, I think the Soyuz model might actually cope with having duplicate Builds.
[04:07] <jtv> Why have a BinaryPackageBuild.buildstate and a SourcePackageRecipeBuild.build_state?
[04:08] <wgrant> Because I haven't resolved the unresolved issue.
[04:08] <wgrant> And I apparently forgot to rename the attributes that I copied from the original classes.
[04:09] <wgrant> 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] <jtv> Another point is that what we are working on is not a "package" build.
[04:10] <wgrant> "we"?
[04:11] <wgrant> Do you refer to the template jobs?
[04:13] <jtv> Right.
[04:14] <wgrant> I don't see any implication in the current model or my experiments that it is.
[04:15] <jtv> Well, none of PackageBuild would be applicable to us.
[04:16] <jtv> Okay, "job" would.  :-)
[04:16] <james_w> 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] <wgrant> jtv: That's why it's not connected to any of the Translations bits.
[04:17] <jtv> wgrant: so if we wanted to keep history for the translations jobs as well, where would it fit into your model?
[04:17] <wgrant> james_w: Which collection?
[04:17] <james_w> wgrant: code-imports
[04:17] <wgrant> jtv: TTB
[04:17] <jtv> oh, I had been completely ignoring the lhs!
[04:17] <wgrant> james_w: I don't think you should export that. Code imports exist under branches, and should be created from under productserieses.
[04:17] <wgrant> I don't think exporting the root collection is useful.
[04:18] <james_w> wgrant: productserieses/distributionsourcepackage?
[04:18] <wgrant> jtv: Heh.
[04:18] <jtv> wgrant: I now see why.
[04:18] <wgrant> james_w: Hmmm.
[04:18] <jtv> wgrant: I don't see any meaningful difference between TTB and TranslationTemplatesBuildJob.
[04:18] <james_w> wgrant: what I want to achieve is to be able write a script that syncs Vcs-* with LP
[04:19] <wgrant> james_w: Expose it on IBranchTarget or whatever it is, then.
[04:19] <james_w> ok
[04:19]  * james_w changes direction
[04:19] <wgrant> jtv: TTBJ doesn't exist, does it?
[04:19] <jtv> wgrant: does too!
[04:20] <wgrant> I thought it was just Branch<->BranchJob<->Job<->BuildQueue
[04:20] <jtv> In the database, yes.
[04:20] <jtv> In terms of storage, a TTBJ is just a BranchJob.
[04:20] <jtv> But it's also a BuildFarmJob.
[04:20] <wgrant> 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] <james_w> wgrant: right
[04:21] <wgrant> jtv: OK, so the meaningful difference is probably that TTBJs die when the operation completes.
[04:21] <wgrant> And the current model has too many duplicated classes, so I want to kill it.
[04:21] <jtv> wgrant: right, so the TTB would simply be a copy of the TTBJ
[04:21] <wgrant> jtv: TTBJ ceases to exist.
[04:21] <james_w> wgrant: so, code imports should be retrieved by getting a subordinate URI of the branch they import to?
[04:22] <jtv> 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] <mwhudson> james_w: my understanding was that someone tried that and lazr.restful stabbed them
[04:22] <mwhudson> james_w: but noone's completely sure any more :-)
[04:22] <wgrant> mwhudson: '@stepto("+code-import")'?
[04:23] <wgrant> jtv: I mean, why does TTBJ need to exist if TTB does?
[04:23] <wgrant> Is there any point in it sharing the table?
[04:23] <wgrant> Same for Job itself.
[04:23] <james_w> mwhudson: I am equipped with a stab-proof vest, my naivety, and a glass of wine, I hope to prevail
[04:23] <mwhudson> wgrant: eh?
[04:23] <wgrant> mwhudson: Do you recall what the problem was?
[04:23] <mwhudson> wgrant: no
[04:23] <wgrant> It seems like one could just add @stepto("+code-import") to BranchNavigation, and it would have to work.
[04:23] <mwhudson> i don't think i ever knew
[04:24] <wgrant> I recall I brought it up in Wellington one day, and nobody knew there either :(
[04:24] <wgrant> Which is odd, since all of Code in recent memory was there.
[04:24] <mwhudson> something to do with having an entry as part of another entry rather than as part of a collection
[04:24] <mwhudson> james_w: please try, and if it fails, please explain what happens in the bug report
[04:25] <james_w> 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] <jtv> 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] <wgrant> jtv: The other Build types can never be removed.
[04:26] <mwhudson> the bug btw https://bugs.edge.launchpad.net/launchpad-code/+bug/366102
[04:26] <mup> Bug #366102: API for creating and managing code imports <api> <code-import> <package-branches> <udd> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/366102>
[04:26] <wgrant> If they succeed, they are deeply integrated into the terrible web that is the Soyuz data model.
[04:26] <wgrant> They are never removed.
[04:26] <wgrant> Oh, misread.
[04:27] <wgrant> jtv: I don't see how the futureness is different.
[04:27] <wgrant> A TTB will start to exist moments before it is queued.
[04:27] <wgrant> SPRBs and BPBs do as well.
[04:28] <jtv> wgrant: I thought that was in the same transaction that also dispatched it.
[04:28] <wgrant> jtv: No. They are created by any one of a number of processes on several different machines.
[04:28] <jtv> Does build candidate selection etc. use Build?
[04:28] <wgrant> Yes.
[04:28] <jtv> I see.  Then it's not really different.
[04:28] <wgrant> Exactly.
[04:30] <wgrant> No class in my non-current diagrams gets deleted.
[04:30] <wgrant> (except when a branch gets deleted, but mrrhrhrrhrhr)
[04:32] <wgrant> Whereas all the common classes in the old one do.
[04:32] <jtv> 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] <wgrant> I think we should probably just ban branch deletes in some circumstances.
[04:33] <wgrant> 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] <mwhudson> we have a kind of denormalized history for code imports
[04:33] <mwhudson> completely unused :/
[04:33] <wgrant> Heh.
[04:34] <jtv> 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] <wgrant> jtv: SPR references SPRB.
[04:35] <wgrant> Deleting an SPRB removes all accountability information for any SPR built from it.
[04:35] <jtv> wgrant: and the reference from SPR to the branch does not go through the recipe?
[04:35] <jtv> Because if it does, well, cascading nulls solve it very nicely.  :)
[04:36] <wgrant> It does. But then you end up with a broken recipe.
[04:36] <mwhudson> grar
[04:37] <wgrant> Hm?
[04:37] <mwhudson> i revoked ec2 lands oauth token and now it's broken
[04:37] <mwhudson> do i have to clear some cache somewhere?
[04:37] <wgrant> Hah.
[04:37] <wgrant> Try removing the launchpadlib cache, i guess...
[04:38]  * mwhudson finds /home/mwh/.launchpadlib/api.edge.launchpad.net/credentials/launchpad-branch-lander
[04:38] <wgrant> jtv: Anyway, any more impressions of the model?
[04:39] <mwhudson> and a few other similarly named files
[04:40] <jtv> wgrant: contrary to all experience so far, emotionally I still have trouble believing that something so much simpler can work.  :-)
[04:41] <wgrant> Haha.
[04:41] <wgrant> The current one has too many arrows.
[04:41] <wgrant> It makes me sad.
[04:41] <mwhudson> oh what now
[04:42] <jtv> 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] <mwhudson> jtv: i think that's only london
[04:43] <jtv> mwhudson: oh, London stops somewhere before the coast?  I never really noticed.
[04:44] <jtv> wgrant: the current one has enough arrows to scare us out of cleaning up.
[04:44] <wgrant> True.
[04:44] <jtv> So I think it's a great thing you're doing, but it looks like one hell of a job.
[04:44] <james_w> mwhudson: I'm starting to see the issue
[04:45] <wgrant> jtv: Well, we need to get some centralised permanent history table for builder history to work.
[04:45] <wgrant> And it's not that much more work to fix the rest up.
[04:45] <mwhudson> james_w: :(
[04:45] <wgrant> james_w: What's going wrong?
[04:46] <james_w> 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] <wgrant> "create a link"?
[04:46] <james_w> oh no, I've confused myself
[04:46] <james_w> it seems that wine was not my ally on this adventure
[04:46] <wgrant> Heh.
[04:47] <mwhudson> :)
[04:47] <james_w> I'm stuck trying to work out how to export() code_import on IBranch though
[04:47] <james_w> as it's just Attribute currently, apparently due to circular import issues.
[04:47] <wgrant> code_import = exported(Reference(..., schema=Interface))
[04:47] <james_w> I've seen workarounds for that elsewhere
[04:47] <wgrant> Then patch it in _schema_circular_imports.py with the rest.
[04:48] <james_w> ah, I was wondering if it had to be a *Choice
[04:49] <wgrant> I don't believe so.
[04:49] <wgrant> I think ReferenceChoices are only used for fields editable in the UI.
[04:51] <james_w> ok
[04:51]  * wgrant heads trainward.
[04:54]  * mwhudson stops too
[06:33] <wgrant> 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] <jtv1> hi al-maisan!  Say, do you know of any pagetests for the access check on build logs?
[06:38] <wgrant> Access check?
[06:38] <al-maisan> jtv: not off the top of my head ..
[06:38] <al-maisan> page tests that verify the access to build logs I assume..?
[06:39] <jtv1> wgrant: yes, the bit that hides build logs when private.
[06:41] <wgrant> 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] <jtv1> wgrant: there are more places that access the log, without going through archive.
[06:41] <jtv1> Builder page.
[06:42] <wgrant> 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] <wgrant> Oh, unless you mean logtail?
[06:45] <StevenK> Ddoes anyone know off hand how to run the test suite for gina? test_gina.py is being unhelpful.
[06:47] <wgrant> StevenK: IIRC I've just 'bin/test -vvt gina' in the past.
[06:47]  * wgrant tries.
[06:48] <wgrant> That looks like it's working.
[06:49] <StevenK> I was trying bin/test -vvt test_gina, which just did nothing
[06:49] <wgrant> Ah.
[06:49] <wgrant> Most of them are doctests.
[06:50] <wgrant> So that won't catch them.
[06:50] <wgrant> You're fixing it too like multiple published versions of the same source?
[06:50] <StevenK> Yeah
[06:51] <wgrant> StevenK: Which archive admins use the queue web UI?
[06:51] <wgrant> 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] <StevenK> 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] <jtv1> wgrant: that's right, the logtail...  I'm moving that check into security.py.
[06:53] <wgrant> jtv1: Ah. Ew.
[06:53] <wgrant> (good idea)
[06:54] <jtv1> wgrant: the two opinions seem ill-matched.  :)
[06:54] <persia> wgrant: You might check with infinity also, although I haven't seen much activity from him in a while.
[06:54] <wgrant> jtv: The current status is ew. Fixing it properly is a good idea.
[06:54] <jtv> ah :)
[06:54] <wgrant> persia: infinity has been gone for a long time now.
[06:54] <persia> He's still listed as archive-admin though.
[06:55] <wgrant> Hm. that seems odd.
[06:55] <StevenK> And a member of ubuntu-cdimage
[06:55] <persia> He's just no longer a buildd-admin
[06:55] <jtv> wgrant: I'm making the view use View permissions for IBuildFarmJob, which I newly defined & provided with checks for private builds & branches.
[06:56] <wgrant> jtv: It's probably untested.
[06:56] <wgrant> I can't see any tests for it.
[06:56] <wgrant> And it was Soyuz until recently.
[06:56] <jtv> wgrant: oh well, then I guess I'll write some.
[06:56] <jtv> (grumble grumble bloody nuisance)
[06:57] <wgrant> persia: He is still a buildd admin, though.
[06:57] <persia> Ah.  I thought he stopped being something.  Maybe I was misinformed.
[06:57] <wgrant> An admin, perhaps.
[06:57] <persia> perhaps.
[07:19] <jtv> wgrant, al-maisan: xx-private-builds.txt tests for access.
[07:19] <al-maisan> jtv: thanks for the pointer!
[07:19] <jtv> I think I'll write up an MP now before I go mad with it all.  :-)
[08:01] <wgrant> henninge: Thanks for landing those.
[08:02] <henninge> wgrant: you are welcome
[08:02] <adeuring> good morning
[08:04] <stub> 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] <wgrant> 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] <bigjools> morning
[09:07] <wgrant> Morning.
[09:12] <gmb> stub: There's nothing pruning them at the moment. I can easily add something that does, though.
[09:13] <gmb> stub: But if that table's bloating you can probably delete anything more than a day old.
[09:13] <stub> 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] <stub> gmb: Otherwise it should go in garbo.py, and possibly need to be cherry picked too to avoid the Librarian exploding.
[09:14] <gmb> 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] <stub> ok
[09:15] <mrevell> Morning
[10:00] <deryck> Morning, all.
[10:09] <jtv> 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] <henninge> jtv: is "None" supposed to mean "success" of "failure"?
[10:11] <jtv> henninge: neither.  AFAICT it's not supposed to happen.
[10:11] <jtv> 0 means success.
[10:11] <henninge> jtv: I know that
[10:12] <henninge> jtv: what I mean is that anything != 0 is treated as a failure.
[10:12] <wgrant> So the subprocess ends without a return code?
[10:12] <jtv> The code treats it as a failure; it explicitly compares to 0.
[10:12] <henninge> yes, looks like it
[10:12] <wgrant> Huh
[10:12] <jtv> Or _somehow_ twisted feeds us a None.
[10:12] <henninge> jtv: which state was it again?
[10:13] <jtv> I'll double-check.
[10:13] <jtv> Oh, can't check that now.  IIRC it was UNPACK.
[10:13] <henninge> jtv: I did notice that "None" in there but thought it was a sign of failure
[10:13] <henninge> (and it does not happen in our code ... ;)
[10:13] <jtv> Maybe it was.
[10:14] <jtv> Nope, that's what makes it so infuriating.
[10:14] <wgrant> An early stage that's used by two other managers? Really?
[10:14] <henninge> wgrant: yup
[10:14] <jtv> Well, I'm sure we're _causing_ it somehow, but...
[10:14] <jtv> Does twisted get a timeout somewhere, after which it passes None?
[10:14] <henninge> jtv: you always feel guilty
[10:14] <henninge> ;-)
[10:14] <wgrant> Does a recipe build work OK on the same machine?
[10:14] <jtv> henninge: sorry.
[10:15] <jtv> wgrant: I haven't tried that; is there documentation on how to test that?
[10:15] <wgrant> jtv: Not really, no. But a binary build is well-documented on HowToUseSoyuzLocally, and just as useful.
[10:17] <bigjools> james_w: did you do any QA on your fix for https://bugs.edge.launchpad.net/soyuz/+bug/89150 ?
[10:17] <mup> Bug #89150: sync-source should not assume 0 is the lowest version number possible <qa-needstesting> <soyuz-ftpmaster-tools> <Soyuz:Fix Committed by james-w> <https://launchpad.net/bugs/89150>
[10:18] <jtv> 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] <wgrant> jtv: Give debuild '-kKEYID'.
[10:21] <wgrant> jtv: Normally if the changelog matches your key it won't be necessary, though.
[10:23] <jtv> wgrant: I didn't have a changelog of my own handy
[10:25] <jtv> wgrant: wait... you're saying I need to rebuild the package for this?
[10:25] <jtv> I thought there was a way around that...
[10:26] <wgrant> jtv: debsign blah.changes
[10:27] <jtv> nope, that's not it
[10:27] <jtv> that still complains when I'm not in the changelog.
[10:28] <jtv> ahhh, -u does it.
[10:30] <jtv> gah, unable to find mandatory field 'files' in the changes file.
[10:31] <wgrant> jtv: Insufficiently signed.
[10:32] <bigjools> yeah that error sucks
[10:33] <jtv> okay, debsign -k<me@example.com> <foo>_source.changes
[10:33] <jtv> debsign: Only a .changes, .dsc or .commands file is allowed as argument!
[10:33] <jtv> one gets so tired...
[10:34] <wgrant> 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] <jtv> ah, I had a space after the -k
[10:34] <bigjools> -C absolutely-anything
[10:34] <jtv> bigjools: ?
[10:34] <wgrant> Yeah, absolutely-anything will work now.
[10:34] <bigjools> it's a policy for process-upload
[10:35] <wgrant> jtv: If you give that to process-upload.py, it should not require a sig.
[10:35] <bigjools> wgrant: as opposed to "anything" which is not anything!
[10:35] <wgrant> Yep.
[10:35] <jtv> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah!
[10:35] <jtv> and just when I got my changes file signed...
[10:39] <bigjools> jtv: I made that policy explicitly for testing
[10:40] <bigjools> see the comment on it :)
[10:40] <jtv> 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] <bigjools> though I'd like to rename it to "anything" and rename the existing "anything" to what it really is
[10:48] <jtv> wgrant: not getting the slave to do much...  says it's still idle.
[10:49] <jtv> maybe one of my failed attempts got in the way somehow.
[10:49] <jtv> Or I missed a step.
[10:49] <jtv> But it's definitely not getting to the point where the translations fsm is breaking.
[10:54] <wgrant> jtv: The virtualisation setting matches between the PPA and builder?
[10:54] <jtv> wgrant: uhhh...  I'll have a look.
[10:56] <jtv> wgrant: ppa does not require a virtualized builder; builder is virtualized.
[10:56] <wgrant> jtv: Flip the PPA's flag.
[10:56] <wgrant> 'Does not require a virtualized builder' means 'Requires a non-virtualized builder'
[10:57] <jtv> ah
[11:03] <jtv> $ ./scripts/process-upload.py /var/tmp/poppy -C absolutely-anything -vvv
[11:04] <jtv> 2010-03-16 11:01:45 INFO    creating lockfile
[11:04] <jtv> 2010-03-16 11:01:49 DEBUG   Initialising connection.
[11:04] <jtv> 2010-03-16 11:01:49 DEBUG   Beginning processing
[11:04] <jtv> 2010-03-16 11:01:49 DEBUG   Checked in /var/tmp/poppy/incoming, found []
[11:04] <jtv> 2010-03-16 11:01:49 DEBUG   Rolling back any remaining transactions.
[11:04] <jtv> 2010-03-16 11:01:49 DEBUG   Removing lock file: /var/lock/process-upload-absolutely-anything.lock
[11:04] <jtv> wgrant: ^^^ doesn't look right, does it?
[11:06] <wgrant> jtv: You've not uploaded it?
[11:07] <jtv> wgrant: I dput it, and dput said it was successful.  What else do I need to do?
[11:08] <wgrant> jtv: Try uploading it again, I guess (you'll probably need to give dput '-f').
[11:08] <jtv> wgrant: did that several times
[11:08] <wgrant> Unless poppy is being stupid...
[11:08] <jtv> with different changes files
[11:09] <wgrant> Are you getting any errors in the terminal in which you started poppy?
[11:09] <bigjools> why are you using poppy?
[11:09] <wgrant> When it works it's a trivial way to get the directory structure right.
[11:09] <wgrant> But since it doesn't seem to be working...
[11:10] <jtv> wgrant: I have a lot of output mixed together... when exactly should the poppy error happen?  During dput?
[11:11] <wgrant> jtv: Generally at the end of dput.
[11:11] <wgrant> But as bigjools says, you could work out the directory structure and avoid poppy.
[11:11] <bigjools> what is in /var/tmp/poppy?
[11:11] <jtv> one item (dir+file) in failed, one (dir+file) in rejected.
[11:11] <jtv> I dput rather more.
[11:12] <bigjools> poppy is not putting stuff where you think it is then
[11:12] <wgrant> Which generally means you're getting that client accept hook failure or whatever it is.
[11:12] <wgrant> Which should be spewing tracebacks everywhere.
[11:14] <jtv> maybe it's in a different shell then... I have to stop now.
[11:14] <bigjools> jtv: just mkdir -p /var/tmp/poppy/incoming/jtv
[11:14] <bigjools> then copy your upload there
[11:14] <jtv> why jtv?
[11:14] <bigjools> it doesn't matter
[11:14] <bigjools> anything
[11:15] <jtv> ah ok
[11:15] <jtv> and my upload is the changes file, dsc file etc?
[11:15] <bigjools> call it I_hump_donkeys
[11:15] <bigjools> yes
[11:15] <wgrant> Doesn't it need an upload path?
[11:15] <bigjools> this is a PPA upload?
[11:16] <bigjools> then yes
[11:18] <jtv> I'm afraid I really have to stop typing now
[11:20] <jml> wtf https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1536EA471
[11:24] <bigjools> jml: foundations bug
[11:24] <bigjools> they're working on it
[11:24] <jml> oh good.
[11:24] <bigjools> something to do with assuming all views are LPViews
[11:42] <jml> heh heh
[11:43] <jml> Unable to obtain lock lp-66556816:///~launchpad/lp-source-dependencies/trunk/.bzr/branch/lock
[11:43] <jml> held by leonardr@bazaar.launchpad.net on host crowberry [process #5035]
[11:43] <leonardr> jml: i'm committing right now
[11:43] <jml> leonardr, so I gathered :)
[11:43] <leonardr> jml: all done
[11:43]  * jml parties like its 1999
[11:44]  * bigjools sighs at lucid bugs
[11:58] <maxb> lucid bugs?
[12:05] <bigjools> laptop suspending at battery low instead of critical
[12:05] <bigjools> laptop not resuming from suspend 50% of the time
[12:05] <bigjools> fsck at boot freezing
[12:06] <jtv> 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] <mup> Bug #539499: Build-farm slave FSM fails early on <buildfarm> <Launchpad Translations:New> <https://launchpad.net/bugs/539499>
[12:09] <wgrant> 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] <wgrant> So it's either something broken on your machine, or something very recently broken.
[12:12] <jtv> wgrant: so intltool was actually run on your branch?
[12:13] <wgrant> jtv: Yes.
[12:13] <wgrant> It printed out the template paths and everything.
[12:13] <jtv> wgrant: that's great news, thanks.  This was the Debian-based FSM, right?
[12:13] <wgrant> 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] <wgrant> But... sleep.
[12:14] <jtv> thanks.  yes.  Very glad to hear this.
[12:14]  * jtv really buggers off
[12:14] <wgrant> (it worked sufficiently that I could just push a branch, run 'make sync_branches', and it would print out the template names.
[12:14] <wgrant> Night.
[12:15] <jtv> cool cool cool sweet dreams
[12:16] <henninge> wgrant: yes, printing out template names is success. cool!
[12:16] <henninge> g'night
[13:56] <sinzui> salgado: ping
[13:56] <salgado> hi sinzui
[13:58] <sinzui> salgado: I am seeing several questions about how to change launchpad passwords. I think I should update the FAQs about this. Maybe you are planning to update the user profile page to explain that accounts/emails/passwords are managed at login.ubuntu.com?
[13:59] <salgado> sinzui, I didn't have plans to do it, but I could do so.  also, it's only the password that is managed by login.lp.net; email addresses are still managed by LP
[14:00] <sinzui> understood
[14:01] <sinzui> salgado: Can we do something as simple as a sentence:
[14:01] <sinzui> "Manage your Ubuntu account and password > login.launchpad.net"
[14:02] <salgado> sinzui, I suppose so, but I think we should s/Ubuntu/Login Service
[14:03] <sinzui> I think that will lead to confusion. Changing my Launchpad password is changing my Ubuntu password isn't it?
[14:05] <james_w> bigjools: how would I QA sync-source.py?
[14:05] <james_w> bigjools: or is it on production?
[14:06] <salgado> sinzui, login.u.c and ubuntu accounts are not used/mentioned when logging into LP, but I'm not sure what's the plan on the SplitIt front -- can you check with flacoste?
[14:06] <sinzui> I will
[14:10] <flacoste> salgado, sinzui: they should be mentioned since they are the same thing
[14:11] <flacoste> a Launchpad login service account is really a Ubuntu account
[14:12] <sinzui> flacoste: I was thinking to using a sentence on user +edit sending the user to l.l.n. We want to update the header/footer of l.l.n to state the service is provided by l.u.c
[14:12] <flacoste> sinzui: right, can you file a bug about this on the ISD project?
[14:13] <sinzui> I will
[14:19] <bigjools> james_w: I can run it on dogfood, I was just wondering if you had a test case or had already tested it
[14:20] <james_w> I don't know one offhand, and I haven't tested it
[14:20] <james_w> let me see if I can find one
[14:29] <james_w> bigjools: I can't find anything waiting to be synced from Debian that has an appropriate version number
[14:31] <bigjools> james_w: :(
[14:41] <kfogel> vila: so I think I finally have it working.  What's weird is I successfully pushed a commit to a branch (up to a server using the kind of authn we were talking about), and on the server side I can't figure out where the actual commit data lives.  See http://paste.ubuntu.com/396199/ -- just out of academic curiousity, what file under .bzr has the commit?  I created a file named "fish.txt" with the text "Hello, world!", and it's hard to see, even with
[14:41] <kfogel> compression, where that data is.
[14:41] <kfogel> vila: mind you, it *is* working.  If I branch that branch again, the data is there.
[14:42] <vila> kfogel: that's because there is no working tree here, try 'bzr co .'
[14:42] <vila> kfogel: or 'bzr cat fish.txt'
[14:43] <kfogel> vila: yeah, no working tree, but the data has to be *somewhere* in there.
[14:43] <kfogel> vila: I understand the upstream doesn't have a working tree, but it obviously is remembering this data somewhere.
[14:43] <vila> kfogel: what does 'bzr info -v' says ? maybe a shared repo up
[14:43] <kfogel> vila: AAAAAAAAAAAAAAAAAAAH
[14:43] <kfogel> vila: that's right, I did create a shared repo upstream
[14:43] <kfogel> vila: thanks, that's it
[15:56] <james_w> anybody recognise "RuntimeError: Property used in an unknown class" ?
[15:56] <james_w> I'm just trying to use the factory
[16:14] <james_w> an, using a project in place of a product
[16:36] <jml> james_w, more context please
[17:53] <james_w> jml: if you pass product=IProject to a factory method you get a cryptic error message
[18:28] <mrevell> nytol
[18:39] <mwhudson> good morning
[18:51] <james_w> morning mwhudson
[19:01] <jml> mwhudson, good morning
[19:01] <jml> I've got buildout building subunit from the tarball and installing it in the parts/ directory
[19:01] <jml> but I'm not sure how to get it into the PYTHONPATH
[19:04] <jml> gary-lunch, when you're back, I'd appreciate some advice
[19:17] <james_w> mwhudson: would you like to help me get https://code.edge.launchpad.net/~james-w/launchpad/export-code-import/+merge/21472 finished?
[19:17] <mwhudson> james_w: probably
[19:17]  * mwhudson looks
[19:17] <mwhudson> (actually i kinda want to go back to bed already, but struggling on...)
[19:18] <mwhudson> james_w: "This exports ICodeReview." ?
[19:18] <james_w> ach
[19:18] <maxb> salgado_: Uploading to the launchpad PPA with a Debian-lookalike version isn't optimal
[19:18] <james_w> fixed
[19:19] <salgado> maxb, you mean the -2 bit?
[19:20] <maxb> yes
[19:20] <maxb> Preferably the name or version of every package would contain 'launchpad' so that people can easily identify them as non-distro packages
[19:20] <salgado> ah, right
[19:20] <mwhudson> james_w: i don't think ICodeImport['owner'] is used anywere at all
[19:21] <gary_poster> jml: yo
[19:21] <gary_poster> jml: extra-paths might be what you are looking for
[19:21] <gary_poster> see how mailman is done?
[19:21] <salgado> maxb, I'll upload another one and delete the -2 one
[19:21] <mwhudson> i'm not even sure registrant is
[19:22] <james_w> mwhudson: yeah, I was a bit confused between registrant, owner and assignee
[19:22] <james_w> you mean I should export the latter instead?
[19:22] <maxb> salgado: So, given its effectively a backport from lucid, it should be named something like 0.2.0-1~BLAH
[19:22] <mwhudson> james_w: all a legacy of over design
[19:23] <gary_poster> jml: extra-paths = ${buildout:directory}/lib/mailman is what we have now.  You would add a newline and then an indented value for the other directory
[19:23] <maxb> salgado: For example, look at what I did with the python-imaging backports in the LP PPA
[19:24] <maxb> But really, the main problem with 0.2.0-2 is that's what the next upload to Debian itself will be! :-)
[19:24] <james_w> mwhudson: one thing that I was unsure about is the information that seems to be duplicated with ICodeImport.branch, e.g. product
[19:24] <james_w> especially since I would like to have code imports for package branches as well as product branches
[19:25] <mwhudson> um
[19:25] <mwhudson> that looks screwy
[19:25] <mwhudson> i wonder if _that's_ used anywhere
[19:25] <james_w> series I can kind-of understand, as that's not an attribute of branch
[19:25]  * mwhudson is tempted to delete a few things from ICodeImport and run the tests...
[19:25] <salgado> maxb, heh, good point.  thanks for the heads up; I'll re-upload with proper versions (following the pattern used in python-imaging)
[19:26] <maxb> thanks
[19:26] <mwhudson> james_w: i think you shouldn't export registrant, owner, assignee, product, series
[19:28] <mwhudson> james_w: actually, registrant might be worth exporting
[19:28] <james_w> deleted the export of owner, so now none of those are exported
[19:28] <mwhudson> ok
[19:28] <mwhudson> easier to add than remove an export i guess :-)
[19:28] <james_w> it tends not to be exported elsewhere
[19:29] <mwhudson> james_w: so when you say "help you finish", what does that mean?
[19:30] <james_w> review if that is all it takes
[19:30] <james_w> I expected there to be several more things involved though
[19:30] <mwhudson> it looks like a start
[19:30] <mwhudson> i'm not super familiar with api stuff
[19:31] <mwhudson> james_w: have you tried accessing code imports on launchpad.dev ?
[19:31] <james_w> adding exported() around things and testing that they are in the representation is easy
[19:31] <james_w> it' the traversal stuff that I wasn't sure about
[19:31] <mwhudson> with launchpadlib
[19:31] <james_w> I'll try that now
[19:32] <mwhudson> james_w: well, webservice.get() in the page test is testing the traversal stuff
[19:33] <mwhudson> i presume $branch/+code-import will still 404 in the webapp as there are no pages registered
[19:35] <james_w> mwhudson: well, there's working and then the "correct" way to do it :-)
[19:36] <mwhudson> james_w: it looks ok to me
[19:36] <james_w> thankfully there was a wiki page for that, so I took enough from there to get the tests to pass
[19:36] <mwhudson> i wonder why the first people to try this couldn't get it to work
[19:36] <james_w> the rest seemed to be presenting it in the webapp as you say, but we don't want that
[19:36] <mwhudson> maybe lazr.restful bugs that are now fixed
[19:36] <james_w> mwhudson: any idea who it was? We should get their review if so, as they may spot something I missed
[19:37] <mwhudson> james_w: no, maybe i'm in fact making up that this problem was encountered :/
[19:37] <mwhudson> if it works it works, there is limited potential for subtle traps here
[19:37] <james_w> right
 the rest seemed to be presenting it in the webapp as you say, but we don't want that
[19:38] <mwhudson> james_w: i don't understand what you mean here
[19:39] <james_w> the rest of the wiki page seemed to be about linking up pages to interfaces so that the webapp would render them
[19:39] <mwhudson> ah ok
[19:40] <mwhudson> i wasn't completely sure that 'rest' in what you said was the english word :)
[19:40] <james_w> heh
[19:49] <james_w> mwhudson: yep, it all shows up in +apidoc, +code-import 404s in the webapp, and lplib can query the code import in sampledata
[19:50] <james_w> the only issue is that most attributes are writeable, I assume we don't want that
[19:53] <mwhudson> oh right
[19:59] <james_w> if I just mark everything as read-only will that break other code?
[20:02] <mwhudson> james_w: i think it might break the +new form
[20:02] <mwhudson> but that's fixable
[20:03] <mwhudson> hm, no it shouldn't, should it?
[20:21] <wgrant> james_w: So it all pretty much just worked?
[20:21] <james_w> wgrant: seems like it
[20:22] <james_w> once I worked out how to do canonical_url for ICodeImport and then traversal
[20:39] <mwhudson> james_w: trying to set attributes through launchpadlib fails in a pretty strange way
[20:39] <mwhudson> they should be read_only for now
[20:40] <mwhudson> and any fallout that causes should just be fixed
[20:41] <james_w> mwhudson: changed and ec2 test running to discover any fallout
[20:41] <mwhudson> james_w: awesome
[20:42] <mwhudson> that means i can ignore the issue for a few hours :-)
[20:42] <james_w> you and me both
[21:03] <maxb> Gaaah setuptools distribute pkg_resources buildout namespace-packages ARGH
[21:03] <maxb> Clean bootstrap on lucid appears broken
[23:34]  * thumper is back around
[23:41]  * mwhudson lunches