[00:02] <thumper> when I'm not trying to fix freaking annoying bugs that is
[00:05] <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:06] <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:07] <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:09] <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:12] <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:13] <mwhudson> 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] <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:18] <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:19] <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:20] <mwhudson> or not
[00:20] <wgrant> Why would run_all be committing?
[00:21] <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:22] <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:23] <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:24] <thumper> :(
[00:24] <thumper> nope
[00:24] <thumper> now links are being clicked and taken to translations sites
[00:25] <thumper> or other sites on a different subdomain
[00:25] <thumper> clucking bell
[00:27] <wgrant> Wasn't there a bit of a proposal a while ago to remove the individual rootsites?
[00:28] <thumper> I don't recall
[00:28] <thumper> vague recollections
[00:28] <thumper> but not likely
[00:28] <thumper> down to 19 failures
[00:32] <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:33] <mwhudson> wgrant: no
[00:33] <wgrant> Yay.
[00:33] <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:34] <wgrant> Yay.
[00:34] <wgrant> It still works correctly with tabs and breadcrumbs?
[00:36] <thumper> seems to
[00:36]  * thumper sighs
[00:39]  * thumper cries quietly
[00:41] <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:46] <thumper> 17 failures...
[00:53] <thumper> lib/canonical/launchpad/pagetests/basics/notfound-traversals.txt takes a LONG time to run
[00:53] <wgrant> But it's also deprecated.
[00:58] <thumper> but no one will remove it
[01:04]  * thumper taps fingers while the tests run....
[01:04] <thumper> again
[01:05] <jelmer> thumper: does CodeImport have any unittests?
[01:05] <thumper> it should do
[01:06] <thumper> lp.code.model.tests.test_codeimport
[01:06] <thumper> would be my first guess
[01:06] <thumper> and lp.code.stories.codeimport
[01:07] <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:09] <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:10] <wgrant> I admit that model/tests probably makes more sense, though.
[01:14] <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:15] <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:17] <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:18] <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:20] <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:21] <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:22] <thumper> ah FFS!!!
[01:22] <thumper> ✁☹
[01:23] <james_w> arghl OOPS-1693EA64
[01:24] <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:25] <mwhudson> james_w: luckily* the lp-oops application seems to have fallen over
[01:25] <wgrant> james_w: Hm, it wasn't tested?
[01:26] <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:40] <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:49] <thumper> :(
[01:49] <thumper> the counts that it adds up are taking over a second each
[01:49] <thumper> down to 6 failing tests
[02:00] <poolie> hello thumper
[02:01] <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:02] <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:10]  * thumper sighs
[02:10] <thumper> 4 failures...
[02:38] <thumper> 3 failures
[02:41] <thumper> 1 failure
[02:43] <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:44] <mwhudson> yeah, would be interesting
[02:44] <mwhudson> i wonder how many weave branches there are...
[02:46] <poolie> i think you should
[02:47] <thumper> ec2 landing now
[02:48] <mwhudson> thumper: congrats
[02:52] <thumper> phew
[02:53]  * thumper goes to have lunch
[05:59] <StevenK> wgrant: It makes me sad too. It also makes me sad that I'm missing a table.
[06:07] <wgrant> StevenK: Ah, PackageSetInclusion?
[06:07] <StevenK> wgrant: Yup
[06:08] <StevenK> I think I've figured out how to deal with that, too
[06:08] <StevenK> Two extra queries :-(
[06:11] <wgrant> Why so many?
[06:12] <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:19] <StevenK> wgrant: You don't agree, or I just confused you?
[06:20] <wgrant> You confused me.
[06:20] <wgrant> Then I decided to go and pester my useless project team.
[06:21] <wgrant> So, can you reword?
[06:22] <StevenK> wgrant: The problem is I have two many parent and child thing
[06:22] <StevenK> *things
[06:23] <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:24] <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:26] <wgrant> StevenK: I don't see how you could do it in two.
[06:28] <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:41] <wgrant> StevenK: How does my suggestion look?
[06:58] <StevenK> wgrant: I don't get how to expand <map old parent to new parent>
[07:00]  * mwhudson runs away, good weekend all
[07:04] <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:09] <wgrant> Ah, this is all within a parent-specific iteration. I seee.
[07:20] <StevenK> wgrant: So now you agree with me?
[07:21]  * StevenK heads to the doctors
[07:23] <wgrant> StevenK: Well, I don't think that loop should be there.
[07:24] <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:25] <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?
[08:36] <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:37] <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:38] <poolie> i want to find out how much people use old distroseries from our ppas
[08:39] <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:40]  * 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:41] <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:42] <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:43] <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:48] <poolie> and then summarize it myself
[08:48] <poolie> anyhow, that would be very nice
[08:49] <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:50] <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:51] <wgrant> It'll be good once it can actually be turned on safely.
[08:53] <adeuring> good morning
[09:12] <mrevell> Hello
[09:15] <jtv> hi mrevell!
[09:20] <StevenK> wgrant: But that doesn't cover the case of parent packageset being copied too
[09:21] <wgrant> StevenK: Hm, does PackagesetInclusion work across distroseries boundaries?
[09:21] <wgrant> I guess so :(
[09:23] <StevenK> wgrant: So you finally agree with me, or you have a better idea?
[09:27] <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:28] <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:29] <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] <wgrant> How do I copy that?
[09:29] <StevenK> The child packageset changes to maverick and the parent stays as karmic?
[09:30] <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:31] <StevenK> Yes, adding more children is dangerous
[09:33] <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:34] <wgrant> al-maisan: Yes.
[09:34] <wgrant> But there's nothing in PackagesetInclusion to require that.
[09:35] <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:36] <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:37] <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:38] <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:39] <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:40] <al-maisan> .. and a db constraint on INSERT/BEFORE into PackagesetInclusion could be easily formulated
[09:41] <al-maisan> 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] <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:45] <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:48] <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:49] <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:53] <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:55] <wgrant> Bug #620989
[09:55] <_mup_> Bug #620989: Package sets can include sets in other series <Soyuz:New> <https://launchpad.net/bugs/620989>
[09:57] <al-maisan> thanks
[09:57] <al-maisan> for filing :)
[09:58] <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:59] <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
[10:00] <lifeless> mthaddon: separately
[10:00] <lifeless> do you know when we're likely to get edge moving again :)
[10:01] <lifeless> as in, is it waiting a dev to change something, or losa cycles, or cron?
[10:02] <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:16] <StevenK> wgrant: I didn't hack on it, lifeless said there ways around it, but my lack of knowledge about Storm defeated me
[10:17] <wgrant> Ah, OK.
[10:18] <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:19] <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:20]  * 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:21] <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:22] <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:23] <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:24] <lifeless> LP_DEBUG_STORM or something?
[10:24] <allenap> lifeless: I guess Store.of(self) should work fine there.
[10:26] <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:31] <lifeless> allenap: its a BugTaskSet
[10:31] <allenap> lifeless: Oh balls.
[10:32] <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:34] <jml> jtv, before which stage?
[10:34] <jtv> jml otp
[10:38] <allenap> lifeless: One option is to modify the c.l.webapp.adapter.get_store adapter so that you can use IStore(search_results).
[10:39] <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:40] <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:41] <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:42] <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:43] <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:44] <lifeless> but I stand by my 'two queries here is nuts' comment
[10:48]  * 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:49] <lifeless> sqlobject
[10:50] <allenap> Possibly.
[11:00] <lifeless> hmm
[11:00] <lifeless> may be closing in on 'working'. zomg.
[11:01] <lifeless> jml: got a few ?
[11:01] <jml> lifeless, sure.
[11:11] <wgrant> lifeless: How much of the milestone index is SQL time?
[11:13] <lifeless> jml: you cut out
[11:13] <lifeless> wgrant: all of it
[11:13] <lifeless> wgrant: (more or lesss)
[11:14] <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:32] <lifeless> jml: https://edge.launchpad.net/~bobthebuilder
[11:48] <lifeless> gnight
[11:51] <jelmer> 'night lifeless
[12:03] <deryck> Morning, everyone.
[12:25] <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:56] <jml> how would I find out how many different pages we have?
[12:57] <jml> "find . -name '*.pt' | wc -l" gives me a rough approximation.
[13:02] <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:03] <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:04] <noodles775> jml: I'm not sure, but thought it would (given that each page has the ga js snippet)...
[13:05] <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:08] <jml> getting a list of page ids would be a good start.
[13:11] <sinzui> jml google analytics is the best answers
[13:11] <jml> what makes up page ids?
[13:12] <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:14] <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:15] <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:16] <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:19] <wgrant> Well, views are just adapters, so yeah.
[13:20] <jml> although I guess there's no way of distinguishing views that are pages from views that are not.
[13:21] <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:24] <jml> ok. shelving this problem for now. perhaps after lunch, code review, meetings, email and my weekly organizational cleanup.
[13:40] <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:44] <wgrant> I need to refactor stuff so we can remove most of those test uploads.
[13:57] <deryck> sinzui, hi.  I'm having a poke at your email and branch about heat and bug counts now.
[13:59] <sinzui> deryck, thanks
[14:20] <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:26] <bigjools> salgado: I don't need to see that, you can use the OCR if you don't mind
[14:27] <salgado> bigjools, sure, that's fine with me
[14:27] <bigjools> cheers
[15:28] <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:29] <sinzui> ahh@
[15:29] <sinzui> deryck, thank you very much
[15:29] <sinzui> I had not considered dupes at all
[15:30] <deryck> sinzui, no worries.  I'll reply on list, too, just for the sake of anyone else playing along.
[19:17] <jml> I'm stopping.
[19:17] <jml> Have a good weekend everyone.
[19:47] <lifeless> ciao
[20:10] <lifeless> whats the batch size trick again
[20:10] <lifeless> to turn batching off
[20:13] <mtaylor> merging accounts seems to lose karma ...
[20:19] <lifeless> how so
[22:17] <EdwinGrubbs> lifeless: what is LBYL?
[22:21] <lifeless> look before you leap
[22:23] <lifeless> aka EAFP
[22:34] <nigelb> European Association of Fish Pathologists?
[22:34] <lifeless> eaier to ask forgiveness than permission
[22:34] <nigelb> Aha
[22:35] <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:36] <nigelb> lifeless: ok, my mistake.  3 am.  should sleep.
[22:42] <lifeless> :P