| thumper | when I'm not trying to fix freaking annoying bugs that is | 00:02 |
|---|---|---|
| mwhudson | thumper: canonical_url still? | 00:05 |
| thumper | mwhudson: yep | 00:05 |
| mwhudson | :/ | 00:05 |
| thumper | firstly rootsite from the canonical_url_data can be None | 00:05 |
| thumper | moved the fix | 00:05 |
| mwhudson | ah | 00:05 |
| thumper | still have things that blowup | 00:05 |
| mwhudson | just in the canonical url fix branch? | 00:06 |
| thumper | yeah | 00:06 |
| mwhudson | or in your one that adds layers everywhere | 00:06 |
| mwhudson | :( | 00:06 |
| thumper | I think the "correct" checking is causing other errors | 00:06 |
| mwhudson | you mean exposing latent bugs? | 00:06 |
| thumper | yeah | 00:07 |
| thumper | haha, found one | 00:07 |
| mwhudson | wheee | 00:07 |
| mwhudson | so we have 404s from this today? | 00:07 |
| thumper | not sure | 00:07 |
| thumper | still checking | 00:07 |
| thumper | lib/lp/translations/templates/product-translations.pt:47: <a tal:attributes="href target/fmt:url/+export" | 00:09 |
| thumper | +export is only on the translations page | 00:09 |
| thumper | however the canonical url of the product series is rootsite | 00:09 |
| thumper | mainsite sorry | 00:09 |
| thumper | so in the past this worked | 00:09 |
| thumper | using the current request | 00:09 |
| thumper | now it doesn't | 00:09 |
| mwhudson | well also fmt:url/canonical_url used to prefer the link on the site of the current request | 00:12 |
| wgrant | jelmer: Does your XB-* branch also publish non-XB-* fields? | 00:12 |
| mwhudson | so it generated a good link before 3.0 even | 00:12 |
| mwhudson | thumper: i guess the fix is target/fmt:url:translations/+export ? | 00:13 |
| * thumper nods | 00:13 | |
| * mwhudson has surprising news: the blueprints code isn't very good | 00:17 | |
| * thumper is in shock | 00:17 | |
| wgrant | I do not understand why Blueprint has been left to stagnate. | 00:17 |
| wgrant | Kill it off or fix it... don't leave it to drag LP down! | 00:17 |
| mwhudson | we can't kill it without the ubuntu devs coming after us with pitchforks | 00:18 |
| mwhudson | i imagine | 00:18 |
| mwhudson | er | 00:18 |
| mwhudson | make run_all is stabbing me in the face | 00:19 |
| mwhudson | bzrlib.errors.NoWhoami: Unable to determine your name. | 00:19 |
| mwhudson | i guess make -k run_all is a sort of workaround | 00:19 |
| mwhudson | or not | 00:20 |
| wgrant | Why would run_all be committing? | 00:20 |
| thumper | wgrant: it calls run_codehosting | 00:21 |
| thumper | wgrant: which makes real branches | 00:21 |
| wgrant | Oh. | 00:21 |
| wgrant | And makes fake branches. | 00:21 |
| thumper | for those in the sample data | 00:21 |
| wgrant | Rihgt. | 00:21 |
| wgrant | That feature is annoying. | 00:21 |
| wgrant | I want to remove it. | 00:21 |
| thumper | heh | 00:21 |
| thumper | it wouldn't bother me | 00:21 |
| thumper | I never use the 'fake' sample data branches | 00:21 |
| wgrant | "Let me just restart the appserver to test this recipe change..." | 00:21 |
| wgrant | "WHERE did my branches go?" | 00:21 |
| thumper | wgrant: fix it and I'll approve | 00:22 |
| thumper | wgrant: we should clean codehosting on make clean | 00:22 |
| thumper | not make run | 00:22 |
| thumper | mwhudson: I might have fixed the bugs with 3 .pt edist | 00:22 |
| thumper | edits | 00:22 |
| thumper | 28 failing tests to check | 00:22 |
| mwhudson | thumper: cool | 00:22 |
| thumper | all for translations +imports and +export | 00:23 |
| mwhudson | hooray for OAOO | 00:23 |
| thumper | OAOO?? | 00:23 |
| mwhudson | (Once And Only Once) | 00:23 |
| thumper | heh | 00:23 |
| thumper | :( | 00:24 |
| thumper | nope | 00:24 |
| thumper | now links are being clicked and taken to translations sites | 00:24 |
| thumper | or other sites on a different subdomain | 00:25 |
| thumper | clucking bell | 00:25 |
| wgrant | Wasn't there a bit of a proposal a while ago to remove the individual rootsites? | 00:27 |
| thumper | I don't recall | 00:28 |
| thumper | vague recollections | 00:28 |
| thumper | but not likely | 00:28 |
| thumper | down to 19 failures | 00:28 |
| thumper | Link has site=, canonical_url has rootsite= :( | 00:32 |
| thumper | yay consistency | 00:32 |
| mwhudson | + layer + facet | 00:32 |
| mwhudson | woo | 00:32 |
| * thumper looks for the sarcasterisk | 00:32 | |
| wgrant | Is there any reason not to delete facets entirely? | 00:32 |
| mwhudson | wgrant: no | 00:33 |
| wgrant | Yay. | 00:33 |
| === beuno_ is now known as beuno | ||
| wgrant | StevenK: The raw SQL in your branch makes me sad. But it looks good. | 00:33 |
| thumper | wgrant: I have a branch that removes all facet definitions for LP code | 00:33 |
| thumper | as in lp.code | 00:33 |
| thumper | not all code in lp | 00:33 |
| wgrant | Yay. | 00:34 |
| wgrant | It still works correctly with tabs and breadcrumbs? | 00:34 |
| thumper | seems to | 00:36 |
| * thumper sighs | 00:36 | |
| * thumper cries quietly | 00:39 | |
| jelmer | 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 |
| wgrant | jelmer: Oh, true. | 00:41 |
| * wgrant fails. | 00:41 | |
| thumper | 17 failures... | 00:46 |
| thumper | lib/canonical/launchpad/pagetests/basics/notfound-traversals.txt takes a LONG time to run | 00:53 |
| wgrant | But it's also deprecated. | 00:53 |
| thumper | but no one will remove it | 00:58 |
| * thumper taps fingers while the tests run.... | 01:04 | |
| thumper | again | 01:04 |
| jelmer | thumper: does CodeImport have any unittests? | 01:05 |
| thumper | it should do | 01:05 |
| thumper | lp.code.model.tests.test_codeimport | 01:06 |
| thumper | would be my first guess | 01:06 |
| thumper | and lp.code.stories.codeimport | 01:06 |
| jelmer | ah, they're hidden under model/ | 01:07 |
| thumper | jelmer: we have model tests under model | 01:07 |
| thumper | browser tests under browser | 01:07 |
| thumper | interface tests under interface | 01:07 |
| thumper | you know | 01:07 |
| thumper | where they should be :) | 01:07 |
| wgrant | I thought most apps just had lib/lp/APP/tests, and a couple had lib/lp/APP/browser/tests. | 01:09 |
| jelmer | yeah, that's what confused me | 01:09 |
| wgrant | I admit that model/tests probably makes more sense, though. | 01:10 |
| thumper | wgrant: most apps do | 01:14 |
| thumper | wgrant: but code blazes the "correct" way | 01:14 |
| thumper | \o/ | 01:14 |
| wgrant | Code seems to be correct in a lot of ways :( | 01:14 |
| thumper | wgrant: we still have lp.code.tests, but I'm trying to get around to shuffling them into the right place | 01:15 |
| thumper | I've almost fixed all the translation story failures in my canonical_url branch fix | 01:15 |
| * thumper crosses fingers | 01:15 | |
| james_w | 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 |
| wgrant | But Git's better!!! | 01:17 |
| james_w | 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 |
| thumper | interesting | 01:18 |
| thumper | 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 |
| thumper | and it will make that branch the trunk | 01:20 |
| wgrant | thumper: Who will own the branch? | 01:20 |
| wgrant | Project owner? | 01:20 |
| thumper | there have been suggestions that we should also create a project | 01:20 |
| thumper | wgrant: the pusher owns the branch | 01:20 |
| james_w | cool, but that's not my use case for demos | 01:20 |
| wgrant | thumper: :( | 01:20 |
| thumper | wgrant: it could be changed | 01:21 |
| thumper | wgrant: it isn't hard | 01:21 |
| thumper | wgrant: but it should be a separate fix (IMO) | 01:21 |
| james_w | the maintainer of the project if one is set? | 01:21 |
| james_w | (and it's a team that the pusher is part of) | 01:21 |
| thumper | the push fails if the pusher doesn't have permission to set the link | 01:21 |
| james_w | right | 01:21 |
| thumper | ah FFS!!! | 01:22 |
| thumper | ✁☹ | 01:22 |
| james_w | arghl OOPS-1693EA64 | 01:23 |
| james_w | 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:24 |
| mwhudson | james_w: luckily* the lp-oops application seems to have fallen over | 01:25 |
| wgrant | james_w: Hm, it wasn't tested? | 01:25 |
| james_w | wgrant: I guess not | 01:26 |
| james_w | I was one of those that ACKed it and didn't spot it at the time | 01:26 |
| mwhudson | ah, it's back now | 01:26 |
| james_w | apparently not finding my oops though | 01:40 |
| james_w | I think it's bug 518337 anyway | 01:40 |
| _mup_ | Bug #518337: timeout oopses on person page <timeout> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/518337> | 01:40 |
| thumper | :( | 01:49 |
| thumper | the counts that it adds up are taking over a second each | 01:49 |
| thumper | down to 6 failing tests | 01:49 |
| poolie | hello thumper | 02:00 |
| poolie | thumper pitti says that https://code.edge.launchpad.net/~pitti/postgresql/common-dapper does not have an upgrade button for him | 02:01 |
| poolie | even though it does seem to be a pack-0.92 branch | 02:01 |
| * thumper looks | 02:01 | |
| thumper | poolie: we don't know what format it is in | 02:01 |
| thumper | poolie: as it hasn't been touched forever | 02:02 |
| thumper | since we don't know | 02:02 |
| thumper | we don't show it | 02:02 |
| * thumper sighs | 02:10 | |
| thumper | 4 failures... | 02:10 |
| thumper | 3 failures | 02:38 |
| thumper | 1 failure | 02:41 |
| mwhudson | thumper: mind you, the lock/unlock trick will update the format now | 02:43 |
| thumper | mwhudson: it will | 02:43 |
| thumper | perhaps we should just twiddle everything we don't have formats for | 02:43 |
| mwhudson | yeah, would be interesting | 02:44 |
| mwhudson | i wonder how many weave branches there are... | 02:44 |
| poolie | i think you should | 02:46 |
| thumper | ec2 landing now | 02:47 |
| mwhudson | thumper: congrats | 02:48 |
| thumper | phew | 02:52 |
| * thumper goes to have lunch | 02:53 | |
| StevenK | wgrant: It makes me sad too. It also makes me sad that I'm missing a table. | 05:59 |
| wgrant | StevenK: Ah, PackageSetInclusion? | 06:07 |
| StevenK | wgrant: Yup | 06:07 |
| StevenK | I think I've figured out how to deal with that, too | 06:08 |
| StevenK | Two extra queries :-( | 06:08 |
| wgrant | Why so many? | 06:11 |
| StevenK | 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:12 |
| StevenK | wgrant: You don't agree, or I just confused you? | 06:19 |
| wgrant | You confused me. | 06:20 |
| wgrant | Then I decided to go and pester my useless project team. | 06:20 |
| wgrant | So, can you reword? | 06:21 |
| StevenK | wgrant: The problem is I have two many parent and child thing | 06:22 |
| StevenK | *things | 06:22 |
| StevenK | 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:23 |
| wgrant | 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 |
| StevenK | wgrant: I can't think of how to do in one query | 06:24 |
| StevenK | wgrant: Suggestions are welcome | 06:24 |
| wgrant | StevenK: I don't see how you could do it in two. | 06:26 |
| wgrant | INSERT INTO packagesetinclusion (parent, child) SELECT <map old parent to new parent>, <map old child to new child> FROM packagesetinclusion blah blah blah | 06:28 |
| wgrant | StevenK: How does my suggestion look? | 06:41 |
| StevenK | wgrant: I don't get how to expand <map old parent to new parent> | 06:58 |
| * mwhudson runs away, good weekend all | 07:00 | |
| thumper | wgrant: add some more details :) | 07:04 |
| thumper | wgrant: like the rest of the SQL | 07:04 |
| thumper | heh | 07:04 |
| * thumper wants a beer | 07:04 | |
| wgrant | thumper: I would have if I wasn't really busy. I will in half an hour :) | 07:04 |
| wgrant | Ah, this is all within a parent-specific iteration. I seee. | 07:09 |
| StevenK | wgrant: So now you agree with me? | 07:20 |
| * StevenK heads to the doctors | 07:21 | |
| wgrant | StevenK: Well, I don't think that loop should be there. | 07:23 |
| wgrant | 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:24 |
| jtv | 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? | 07:25 |
| poolie | noodles775: hi, is the context of your mail about ppas "if this was done it would answer martin's question"? | 08:36 |
| poolie | hi jml, jtv | 08:36 |
| jtv | hi poolie | 08:36 |
| noodles775 | 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:37 |
| poolie | i want to find out how much people use old distroseries from our ppas | 08:38 |
| wgrant | It's implemented, but waiting on LOSAs :( | 08:39 |
| noodles775 | 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 |
| nigelb | wgrant: heh, poke spm in the eye? | 08:39 |
| * wgrant sees no such email. | 08:40 | |
| * noodles775 forwards it to wgrant. | 08:40 | |
| wgrant | noodles775: But the memory issue should be fixed now, right? | 08:40 |
| noodles775 | 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 |
| wgrant | noodles775: Ah, I see. Thanks. | 08:41 |
| wgrant | I wasn't aware that work was actually ongoing to get it running. | 08:42 |
| poolie | and this will answer that question, when it's done? | 08:42 |
| wgrant | You will be able to grab download counts per country and date for each .deb in a PPA. | 08:43 |
| wgrant | Only through the API for now, though. | 08:43 |
| poolie | and then summarize it myself | 08:48 |
| poolie | anyhow, that would be very nice | 08:48 |
| poolie | i think i'd actually be more interested in knowing how many IPs polled the ppa | 08:49 |
| poolie | but either will do | 08:49 |
| * poolie thinks the less launchpad makes me use my mail client, the better | 08:49 | |
| wgrant | 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 |
| poolie | well, thanks very much for doing it | 08:50 |
| wgrant | It'll be good once it can actually be turned on safely. | 08:51 |
| adeuring | good morning | 08:53 |
| === almaisan-away is now known as al-maisan | ||
| mrevell | Hello | 09:12 |
| jtv | hi mrevell! | 09:15 |
| StevenK | wgrant: But that doesn't cover the case of parent packageset being copied too | 09:20 |
| wgrant | StevenK: Hm, does PackagesetInclusion work across distroseries boundaries? | 09:21 |
| wgrant | I guess so :( | 09:21 |
| StevenK | wgrant: So you finally agree with me, or you have a better idea? | 09:23 |
| wgrant | 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 |
| wgrant | What should be done in that case? | 09:27 |
| StevenK | al-maisan was suggesting looping over at the end | 09:28 |
| wgrant | To do what? | 09:28 |
| wgrant | I don't actually know what the behaviour in this case should be. | 09:28 |
| wgrant | It's certainly not obvious. | 09:28 |
| StevenK | To copy the records from packagesetinclusion | 09:28 |
| wgrant | 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. | 09:29 |
| === al-maisan is now known as almaisan-away | ||
| wgrant | How do I copy that? | 09:29 |
| StevenK | The child packageset changes to maverick and the parent stays as karmic? | 09:29 |
| wgrant | I guess. | 09:30 |
| StevenK | This is a little sub-optimal | 09:30 |
| wgrant | Now, what if it's the other way around? | 09:30 |
| StevenK | parent moves and child doesn't | 09:30 |
| wgrant | In one of the directions, creating a new series is going to magically add more packages into an older series' packageset. | 09:30 |
| StevenK | Yes, adding more children is dangerous | 09:31 |
| === almaisan-away is now known as al-maisan | ||
| al-maisan | 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:33 |
| wgrant | al-maisan: Yes. | 09:34 |
| wgrant | But there's nothing in PackagesetInclusion to require that. | 09:34 |
| wgrant | 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 |
| al-maisan | 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 |
| wgrant | 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:35 |
| al-maisan | 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 |
| wgrant | al-maisan: Pretty much. | 09:36 |
| wgrant | I'm not sure how much of a risk it is. | 09:37 |
| wgrant | But it needs to be examines. | 09:37 |
| StevenK | Well, we could run a query on staging? | 09:37 |
| wgrant | There shouldn't be any data like that now. | 09:37 |
| wgrant | But some could spring up in the future. And then i-f-p does something very confusing and dangerous without telling anybody. | 09:38 |
| wgrant | We might just ignore the risk. But we need to explicitly decide that. | 09:38 |
| StevenK | Well, currently, i-f-p does nothing of the sort? | 09:38 |
| wgrant | Once it starts copying PsI it will. | 09:39 |
| al-maisan | Packageset._addDirectSuccessors() (in lib/lp/soyuz/model/packageset.py, line 114) could be refined to prevent that from happening | 09:39 |
| wgrant | al-maisan: Having that restriction outside the DB makes me sad, but I guess it's the best that can be done. | 09:39 |
| al-maisan | .. and a db constraint on INSERT/BEFORE into PackagesetInclusion could be easily formulated | 09:40 |
| al-maisan | hmm .. there is already an INSERT/AFTER trigger on packagesetinclusion : packagesetinclusion_inserted_trig | 09:41 |
| * al-maisan never tried having a trigger before *and* after an INSERT on the same table | 09:42 | |
| wgrant | I guess that's there to update flatpackagesetinclusion. | 09:42 |
| wgrant | Yep. | 09:42 |
| al-maisan | I'll do a quick test when I have some spare time and let you know | 09:42 |
| al-maisan | 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 |
| StevenK | I don't see why that would be an issue, personally | 09:45 |
| al-maisan | if that works we could add the before insert trigger on packagesetinclusion and veto associations of package sets across distro series | 09:48 |
| wgrant | That seems to make sense. | 09:48 |
| wgrant | And it makes me less wary about breaking Ubuntu... | 09:49 |
| al-maisan | wgrant: maybe you could open a bug and I can look into it in the next couple of days..? | 09:49 |
| wgrant | al-maisan: If you could. If not, I can look at fixing it at some point. | 09:53 |
| * wgrant files. | 09:53 | |
| al-maisan | who ever gets to it first :) | 09:53 |
| wgrant | Bug #620989 | 09:55 |
| _mup_ | Bug #620989: Package sets can include sets in other series <Soyuz:New> <https://launchpad.net/bugs/620989> | 09:55 |
| al-maisan | thanks | 09:57 |
| al-maisan | for filing :) | 09:57 |
| wgrant | 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 |
| lifeless | mthaddon: hi; just wanted to say I'm really glad to hear we can move forward on the additional QA environment soonish. | 09:58 |
| lifeless | wgrant: looked entirely straight forward to me | 09:58 |
| mthaddon | lifeless: yep | 09:59 |
| lifeless | mthaddon: if there is anything I can do to make it simpler/unblock things, please shout! | 09:59 |
| mthaddon | will do | 09:59 |
| lifeless | mthaddon: separately | 10:00 |
| lifeless | do you know when we're likely to get edge moving again :) | 10:00 |
| lifeless | as in, is it waiting a dev to change something, or losa cycles, or cron? | 10:01 |
| mthaddon | lifeless: hmm, it was something spm was working on, but he was ill today - I'll get out and push | 10:02 |
| lifeless | thanks | 10:02 |
| StevenK | wgrant: I didn't hack on it, lifeless said there ways around it, but my lack of knowledge about Storm defeated me | 10:16 |
| wgrant | Ah, OK. | 10:17 |
| lifeless | is this evil ? | 10:18 |
| lifeless | milestones = search_results._store.find( | 10:18 |
| lifeless | the _store I mean | 10:18 |
| lifeless | why would that be needed? | 10:18 |
| wgrant | It's wrong. | 10:18 |
| lifeless | gmb: ^ yo, its in bugtask, I blame you. | 10:18 |
| lifeless | wgrant: what should it be ? | 10:18 |
| wgrant | Store.of(search_results) is the right way to spell that. | 10:18 |
| lifeless | its blowing up because DRS doesn't have that attribute | 10:18 |
| wgrant | But do you really want to do that rather than ISlaveStore(something)? | 10:19 |
| lifeless | I don't know | 10:19 |
| lifeless | I'm guessing it sometimes runs in posts | 10:19 |
| lifeless | and rather than explicit its trying to be magical. | 10:19 |
| * gmb has no idea why that's there. | 10:20 | |
| lifeless | magical magical goodness. 'goodness' | 10:20 |
| * gmb bzr blames... | 10:20 | |
| lifeless | I have only 46 failing tests with this bugtaskset overhaul | 10:20 |
| gmb | allenap, J'accuse! | 10:20 |
| lifeless | well | 10:20 |
| lifeless | 46 in my current reduce() phase | 10:20 |
| lifeless | I may have broken a tonne of other shit | 10:20 |
| allenap | gmb: What? :) | 10:21 |
| gmb | allenap, Using _store. Apparently, this is bad. | 10:21 |
| wgrant | _. 'nuff said. | 10:21 |
| allenap | gmb: Yeah, I agree. Did I do it? | 10:21 |
| lifeless | es | 10:21 |
| lifeless | and my patch to cut hundreds of queries out of the landscape milestone 'later' page loads is blowing up in there | 10:22 |
| lifeless | because DecoratedResultSet doth not have _store | 10:22 |
| gmb | allenap, Apparently. TBH, I just wanted lifeless to blame someone else so I could get back to my JS horrorshow uninterrupted. | 10:23 |
| lifeless | whats the magic env variable again, for SQL output | 10:23 |
| lifeless | LP_DEBUG_STORM or something? | 10:24 |
| allenap | lifeless: I guess Store.of(self) should work fine there. | 10:24 |
| wgrant | lifeless: LP_DEBUG_SQL and LP_DEBUG_SQL_EXTA, IIRC. | 10:26 |
| allenap | lifeless: LP_DEBUG_SQL and LP_DEBUG_SQL_EXTRA | 10:26 |
| wgrant | *EXTRA | 10:26 |
| lifeless | allenap: its a BugTaskSet | 10:31 |
| allenap | lifeless: Oh balls. | 10:31 |
| lifeless | allenap: I'm trying Store.of(self) | 10:32 |
| lifeless | allenap: well, this is a reason not to have Sets as currently conceived | 10:32 |
| lifeless | and instead collections which are more query builders yada yada yada | 10:32 |
| lifeless | it would be nice to have an explicit mapper structure | 10:32 |
| jml | jtv, before which stage? | 10:34 |
| jtv | jml otp | 10:34 |
| allenap | lifeless: One option is to modify the c.l.webapp.adapter.get_store adapter so that you can use IStore(search_results). | 10:38 |
| lifeless | allenap: well, if Store.of(DRS) works, then I'll use that. | 10:39 |
| allenap | lifeless: Ah, yes, that would be better. I just assumed it wouldn't :) | 10:39 |
| lifeless | allenap: is there any reason this can't ? | 10:40 |
| lifeless | I mean, I assume it will be pain and heartache | 10:40 |
| lifeless | the other question | 10:40 |
| lifeless | is that there is a query | 10:40 |
| lifeless | bringing in milestones already | 10:40 |
| jml | in any case, hello | 10:40 |
| lifeless | it seems nuts to me to be querying bugtasks, extracting IDs and throwing away th eobjects and then requerying for milestones | 10:41 |
| lifeless | why not use the other query as an alias | 10:41 |
| lifeless | and just do a single query | 10:42 |
| lifeless | jml: ho hai | 10:42 |
| allenap | 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:42 |
| lifeless | Decorated is what you mean, and yes, Isee that | 10:43 |
| lifeless | (I'm in a big hariry branch stormifying bugtaskset | 10:43 |
| lifeless | not entirely by choice | 10:43 |
| lifeless | anyhow, I'm going to take the 'do this later approach | 10:43 |
| lifeless | but I stand by my 'two queries here is nuts' comment | 10:44 |
| * lifeless encommenates | 10:48 | |
| allenap | 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:48 |
| lifeless | sqlobject | 10:49 |
| allenap | Possibly. | 10:50 |
| lifeless | hmm | 11:00 |
| lifeless | may be closing in on 'working'. zomg. | 11:00 |
| lifeless | jml: got a few ? | 11:01 |
| jml | lifeless, sure. | 11:01 |
| wgrant | lifeless: How much of the milestone index is SQL time? | 11:11 |
| lifeless | jml: you cut out | 11:13 |
| lifeless | wgrant: all of it | 11:13 |
| lifeless | wgrant: (more or lesss) | 11:13 |
| lifeless | wgrant: one query per private bug | 11:14 |
| wgrant | lifeless: Oh, I heard there was lots of Python. | 11:14 |
| wgrant | And that's why memcached was used. | 11:14 |
| lifeless | wgrant: see my perf tuesday mail this week | 11:14 |
| lifeless | yeah, not a memcache issue | 11:14 |
| === adeuring1 is now known as adeuring | ||
| lifeless | jml: https://edge.launchpad.net/~bobthebuilder | 11:32 |
| lifeless | gnight | 11:48 |
| jelmer | 'night lifeless | 11:51 |
| deryck | Morning, everyone. | 12:03 |
| === al-maisan is now known as almaisan-away | ||
| salgado | 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 <cleanup> <qa-needstesting> <tech-debt> <wellington> <Soyuz:Fix Committed by salgado> <https://launchpad.net/bugs/510892> | 12:25 |
| _mup_ | Bug #510894: Upload policy names are duplicated with the actual builds <cleanup> <qa-needstesting> <tech-debt> <wellington> <Soyuz:Fix Committed by salgado> <https://launchpad.net/bugs/510894> | 12:25 |
| bigjools | salgado: I think so, yes. | 12:25 |
| jml | how would I find out how many different pages we have? | 12:56 |
| jml | "find . -name '*.pt' | wc -l" gives me a rough approximation. | 12:57 |
| jml | sinzui, perhaps you'd know? | 13:02 |
| noodles775 | jml: the google analytics don't do that? (it's been a while since I've used it) | 13:02 |
| noodles775 | (assuming we've got the ga js code on each page) | 13:03 |
| jml | noodles775, by number of pages, I mean "bug-index" would count as one | 13:03 |
| jml | noodles775, would GA help with that? | 13:03 |
| noodles775 | jml: I'm not sure, but thought it would (given that each page has the ga js snippet)... | 13:04 |
| wgrant | Does GA know the page ID, or just the URL? | 13:05 |
| jml | nfi. | 13:05 |
| noodles775 | wgrant, jml: ah, sorry - I see what you mean now. | 13:05 |
| * jml is looking for the GA details. | 13:05 | |
| jml | getting a list of page ids would be a good start. | 13:08 |
| sinzui | jml google analytics is the best answers | 13:11 |
| jml | what makes up page ids? | 13:11 |
| wgrant | Class:+page | 13:12 |
| wgrant | Or you mean what calculates them? | 13:12 |
| jml | well, what I *actually* mean is "why isn't there a script I can run to get me a list" | 13:12 |
| jml | but yeah, what calculates them. | 13:12 |
| sinzui | jml: flacoste wrote it. It is object + view and I recall it does not work if we registered an object with a template | 13:14 |
| wgrant | sinzui: See constructPageID in c.l.w.publication | 13:15 |
| wgrant | Er. | 13:15 |
| wgrant | jml: ^^ | 13:15 |
| jml | wgrant, thanks. | 13:15 |
| wgrant | But not useful for your purposes :( | 13:15 |
| jml | useful enough. | 13:16 |
| jml | Now that I know how it's calculated, I bet I could extract the info I need from ZCA | 13:16 |
| wgrant | Well, views are just adapters, so yeah. | 13:19 |
| jml | although I guess there's no way of distinguishing views that are pages from views that are not. | 13:20 |
| wgrant | Well, lots that aren't will have 'portlet' in the view name. And most of the rest that aren't will have '-macros' in the template name. | 13:21 |
| jml | heuristics yay | 13:21 |
| wgrant | Yes :( | 13:21 |
| jml | ok. shelving this problem for now. perhaps after lunch, code review, meetings, email and my weekly organizational cleanup. | 13:24 |
| === mrevell is now known as mrevell-lunch | ||
| salgado | bigjools, I've got a branch which changes a bunch of tests that were relying on mixed uploads to not rely on that anymore, as those don't happen in practice. would you like to review it? | 13:40 |
| wgrant | I need to refactor stuff so we can remove most of those test uploads. | 13:44 |
| deryck | sinzui, hi. I'm having a poke at your email and branch about heat and bug counts now. | 13:57 |
| sinzui | deryck, thanks | 13:59 |
| === mrevell-lunch is now known as mrevell | ||
| deryck | sinzui, so if I'm playing locally, say at https://launchpad.dev/ubuntu/hoary/+needs-packaging ... | 14:20 |
| deryck | ah, crap. he has gone. | 14:20 |
| bigjools | salgado: I don't need to see that, you can use the OCR if you don't mind | 14:26 |
| salgado | bigjools, sure, that's fine with me | 14:27 |
| bigjools | cheers | 14:27 |
| === mthaddon changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 1 of 10.09 | PQM is OPEN | firefighting: - | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in irc://irc.freenode.net/#launchpad-reviews | mailman down approx 13:30 - 14:30 UTC for lucid upgrade | ||
| === almaisan-away is now known as al-maisan | ||
| deryck | sinzui, so I see two things that I believe will fix your need-packing page counts.... | 15:28 |
| deryck | sinzui, one is to move your calls to task.target.recalculateBugHeatCache() inside updateHeat, not setHeat.... | 15:28 |
| deryck | sinzui, and the other is that you need to filter out dupes as well as closed bugs. | 15:28 |
| sinzui | ahh@ | 15:29 |
| sinzui | deryck, thank you very much | 15:29 |
| sinzui | I had not considered dupes at all | 15:29 |
| deryck | sinzui, no worries. I'll reply on list, too, just for the sake of anyone else playing along. | 15:30 |
| === mthaddon changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 1 of 10.09 | PQM is OPEN | firefighting: - | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in irc://irc.freenode.net/#launchpad-reviews | ||
| === Ursinha is now known as Ursinha-lunch | ||
| === deryck is now known as deryck[lunch] | ||
| === Ursinha-lunch is now known as Ursinha | ||
| === al-maisan is now known as almaisan-away | ||
| jml | I'm stopping. | 19:17 |
| jml | Have a good weekend everyone. | 19:17 |
| lifeless | ciao | 19:47 |
| lifeless | whats the batch size trick again | 20:10 |
| lifeless | to turn batching off | 20:10 |
| mtaylor | merging accounts seems to lose karma ... | 20:13 |
| lifeless | how so | 20:19 |
| === Ursinha is now known as Ursinha-bbl | ||
| EdwinGrubbs | lifeless: what is LBYL? | 22:17 |
| lifeless | look before you leap | 22:21 |
| lifeless | aka EAFP | 22:23 |
| nigelb | European Association of Fish Pathologists? | 22:34 |
| lifeless | eaier to ask forgiveness than permission | 22:34 |
| nigelb | Aha | 22:34 |
| nigelb | lifeless: wait a minute, didn't I see you before I went to bed last night? | 22:35 |
| nigelb | long day/ | 22:35 |
| lifeless | theres a general pattern in python, and it applies to performance as well, where asking-in-advance can be slow (unless fancy caching is employed) compared to just doing the thing (but once and only once) | 22:35 |
| lifeless | nigelb: its 0935 here | 22:35 |
| nigelb | lifeless: ok, my mistake. 3 am. should sleep. | 22:36 |
| lifeless | :P | 22:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!