[10:50] <cjwatson> wgrant: Urgh, test failure on fix-check-copy-permissions in lp.registry.browser.tests.test_distroseries.TestDistroSeriesLocalDifferences.test_sync_error_no_perm_component, which turns out to be because my change fails to do a proper ancestry check so if you copy into updates it doesn't realise that it has to check against release.  (Well, actually, the test creates a publication in backports; I haven't decided yet whether ...
[10:50] <cjwatson> ... I think the test needs to be changed, but regardless the code is clearly still wrong.)
[10:51] <cjwatson> wgrant: So I need to do an ancestry check.  There are at least two copies of getSourceAncestry already, one in NascentUpload and one in PackageUploadSource, but I don't have the right context to be able to use either of them.  I'm loath to add yet another copy of essentially the same logic.
[10:53] <cjwatson> wgrant: Do you think it might make sense to move PackageUploadSource.getSourceAncestry somewhere else (where?  maybe under lp.soyuz.adapters?), since it doesn't actually need the PUS directly, just archive/DS/pocket/name?
[10:55] <cjwatson> Actually, NascentUpload.getSourceAncestry is a closer match, looking at it, because it doesn't fall back to the primary archive.  Upload permissions to the primary archive shouldn't confer upload permissions to a PPA, and likewise for copying.  PUS.getSourceAncestry makes more sense for diff generation.
[10:56] <wgrant> cjwatson: Can they sensibly be merged and just take a sequence of archives instead?
[10:57] <cjwatson> Possibly.  PUS.gSA has a puzzling thing where it falls back to any DS in the primary archive but not in the context archive.
[10:58] <cjwatson> And NU.gSA still uses the old DS.getPublishedSources, which doesn't make things any less confusing.
[10:59] <cjwatson> Uh, and PUS.gSA takes the *last* of its sequence of lookups that it finds, not the first.
[10:59] <cjwatson> Oh, no, it doesn't, it's just confusingly written.
[10:59] <cjwatson>         for blah:
[10:59] <cjwatson>             try:
[10:59] <cjwatson>                 ancestry = ancestries[0]
[10:59] <cjwatson>             except IndexError:
[10:59] <cjwatson>                 continue
[10:59] <cjwatson>             break
[10:59] <cjwatson>         return ancestry
[10:59] <cjwatson> Hi, dear PUS.gSA, how about "return ancestries[0]", love Colin
[11:02] <cjwatson> So if you upload packages to a PPA for both precise and quantal, then the quantal PPA package will be diffed against whatever's in quantal in the primary archive and failing that whatever's newest in the primary archive, but never against the precise PPA package.
[11:02] <wgrant> Yeah
[11:02] <wgrant> That's a bit odd.
[11:02] <cjwatson> I suppose that makes some kind of sense if the goal of PPA diffs is to work out what would happen if they landed in the primary archive.
[11:03] <wgrant> Potentially deliberate
[11:03] <cjwatson> I'm not sure I feel confident about merging these two, but renaming PUS.gSA to getSourceAncestryForDiffs might be a plan.
[11:04] <wgrant> A good start, indeed
[11:04] <cjwatson> Because honestly argh.
[11:05] <cjwatson> Still not sure I know a good place for NU.gSA.  Is adapters a sane place for stuff that doesn't really have a single context object?
[11:06] <wgrant> cjwatson: There, or maybe PublishingSet.
[11:07] <cjwatson> Ah, I hadn't thought of *Set.
[11:07] <cjwatson> That has a getNearestAncestor that is also not what I want.
[11:09] <cjwatson> Wait.  SPPH.overrideFromAncestry will look for ancestry in any pocket.
[11:10] <cjwatson> So, if I'm reading this right, if you only have universe component upload permissions, you can upload a package to backports that only exists in updates/main, but it will then be automatically overridden into backports/main.
[11:12] <cjwatson> Maybe I need to go back to querying for publications in any pocket (which is what the previous code effectively did) just in order to get this permissions regression sorted out and unblock deployment, and leave an XXX comment to sort out the insanity separately.
[11:12] <cjwatson> Because I'm really not entirely convinced by any of the three different implementations of this logic.
[11:13] <wgrant> Indeed... :/
[11:17] <cjwatson> wgrant: http://paste.ubuntu.com/1067513/ ?
[11:17] <cjwatson> Oh and I need to fix an interface there too.
[11:19] <cjwatson> So http://paste.ubuntu.com/1067517/
[11:20]  * cjwatson should go and clean house instead of cleaning Launchpad ...
[23:19] <Bert_2> can I ask questions here about issues I have with the launchpad code ?
[23:21] <rick_h_> Bert_2: yea, most people are afk during the weekend, but feel free to ask
[23:22] <Bert_2> yeah, I'll just ask ;)
[23:22] <Bert_2> I'm trying to run my own instance of launchpad
[23:23] <Bert_2> well, we, I'm working for a students developer group
[23:23] <Bert_2> anyway, we have launchpad running using the rocketfuel script and the make schema make LISTEN... install make run thing
[23:24] <Bert_2> but the information on the wiki only describes how to make it available to people who then have their dns changed so they can access it from launchpad.dev
[23:24] <rick_h_> right, you need some DNS to tell everywhere where it's at.
[23:24] <Bert_2> however, I want to use an actial domain for this instance of launchpad (something like launchpad.ulyssis.org)
[23:24] <Bert_2> yeah, that doesn't work :S
[23:24] <rick_h_> ok, so you'll need to adjust the apache conf file to be listening to that address
[23:24] <Bert_2> launchpad won't show :S
[23:25] <Bert_2> apache listens on it
[23:25] <Bert_2> but doesn't display launchpad, but the it-works page :S
[23:25] <rick_h_> for that name?
[23:26] <rick_h_> http://paste.mitechie.com/show/717/
[23:26] <Bert_2> yeah, it listens on the direct IP, I told it to, but it displays it works :S
[23:26] <rick_h_> all of those launchpad.dev need to be changed
[23:26] <Bert_2> or isn't an IP a good test ?
[23:26] <rick_h_> no, because apache is looking for names
[23:26] <Bert_2> yeah, I've read that
[23:26] <rick_h_> it's a named virtualhost for all of the various bits, launchpad, bazaar.launchpad, etc
[23:26] <Bert_2> I tried adding stuff, but that didn't work
[23:27] <rick_h_> so unless the name in the url matches the apache config it won't serve the request
[23:27] <Bert_2> zo I can actually just s/launchpad.dev/launchpad.ulyssis.org/ ?
[23:27] <Bert_2> *so
[23:27] <rick_h_> yea, that's what I'd start with
[23:27] <rick_h_> I've not actually run it on a different hostname, so not sure what else might break, but at least that part needs to happen
[23:27] <Bert_2> k, I was thinking about that but it seemed a little too simple because launchpad is so custom :S
[23:28] <rick_h_> well, only in ServerName and ServerAlias
[23:28] <Bert_2> I'll give it a try tomorrow and I'll probably be back later then
[23:28] <Bert_2> yeah, I know ;)
[23:28] <rick_h_> stuff like  <Directory /var/tmp/bazaar.launchpad.dev/mirrors/>
[23:28] <Bert_2> yeah, I know that ;)
[23:28] <rick_h_> might not like being changed
[23:28] <Bert_2> don't touch other stuff :p
[23:28] <rick_h_> ok cool
[23:28] <Bert_2> probably not, the process will be custom there
[23:29] <Bert_2> ulyssis runs a hosting service for student IT projects etc. over multiple servers with apache, ldap, nfs, etc., so we have quite some experience :p
[23:29] <rick_h_> cool, yea give it a shot and see if that gets your father along.
[23:29] <Bert_2> we just didn't want to fool around with launchpad too much ;)
[23:29] <rick_h_> heh, understand :)
[23:29] <Bert_2> yeah, I'll give it a go ;)
[23:29] <Bert_2> let's hope we'll get it sorted out, this'll be a great service to the students
[23:29] <Bert_2> also: is it normal that launchpad.dev by default contains some projects ?
[23:30] <Bert_2> (or at least displays some on the homepage)
[23:30] <rick_h_> yea, when you run make schema, if it's in dev mode, it'll load some sample data
[23:30] <Bert_2> how do I take it out of dev mode then ?
[23:30] <rick_h_> saves us a ton of time hacking on launchpad to have some default users, projects, etc
[23:30] <Bert_2> (I saw an error on)
[23:30] <Bert_2> *on make run
[23:31] <rick_h_> yea, it's part of the configs directory I believe
[23:31] <rick_h_> right, in dev mode you'll get more useful error messages/etc
[23:31] <rick_h_> which can be used against you by hackers in production, to tell your server directory layout, etc
[23:32] <rick_h_> so you're looking for the setting "devmode"
[23:32] <rick_h_> which is in the configs/development/launchpad.conf
[23:32] <rick_h_> so you'd want to setup a configs/production/launchpad.conf and get it started off of that once you've got things figured out
[23:32] <Bert_2> yeah, I did some searching but I couldn't find any useful docs on help.launchpad.net :S
[23:33] <rick_h_> https://dev.launchpad.net/WorkingWithProductionConfigs
[23:33] <rick_h_> might help some
[23:33] <Bert_2> fail
[23:33] <Bert_2> how did I miss that link XD
[23:33] <Bert_2> where was it ?N
[23:33] <Bert_2> where was it ?
[23:34] <rick_h_> I just searched the wiki for production and it came up
[23:34] <rick_h_> I think you'll want dev.launchpad.net more than help.
[23:34] <Bert_2> yeah, sorry, I mean dev.launchpad.net
[23:34] <Bert_2> I went around looking on the pages concerning building and running launchpad
[23:35] <rick_h_> anyway, off to pick up some dinner so good luck and it'll be a little quiet over the weekend so sorry if it takes some time to get answers, but there are people available to help.
[23:35] <Bert_2> the production config thing is nog linked there
[23:35] <rick_h_> yea, search ftw
[23:35] <Bert_2> can I change that myself, cause that seems like something that's missing
[23:35] <Bert_2> no problem man
[23:35] <rick_h_> hmm, probably not. but you might suggest a good edit and we can help on that
[23:35] <Bert_2> I'm used to longer delays on IRC ;)
[23:35] <rick_h_> only launchpad devs can edit
[23:35] <Bert_2> sure, I'll be in touch
[23:36] <Bert_2> see ya ;)