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