[00:09] <thumper> rinze: new nick jelmer?
[00:10] <rinze> thumper: Two nicks :-) One I use for work channels and one for non-work channels in an attempt to keep the two more separate
[00:10] <rinze> obviously I'm failing since it's midnight here
[00:10] <thumper> rinze: :)
[00:11] <thumper> rinze: and you are in a work channel
[00:12] <wgrant> rockstar: What are the security concerns with 'run' in recipes?
[00:12] <wgrant> We already run it in a secure environment.
[00:39] <rinze> thumper: are code imports for packaging branches on the roadmap for the near future?
[00:39] <thumper> rinze: not the immediate future
[00:41] <wgrant> Lots of the work was done earlier in the year, though.
[00:45] <rinze> wgrant: not related to code imports for packaging branches..
[00:46] <rinze> (I'm not complaining, regular code imports work quite well too)
[00:48] <wgrant> rinze: IIRC james_w removed lots of roadblocks relating to that.
[00:48] <mwhudson> newImport is on IBranchTarget now isn't it?
[00:49] <wgrant> I'm not sure if it got finished, but it was mostly done.
[00:49] <rinze> ah, I didn't realize that
[00:49] <rinze> James is everywhere :-)
[00:49] <wgrant> He is.
[00:53] <mwhudson> you might be able to create code imports for package branches over the api already
[00:54] <wgrant> I wonder how happy the UI will be about that.
[00:55] <mwhudson> https://edge.launchpad.net/+apidoc/devel.html#source_package-newCodeImport
[00:55] <mwhudson> possibly not very
[00:56] <wgrant> It's possible it will be fine.
[00:56] <wgrant> But if it was working, I would have thought we'd see some of these imports around.
[00:56] <mwhudson> mm, might be ok
[00:57] <mwhudson> someone should try it on staging :-)
[00:57]  * rinze is about to
[01:02] <rinze> mwhudson: w00t, that works
[01:02] <rinze> https://code.staging.launchpad.net/debian/experimental/+source/tdb
[01:02]  * rinze hugs james_w
[01:03] <mwhudson> cool
[01:03] <wgrant> Excellent.
[01:04] <rinze> mwhudson: thanks!
[01:04]  * rinze gets some sleep
[01:04] <mwhudson> even https://code.staging.launchpad.net/+code-imports?field.review_status=NEW&field.review_status-empty-marker=1&field.rcs_type=&field.rcs_type-empty-marker=1&submit=Submit+Query works
[01:05]  * mwhudson approves the branch, lets see if the staging code import infrastructure has rotted and died again
[01:23] <mwhudson> seems not
[01:23] <wgrant> Yep.
[01:23] <wgrant> Although codebrowse is unhappy with it.
[01:23] <mwhudson> oh?
[01:23] <mwhudson> boo
[01:23] <wgrant> Try to browse into debian/
[01:24] <wgrant> Hmm.
[01:24] <mwhudson> yeah, strange
[01:25] <mwhudson> http://bazaar.staging.launchpad.net/~jelmer/debian/experimental/tdb/experimental/files/head:/debian/patches is ok though
[01:26] <wgrant> Odd.
[01:35] <mwhudson> looks like a loggerhead bug
[01:38] <wgrant> spm: Hi. There's an upload failure caused by a buildd-manager bug that requires some time-sensitive debugging. Do you have a few minutes?
[01:39] <spm> wgrant: sure
[01:39] <wgrant> spm: Firstly, when does librarian-gc run?
[01:39] <wgrant> it destroys the evidence (which was why the debugging failed last time)
[01:39] <spm> "regularly", let me verify
[01:41] <spm> once a day, 6pm server
[01:41] <wgrant> That was 7ish hours ago?
[01:42] <spm> ath too hard; kcalc; yes.
[01:42] <spm> *math
[01:42] <wgrant> If so, it may not have erased everything yet. Yay.
[01:42] <spm> heh
[01:43] <wgrant> So, https://edge.launchpad.net/ubuntu/+source/qt4-x11/4:4.7.0~beta2-0ubuntu2/+build/1879966 somehow succeeded once, then succeeded again.
[01:43] <wgrant> It shouldn't have run again after it succeeded the first time, of course.
[01:44] <wgrant> Can you check how many LFAs there are with the filename 'buildlog_ubuntu-maverick-powerpc.qt4-x11_4:4.7.0~beta2-0ubuntu2_BUILDING.txt.gz', and how many with the filename 'buildlog_ubuntu-maverick-powerpc.qt4-x11_4:4.7.0~beta2-0ubuntu2_FULLYBUILT.txt.gz'?
[01:44] <wgrant> (the buggy retry unlinks the log LFAs, so we can't tell what's gone on through the UI, and they get destroyed by librarian-gc as soon as it runs)
[01:45] <wgrant> But they should still be around at the moment.
[01:45] <wgrant> Since the event was roughly 6 hours ago.
[01:46] <spm> so it succeeeded twice? that's a nice trick.
[01:46] <wgrant> Yes.
[01:47] <wgrant> And the second time failed to upload, since the files were already uploaded.
[01:47] <mwhudson> well
[01:47] <wgrant> And because the Soyuz data model is awesome, there's no record in the DB of the first attempt, except for the orphaned LFAs.
[01:47] <mwhudson> if it succeeded the first time it should succeed the second time too :-)
[01:47] <mwhudson> it's the retry that's mysterious
[01:48] <spm> It's a Miracle, perhaps?
[01:51] <wgrant> Do you want queries for my above request?
[01:53] <wgrant> SELECT * FROM libraryfilealias WHERE filename IN ('buildlog_ubuntu-maverick-powerpc.qt4-x11_4:4.7.0~beta2-0ubuntu2_FULLYBUILT.txt.gz', 'buildlog_ubuntu-maverick-powerpc.qt4-x11_4:4.7.0~beta2-0ubuntu2_BUILDING.txt.gz');
[01:53] <spm> if you can that'd be wonderful - just got pulled into a U1 deploy/update thingy...
[01:54] <wgrant> Ah, you can do that. This isn't so critical now I know there's a while until librarian-gc runs.
[01:55] <spm> so generous of you! ;-)
[01:56] <wgrant> Heh, sorry. Just the last couple of times we've tried to catch this, we've been too late.
[01:56] <spm> nod
[01:56] <spm> http://paste.ubuntu.com/467277/ fwiw
[01:57] <wgrant> Thanks.
[01:59] <spm> yarp; and they're both still live too
[02:00] <wgrant> Yeah. Unfortunately the it looks like the first occurence of the issue with this build was a couple of days ago, and it was just retried again this morning.
[02:00] <spm> curious: The following NEW packages will be installed: libdconf0 libmpfr4 <== the latter is new
[02:00] <wgrant> So we are again too late.
[02:01] <wgrant> spm: Um, you're running maverick?
[02:01] <spm> I'm not, no.
[02:01] <wgrant> Those two are only in maverick...
[02:01]  * spm raises eyebrows
[02:57] <wgrant> +class ILaunchpadPublicationDirective(IRequestPublicationDirective):
[02:57] <wgrant> +
[02:57] <wgrant> +    priorty = Int(required=False)
[02:57] <wgrant> I don't think that's how one spells 'priority'. Does this mean that interface doesn't actually do anything?
[02:58] <mwhudson> wgrant: oops
[02:59] <wgrant> Heh.
[03:00] <mwhudson> yes, the interface is in fact not required
[03:10] <mwhudson> wgrant: want to review a branch in a sec? :-)
[03:11]  * wgrant isn't a reviewer yet...
[04:27] <lifeless> wgrant: we should fix that
[04:29] <lifeless> Ursinha: still up ?
[04:29] <Ursinha> haha yes sir
[04:29] <Ursinha> I wanted to talk to you
[04:30] <lifeless> when should we use the oops tag? (bug 607879)
[04:30] <_mup_> Bug #607879: https://bugs.edge.launchpad.net/~person/+participation timeouts <timeout> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/607879>
[04:30] <Ursinha> about a timeout bug
[04:30] <lifeless> oh oh, I'm in trouble ;)
[04:30] <Ursinha> lifeless, timeout implies oops
[04:30] <Ursinha> so it's redundant to tag timeout and oops
[04:30] <lifeless> Ursinha: So, I was following https://dev.launchpad.net/PolicyAndProcess/ZeroOOPSPolicy
[04:30] <Ursinha> lifeless, and I love you for that, but let me read the page
[04:31] <Ursinha> lifeless, "It should be tagged with either 'oops' or 'timeout' on it."
[04:31] <lifeless> Ursinha: I'll stop using both on the same tag
[04:31] <Ursinha> that?
[04:32] <lifeless> yeah, i think its a little subtle
[04:32] <lifeless> I mean, to me the value in a oops tag is that one can look at the tag and get all oops related bugs
[04:32] <lifeless> but if it causes some script/reporting issue its obviously better to have only one, which is what I'm guessing is the issue?
[04:33] <Ursinha> lifeless, is it hard to get bugs tagged oops and timeout at once?
[04:33] <Ursinha> I mean, the two sets
[04:34] <Ursinha> lifeless, I was pondering about having only one tag to fetch all oops bugs, but I guess lp lets you query bugs with one or another tag very easily
[04:35] <lifeless> Ursinha: well, theres quite a few tagged both before my filing efforts yesterday
[04:35] <lifeless> it would be easy to clean the data up
[04:35] <Ursinha> really? why?
[04:35] <lifeless> I don't know, it was just like that
[04:36] <lifeless> (I think)
[04:36] <lifeless> <- 0536, not 100% awake yet
[04:36] <Ursinha> :)
[04:36] <lifeless> anyhow - I'll check and fix today, thats easy.
[04:37] <Ursinha> lifeless, that's ok, not that critical, just trying to be consistent as I know that some scripts that fetch stats consider them separately
[04:37] <lifeless> yup
[04:37] <Ursinha> lifeless, about the timeout bug
[04:37] <lifeless> I'm not panicking on it, I'm just rectifying something I've made a little worse.
[04:37] <lifeless> easy
[04:38] <lifeless> ok, about the bug - which one ?
[04:38] <Ursinha> finding the number, just a min
[04:40] <Ursinha> lifeless, bug  607879, that you filed for +participation timeouts
[04:40] <_mup_> Bug #607879: https://bugs.edge.launchpad.net/~person/+participation timeouts <timeout> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/607879>
[04:40] <lifeless> ok
[04:40] <Ursinha> I see that now this bug is linked to another oops, the most offender in timeouts list, like https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1662A100
[04:41] <lifeless> I think thats the oopstools confusion
[04:41] <lifeless> I put the link in on a more suitable oops, I'm sure
[04:42] <lifeless> yeah, I did - the ones in the bug at the top
[04:42] <Ursinha> I wanted to know if they're related somehow, of if the correct bug for this oops is bug 424671
[04:42] <_mup_> Bug #424671: attachments: accessing attachment's message is very slow <api> <performance> <Launchpad Foundations:Triaged by leonardr> <https://launchpad.net/bugs/424671>
[04:42] <lifeless> they are only related by being 'timeout' errors with 'select' in the exception value
[04:42] <lifeless> e.g. not related at all
[04:42] <Ursinha> right
[04:43] <Ursinha> that bug in oops-tools is really annoying
[04:43] <lifeless> yes
[04:43] <Ursinha> the timeouts count is ultrahigh, I guess that bug needs some more attention
[04:44] <lifeless> gmb had a fix in the pipeline
[04:44] <lifeless> but went on leave
[04:44] <lifeless> and now deryck is too
[04:44] <lifeless> is bryceh at the rally? or brian? I can ping them
[04:45] <bryceh> lifeless, nope we're both in PDX
[04:45] <lifeless> ok, I might see about moving it forward today
[04:45] <Ursinha> cool lifeless
[04:46] <lifeless> perhaps you can pick it up my afternoon and drive it? its kindof killing leanne :)
[04:46] <Ursinha> thanks
[04:46] <Ursinha> lifeless, 'you' me or bryceh?
[04:46] <lifeless> bryceh
[04:46] <lifeless> or brian
[04:47] <lifeless> now where did the branch go
[04:47]  * bryceh needs to learn to keep his fat mouth shut
[04:47] <Ursinha> haha
[04:47] <Ursinha> lifeless, the bug that should be fixed in oops tools is bug 461269
[04:48] <_mup_> Bug #461269: oops reports should be grouped by oops signature not exception type and exception value <OOPS Tools:Triaged> <https://launchpad.net/bugs/461269>
[04:48] <Ursinha> but I guess I already told you that
[04:49] <Ursinha> this bug is kinda critical to our ZeroOopsPolicy to happen :/
[04:54] <lifeless> is matsubara's branch insufficient?
[04:55] <Ursinha> lifeless, no idea. he'll be back today and I'll ask him.
[04:56] <lifeless> Ursinha: revno 11156 in devel
[04:56] <lifeless> Ursinha: should fix that attachments thing
[04:56] <Ursinha> lifeless, cool
[04:56] <lifeless> so I'll test it on edge and if its better there, organise a CP
[04:58] <lifeless> meep: http://www.zdnet.com/blog/security/dell-ships-motherboard-with-malicious-code/6901?tag=nl.e589
[05:00] <wgrant> Awesome...
[05:04] <lifeless> bryceh: http://pastebin.com/GTc6Y1LY
[05:04] <lifeless> bryceh: I have /no/ idea how I seem to have triggered these failures in bugs
[05:04] <lifeless> I haven't changed templates
[05:05] <Ursinha> I'm going to sleep a bit
[05:05] <lifeless> gnight
[05:05] <Ursinha> bye lifeless
[05:06] <lifeless> wgrant: or perhaps you have some idea?
[05:07] <lifeless> wgrant: oh oh, excellent you're up - you wouldn't happen to be willing to qa something for me ?
[05:07] <wgrant> lifeless: Sure.
[05:07] <wgrant> Also, looking at that traceback now...
[05:08] <lifeless> wgrant: make an api call to https://api.launchpad.net/1.0/bugs/414746/attachments - it should boom; make the same to edge - if it works, we have a CP we need to do.
[05:08] <_mup_> Bug #414746: speakers cannot be muted when using headphones regression (karmic) <apport-bug> <apport-collected> <i386> <regression-release> <pulseaudio (Ubuntu):Confirmed> <https://launchpad.net/bugs/414746>
[05:09] <wgrant> Most of the diff is crap -- the problem with the first and last is that the mailto: stuff is missing.
[05:09] <lifeless> ok
[05:09] <lifeless> well thats due to having ubuntu as a stopword now, I think
[05:09] <lifeless> so I'll just nuke that
[05:09] <wgrant> Ah.
[05:10] <wgrant> lifeless: Timed out on edge for me.
[05:10] <lifeless> darn
[05:10] <wgrant> OOPS-1664ED389
[05:10] <wgrant> Worked the second time, though.
[05:10] <lifeless> ok, give that a few minutes and I'll get another bug up
[05:10] <lifeless> well, thats an improvement
[05:10] <lifeless> != fixed though
[05:10] <wgrant> Still fails on production.
[05:10] <lifeless> gawd yes
[05:11] <lifeless> lib/lp/bugs/tests/../stories/guided-filebug/xx-sorting-by-relevance.txt is still naffed, hmm
[05:12] <wgrant> Right, I'm not sure about that one.
[07:10] <lifeless> turns out it was one extra row missing or so
[07:10] <lifeless> I'm going to do a follow up patch to remove all filtering of terms
[08:30] <lifeless> losa ping
[08:30] <mthaddon> lifeless: can you give us a few - in a review meeting atm
[08:30] <lifeless> of course
[08:31] <lifeless> take as long as needed
[08:31] <mthaddon> thx
[08:33]  * wgrant is also interested on when Lucid's happening.
[08:34] <wgrant> Since there's a dpkg issue that's fixed there.
[08:43] <lifeless> \o/ rockstar your bugs all came through qa bot just now ;)
[08:44] <lifeless> flacoste: are you still around ?
[08:45] <lifeless> flacoste: if so, could you, if you agree, move rt 40477 and 40480 both to pri 88, and drop rt 40403 to pri 87, and nuke rt 31058
[09:00] <mrevell> Hey
[09:09] <lifeless> hi mrevell
[09:10] <mrevell> Hey there lifeless
[09:17] <mthaddon> lifeless: what did you need?
[09:18] <lifeless> I wanted to see if I could help with the slony packages thing
[09:18] <lifeless> either by doing, or perhaps talking with the server team folk here who are keen to offer assistance for backports and things like that that we need
[09:19] <maxb> did my backports not work?
[09:19] <mthaddon> lifeless: ah, spm (who's just EODed) is working on that one, and I believe have made some better progress on it today
[09:20] <lifeless> maxb: I think they did, but its a ppa and versioning + availability of old builds trickiness
[09:20] <lifeless> maxb: or something like that
[09:21] <lifeless> mthaddon: ok.
[09:22] <mthaddon> lifeless: although the lucid buildbot instance has been failing consistently for a few days now (had meant to chase someone about that) which would be a problem for lucid upgrades
[09:22] <lifeless> mthaddon: well if you need help of any sort; please let me know :- on the packages side Jos has made it clear that he considers his team are here to support us; on other sides - well, I have the odd trick up my sleeve
[09:22] <lifeless> mthaddon: I believe mars looked at that overnight; will see if there is a bug and if not make one.
[09:22] <mthaddon> cool, thx
[09:23] <spm> lifeless: before I go eat, and despite my EOD'd nature; yeah. it's just been a tad fiddly, and a bit of a learning experience for me. I am *hopeful* that the next submissions (early tomorrow I hope) will succeed, and then progress will occour.
[09:23] <lifeless> spm: thanks!
[09:24] <spm> the most recent build was a fail, becuase it built the pg 8.3, with a dependancy on pg 8.4. which is um... bad.
[09:25] <lifeless> spm: the packages, or bb ?
[09:35] <lifeless> stub: around ?
[09:35] <stub> physically, yes.
[09:35] <lifeless> whats he wiki page that the lp dependency deb updates is documented on ?
[09:36] <lifeless> seems i doesn't mention doing hardy as well as lucid atm
[09:36] <lifeless> brb
[09:36] <stub> LaunchpadPPA
[09:41] <rinze> gmb: Hi
[09:41] <gmb> rinze, Morning.
[09:41] <gmb> hurrah for /whois
[09:43] <rinze> gmb: There's a buildbot failure for db_lp in bugtask-search.txt. It looks spurious but caused by the fact there is no sorting done before printing.
[09:43] <rinze> gmb: I was wondering if you could confirm that - https://lpbuildbot.canonical.com/builders/db_lp/builds/971/steps/shell_7/logs/summary
[09:44] <gmb> rinze, Yeah, that looks to be the case.
[09:44] <gmb> Thought we'd fixed all of those.
[09:45] <gmb> rinze, Want me to take care of it or are you already in the process.
[09:46] <rinze> gmb: I was already in the process of getting a branch up.
[09:46] <gmb> rinze, Okay, cool.
[10:02] <rinze> gmb: Reading the doctest in more detail I'm wondering if simply sorting wouldn't defeat the test - it asserts that bug #9 is on top of the list.
[10:02] <_mup_> Bug #9: Rosetta's po parser is too strict <Launchpad Translations:Fix Released by carlos> <https://launchpad.net/bugs/9>
[10:02] <gmb> Gaaargh.
[10:03] <rinze> gmb: Does the order not matter for the other bugs ?
[10:06] <gmb> rinze, From reading the test I think not. But it's spectacularly unclear.
[10:06] <gmb> *why* is it printing out bugtask ids? Hell's teeth.
[10:07] <gmb> rinze, So, yes, sorting would defeat the object of the test
[10:07] <gmb> Because the test is that things are sorted properly.
[10:07] <gmb> So there's some bigger underlying cause here.
[10:09] <rinze> gmb: Any chance you could take over? I can handle adding a trivial sorted() call somewhere, but this looks more complex.
[10:09] <gmb> rinze, Sure.
[10:38] <lifeless> gmb: oh hai
[10:38] <lifeless> gmb: aren't you on leave?
[10:39] <gmb> lifeless, Yesterday I was. Working today and tomorrow then I'm on leave for two weeks.
[10:39] <lifeless> qargh
[10:39] <lifeless> testfix ?
[10:40] <rinze> lifeless: https://lpbuildbot.canonical.com/builders/db_lp/builds/971/steps/shell_7/logs/summary
[10:41] <lifeless> hmm
[10:41] <lifeless> gmb: tell me about that ^
[10:41] <lifeless> I have a branch changing bug stuff, so I can put a fix in too
[10:42] <gmb> lifeless, I'm trying to look at it now but it's taking an age to update my local copy of db-devel.
[10:42] <gmb> lifeless, It looks like something broke with the ordering of search results. Will know more shortly, hopefully.
[10:43] <lifeless> they are ordered by fti
[10:43] <lifeless> aren't they ?
[10:43] <lifeless> gmb: I'm about to land my malone branch - it passed ec2land
[10:44] <lifeless> oh, so heat is intended too
[10:44] <lifeless> why does db-devel builds break devel ?
[10:45] <gmb> lifeless, The test that's failing tests that ordering by '-number_of_duplicates' works properly. Which it apparently doesn't any more. Can't say why, yet.
[10:45] <gmb> lifeless, I think it's a stop-the-line measure. One builder breaks, everything stops.
[10:45] <gmb> (Which is why trying to get my CP for initial_message landed was such a ballache)
[10:47] <lifeless> gmb: which, btw, isn't enough.
[10:47] <gmb> lifeless, Yeah, we figured as much on Tuesday IIRC.
[10:50] <lifeless> also
[10:50] <lifeless> holy fuck searchTasks
[10:52] <lifeless> rev 11188 is a candidate
[10:52]  * gmb looks while make schema runs
[10:53] <lifeless> its changing duplicate bug logic
[10:53] <gmb> AAAAA.
[10:53] <gmb> Yep.
[10:54] <lifeless> cause I'm keen to get this landed, I'd love to put a one-liner in my branch and shove it through ;)
[10:55] <gmb> shame deryck made duplicateof readonly :)
[10:56] <gmb> I wonder whether this is as simple as a db flush that needs to happen.
[10:56] <gmb> Mind you, there's already a flush_database_updates() call in there. Hmm.
[10:57]  * gmb adds a transaction.commit() for good measure
[10:57] <lifeless> how dnah
[10:57] <bigjools> urgh, death to commit in tests
[10:57] <gmb> lifeless, yeah, didn't work anyway :)
[10:57] <lifeless> doubt that thats it - you're calling into model code directly.
[10:58] <gmb> True.
[10:59] <wgrant> bigjools: The master/slave split means we have to, though...
[11:00] <wgrant> bigjools: I wish there was a way around that.
[11:00] <bigjools> there isn't
[11:00] <wgrant> Damn.
[11:00] <bigjools> we still have a lot of tests doing commit() unnecessarily though
[11:00] <wgrant> Well.
[11:00] <gmb> Agreed.
[11:01] <bigjools> I'm considering the idea of having another master store for derived distros actually
[11:01] <wgrant> There are two reasons I know of: 1) librarian 2) slave store
[11:01] <wgrant> Are there any other reasons left?
[11:01] <bigjools> not that I know about
[11:01] <bigjools> we can fix (1) in tests
[11:01] <wgrant> How?
[11:02] <bigjools> make the file available in the librarian right away
[11:02] <lifeless> you may be misunderstanding the issue there
[11:02] <wgrant> I guess.
[11:03] <lifeless> although, read committed may workaround it
[11:03] <bigjools> the issue is that when we use slave stores to read data, we have to commit to get them to sync
[11:03] <bigjools> and I think that's a good thing to still have to do in tests
[11:04] <wgrant> Apart from the fact it's slow.
[11:04] <bigjools> indeed
[11:05] <gmb> lifeless, Ah, interesting. Bug 10 is marked as a dupe of bug 9, but bug 9's number_of_duplicates is still zero. It should be 1; that's why the sorting's off.
[11:05] <_mup_> Bug #10: It says "displaying matching bugs 1 to 8 of 8", but there is 9 <Launchpad Bugs:Invalid> <https://launchpad.net/bugs/10>
[11:05] <_mup_> Bug #9: Rosetta's po parser is too strict <Launchpad Translations:Fix Released by carlos> <https://launchpad.net/bugs/9>
[11:05] <_mup_> Bug #9: Rosetta's po parser is too strict <Launchpad Translations:Fix Released by carlos> <https://launchpad.net/bugs/9>
[11:05] <gmb> Shut up you stupid bot
[11:05] <lifeless> gmb: so the aggregation is failing
[11:06] <lifeless> is number_of_dupes a cached value - either db or model ?
[11:06] <gmb> lifeless, Well, I think that it's a trigger that's failing to be run for some reason.
[11:06] <lifeless> gmb: or a bug in the trigger :P
[11:06] <gmb> I'm checking now.
[11:06] <gmb> Yeah.
[11:08] <lifeless> yeah ?
[11:08] <gmb> lifeless, The triggered function *looks* fine (database/schema/trusted.sql:917)
[11:08] <gmb> lifeless, That was a sort of "yes, that's possible" noise.
[11:08] <gmb> I can't express "ugnh" properly in textual form
[11:09] <lifeless> no, its wrong
[11:09] <bigjools> stub: what do you think to the idea of having a new master store for derived distributions?  I am concerned about the load they'll put on the DB when doing everything a distro needs to do.
[11:09] <gmb> lifeless, Really?
[11:09] <lifeless> gmb: totally
[11:09] <gmb> lifeless, Maybe I'm just not caffeined-up enough yet. Why?
[11:10] <lifeless> bigjools: I'm keen on sharding/partitioning; I think you'll find that that isn't going to split out terribly well with our current setup; also I think the load isn't a huge concern in the short term - we are write limited yes, but we can reduce IO massively by fixing a few bugs.
[11:10] <lifeless> gmb: because
[11:10] <lifeless> gmb: voice?
[11:11] <lifeless> I really want a whiteboard for this
[11:11] <bigjools> lifeless: why do you think it won't split?
[11:11] <bigjools> the write load that Soyuz generates is huge, BTW.
[11:11] <lifeless> because you have links throughout the system that are doing FK's
[11:11] <lifeless> and slony isn't a multi-master system
[11:11] <gmb> lifeless, Sure. Though be warned, I'm in a coffee shop, so there may be bean-grinding and child noises.
[11:11] <wgrant> Why is the write load so huge?
[11:12] <wgrant> The read load is certainly massive.
[11:12] <gmb> lifeless, Skype, mumble?
[11:12] <lifeless> gmb: skype; id ?
[11:12] <bigjools> publisher for starters
[11:12] <gmb> lifeless, binnsgm. Starting it now.
[11:12] <stub> bigjools: It might actually make things better. At the moment, we have 31 distributions but almost the entire database is linked to just 1 (Ubuntu). This can give us some wonky query plans.
[11:12] <wgrant> bigjools: How's that write-heavy?
[11:12] <wgrant> It just touches a couple of fields on a few publications.
[11:12] <bigjools> a lot of publications
[11:12] <wgrant> It's going to be doing less than the thing that sends bug notifications.
[11:13] <bigjools> the scripts also mostly use the master DB out of necessity
[11:13] <wgrant> True.
[11:13] <bigjools> which is part of what I meant by write load I guess
[11:14] <wgrant> The publisher doesn't need to be as bad as it is.
[11:14] <bigjools> undoubtedly!
[11:14] <bigjools> I'd like to pipeline it
[11:15] <wgrant> We need to work out what to do about index generation.
[11:15] <wgrant> Everything else is pretty quick.
[11:16] <wgrant> (apart from source domination, but that's a trivial fix)
[11:17] <bigjools> for indexes we can just append to Packages/Sources
[11:17] <wgrant> But what exactly do you mean by pipelining?
[11:17] <bigjools> the opposite of batching like we do now
[11:17] <wgrant> I considered that... but we have to regenerate them some time.
[11:17] <elmo> bigjools: gah, that's such a bad bad bad tradeoff
[11:18] <bigjools> yes, we can do it occasionally
[11:18] <bigjools> elmo: why?
[11:18] <elmo> you're trading CPU time on one server (ours) for increased download time for millions and millions of users
[11:19] <bigjools> so then we also need incremental updates - isn't there something that does that already?
[11:19] <elmo> yes, but it's crack and also pessmizes things for users
[11:19] <wgrant> pdiffs aren't really awesome.
[11:19] <elmo> but I also don't buy the argument that the answer to 'append sucks' is incremental updates
[11:19] <elmo> the answer is 'don't do append'
[11:20] <bigjools> why?
[11:20] <elmo> because it's not expensive to actually write a packages file in a non-append fashion
[11:20] <elmo> apt-ftparchive is slow, yes, that doesn't mean doing non-append packages file generation will always be slow
[11:20] <wgrant> At the moment it is. But I should work out how to effectively benchmark my caching experiments from earlier in the year.
[11:21] <bigjools> someone told me that a-f is actually quick, it's generating its input files that's slow
[11:21] <elmo> bigjools: they're lieing
[11:21] <wgrant> Both parts are slow.
[11:21] <elmo> and/or confused and/or stupid
[11:21] <wgrant> The publisher logs make that clear.
[11:21] <elmo> or some combination thereof
[11:21] <bigjools> where that someone was Celso after he wrote the PPA publisher
[11:21] <wgrant> Generating input files was much slower.
[11:21] <elmo> yeah, and I've had this argument before with Celso
[11:21] <bigjools> ok
[11:21] <wgrant> But cprov apparently cut that time a lot just before he left.
[11:22] <lifeless> gmb: http://pastebin.com/FUgp9kHc
[11:22] <lifeless> gmb: http://pastebin.com/wWaziqcT
[11:23] <bigjools> we could probably sit down and analyse the publisher at some point, but it's not worth it right now
[11:23] <elmo> the Packages file is 26Mb; I utterly fail to believe that's something so expensive to update inline that we need to penalise our users to avoid the cost
[11:23] <elmo> sorry, a lucid i386 universe Packages file
[11:23] <elmo> I appreciate there's lots of them, and they add up
[11:23] <bigjools> yeah, you do notice the slowness when you're not on a fast link
[11:25] <lifeless> I would comment, but ETESTFIX
[11:26] <wgrant> a-f file list generation appears to only take ~2 minutes now. The a-f run is something like 15 minutes. :/
[11:27] <bigjools> wgrant: :o
[11:27] <bigjools> I've not looked for ages
[11:27] <bigjools> I do know that PPA publication is >10 minutes now :/
[11:27] <bigjools> it used to be about 3
[11:27] <elmo> a-f is fucking around inside a *massive* berkley DB file as part of this
[11:28] <elmo> it's not fair to compare a-f with switching to an append mechanism
[11:28] <elmo> a fair comparison would be a non-a-f, sane inline mechanism with an append mechanism
[11:28] <wgrant> bigjools: what's taking most of that time these days?
[11:29] <bigjools> by sane inline, you mean to replace entries when new versions appear?
[11:29] <bigjools> and append new stuff
[11:29] <bigjools> wgrant: no idea
[11:29] <bigjools> I've not analysed it
[11:29] <elmo> bigjools: yeah, and without the a-f DB madness overhead
[11:29] <bigjools> I've just seen the cronjob blocking as it's every 5
[11:29] <bigjools> elmo: ok, sounds, err, sane :)
[11:30] <bigjools> if we can get the PPA publisher to do the extra overrides, a-f can go
[11:30] <bigjools> IIRC
[11:31] <wgrant> Well, and it has to be an order of magnitude faster.
[11:31] <wgrant> But extra overrides is the only missing feature, I believe, yes.
[11:31] <bigjools> yes - but that's going to be relatively trivial, we have a few people who know how to make Python code faster ;)
[11:31] <elmo> wgrant: *blink* - why does it have to be?
[11:32] <wgrant> elmo: Because it's currently *really* *really* slow.
[11:33] <wgrant> It took roughly 7 minutes locally for a 30000-publication index, IIRC. With hot caches.
[11:33] <wgrant> (that's a single component-pocket-DAS index -- not all of them)
[11:36] <elmo> wgrant: oh, faster than it is now, you mean
[11:36] <elmo> wgrant: I thought you were setting the benchmark as an order of magnitude faster than a-f
[11:36] <elmo> which seemed harsh
[11:36] <wgrant> elmo: Ah, no, sorry.
[11:36] <wgrant> But it should be :)
[11:37] <wgrant> I can do a full pocket of indices of that size in under 2 minutes, though.
[11:39] <wgrant> Hmm. Why should main archives automatically build everywhere?
[11:40] <wgrant> Isn't that what we're about to start *not* wanting, once we have derivative distros?
[11:43] <lifeless> gmb: want some brain fuckage ?
[11:43] <gmb> lifeless, Always.
[11:43] <lifeless> I've switched to db-devel
[11:44] <lifeless> done make schema
[11:44] <lifeless> guess what happens when I run :!bin/test -vv -t 'duplicate_handling' -t doc/bugtask\\.txt
[11:44] <gmb> lifeless, I'm going to put 50p on "bad things"
[11:44] <lifeless> it works
[11:45] <gmb> D^F&*QY(EUH!
[11:45] <lifeless> what pg does db-devel buildbot use ?
[11:45] <gmb> Good question. IDK.
[11:45] <lifeless> losa ping ^
[11:46] <mthaddon> lifeless: 8.3 - it's on hardy
[11:47] <gmb> Interestingly, fails for me locally on... 8.3.9.
[11:47] <lifeless> \o/
[11:47] <lifeless> gmb: ok, try this patch and see if the unit style test passes
[11:48] <lifeless> http://pastebin.com/W06ZjYMg
[11:48] <lifeless> :!bin/test -vv -t 'duplicate_handling' -t bugs/doc/
[11:48] <lifeless> is how I'm running the tests
[11:48] <lifeless> 7 tests run for me
[11:49] <lifeless> mthaddon: thanks
[11:49] <bigjools> wgrant: the "main archives automatically build everywhere" is so that the restricted ARM stuff doesn't require manual SQL to be run, until we do a similar thing for derived distros as we've done for PPAs.
[11:49] <bigjools> but basically it can be controlled via DAS anyway so it's not really an issue
[11:50] <bigjools> wgrant: did you see the LEP for derived distros BTW?
[11:51] <wgrant> bigjools: Given that there are only two main archives, it seems like a pretty bad hack to prevent people from having to check a couple of checkboxes..
[11:51] <wgrant> bigjools: Is Ubuntu in scope for that LEP?
[11:51] <bigjools> wgrant: it's not a hack, it;s maintaining the status quo
[11:51] <bigjools> because the recent change buggered it up for main archives
[11:51]  * gmb waits for tests to run.
[11:51] <wgrant> Perhaps.
[11:51] <gmb> lifeless, That passes.
[11:52] <bigjools> wgrant: sort of, I have Debian NSS in mind
[11:52] <lifeless> gmb: ><
[11:52] <lifeless> gmb: so, when you said you triggered the failure locally ... ?
[11:52] <wgrant> bigjools: OK. I just think it would be a really good idea to keep that in mind before designing a system that might be incompatible...
[11:52] <gmb> lifeless, The failure that jelmer originally found in the build.
[11:52] <lifeless> cause my patch is clearly just trying to trigger the damage
[11:52] <lifeless> gmb: yes, but how
[11:53] <lifeless> how do we make it go boom
[11:53] <gmb> lifeless, bin/test -vv -t bugtask-search.txt
[11:53] <gmb> Worked for me befoew
[11:53] <gmb> Let's see if it still goes boom...
[11:54] <gmb> lifeless, http://pastebin.ubuntu.com/467453/
[11:54] <gmb> Still
[11:57] <gmb> lifeless, And adding the number_of_duplicates count, of course, gets us http://pastebin.ubuntu.com/467457/, as expected.
[11:57] <lifeless> yeah
[11:58] <lifeless> you'll need a commit to get them
[11:59] <gmb> Arsemonkeys.
[11:59] <gmb> Question is: where?
[11:59]  * gmb plays
[12:05] <lifeless> gmb: after markAsDuplicate
[12:05] <lifeless> we have lunch nazis happening
[12:05] <lifeless> will try to assist downstairs
[12:05] <gmb> lifeless, That's what I thought, but it seemed not to work.
[12:06] <gmb> lifeless, Much appreciated.
[12:11] <gmb> Ah, that's intriguing and frustrating. Even doing the update in the db seems not to work.
[12:12] <gmb> Ahah, no, it works.
[12:12] <gmb> But I managed to set number_of_duplicates to -1.
[12:12] <gmb> FAIL.
[12:13] <StevenK> gmb: "This bug does not exist in any other bug tracker, in the world!"
[12:14] <gmb> StevenK, I like how your mind works.
[12:14] <gmb> And I use the word "works" quite wrongly.
[12:16] <lifeless> gmb: right, trigger failing
[12:16] <lifeless> gmb: check markAsDuplicates, it *can't* read from the DB mid-transaction
[12:16] <lifeless> without hilarity
[12:19] <gmb> I confess, I'm starting to wonder at what point we can drag this revision out and shoot it.
[12:19] <gmb> lifeless, Bingo!
[12:20] <gmb> If you comment out the bug heat code after the try...except in markAsDuplicate() it works.
[12:20] <gmb> So essentially by modifying the bugs' heat we're clobbering the number_of_duplicates.
[12:20] <gmb> Or something.
[12:24] <gmb> lifeless, http://pastebin.ubuntu.com/467465/ fixes the doctest. However, I can't comment as to the rightness of the solution.
[12:24] <wgrant> bigjools: Why is the 'Publish' flag editable by users?
[12:24] <wgrant> It causes great confusion, and is of dubious utility.
[12:24] <bigjools> so copy archive owners can turn them on and off, mainly
[12:25] <bigjools> who is confused?
[12:25] <wgrant> We'll occasionally get someone in #launchpad complaining that their PPA isn't publishing.
[12:25] <wgrant> There's no indication anywhere except +edit that the flag is switched off.
[12:25] <wgrant> And they never know how it got turned off.
[12:25] <lifeless> gmb: yes
[12:26] <lifeless> let me look
[12:26] <lifeless> gmb: oh, thats not safe
[12:26] <lifeless> we can't commit in model code
[12:26] <lifeless> stub: around ?
[12:26] <bigjools> wgrant: we need a big warning on the front page to say it's turned off then
[12:26] <stub> lifeless: yer
[12:26] <wgrant> bigjools: Probably.
[12:26] <gmb> lifeless, Yeah, I was pretty sure that was the case.
[12:27] <lifeless> stub: we have a trigger interaction
[12:28] <lifeless> stub: the number_of_duplicates trigger is being broken by an update which separately sets the value in the master, when we move multiple bugs to a new master in one xaction
[12:28] <gmb> lifeless, The simple solution may be to have the function that updates the number of duplicates to also update the bug heat for the duplicated bug.
[12:28] <lifeless> stub: any input you have would be useful
[12:29] <stub> Do you have an exception?
[12:29] <stub> hmm... no... i see the problem.
[12:30] <lifeless> apparently there may be some storm thing which can help
[12:30] <lifeless> I'm guessing storm is adding an update to that column because we read it
[12:30] <lifeless> I'm going to hunt him down
[12:30] <stub> So when we sent a duplicate, we need to send a message to the messaging system so the update can happen post-transaction... oh... wait...
[12:30] <lifeless> yes yes
[12:30] <lifeless> if you wanted to build the messaging dependencies package for hardy, I think tom would install it
[12:32] <maxb> So, now devel is py2.6 capable.... should we delete the py2.5 rebuilds from the launchpad PPA for lucid? Or is there worth in retaining them? What about other series? [Mainly just gathering some initial thoughts, I'll send a mail later]
[12:34] <stub> lifeless: works for me.
[12:34] <wgrant> I suppose we'll need to port to 2.7 in a few months :(
[12:34] <maxb> Lucid first, before we worry about Maverick
[12:34] <wgrant> Maverick's not having 2.7 by default, fortunately.
[12:35] <wgrant> That's for Nifty.
[12:35] <maxb> woo
[12:35] <stub> lifeless: https://pastebin.canonical.com/34956/
[12:35] <maxb> problem. brush. carpet. :-)
[12:38] <wgrant> lifeless: What's the issue with raising an AssertionError?
[12:38] <wgrant> It's not a valid way to call the method.
[12:39] <maxb> boo. +copy-packages timeout. I should be able to copy 21 source packages at once, right? :-)
[12:39] <lifeless> stub: whats that pastebin demonstrating?
[12:40] <stub> Changing the master for multiple bugs in one transaction
[12:40] <lifeless> stub: oh sure, the transactions succeed
[12:40] <lifeless> gmb: get a postgresql / storm trace of the calls being made
[12:40] <lifeless> gmb: hunch is that we're seeing an 'update ...' call setting that column
[12:41] <lifeless> gmb: also are we gaining one, or losing one, or just failing to update?
[12:42] <gmb> lifeless, I'm not sure. Give me a sec; just testing a theory then I'll get the PG trace.
[12:42] <lifeless> kk
[12:42] <lifeless> wgrant: are the inputs invalid - ValueError
[12:43] <bigjools> maxb: Yes. :/  I'm going to move package copying to the job system over the next few months
[12:43] <wgrant> lifeless: That's forbidden.
[12:44] <wgrant> lifeless: https://dev.launchpad.net/Hacking forbids raising TypeError, NameError or ValueError.
[12:44] <maxb> bigjools: no more synchronous feedback? :-(
[12:45] <lifeless> raising AssertionError is as bad or worse.
[12:45] <lifeless> I'd rather you raise ValueError than assertion error, or a custom exception
[12:45] <wgrant> lifeless: But it's not forbidden by the documentation :(
[12:45] <wgrant> win 2
[12:45] <lifeless> wgrant: best practice is historical not live ;)
[12:45] <bigjools> maxb: we'll try and do it via ajax polling
[12:45] <bigjools> landscape has a similar thing already
[12:46] <bigjools> the problem is that the webapp request is really not the right place to do the hundreds of checks required when copying :(
[12:46] <maxb> That could work. Though, it'll be irksome for people who promote PPA packages via the API
[12:46] <bigjools> yeah, but... I dunno what else to do here
[12:46] <wgrant> Why is copy checking so slow?
[12:47] <bigjools> because it does a shedload of db queries
[12:47] <bigjools> mostly unavoidable
[12:47] <gmb> lifeless, stub: So, this patch http://pastebin.ubuntu.com/467471/ (includes lifeless's original patch) fixes our problem by moving the bug heat stuff into the set_bug_number_of_duplicates function. Which feels like the wrong place for it, but only because of the name of the function.
[12:47] <lifeless> stub: https://dev.launchpad.net/LaunchpadPpa?action=diff
[12:48] <maxb> lifeless: two versions of what?
[12:48] <lifeless> the packages
[12:49] <gmb> Argh. Annoyingly, fucks up the heat tests. But I think that's my fault...
[12:49] <lifeless> hang a sec
[12:49] <wgrant> We still support Karmic, don't we?
[12:50] <maxb> lifeless: It's not clear to me what that paragraph is saying. We *already* sustain hardy/karmic/lucid in the PPA
[12:50] <maxb> we haven't officially de-supported jaunty yet
[12:50] <maxb> though it's likely bitrotten
[12:50] <lifeless> maxb: ok, then I was confused; it seemed to me that it wasn't clear that people needed to do this.
[12:50] <wgrant> I think it may have bitrotten a bit, though.
[12:50] <wgrant> Right.
[12:50] <lifeless> maxb: we need a hardy build of launchpad-messagequeue-dependencies
[12:51] <gmb> Oh, wait, that might be because I forgot to make schema. Durr.
[12:51] <maxb> lifeless: Yes, someone has ignored point 11 under the list at the top
[12:51] <lifeless> maxb: ok, nuke my change then
[12:52]  * maxb expands it a bit instead
[12:53] <wgrant> lifeless: So, what should I do about that exception?
[12:54] <lifeless> wgrant: in the review I said you could just document that it sucks
[12:54] <lifeless> maxb: if you were to also refresh the builds, I'd be hugely appreciative.
[12:54] <stub> lifeless: The comment sounds sane, but it is worth documenting the commands so people like me can actually do it.
[12:55] <lifeless> stub: ack
[12:55] <lifeless> stub: I can show you the error now
[12:55] <wgrant> lifeless: Ah, true.
[12:55] <lifeless> https://pastebin.canonical.com/34957/
[12:55] <lifeless> stub: ^
[12:55] <lifeless> wgrant: I'm usually pretty careful to not block people; please shout if you feel blocked - its probably a miscommunication
[12:57] <lifeless> http://pastebin.com/sMtQapT4 <- same sql trace
[12:57] <lifeless> gmb: I'm almost totally convinced this is a storm bug
[12:58] <gmb> lifeless, Ah, right. Still want me to grab that storm trace?
[12:58] <jkakar> Hi lifeless! :)
[12:58] <lifeless> gmb: yes
[12:58] <lifeless> gmb: or postgresql
[12:58] <lifeless> jkakar: hi
[12:58] <gmb> Right. On it.
[12:59] <lifeless> jkakar: http://pastebin.com/sMtQapT4
[12:59] <lifeless> jkakar: this shows the problem
[12:59] <stub> lifeless: right, so the db end is fine and something else is issuing updates it shouldn't, such as storm perhaps using the version from the start of the transaction.
[12:59] <lifeless> jkakar: we're getting confirmation that it actually happens
[12:59] <lifeless> stub: I think so, yes.
[12:59] <jkakar> So yeah, therve and I were wondering if it's a flush issue...
[13:00] <stub> We can issue a foo.duplicate_bug_count = <mumble> to force it to reload that value from the database
[13:00] <stub> (I forget the 'magic reload' object)
[13:00] <jkakar> AutoReload.
[13:00] <lifeless> stub: won't work
[13:00] <lifeless> stub: because the trigger is an after trigger
[13:00] <jkakar> Anyway, that might be hack fix if it worked.
[13:01]  * jkakar looks at some Storm code...
[13:01] <lifeless> until we commit we don't know the new value
[13:01] <wgrant> lifeless: I've added a comment. Could you please land that?
[13:01] <lifeless> wgrant: not until we're out of testfix
[13:01] <wgrant> lifeless: Fair point.
[13:02] <stub> lifeless: after triggers fire after the statement, not at the end of the transaction
[13:02] <gmb> lifeless, stub: Here's the trace, from just before the markAsDuplicate() call to just after flush_database_updates() in bugtask-search.txt: http://pastebin.ubuntu.com/467476/
[13:03] <gmb> lifeless, stub: The last line makes interesting reading :)
[13:03] <lifeless> jkakar: so - http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/annotate/head:/lib/lp/bugs/model/bug.py
[13:03] <lifeless> stub: ah, doh.
[13:03] <lifeless> stub: its been a while. sorry ;)
[13:03] <lifeless> ok, thats a decent, if ugly, workaround
[13:03] <lifeless> does AutoReload kick in at UPDATE() or will we need a flush as well ?
[13:03] <lifeless> gmb: yes, i thought so
[13:04] <stub> I don't know
[13:04] <lifeless> jkakar: ^
[13:04] <lifeless> gmb: so try a flush + this autoreload trick
[13:04] <stub> flush will hopefully happen automagically
[13:04] <jkakar> lifeless: AutoReload marks the column as "flush this the next time I access it".
[13:04] <jkakar> lifeless: It doesn't perform an UPDATE.
[13:04] <jml> are we in some sort of testfix mode?
[13:04] <lifeless> jml: yes
[13:05] <lifeless> see backlog, its a fun one
[13:05] <lifeless> jkakar: so, it flushes everything, then reads back that column ?
[13:05] <gmb> Where fun == 'I want to stab myself in the face'
[13:05] <lifeless> jkakar: and if we don't access the column at all, will storm do it itself mid commit ?
[13:06] <gmb> jkakar, Can you help me out with AutoReload magicks? I'm scannign scrollback but I see nothing I can grok.
[13:08] <jkakar> lifeless: AutoReload flushes the store, not just the column.
[13:08] <lifeless> sure
[13:08] <jkakar> gmb: If you set a column to AutoReload it will cause a flush on next access.
[13:08] <lifeless> but you see my concern
[13:09] <lifeless> we *don't access* the column
[13:09] <lifeless> storm might, we don't.
[13:09] <jkakar> gmb: So, Bug.duplicateof = AutoReload will cause the store to be flushed the next time Bug.duplicateof is accessed.
[13:09] <gmb> jkakar, Ah, right, gotcher. Crikey that seems nasty.
[13:09] <jkakar> lifeless, gmb: It's not what you want, it's useful in other contexts.
[13:09] <lifeless> ok
[13:09] <lifeless> where do we import AutoReload from ?
[13:09] <jkakar> So I think we need to add a thing to Storm to tell it to never include the column in an UPDATE.
[13:10] <lifeless> jkakar: See, lifeless isn't nuts.
[13:10] <jkakar> lifeless: from storm.locals import AutoReload (it's actually in storm.store, though).
[13:10] <jkakar> lifeless: :)
[13:10] <gmb> lifeless, storm.locals
[13:10] <jkakar> lifeless: You are referring to yourself by name which is indicative of some kind of deep seated problem, no?
[13:10] <lifeless> yes
[13:10] <lifeless> gmb: already have store imported in this module :)
[13:11]  * gmb was cargo-culting
[13:11] <jkakar> Hehe
[13:11] <jkakar> Okay, I'll take a look at what it will take to add this functionality to Storm.
[13:11] <lifeless> jkakar: oh, and it replaces IntCol ?
[13:11] <jkakar> lifeless: IntCol?
[13:12] <lifeless>   File "/home/robertc/launchpad/lp-branches/working/lib/lp/bugs/tests/test_duplicate_handling.py", line 101, in test_duplicates_are_moved
[13:12] <jkakar> Oh right, SQLObject compatibility...
[13:12] <lifeless>     new_bug.number_of_duplicates = AutoReload
[13:12] <lifeless> ForbiddenAttribute: ('number_of_duplicates', <Bug at 0xdaa9050>)
[13:12] <jkakar> Yes, it replaces IntCol on the instance.
[13:12] <jkakar> I guess the object is security proxied.
[13:12] <lifeless> jkakar: the above is why I was sure we were not writing to the attribute
[13:12] <jkakar> Cool.
[13:12] <gmb> Stabby.
[13:12] <lifeless> gmb: I think we should pull this branch
[13:12] <gmb> lifeless, I agree.
[13:12] <lifeless> gmb: its a deep fix, the queue is stalled.
[13:13] <lifeless> gmb: r=lifeless on a pull
[13:13] <gmb> lifeless, Right; on it. Is it DTRT to remove it from devel and let it trickle down or should i submit merges for both?
[13:13] <gmb> (That could be interesting)
[13:20] <james_w> could oops generated during a test be attached as details to the result?
[13:24] <lifeless> james_w: yes please
[13:24] <lifeless> gmb: devel with testfix
[13:24] <james_w> they are just text?
[13:24] <lifeless> gmb: then queue will unblock and next buildbot run should fix it
[13:24] <lifeless> james_w: serialised as yes
[13:24] <lifeless> utf8 actually I think
[13:25] <james_w> readable and not too large?
[13:25] <gmb> lifeless, Righto. Almost done; just checking that I'm not breaking anything else in a spectacularly obvious fashion.
[13:25] <lifeless> they have i18n usernames in them
[13:25] <lifeless> gmb: not AFAIK.
[13:25] <lifeless> wgrant: stub: jml: ^ gmbs query
[13:25] <stub> eh?
[13:26] <lifeless> when fixing a testfix failure in db-devel
[13:26] <wgrant> If you revert it in devel, it will filter down to db-devel after the next buildbot run.
[13:26] <lifeless> is landing a testfix in devel sufficient
[13:26] <wgrant> Oh. Hmm.
[13:26] <wgrant> I don't know if that will kick PQM.. good point.
[13:27] <stub> It might need a manual merge - I think the automatic stable->db-devel merges are disabled in testfix mode
[13:27] <stub> But I don't know for sure.
[13:28] <wgrant> But once the commit kicks it out of testfix, devel will get tested, and merged into db-devel, which will then be tested, and not land back in testfix.
[13:28] <gmb> lifeless, stub: 'tis in the queue now for devel. We'll see what happens and if necessary I'll do a manual merge.
[13:28] <gmb> wgrant, ^
[13:28] <wgrant> Unless db_lp decides to run again before the next stable merge, I guess...
[13:29] <gmb> Yes, that would be amusing.
[13:30] <wgrant> For some rather more masochistic values of amusing than usual.
[13:33] <jkakar> lifeless, gmb: I think there might be a problem in your application code (and also a problem in Storm).
[13:33] <lifeless> jkakar: I'm sure :)
[13:34] <gmb> jkakar, lifeless, I've emailed canonical-launchpad@ about the [testfix]; can you elaborate abut the storm bug on that list please? (This should probably move to launchpad-dev@, tbh)
[13:34] <lifeless> ack
[13:35] <gmb> Ta
[13:35] <lifeless> gmb: will you save my test improvement somewhere?
[13:36] <gmb> lifeless, I'll push it up to LP, along with my patch to move stuff into the stored procedure.
[13:36] <lifeless> gmb: I'm not sure thats needed/right, FWIW
[13:36] <gmb> lifeless, No, I know, but I'd like it for my own reference later should we need to do it.
[13:36] <lifeless> gmb: the stored procedure won't run on the master you see
[13:37] <gmb> lifeless, OIC.
[13:37] <gmb> Okay.
[13:37] <lifeless> gmb: (if you don't update it). And if you do update it, the problem exists.
[13:37] <gmb> Right
[13:37] <jkakar> gmb: Yep, I'm just figuring out what you need to determine if there's a bug in Launchpad.
[13:37] <jkakar> Also, therve and I are looking at what it will take to fix Storm.
[13:37] <lifeless> jkakar: I grepped, I can't see anything setting that oclumn in the entire codebase
[13:37] <jkakar> lifeless: Hrm.
[13:38] <lifeless> jkakar: come sit by me if you like.
[13:38] <jkakar> lifeless: It might be an update issue in Storm... I found this:
[13:38] <gmb> lifeless, lp:~gmb/launchpad/db-devel-with-lifeless-improvements
[13:38] <jkakar>         # The fromdb check makes sure that values coming from the
[13:38] <jkakar>         # database don't mark the object as dirty again.
[13:38] <jkakar>         # XXX The fromdb check is untested. How to test it?
[13:38] <lifeless> gmb: as long as you<->deryck coordinate on it, I'm happy :)
[13:38] <jkakar> It could be that a flush is getting the triggered value and causing the object to be marked as dirty. :)
[13:38] <jkakar> It may be that the issue in Launchpad teaches us how to test that code path. ;)
[13:38] <lifeless> jkakar: hah.hah.hah.
[13:39] <jkakar> lifeless: You said you have a failing test, yes?
[13:39] <lifeless> yes
[13:39] <lifeless> its awful, but yes.
[13:39] <lifeless> I don't have a unit test yet. I think I can construct one though.
[13:40] <lifeless> its a doctest [[meep]]
[13:40] <jkakar> lifeless: http://paste.ubuntu.com/467498/
[13:41] <jkakar> lifeless: Can you add a validator like in the paste to the duplicateof column and run your test please?
[13:41] <lifeless> jkakar: number_of_duplicates, surely ?
[13:42] <lifeless> duplicate_of is set in related bugs, heat is set in the bug with the wrong number_of_duplicates value
[13:42] <lifeless> jkakar: no change in behaviour
[13:42] <lifeless> jkakar: lets pair. I'm in the community room
[13:47] <poolie> sinzui, hi, want to talk about feature flags?
[13:47] <poolie> しんずい
[13:47] <sinzui> :)
[13:47] <poolie> :)
[13:47] <sinzui> I think I need more caffeine  first
[13:49] <poolie> np
[14:00] <gmb> Okay, we should be out of testfix now.
[14:00] <jelmer> gmb: Awesomeness.
[14:00] <jelmer> thanks :-)
[14:01] <wgrant> gmb: Thanks.
[14:01] <wgrant> lifeless: Can you send my branch off now?
[14:01] <gmb> lifeless did most of the heavy brainwork.
[14:03] <poolie> gmb, lifeless, woo!
[14:05] <jml> woot.
[14:05] <jml> I need some help with bugs / bugbranches: http://paste.ubuntu.com/467503/
[14:06] <jml> there's a doctest that checks to see that editing bugbranch links changes the date_last_updated of the bug
[14:06] <jml> but the test is crummy. the unit test in the paste reproduces the logic of the doctest.
[14:07] <jml> I guess I want to know if editing a bugbranch object is actually possible at all. if it is not possible, I don't really see why it should be tested / supported.
[14:07] <wgrant> bigjools: FWIW, I just came upon a summary of a primary publisher run I made a few months back: http://williamgrant.id.au/f/1/2010/publisher-timeline.html
[14:08] <wgrant> Gives a reasonable picture of how much time goes where.
[14:08] <wgrant> ie. a-f takes 16 minutes.
[14:53] <jtv> salgado: test -vvc -m lp.translations.windmill -t import_queue_entry
[14:53] <jtv> ...but I had it with the bug_me_too test as well, which isn't in Translations.
[15:01] <lifeless> \o/
[15:01] <lifeless> wgrant: sorry, still analysing
[15:01] <lifeless> wgrant: hunt down, oh, hml
[15:17] <lifeless> we have a fix for storm
[15:17] <jelmer> gmb: It looks like we're (back?) in testfix mode
[15:25] <bigjools> lifeless: I also have a fix for Storm
[15:38] <jkakar> Does anyone know which (if any) Storm branch LP is using?  I want to see what's different between it and lp:storm.
[15:38] <jkakar> danilos: ^^ I think the Storm code being used by LP is from you, right?
[15:39] <danilos> jkakar, it's 0.15 + one or two revisions from before 0.16 came out that I needed at the time
[15:39] <jkakar> danilos: Right... is there a branch somewhere?
[15:39] <danilos> jkakar, r342 that is :)
[15:40] <danilos> jkakar, don't think so, it's available as a tar.gz inside download-cache for LP
[15:40] <danilos> jkakar, that's bzr+ssh://bazaar.launchpad.net/~launchpad/lp-source-dependencies/trunk/
[15:44] <Ursinha> bigjools, oi
[15:44] <poolie> sinzui, hi?
[15:45] <sinzui> hi poolie
[15:45] <poolie> hey i think i understand your concerns now
[15:45] <poolie> i might just reply on the list, or we can talk here
[15:45] <sinzui> here is nice
[15:46] <bigjools> Ursinha: oi oi
[15:46] <poolie> i think there are a few use cases worth looking at:
[15:46] <Ursinha> bigjools, e ai? :) could you tell me if bug 595957 is really fix released?
[15:46] <_mup_> Bug #595957: archive uploader tries to move the changelog to the current working directory <archive-uploader> <qa-needstesting> <Soyuz:Fix Released by abentley> <https://launchpad.net/bugs/595957>
[15:47] <Ursinha> bigjools, it was qa-bad and then a commit pointed to it again
[15:47] <abentley> Ursinha, I have been unable to QA it.
[15:48] <bigjools> abentley: I can QA it on dogfood
[15:48] <poolie> 1- adding a new non-trivial feature, that we want to have off by default until we're confident in it
[15:48] <bigjools> Ursinha: it should be committed
[15:48] <Ursinha> abentley, but is that fix released? I don't understand why is it fix released if that was bad and now has a new branch :)
[15:48]  * sinzui nods
[15:48] <abentley> bigjools, I don't think you can, because I think writing to that directory isn't forbidden on dogfood.
[15:48] <Ursinha> oh, that was sinzui
[15:48] <bigjools> abentley: easily fixed
[15:49] <bigjools> besides, I can see if it leaves a changelog behind
[15:49] <abentley> bigjools, okay, please do.
[15:49] <bigjools> when I get faster interwebs back ... :/
[16:00] <lifeless> bigjools: hi, what is your fix ?
[16:00] <lifeless> jml: how does one tell if one is in testfix mode ?
[16:03] <maxb> How odd. Three scripts in the launchpad tree still have a shebang with an explicit python version
[16:05] <poolie> sinzui, so in that case we should have the code declare the feature flag
[16:05] <bigjools> lifeless: it's a patch that strips ordering from SQLObjectResultSet.__nonzero__()
[16:05] <poolie> and then it should check it in the necessary places with getFeatureFlag() (but not too many different places)
[16:05] <bigjools> which makes bool(result) run quite a lot quicker.
[16:06] <poolie> sinzui, then when we're ready to test on lpnet, we turn on the flag in that database
[16:06] <poolie> for your own testing you'll set the flag in your own database
[16:06] <poolie> also we'll provide a context manager to let you test with that flag turned on
[16:06] <poolie> still here?
[16:06] <sinzui> hmm
[16:06] <lifeless> bigjools: is it ready to upstream ?
[16:07] <sinzui> That sounds like a great way to discover bad interactions after the branch is on edge
[16:07] <sinzui> I would rather have all feature on in dev and testrunner
[16:07] <bigjools> lifeless: see bug 24620
[16:07] <_mup_> Bug #24620: Install from DVD+RW complains of bad MD5 <linux-source-2.6.15 (Ubuntu):Fix Released by ben-collins> <https://launchpad.net/bugs/24620>
[16:07] <bigjools> lifeless: no don't look at that one
[16:07] <lifeless> we could - at some cost - run the test suite twice, once on, once off
[16:07] <bigjools> look at bug 246200
[16:07] <_mup_> Bug #246200: SQLObjectResultSet.__nonzero__() implementation does not strip result ordering. <oops> <tech-debt> <Soyuz:Invalid> <Storm:New> <https://launchpad.net/bugs/246200>
[16:08] <lifeless> however I think its likely good enough to use testscenarios to run tests of affected areas only, twice.
[16:08] <lifeless> sinzui: also
[16:08] <bigjools> it's pissing it down here, I'll lose my GPRS connection shortly
[16:08] <lifeless> sinzui: remember that we'll have QA happening before *any* rollout.
[16:08] <lifeless> bigjools: looking
[16:08] <sinzui> Once more I have to decline someone's nomination to fix a bug in the trunk series
[16:08] <poolie> hm, if they're all on in dev, then we are making dev further away from production
[16:08] <lifeless> poolie: production is ill defined
[16:09] <poolie> s//edge
[16:09] <lifeless> jkakar: https://bugs.edge.launchpad.net/soyuz/+bug/246200
[16:09] <_mup_> Bug #246200: SQLObjectResultSet.__nonzero__() implementation does not strip result ordering. <oops> <tech-debt> <Soyuz:Invalid> <Storm:New> <https://launchpad.net/bugs/246200>
[16:09] <sinzui> I should have used my epic time to restrict bug nominations to the handful of people who need them
[16:10] <jkakar> danilos: Hrm... as a suggestion, branches are a good thing. ;b
[16:10] <poolie> sinzui, which bug, for curiousity?
[16:10] <lifeless> bigjools: if you can get a branch up and attached to that, that would be great.
[16:10] <sinzui> https://bugs.edge.launchpad.net/launchpad-web/+bug/490058
[16:10] <_mup_> Bug #490058: Launchpad shouldn't present itself as a database <launchpad-web:Triaged> <https://launchpad.net/bugs/490058>
[16:10] <sinzui> ^ poolie
[16:10] <poolie> tx
[16:10] <bigjools> lifeless: yeah I've been meaning to do so for ages :)
[16:11] <lifeless> bigjools: or even a patch
[16:11] <lifeless> the storm folk will take it from there I suspect ;)
[16:11] <poolie> nice idea though
[16:12] <danilos> jkakar, they are, and they might be one, but if it's not on code.lp.net/~danilo/storm I probably didn't create it at the time
[16:13] <jkakar> danilos: Yeah, it's cool, I was just teasing... I'll get the tar.gz and see what's different from trunk.
[16:16] <sinzui> poolie, of course it is a nice idea. Most ideas about changing our pathetic excuse for a front page are good.
[16:16] <poolie> "real artists ship"
[16:17] <poolie> no point complaining about the speed other people do stuff
[16:17] <poolie> anyhow coming back to the flags thing
[16:18] <poolie> do you have time to talk about it now?
[16:18] <sinzui> poolie. I weep everytime I see the contradictory root pages of each app and for each pillar. We have agreed to contradict each other and confuse the user. I feel helpless to fix an issue that requires half of the lp team to fix
[16:19] <poolie> :/
[16:19] <poolie> we'll get there
[16:19] <lifeless> sinzui: is it the agreement between them all that is the hard bit?
[16:19] <poolie> if we make it easier to change things (without making it too easy to change things rashly) we can fix this
[16:19] <sinzui> We said that in 2.0 and we promised we would revisit the root page problem in the release after 3.0. We lied to ourselves
[16:20] <poolie> istm the concept of an 'x.0' release is part of the problem
[16:20] <poolie> while True: fix_something
[16:21] <sinzui> jml brought up the issue recently. He may have used that as an argument for the web ui position he is hiring for
[16:21]  * sinzui knows those pages are actually used 1.0 layours
[16:21] <sinzui> layouts
[16:22] <poolie> so i'd like to make sure i'm not going to run into avoidable trouble with flags
[16:22] <lifeless> how do we reset testfix?
[16:22] <poolie> can we talk about them?
[16:22] <lifeless> there is nothing in pqm to change it
[16:22] <lifeless> and we're still blocked
[16:22] <lifeless> sinzui: jml: ^
[16:24] <sinzui> lifeless, jml sees the pages as a problem. I jumped to his side when some disagreed about the inconsistency
[16:24]  * sinzui looks for email to forward
[16:24] <poolie> sinzui, i'd like to see a wall with printouts of screenshots of the N top pages
[16:25] <poolie> would they make any sense viewed side by side?
[16:25] <poolie> then you could do wireframes of proposed alternatives
[16:25] <sinzui> poolie, I think jml made that. I will look for that email too
[16:25] <lifeless> mars: around ?
[16:25] <poolie> of course there's not really any necessary reason why there has to be a 'bugs home page'
[16:25] <poolie> for the whole of launchpad
[16:25] <poolie> it's really more of a consequence of having a domain per 'app'
[16:26] <mars> lifeless, yep
[16:26] <poolie> not that users really see them as apps
[16:26] <mars> lifeless, what's up?
[16:26] <lifeless> I'm trying to get us out of testfix
[16:26] <lifeless> gmb landed a revert of the problem patch, I believe
[16:26] <mars> ok
[16:29] <mars> lifeless, if it isn't moving, and the patch is OK, gmb suggested merging into db-devel directly and then forcing the build
[16:29] <lifeless> https://lpbuildbot.canonical.com/one_box_per_builder suggests a build is in progress
[16:29] <lifeless> the wiki page says that when a build starts the flag is reset
[16:29] <lifeless> is that true ?
[16:31] <poolie> sinzui, lifeless, i think i'll write up some use cases in that thread
[16:31] <mars> I don't know.  gary_poster, ^ do you know if the testfix flag is cleared when we land on devel?  The wiki says yes, but...
[16:31] <poolie> and proceed with landing https://code.edge.launchpad.net/~mbp/launchpad/flags/+merge/30581
[16:31] <poolie> if i can get ec2 to cooperate
[16:31] <lifeless> mars: specifically 'when you start a build'
[16:31] <poolie> then if you want to talk online or in mail later, we can
[16:31] <poolie> i'm going to be offline monday/tuesday next week, travelling
[16:31] <mars> lifeless, which wiki page?  (Shows you how much I know about it :)
[16:31] <gary_poster> mars, if the problem was devel, then eventually, yes
[16:31] <gary_poster> (I'm on call)
[16:32] <lifeless> mars: https://dev.launchpad.net/Trunk
[16:32] <lifeless> gary_poster: it was db-devel
[16:32] <gary_poster> then no, landing a testfix on devel will not help db-devl, I don't think
[16:32] <gary_poster> I mean, from testfix perspective
[16:32] <lifeless> after it passes on devel, will the automerge to db-devel still kick in ?
[16:32] <lifeless> if so, it will right itself eventually I guess.
[16:32] <mars> lifeless, that is what I would expect
[16:33] <mars> rule of least surprise and all
[16:33] <lifeless> mars: I might do something a little cheeky then
[16:33] <lifeless> and tell bb to build db-devel
[16:33] <lifeless> to unblock us
[16:33] <mars> land on db-devel an kick it?
[16:33] <gary_poster> land it on both branches
[16:33] <gary_poster> should merge fine
[16:33] <gary_poster> get us out of testfix faster
[16:33] <lifeless> gmb: can you toss it at db-devel then ?
[16:33] <lifeless> gary_poster: looking forward to no testfix mode ? :)
[16:33] <gary_poster> yeah :-)
[16:34] <mars> I am starting to understand why it would be a nice thing to get rid of.
[16:35] <lifeless> mars: pipeline stalls are painful; stop-the-line should be short and fast :- this isn't
[16:35] <mars> Since I technically maintain that part, and I don't even know what wiki page to look at...
[16:36] <lifeless> gmb: hi
[16:36] <mars> policy in the wiki text is not code - buildbot does not execute wiki documents
[16:37] <Ursinha> bigjools, is noodles on leave or something?
[16:37] <mars> lifeless, "If only one branch is broken, a [testfix] to the broken branch that then makes the tests pass will reopen both branches for normal use."
[16:37] <bigjools> Ursinha: no, he's en route from Prague to Berlin
[16:38] <Ursinha> bigjools, oh, I see
[16:38] <mars> lifeless, but again, just because the wiki says so does not mean code does same
[16:39] <gmb> lifeless, Hi. What's up?
[16:39] <lifeless> gmb: can you land the revert patch on db-devel too please !
[16:39] <lifeless> gmb: I was about to start grovelling around for it to do
[16:39] <gmb> lifeless, Sure. On it now.
[16:39] <lifeless> thanks!
[16:39] <lifeless> and sorry for the escalating pings ;)
[16:40] <gmb> lifeless, No worries :)
[16:42] <gary_poster> mars, heads up: bug 608593 may move from high to critical :-)
[16:42] <_mup_> Bug #608593: buildbot lucid builds dying on xvfb <Launchpad Foundations:New> <https://launchpad.net/bugs/608593>
[16:45] <mars> gary_poster, will do!
[16:59] <jkakar> lifeless: https://code.edge.launchpad.net/~jkakar/storm/is-empty-strips-order-by/+merge/30677 <-- This is a fix for bug #246200.  Review appreciated (it's trivial). :)
[16:59] <_mup_> Bug #246200: SQLObjectResultSet.__nonzero__() implementation does not strip result ordering. <oops> <tech-debt> <Soyuz:Invalid> <Storm:In Progress by jkakar> <https://launchpad.net/bugs/246200>
[16:59] <lifeless> natching
[17:00] <lifeless> jkakar: done
[17:02] <jkakar> lifeless: Ta. :)
[17:03] <poolie> sinzui, thanks!
[17:04] <poolie> does 'martin' mean me or beuno? it sounds like me, but it could also be him
[17:06] <gmb> Buggeration.
[17:06] <lifeless> ah, the british are here.
[17:06] <gmb> Looks like we're heading for another testfix folks; I'm on it now, though.
[17:09] <leonardr> do we have a helper function that encapsulates 'stick this query string onto this URL with a & if there's already a query string and a ? otherwise"? i can't find one in urllib or lazr.uri, but i feel like there is one
[17:11] <sinzui> poolie, "martin" is beuno in the design conversations
[17:11] <poolie> sinzui, it's a good thread
[17:11] <poolie> wbn to redesign them all as a group
[17:12] <maxb> lifeless: Regarding lp-mq-deps and hardy... Given hardy has no rabbitmq at all, and a drastically older erlang, .... do we get to move to lucid before rabbit?
[17:12] <poolie> even if it wasn't all implemented at least getting some wireframes for "what this kind of page should generally look like" would be nice
[17:14] <poolie> I like the idea of "some features only after 10pm"
[17:15] <gmb> poolie, Just the man. How would I find out which revision a  sub revision (e.g. 1.2.3) belongs to?
[17:16] <lifeless> log --show-ids
[17:16] <gmb> poolie, I like your ventriloquism skills.
[17:16] <gmb> lifeless, Ta.
[17:31] <gmb> lifeless, Can I have your r= on http://pastebin.ubuntu.com/467585/? It turns out that we needed to revert r11190 as well as 11188, otherwise the build will stay broken.
[17:31] <gmb> (Abel gave me the heads-up)
[17:32] <lifeless> doit
[17:33] <lifeless> now I'll look at the pastebin
[17:33] <lifeless> in general
[17:33] <lifeless> I don't think backouts need approval, do they ?
[17:33] <gmb> lifeless, IDK; better to get at least an rs, I guess.
[17:34] <lifeless> yeah
[17:34] <lifeless> so it looks like a patch
[17:34] <lifeless> which we don't want for now
[17:34] <lifeless> seems like we should remove it:)(
[17:34] <gmb> lifeless, Agreed :)
[17:36]  * bigjools hi-5s jkakar
[17:36] <jkakar> bigjools: :)
[17:37] <jkakar> bigjools: Any other Storm issues you want me to fix while I'm in the mood...? :)
[17:37] <bigjools> jkakar: my issues would most certainly take you out of that mood and into a completely different one
[17:37] <lifeless> mthaddon: whats the losa email address again ?
[17:38] <mthaddon> losas@canonical.com?
[17:38]  * mthaddon just realised it's now a spam target
[17:38] <lifeless> mthaddon: oh, sorry!
[17:38] <bigjools> lol
[17:38] <lifeless> mthaddon: should I not copy you on a public mail via it ?
[17:39] <jkakar> bigjools: It'd be good to find out what they are... even if they do turn out to be soul destroying.
[17:40] <bigjools> jkakar: ok - plz to be adding comments and docstrings to the storm code :)
[17:40] <lifeless> bigjools: hah!
[17:40]  * bigjools just destroyed jkakar's soul
[17:41]  * jkakar explodes
[17:42] <bigjools> jkakar: the only other thing that hurts my brain is the prejoin stuff but I doubt you can do much about that!
[17:43] <jkakar> bigjools: Actually, free has a branch that he wants us to look at that does something like prejoin but I think in a less confusing way.
[17:43] <bigjools> \o/
[17:52] <poolie> jkakar, i was thinking of sending you a doc-adding patch but now i understand it the moment has passed :)
[17:52] <jkakar> poolie: :)
[17:55] <gmb> Okay, we're out of TF mode again. There's a chance we'll hit it again due to stuff landing after the latest build started; we'll jump off that bridge when it comes.
[18:07] <poolie> benji/garry, if i want to create a FeatureController per request, should i just do that from beforeTraversal?
[18:08] <benji> poolie: sounds good to me
[18:09] <benji> poolie: do you mean IBeforeTraverseEvent?
[18:10] <benji> because that gets generated once for each object being traversed, not once per request
[18:12] <poolie> i actually just meant patching it into LaunchpadBrowserPublication.beforeTraversal
[18:12] <poolie> which is where similar things seem to be
[18:13] <benji> looking at the code, that looks like the right place
[18:14] <poolie> it seems like there are notifications that could be hooked but i'm not sure that would be worth it
[18:19] <benji> my opinion is that events are good if there are different configurations the app runs with; in this case there is only one desired configuration, so no need to make it pluggable
[19:18] <poolie> thanks benji
[19:18] <benji> np
[19:39] <lifeless> poolie: see the profile hooked code - it does before & after hooks
[19:39] <lifeless> poolie: berforeTraversal is not what you think it is
[20:32] <lifeless> what rolls onto edge - stable, right ?
[20:46] <mars> lifeless, yes, stable is deployed to edge
[20:47] <lifeless> ok, so I has to be patient ;)
[20:48] <lifeless> hopefully I will have a pleasant surprise in the morning
[21:25] <lifeless> Ursinha: hi
[21:25] <Ursinha> hi lifeless
[21:25] <Ursinha> shoot
[21:26] <lifeless> Ursinha: in the edge errors mail sent to the list, Errors for 2010-07-21
[21:26] <Ursinha> hm
[21:26] <lifeless> = Top 15 Time Outs (total of 52 unique items) ==
[21:26] <lifeless> 54  SELECT COUNT(*) FROM Archive ...
[21:26] <lifeless> there is no bug number
[21:26] <lifeless> but if I go to the first oops
[21:26] <lifeless> there is a bug on the oops
[21:26] <lifeless> is there a bug on oopstools about this ?
[21:27] <Ursinha> lifeless, I'm filing one now
[21:27] <lifeless> same for the next group
[21:27] <lifeless> Ursinha: thanks a lot
[21:27] <lifeless> IMO this should be high, because its workflow support for the zero oops story
[21:28] <lifeless> Ursinha: I was going to look at the bug in oops tools you mentioned, but we had a massive testfix failure today, so spent lots of time digging into storm with jkakar to fix that
[21:28] <lifeless> sorry :(
[21:28] <Ursinha> lifeless, that's ok, I know that's not abandoned
[21:30] <Ursinha> lifeless, in fact I have a discussion about that bug with gary_poster today, and the proper fix isn't trivial. I have to ask matsubara which approach he chose in the branch that's linked to the bug
[21:30] <Ursinha> *I had
[21:31] <lifeless> ok
[21:32] <lifeless> thats a little concerning: 116741.01launchpad-main-masterINSERT INTO OAuthNonce (access_token, nonce, request_timestamp) VALUES (%s, %s, %s) RETURNING OAuthNonce.id
[21:32] <lifeless> 16 seconds to login, I guess
[21:37] <lifeless> bryceh: the bug attachments API call that is slow is the single largest oops cause in the system
[21:37] <lifeless> bryceh: just saying :)
[21:37] <lifeless> gnight y'all
[21:38] <lifeless> bryceh: if you want help on it, drop me mail; I'll see what I can do tomorrow.
[21:38] <lifeless> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/424671 for reference
[21:38] <_mup_> Bug #424671: attachments: accessing attachment's message is very slow <api> <performance> <timeout> <Launchpad Foundations:Triaged by leonardr> <https://launchpad.net/bugs/424671>
[21:39] <bryceh> lifeless, yep quite familiar with it I am
[21:40] <bryceh> would be wonderful to get that sorted out
[21:40] <lifeless> -> zzz
[22:16] <mars> Silly question: how do I set something other than the 'trunk' series to be the focus of development?
[22:17] <mars> I've created my new series and pushed the code, but no setting I can find lets me say "This is the focus"
[22:25] <mwhudson> mars: isn't it on the project +edit page?
[22:25] <mwhudson> yeah, it is
[22:25] <mwhudson> near the bottom
[22:32] <mars> mwhudson, alright, thanks.  I lost edit priveledges on the project due to group assignment, so I missed it.