[02:40] <StevenK> Failed tests:      1
[02:40] <StevenK> Bwahaha
[02:40] <StevenK> And that's only because I intentionally broke the interface
[02:41] <StevenK> wgrant: Those Connection is closed errors were caused by my cleanup to the BranchCollection.store property
[02:45] <wgrant> Ah
[02:46] <StevenK> I'm not sure why, but I've reverted them and they'll stay that way
[02:49] <wgrant> StevenK: https://launchpad.net/~tonyyarusso/+archive/ppa/+packages?field.name_filter=&field.status_filter=published&field.series_filter=edgy
[02:49] <wgrant> Spot any problems there?
[02:55] <wgrant> Only 3 PPAs, one copy archive, and the Ubuntu primary archive seem to be afflicted
[02:55] <StevenK> Hahaha
[02:58] <wgrant> Poor Dapper
[02:59] <wgrant> Some 38000 of its files are missing
[03:00] <StevenK> Didn't we inject the missing ones?
[03:00] <StevenK> I can recall a script
[03:04] <wgrant> I don't think we ever ran it
[03:04] <wgrant> We ended up hacking p-d-r instead
[03:04] <wgrant> We ran into this when we obsoleted dapper
[03:04] <StevenK> Yeah
[03:04] <wgrant> And it failed to remove the files because they didn't exist in the DB any more
[03:04] <StevenK> Right
[03:04] <StevenK> So they should be gone anyway,
[03:05] <wgrant> Yeah
[03:05] <wgrant> But there are 9 binaries that built in dapper in the primary archive, are still published somewhere else, and are deleted
[03:06] <StevenK> Now I remember why I don't like hearing about archive consistency
[03:06] <StevenK> It makes me want to curl up under my desk and cry
[03:07] <wgrant> Apart from the copy archive the numbers seem more manageable, so I might track down all PENDING/PUBLISHED pubs with missing files and get them revived.
[03:08] <StevenK> Ignoring the 38,000 for Dapper?
[03:08] <StevenK> Not sure what state Dapper's publications are in
[03:08] <wgrant> Those are obsolete
[03:08] <StevenK> Aside from 'disarray'
[03:08] <wgrant> They should technically still exist, but they don't really matter and would have be recovered from old-releases
[03:09] <wgrant> The only things that will break are those that are still publishe
[03:09] <wgrant> d
[03:09] <StevenK> So the new GC can remove them again?
[03:09] <wgrant> Well, not yet removed
[03:09] <wgrant> No
[03:09] <wgrant> Anything that is obsolete is meant to stay forever, by current policy
[03:09] <StevenK> Sure
[03:09] <wgrant> We only remove *pre-release* binaries.
[03:10] <StevenK> Oh, 38,000 of Dapper's released binaries are missing
[03:10] <StevenK> Handy
[03:10] <wgrant> Yes
[03:10] <wgrant> Only 9 of those are still published somewhere
[03:10] <StevenK> See previous comment about under my desk and sobbing
[03:12] <wgrant> Ah, no, 4 PPAs
[03:46] <StevenK>     raise ValidationFailed("directories differ")
[03:46] <StevenK> ValidationFailed: directories differ
[03:46] <StevenK> wgrant: ^ Seen that before?
[03:47] <wgrant> StevenK: I have no context
[03:48] <StevenK> wgrant: http://pastebin.ubuntu.com/1638432/
[03:50] <wgrant> StevenK: cscvs, run away
[03:51] <StevenK> Haha
[03:51] <wgrant> More than likely unrelated to your changes
[03:51] <StevenK> I'll continue to ignore it
[03:51] <StevenK> Fighting with horrible doctest changes
[03:51] <StevenK>  12 files changed, 212 insertions(+), 618 deletions(-)
[03:56] <StevenK> Oh, ugh
[03:56] <StevenK> These tests rely on searching on branch.url being sane
[03:56] <StevenK> Which I broke because branch.url is only used for mirrored branches and horrible
[03:57] <StevenK> Haha
[03:57] <StevenK> I mention mirrored branches and mwhudson joins
[04:29] <wgrant> Yay, electricity.
[04:29] <StevenK> Haha
[04:29] <StevenK> OH
[04:32] <wgrant> StevenK: How's it going?
[04:34] <StevenK> One failure
[04:34] <StevenK> I broke HostedBranchRestrictedOnOwnerVocabulary, and I was contemplating deleting it, but productseries requires it
[04:36] <StevenK> (IProductSeries.translations_branch, that is)
[04:49] <wgrant> Hmm
[04:49] <wgrant> 66 BPRs are affected
[04:49] <wgrant> 6 of those are from intrepid, so we'll need to restore dists/intrepid temporarily
[04:51] <StevenK> Hmm, I think my query is broken
[04:52] <wgrant> StevenK: Howso?
[04:52] <StevenK> Because the test breaks :-)
[04:52] <StevenK> Pretty good indication
[04:53] <wgrant> Heh
[04:53] <StevenK>     + ~a-branching-user/product-two/hosted
[04:53] <StevenK>       ~a-branching-user/product-two/hosted
[04:53] <StevenK>       ~a-team/product-two/another_hosted
[04:53] <StevenK> That's my slightly fixed query, but it's still broken
[04:58] <StevenK> wgrant: http://pastebin.ubuntu.com/1638511/
[04:59] <wgrant> StevenK: That'll return the branch twice if the user owns it directlyt
[04:59] <StevenK> Which is exactly what I'm seeing, yeah
[05:00] <wgrant> And it will also not do what you want if the user has no TPs (though that never happens, due to the self participation)
[05:02] <StevenK> Right, so the Branch.ownerID == self.user.id was not needed
[05:14] <StevenK> wgrant: So I think this crap actually works, shall I push it up?
[05:15] <wgrant> StevenK: Might as well
[05:17] <StevenK> My smoke test revealed another failure
[05:44] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/new-branch-search/+merge/147840
[05:44] <StevenK> But it can wait until tomorrow if you want to do necromancy instead
[05:45] <wgrant> StevenK: waaaat
[05:45] <wgrant> StevenK: What's this def search_branches stuff?
[05:46] <wgrant> What was wrong with having it on BranchCollection with every other branch search method?
[05:48] <StevenK> wgrant: The BranchCollection stuff makes my brain drip out of my ears
[05:48] <StevenK> IAllBranches and related friends
[05:49] <wgrant> That doesn't mean you should just create a separate parallel and broken in slightly different ways implementation :)
[05:49] <StevenK> How is search_branches broken?
[05:49] <wgrant> It's code
[05:49] <wgrant> => it has bugs
[05:49] <wgrant> BranchCollection is well-tested
[05:49] <wgrant> search_branches is not
[05:50] <wgrant> And there's no reason for divergence AFAICS
[05:52] <StevenK> wgrant: Ah, but you did say I should ignore the current stuff and re-implement
[05:52] <wgrant> The current *algorithm* :)
[05:53] <wgrant> The problem is the algorithm, not BranchCollection
[05:53] <StevenK> Right, and I wasn't sure I could even delete IBranchCollection.search() until two hours ago
[05:53] <StevenK> Which meant I was in a position to have both
[05:53] <StevenK> If I needed
[08:59] <adeuring> good morning
[12:24] <cjwatson> Hm.  I may need to fix bug 604427 before I can test my bpph-phase branch properly
[12:25] <cjwatson> (Because I need to change overrides for ddebs, and I can't do that right now ...)
[12:33] <wgrant> cjwatson: Why can't you?
[12:35] <cjwatson> changeOverride refuses because the archive would change
[12:36] <cjwatson> i.e. "OverrideError: Overriding component to 'universe' failed because it would require a new archive."
[12:36] <wgrant> Ah
[12:36] <wgrant> That's probably just a missing bit in changeOverride
[12:36] <cjwatson> Which is arguably a bug for ddebs
[12:37] <wgrant> If it's a ddeb it should go through .debug_archive
[12:37] <wgrant> As it does in IIRC publishBinaries
[12:37] <wgrant> Two lines missing :)
[12:37] <cjwatson> Ah, yeah, OK
[12:37] <wgrant> I may be way off, it's been a while
[12:37] <cjwatson> Separate branch or should I roll it in?
[12:37]  * wgrant checks the code
[12:37] <cjwatson> Thing is, I suspect phased-update-percentage will leave around a lot of ddebs because there's no really convenient way to override them
[12:38] <wgrant> Well
[12:38] <wgrant> That's not a problem
[12:38] <wgrant> Because there are no ddeb publications for the primary archive today
[12:38] <cjwatson> Well, indeed, but when there are it's a bit of a timebomb
[12:38] <wgrant> There are about 5 other bugs that are similarly bad and filed about that.
[12:38] <wgrant> I'd put the change in the same branch
[12:38] <cjwatson> But I guess we need to fix basically all of https://bugs.launchpad.net/launchpad/+bugs?field.searchtext=ddeb before we can enable ddebs in primary
[12:38] <wgrant> Exactly.
[12:39] <cjwatson> OK, I'll amend bpph-phase accordingly, thanks
[23:50] <wgrant> StevenK: Have you tried these searches?
[23:50] <StevenK> wgrant: Which searches?
[23:51] <StevenK> Shall I cowboy this onto DF?
[23:51] <wgrant> How effective is the new search algorithm?
[23:51] <wgrant> You could.
[23:52] <StevenK> wgrant: Pending merge from you on DF, I'm wary of conflicts.
[23:52] <wgrant> I wonder if the "term.startswith('~') => look up by exact unique_name match" rule should be replaced with "'/' in term => look up by unique_name prefix match"
[23:52] <wgrant> And the name match could perhaps restrict to the relevant pillar
[23:52] <wgrant> StevenK: You can revert that
[23:53] <StevenK> Not sure how to revert just that pending merge
[23:53] <wgrant> No need
[23:53] <wgrant> bzr revert
[23:53] <StevenK> Right
[23:53] <wgrant> Revert the whole thing
[23:53] <wgrant> If you want JS then unshelve and update the revno in that diff
[23:53] <wgrant> So, the idea behind my suggestions is that normally you want to search in the relevant context
[23:53] <StevenK> Probably do, but updating DF first
[23:54] <wgrant> But you need to be able to override
[23:54] <wgrant> So if you specify a full path it will still work
[23:54] <wgrant> But searching for just a name fragment will only return stuff from your projet
[23:54] <StevenK> Depends on the vocab used
[23:54] <wgrant> Yes, similar to the person picker rework
[23:54] <StevenK> If just BranchVocabulary is used, then it will match everything
[23:54] <wgrant> Right
[23:55] <wgrant> But we can do the same thing for the bugtask branch picker that we did for the bugtask person picker
[23:55] <wgrant> So it knows which pillars are relevant
[23:55] <wgrant> Should be fairly easy
[23:55] <StevenK> So I'm not done? :-(
[23:55] <wgrant> And if the context is a branch (eg. for +register-merge) then it should probably use the branch's pillar
[23:56] <wgrant> You're knee-deep in branch search, you might as well make it not completely terrible given we already have the code
[23:56] <StevenK> The RestrictedOnBranch vocab already does that
[23:56] <wgrant> Ah, good
[23:56] <StevenK> Er, RestrictedOnProduct
[23:56] <wgrant> So mostly just bugtask, and maybe the series branch picker
[23:56] <wgrant> Though the latter may already be done
[23:56] <wgrant> But in general there's probably almost no need for a generic branch vocab
[23:57] <wgrant> Unlike people, branches are well-scoped
[23:57] <StevenK> vocabulary='BranchRestrictedOnProduct',
[23:57] <StevenK> For IProductSeries.branch
[23:57] <wgrant> Great
[23:57] <wgrant> So maybe only the bugtask one needs tweaking
[23:57] <wgrant> Is there a trigram index on Branch.name yet?
[23:58] <wgrant> If not, we'll need one
[23:58] <StevenK> No, I was going to do that after
[23:58] <StevenK> Since the index can hit prod before a deployment
[23:58] <wgrant> I suspect we'd be somewhat better off doing a sort of FTI
[23:58] <wgrant> eg. splitting on _- etc.
[23:58] <wgrant> But substring will do for now
[23:58] <StevenK> Shall I change IBugBranch.branch to BranchRestrictedOnProduct ?
[23:59] <wgrant> StevenK: No
[23:59] <wgrant> StevenK: Because a bug doesn't have a single product
[23:59] <wgrant> You should be able to look at the bugtask subscriber vocab, I think
[23:59] <wgrant> To see how to handle multiple products
[23:59] <wgrant> At least I think it does
[23:59] <wgrant> Also, all this should be about pillars
[23:59] <wgrant> Not products
[23:59] <wgrant> Or maybe even products and sourcepackages, rather than pillars