[00:02] when I'm not trying to fix freaking annoying bugs that is [00:05] thumper: canonical_url still? [00:05] mwhudson: yep [00:05] :/ [00:05] firstly rootsite from the canonical_url_data can be None [00:05] moved the fix [00:05] ah [00:05] still have things that blowup [00:06] just in the canonical url fix branch? [00:06] yeah [00:06] or in your one that adds layers everywhere [00:06] :( [00:06] I think the "correct" checking is causing other errors [00:06] you mean exposing latent bugs? [00:07] yeah [00:07] haha, found one [00:07] wheee [00:07] so we have 404s from this today? [00:07] not sure [00:07] still checking [00:09] lib/lp/translations/templates/product-translations.pt:47: +export is only on the translations page [00:09] however the canonical url of the product series is rootsite [00:09] mainsite sorry [00:09] so in the past this worked [00:09] using the current request [00:09] now it doesn't [00:12] well also fmt:url/canonical_url used to prefer the link on the site of the current request [00:12] jelmer: Does your XB-* branch also publish non-XB-* fields? [00:12] so it generated a good link before 3.0 even [00:13] thumper: i guess the fix is target/fmt:url:translations/+export ? [00:13] * thumper nods [00:17] * mwhudson has surprising news: the blueprints code isn't very good [00:17] * thumper is in shock [00:17] I do not understand why Blueprint has been left to stagnate. [00:17] Kill it off or fix it... don't leave it to drag LP down! [00:18] we can't kill it without the ubuntu devs coming after us with pitchforks [00:18] i imagine [00:18] er [00:19] make run_all is stabbing me in the face [00:19] bzrlib.errors.NoWhoami: Unable to determine your name. [00:19] i guess make -k run_all is a sort of workaround [00:20] or not [00:20] Why would run_all be committing? [00:21] wgrant: it calls run_codehosting [00:21] wgrant: which makes real branches [00:21] Oh. [00:21] And makes fake branches. [00:21] for those in the sample data [00:21] Rihgt. [00:21] That feature is annoying. [00:21] I want to remove it. [00:21] heh [00:21] it wouldn't bother me [00:21] I never use the 'fake' sample data branches [00:21] "Let me just restart the appserver to test this recipe change..." [00:21] "WHERE did my branches go?" [00:22] wgrant: fix it and I'll approve [00:22] wgrant: we should clean codehosting on make clean [00:22] not make run [00:22] mwhudson: I might have fixed the bugs with 3 .pt edist [00:22] edits [00:22] 28 failing tests to check [00:22] thumper: cool [00:23] all for translations +imports and +export [00:23] hooray for OAOO [00:23] OAOO?? [00:23] (Once And Only Once) [00:23] heh [00:24] :( [00:24] nope [00:24] now links are being clicked and taken to translations sites [00:25] or other sites on a different subdomain [00:25] clucking bell [00:27] Wasn't there a bit of a proposal a while ago to remove the individual rootsites? [00:28] I don't recall [00:28] vague recollections [00:28] but not likely [00:28] down to 19 failures [00:32] Link has site=, canonical_url has rootsite= :( [00:32] yay consistency [00:32] + layer + facet [00:32] woo [00:32] * thumper looks for the sarcasterisk [00:32] Is there any reason not to delete facets entirely? [00:33] wgrant: no [00:33] Yay. === beuno_ is now known as beuno [00:33] StevenK: The raw SQL in your branch makes me sad. But it looks good. [00:33] wgrant: I have a branch that removes all facet definitions for LP code [00:33] as in lp.code [00:33] not all code in lp [00:34] Yay. [00:34] It still works correctly with tabs and breadcrumbs? [00:36] seems to [00:36] * thumper sighs [00:39] * thumper cries quietly [00:41] wgrant: It just uses the control fields in the binary/source control fields, the XB- bit has already been stripped out at that point. [00:41] jelmer: Oh, true. [00:41] * wgrant fails. [00:46] 17 failures... [00:53] lib/canonical/launchpad/pagetests/basics/notfound-traversals.txt takes a LONG time to run [00:53] But it's also deprecated. [00:58] but no one will remove it [01:04] * thumper taps fingers while the tests run.... [01:04] again [01:05] thumper: does CodeImport have any unittests? [01:05] it should do [01:06] lp.code.model.tests.test_codeimport [01:06] would be my first guess [01:06] and lp.code.stories.codeimport [01:07] ah, they're hidden under model/ [01:07] jelmer: we have model tests under model [01:07] browser tests under browser [01:07] interface tests under interface [01:07] you know [01:07] where they should be :) [01:09] I thought most apps just had lib/lp/APP/tests, and a couple had lib/lp/APP/browser/tests. [01:09] yeah, that's what confused me [01:10] I admit that model/tests probably makes more sense, though. [01:14] wgrant: most apps do [01:14] wgrant: but code blazes the "correct" way [01:14] \o/ [01:14] Code seems to be correct in a lot of ways :( [01:15] wgrant: we still have lp.code.tests, but I'm trying to get around to shuffling them into the right place [01:15] I've almost fixed all the translation story failures in my canonical_url branch fix [01:15] * thumper crosses fingers [01:17] I saw a presentation from a github dev the other day, and his overview of how to contribute equated to "grab trunk, hack, go to web site, fork, add a remote in git, then push to that remote" [01:17] But Git's better!!! [01:18] so whereas I thought that server-side branch would be very useful for demos/beginners, they didn't take advantage of that, and had an even worse experience [01:18] interesting [01:20] james_w: I have a branch in progress (or feature if you will) that will mean you can register a project on LP, then go bzr push lp:project [01:20] and it will make that branch the trunk [01:20] thumper: Who will own the branch? [01:20] Project owner? [01:20] there have been suggestions that we should also create a project [01:20] wgrant: the pusher owns the branch [01:20] cool, but that's not my use case for demos [01:20] thumper: :( [01:21] wgrant: it could be changed [01:21] wgrant: it isn't hard [01:21] wgrant: but it should be a separate fix (IMO) [01:21] the maintainer of the project if one is set? [01:21] (and it's a team that the pusher is part of) [01:21] the push fails if the pusher doesn't have permission to set the link [01:21] right [01:22] ah FFS!!! [01:22] ✁☹ [01:23] arghl OOPS-1693EA64 [01:24] thumper: I've just realised the workaround in buildrecipe for the bzr bug isn't going to cut it, as we execute bzr-builder with sudo [01:25] james_w: luckily* the lp-oops application seems to have fallen over [01:25] james_w: Hm, it wasn't tested? [01:26] wgrant: I guess not [01:26] I was one of those that ACKed it and didn't spot it at the time [01:26] ah, it's back now [01:40] apparently not finding my oops though [01:40] I think it's bug 518337 anyway [01:40] <_mup_> Bug #518337: timeout oopses on person page [01:49] :( [01:49] the counts that it adds up are taking over a second each [01:49] down to 6 failing tests [02:00] hello thumper [02:01] thumper pitti says that https://code.edge.launchpad.net/~pitti/postgresql/common-dapper does not have an upgrade button for him [02:01] even though it does seem to be a pack-0.92 branch [02:01] * thumper looks [02:01] poolie: we don't know what format it is in [02:02] poolie: as it hasn't been touched forever [02:02] since we don't know [02:02] we don't show it [02:10] * thumper sighs [02:10] 4 failures... [02:38] 3 failures [02:41] 1 failure [02:43] thumper: mind you, the lock/unlock trick will update the format now [02:43] mwhudson: it will [02:43] perhaps we should just twiddle everything we don't have formats for [02:44] yeah, would be interesting [02:44] i wonder how many weave branches there are... [02:46] i think you should [02:47] ec2 landing now [02:48] thumper: congrats [02:52] phew [02:53] * thumper goes to have lunch [05:59] wgrant: It makes me sad too. It also makes me sad that I'm missing a table. [06:07] StevenK: Ah, PackageSetInclusion? [06:07] wgrant: Yup [06:08] I think I've figured out how to deal with that, too [06:08] Two extra queries :-( [06:11] Why so many? [06:12] I was going to run through packagesetinclusion where the child packageset is the current parent packageset and change it to the child, and then do the same for the child packagesets [06:19] wgrant: You don't agree, or I just confused you? [06:20] You confused me. [06:20] Then I decided to go and pester my useless project team. [06:21] So, can you reword? [06:22] wgrant: The problem is I have two many parent and child thing [06:22] *things [06:23] wgrant: I was going to run over packagesetinclusion where the child column is the parent packageset, and change it to the child packageset -- and then do the same for the parent column [06:24] StevenK: Can't you do that (and don't you need to do it?) in one query, just mapping parent and child to the new packagesets? [06:24] wgrant: I can't think of how to do in one query [06:24] wgrant: Suggestions are welcome [06:26] StevenK: I don't see how you could do it in two. [06:28] INSERT INTO packagesetinclusion (parent, child) SELECT , FROM packagesetinclusion blah blah blah [06:41] StevenK: How does my suggestion look? [06:58] wgrant: I don't get how to expand [07:00] * mwhudson runs away, good weekend all [07:04] wgrant: add some more details :) [07:04] wgrant: like the rest of the SQL [07:04] heh [07:04] * thumper wants a beer [07:04] thumper: I would have if I wasn't really busy. I will in half an hour :) [07:09] Ah, this is all within a parent-specific iteration. I seee. [07:20] wgrant: So now you agree with me? [07:21] * StevenK heads to the doctors [07:23] StevenK: Well, I don't think that loop should be there. [07:24] StevenK: But regardless, surely just running through all the child packagesets is sufficient. You don't need to run through the parents too -- that would get everything twice. [07:25] jml: just having a look (belated, I know) at your ReadyToCode checklist. Is that really what "ready to code" means? Doesn't some notion of approach and feasibility come in before that stage? [08:36] noodles775: hi, is the context of your mail about ppas "if this was done it would answer martin's question"? [08:36] hi jml, jtv [08:36] hi poolie [08:37] poolie: Yeah, I saw you asking about ppa download logs, but didn't know the context of your irc chat... just sent the email in case it answers your question. [08:38] i want to find out how much people use old distroseries from our ppas [08:39] It's implemented, but waiting on LOSAs :( [08:39] Yes, but we haven't yet been able to process the backlog of ppa logs (due to the memory issue). The email I sent will hopefully enable us to start processing them, but as wgrant says. [08:39] wgrant: heh, poke spm in the eye? [08:40] * wgrant sees no such email. [08:40] * noodles775 forwards it to wgrant. [08:40] noodles775: But the memory issue should be fixed now, right? [08:41] wgrant: apparently not. Well, when it was run, we still hit the issue (but were a bit optimistic with our default number of lines)... the email has more detail. [08:41] noodles775: Ah, I see. Thanks. [08:42] I wasn't aware that work was actually ongoing to get it running. [08:42] and this will answer that question, when it's done? [08:43] You will be able to grab download counts per country and date for each .deb in a PPA. [08:43] Only through the API for now, though. [08:48] and then summarize it myself [08:48] anyhow, that would be very nice [08:49] i think i'd actually be more interested in knowing how many IPs polled the ppa [08:49] but either will do [08:49] * poolie thinks the less launchpad makes me use my mail client, the better [08:50] I considered that. But there wasn't existing code to do that sort of thing, and it's less obvious how it should be counted. [08:50] well, thanks very much for doing it [08:51] It'll be good once it can actually be turned on safely. [08:53] good morning === almaisan-away is now known as al-maisan [09:12] Hello [09:15] hi mrevell! [09:20] wgrant: But that doesn't cover the case of parent packageset being copied too [09:21] StevenK: Hm, does PackagesetInclusion work across distroseries boundaries? [09:21] I guess so :( [09:23] wgrant: So you finally agree with me, or you have a better idea? [09:27] I don't agree that you need two queries. However, an inter-series PsI brings about a situation where the behaviour is undefined. [09:27] What should be done in that case? [09:28] al-maisan was suggesting looping over at the end [09:28] To do what? [09:28] I don't actually know what the behaviour in this case should be. [09:28] It's certainly not obvious. [09:28] To copy the records from packagesetinclusion [09:29] Yes, but what does that mean? What if I have a PsI with its parent in karmic, and child in lucid. I am copying lucid into maverick. === al-maisan is now known as almaisan-away [09:29] How do I copy that? [09:29] The child packageset changes to maverick and the parent stays as karmic? [09:30] I guess. [09:30] This is a little sub-optimal [09:30] Now, what if it's the other way around? [09:30] parent moves and child doesn't [09:30] In one of the directions, creating a new series is going to magically add more packages into an older series' packageset. [09:31] Yes, adding more children is dangerous === almaisan-away is now known as al-maisan [09:33] Isn't the idea that each series has its own package sets i.e. changes to the latter in a child series would not affect the parent series? [09:34] al-maisan: Yes. [09:34] But there's nothing in PackagesetInclusion to require that. [09:35] And while it will probably never happen, I realllly don't want to leave undesirable behaviour in something as critical as i-f-p. [09:35] I did not quite get the "creating a new series is going to magically add more packages into an older series' packageset" statement..? [09:35] al-maisan: If I have a PackagesetInclusion with a parent in karmic, and a child in lucid, creating maverick from lucid will mean that karmic inherits from maverick too. [09:36] wgrant: you mean: it is possible to associate package sets across series in PackagesetInclusion i.e. there's no db constraint precluding that and you see that as a risk? [09:36] al-maisan: Pretty much. [09:37] I'm not sure how much of a risk it is. [09:37] But it needs to be examines. [09:37] Well, we could run a query on staging? [09:37] There shouldn't be any data like that now. [09:38] But some could spring up in the future. And then i-f-p does something very confusing and dangerous without telling anybody. [09:38] We might just ignore the risk. But we need to explicitly decide that. [09:38] Well, currently, i-f-p does nothing of the sort? [09:39] Once it starts copying PsI it will. [09:39] Packageset._addDirectSuccessors() (in lib/lp/soyuz/model/packageset.py, line 114) could be refined to prevent that from happening [09:39] al-maisan: Having that restriction outside the DB makes me sad, but I guess it's the best that can be done. [09:40] .. and a db constraint on INSERT/BEFORE into PackagesetInclusion could be easily formulated [09:41] hmm .. there is already an INSERT/AFTER trigger on packagesetinclusion : packagesetinclusion_inserted_trig [09:42] * al-maisan never tried having a trigger before *and* after an INSERT on the same table [09:42] I guess that's there to update flatpackagesetinclusion. [09:42] Yep. [09:42] I'll do a quick test when I have some spare time and let you know [09:45] maybe stub would know off the top of his head whether it's ok to have a trigger before *and* after an INSERT on the same table..? [09:45] I don't see why that would be an issue, personally [09:48] if that works we could add the before insert trigger on packagesetinclusion and veto associations of package sets across distro series [09:48] That seems to make sense. [09:49] And it makes me less wary about breaking Ubuntu... [09:49] wgrant: maybe you could open a bug and I can look into it in the next couple of days..? [09:53] al-maisan: If you could. If not, I can look at fixing it at some point. [09:53] * wgrant files. [09:53] who ever gets to it first :) [09:55] Bug #620989 [09:55] <_mup_> Bug #620989: Package sets can include sets in other series [09:57] thanks [09:57] for filing :) [09:58] StevenK: Did hacking Storm's Insert to support 'INSERT FROM ... SELECT' prove difficult? I'm just wondering if you can warn me before I get lured into a deceptively simple trap. [09:58] mthaddon: hi; just wanted to say I'm really glad to hear we can move forward on the additional QA environment soonish. [09:58] wgrant: looked entirely straight forward to me [09:59] lifeless: yep [09:59] mthaddon: if there is anything I can do to make it simpler/unblock things, please shout! [09:59] will do [10:00] mthaddon: separately [10:00] do you know when we're likely to get edge moving again :) [10:01] as in, is it waiting a dev to change something, or losa cycles, or cron? [10:02] lifeless: hmm, it was something spm was working on, but he was ill today - I'll get out and push [10:02] thanks [10:16] wgrant: I didn't hack on it, lifeless said there ways around it, but my lack of knowledge about Storm defeated me [10:17] Ah, OK. [10:18] is this evil ? [10:18] milestones = search_results._store.find( [10:18] the _store I mean [10:18] why would that be needed? [10:18] It's wrong. [10:18] gmb: ^ yo, its in bugtask, I blame you. [10:18] wgrant: what should it be ? [10:18] Store.of(search_results) is the right way to spell that. [10:18] its blowing up because DRS doesn't have that attribute [10:19] But do you really want to do that rather than ISlaveStore(something)? [10:19] I don't know [10:19] I'm guessing it sometimes runs in posts [10:19] and rather than explicit its trying to be magical. [10:20] * gmb has no idea why that's there. [10:20] magical magical goodness. 'goodness' [10:20] * gmb bzr blames... [10:20] I have only 46 failing tests with this bugtaskset overhaul [10:20] allenap, J'accuse! [10:20] well [10:20] 46 in my current reduce() phase [10:20] I may have broken a tonne of other shit [10:21] gmb: What? :) [10:21] allenap, Using _store. Apparently, this is bad. [10:21] _. 'nuff said. [10:21] gmb: Yeah, I agree. Did I do it? [10:21] es [10:22] and my patch to cut hundreds of queries out of the landscape milestone 'later' page loads is blowing up in there [10:22] because DecoratedResultSet doth not have _store [10:23] allenap, Apparently. TBH, I just wanted lifeless to blame someone else so I could get back to my JS horrorshow uninterrupted. [10:23] whats the magic env variable again, for SQL output [10:24] LP_DEBUG_STORM or something? [10:24] lifeless: I guess Store.of(self) should work fine there. [10:26] lifeless: LP_DEBUG_SQL and LP_DEBUG_SQL_EXTA, IIRC. [10:26] lifeless: LP_DEBUG_SQL and LP_DEBUG_SQL_EXTRA [10:26] *EXTRA [10:31] allenap: its a BugTaskSet [10:31] lifeless: Oh balls. [10:32] allenap: I'm trying Store.of(self) [10:32] allenap: well, this is a reason not to have Sets as currently conceived [10:32] and instead collections which are more query builders yada yada yada [10:32] it would be nice to have an explicit mapper structure [10:34] jtv, before which stage? [10:34] jml otp [10:38] lifeless: One option is to modify the c.l.webapp.adapter.get_store adapter so that you can use IStore(search_results). [10:39] allenap: well, if Store.of(DRS) works, then I'll use that. [10:39] lifeless: Ah, yes, that would be better. I just assumed it wouldn't :) [10:40] allenap: is there any reason this can't ? [10:40] I mean, I assume it will be pain and heartache [10:40] the other question [10:40] is that there is a query [10:40] bringing in milestones already [10:40] in any case, hello [10:41] it seems nuts to me to be querying bugtasks, extracting IDs and throwing away th eobjects and then requerying for milestones [10:41] why not use the other query as an alias [10:42] and just do a single query [10:42] jml: ho hai [10:42] lifeless: IResultSet is delegated to the real result set, and that doesn't include __storm_object_info__ which is what Store.of() relies upon (via get_obj_info). [10:43] Decorated is what you mean, and yes, Isee that [10:43] (I'm in a big hariry branch stormifying bugtaskset [10:43] not entirely by choice [10:43] anyhow, I'm going to take the 'do this later approach [10:44] but I stand by my 'two queries here is nuts' comment [10:48] * lifeless encommenates [10:48] lifeless: I agree with the "two queries here is nuts" comment. I can't remember why it happened that way. If it was me, I may have not understood or been able to get aliases to work, and just got this working for expediency. [10:49] sqlobject [10:50] Possibly. [11:00] hmm [11:00] may be closing in on 'working'. zomg. [11:01] jml: got a few ? [11:01] lifeless, sure. [11:11] lifeless: How much of the milestone index is SQL time? [11:13] jml: you cut out [11:13] wgrant: all of it [11:13] wgrant: (more or lesss) [11:14] wgrant: one query per private bug [11:14] lifeless: Oh, I heard there was lots of Python. [11:14] And that's why memcached was used. [11:14] wgrant: see my perf tuesday mail this week [11:14] yeah, not a memcache issue === adeuring1 is now known as adeuring [11:32] jml: https://edge.launchpad.net/~bobthebuilder [11:48] gnight [11:51] 'night lifeless [12:03] Morning, everyone. === al-maisan is now known as almaisan-away [12:25] bigjools, I assume it's ok to mark bug 510892 and bug 510894 as qa-untestable, right? [12:25] <_mup_> Bug #510892: Upload policies are instantiated unnecessarily

[12:25] <_mup_> Bug #510894: Upload policy names are duplicated with the actual builds

[12:25] salgado: I think so, yes. [12:56] how would I find out how many different pages we have? [12:57] "find . -name '*.pt' | wc -l" gives me a rough approximation. [13:02] sinzui, perhaps you'd know? [13:02] jml: the google analytics don't do that? (it's been a while since I've used it) [13:03] (assuming we've got the ga js code on each page) [13:03] noodles775, by number of pages, I mean "bug-index" would count as one [13:03] noodles775, would GA help with that? [13:04]