[00:03] <sinzui> wgrant, stevenK mumble>
[00:17] <wgrant> Still no builders :/
[00:20] <LPCIBot> Project windmill-devel build #253: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-devel/253/
[00:32] <jcsackett> sinzui, wgrant, stevenK, wallyworld: i have to run. have a good one!
[00:42] <lifeless> is getUtility(IStoreSelector).get(MAIN_STORE, DEFAULT_FLAVOR) totally equivalent to IMasterStore(class) ?
[00:42] <wgrant> lifeless: No.
[00:42] <wgrant> MASTER_FLAVOR
[00:42] <lifeless> so when should we use IMasterStore?
[00:42] <StevenK> I'd like to kill getUtility(IStoreSelector)
[00:43] <lifeless> I'd like to kill all of it
[00:43] <wgrant> lifeless: IStoreSelector and I(Master|Slave)?Store are alternatives.
[00:43] <lifeless> we have had performance bugs talking to both stores
[00:43] <lifeless> wgrant: sure; but when should we use which one?
[00:44] <LPCIBot> Project devel build #820: STILL FAILING in 5 hr 33 min: https://lpci.wedontsleep.org/job/devel/820/
[00:44] <wgrant> lifeless: There is no difference.
[00:44] <wgrant> lifeless: Assuming you request the same flavour.
[00:45] <lifeless> Is thre an IDefaultStore then ?
[00:45] <StevenK> No, IStore
[00:45] <LPCIBot> Project parallel-test build #52: STILL FAILING in 1 hr 16 min: https://lpci.wedontsleep.org/job/parallel-test/52/
[00:45] <wgrant> Right, DEFAULT_FLAVOR is IStore
[00:45] <lifeless> right
[00:46] <lifeless> so put another way, we probably need to do IStore everywhere and nuke the slave/master use outside of the policy setup
[00:47] <wgrant> lifeless: Possibly.
[00:47] <lifeless> why wouldn't we?
[00:48] <wgrant> lifeless: Because in the past we have sometimes explicitly executed expensive queries on the slave.
[00:49] <lifeless> in terms of db bloat, long transactions (> a few seconds) are bad on any replica
[00:49] <wgrant> Load, not length.
[00:50] <lifeless> yes, I know thats what you wrote
[00:50] <lifeless> I'm picking it apart
[00:50] <lifeless> in terms of memory footprint, queries that are large will spill to disk
[00:51] <lifeless> in terms of cpu overhead, we've got more headroom on the master than on our slaves.
[00:51] <lifeless> if its a script, I want them talking to appservers anyway.
[00:52] <lifeless> I could see a case for parallel execution of complex queries, but our current stack isn't the right place for that anyhow
[00:59] <wgrant> StevenK: http://paste.ubuntu.com/630105/
[01:25] <LPCIBot> Project windmill-db-devel build #407: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill-db-devel/407/
[02:13] <StevenK> wgrant: Mind having another look at https://code.launchpad.net/~stevenk/launchpad/db-add-bprc/+merge/64783 ?
[02:19] <wallyworld> sinzui: ping
[02:27] <wgrant> StevenK: Reviewed.
[02:29] <StevenK> wgrant: You mean the long description of IBPP?
[02:29] <wgrant> Its docstring.
[02:29] <StevenK> Yes, as in the 3 line bit of the docstring?
[02:30] <wgrant> Yes.
[02:31]  * StevenK fixes that by removing it.
[02:38] <StevenK> wgrant: with dest_file as tempfile.NamedTemporaryFile(): ?
[02:43] <StevenK> Sigh, my knowledge of with sucks
[02:55] <wgrant> StevenK: Other way around, but yeah.
[03:44] <lifeless> -> buy a webcam for dublin
[04:00] <jtv> morning friends
[06:09] <wgrant> lifeless: qas is more than four months old. Shall we restore?
[06:23] <wallyworld> wgrant: have you tried to ec2 anything lately? i'm getting loads of what appear to be unrelated (to my changes) errors
[06:24] <wgrant> wallyworld: Not for a while. What's up?
[06:25] <wallyworld> wgrant: lots of stuff, from ImportError: cannot import name PackageBuild in soyez/model/archive.py to bug subscription errors, and much more
[06:26] <wgrant> wallyworld: This isn't your superconflictfun branch, is it?
[06:26] <wallyworld> wgrant: no, i shelved the latter pipes and landed something based on earlier work
[06:27] <wallyworld> the diff in the mp looks as i expect
[06:27] <wgrant> wallyworld: What if you merge devel? No crisscrosses?
[06:27] <wallyworld> not last time i tried which was yerterday. i'll try again. i just wanted to check first to see if it was "just me"
[06:28] <wgrant> buildbot is not crying. So probably just you.
[06:28] <wallyworld> :-(
[06:28] <wgrant> The subscription stuff crisscrossed and had to be reverted when it was landed.
[06:29] <wgrant> I'd merge devel into your branch and then check the rancestor diff.
[06:29] <wallyworld> doesn't really explain the PackageBuild import error and some others
[06:29] <wallyworld> since none of my changes went near there
[06:29] <wgrant> Exactly.
[06:29] <wgrant> Crisscross.
[06:30] <wgrant> Particularly if you merged any of the Bugs branches at any stage.
[06:30] <wgrant> Or anything even slightly related to them.
[06:30] <wallyworld> i've only merged devel
[06:30] <wgrant> Ever?
[06:31] <wallyworld> so far as i can recall
[06:31] <wallyworld> just merged in devel, no aparent problems
[06:32] <wallyworld> but then again, there weren't that many new changes from yesterday
[06:59] <wgrant> wallyworld, StevenK: Do you see any reason to not restrict the email address search to (email = ? OR email LIKE ? || '@%%')?
[06:59] <wgrant> I doubt searching for partial email addresses is common, except for just specifying a local part.
[06:59] <wgrant> (and we get heaps of false prefix matches :/)
[07:03] <wallyworld> wgrant: i think that's a goof idea to implement
[07:03] <wallyworld> wgrant: bug 798847
[07:03] <_mup_> Bug #798847: Person picker search for partial IRC nickname doesn't return intended result <disclosure> <exploratory-testing> <person-picker> <Launchpad itself:Triaged> < https://launchpad.net/bugs/798847 >
[07:03] <wallyworld> wgrant: do we really want to search on partial irc nicks
[07:03] <wgrant> wallyworld: I saw that and considered won'tfixing it.
[07:03] <wgrant> It's a barrel of worms.
[07:03] <wallyworld> i agree
[07:03] <wgrant> Can of worms.
[07:04] <wgrant> Whatever the idiom is.
[07:04] <wallyworld> barrel of monkeys too
[07:04] <wallyworld> especially since the example was 'jools' and the user was searching for 'bigjools'
[07:05] <wallyworld> normally one would enter a prefix, not the last characters in a name
[07:05] <wgrant> That really requires tokenising IRC nicks further.
[07:05] <wgrant> And uh, no.
[07:05] <wallyworld> you mean you search for partial suffixes?
[07:06] <lifeless> wgrant: sure
[07:07] <wgrant> wallyworld: No. But to implement it would either mean matching any substring, or we'd have to guess at tokenising it without whitespace.
[07:08] <wgrant> So... no.
[07:08] <wgrant> Kill it.
[07:08] <wallyworld> wgrant: yes, that's why i said i agree we shouldn't do it :-)
[07:08]  * wgrant won'tfixes.
[07:09] <wgrant> Or perhaps I should wait for sinzui.
[07:11] <wallyworld> wgrant: i was going to ask him about that and also the picker batch widget bug but he had already EOD
[07:11] <wallyworld> i should say the pagination control bug 798772
[07:11] <_mup_> Bug #798772: Pagination in person picker should appear after the results, not before <disclosure> <exploratory-testing> <person-picker> <Launchpad itself:Triaged> < https://launchpad.net/bugs/798772 >
[07:12] <wgrant> wallyworld: We probably want to completely rework that.
[07:12] <wgrant> wallyworld: Remove the page numbers and stuff.
[07:12] <wallyworld> that is done in lazr-js so are we saying we want to change the paginator location for *all* pickers or just personpicker
[07:12] <wgrant> wallyworld: Since it makes lifeless war on batchnav very hard.
[07:12] <wgrant> So if we're going to move it to the bottom and break from lazr-js, we should really change it.
[07:13] <wallyworld> well, one step at a time perhaps
[07:13] <wallyworld> don't want too much scope creep
[07:13] <wallyworld> i'm wondering how that bug got tagged disclosure anyways
[07:14] <wgrant> Which?
[07:14] <wallyworld> the paginator one
[07:14] <wgrant> It was discovered during exploratory testing of the new shiny.
[07:14] <wallyworld> above ^^^
[07:14] <wgrant> So it's our problem unless we decide it isn't.
[07:14] <wallyworld> sure, but it's been there forever and is not related to our work
[07:14] <wallyworld> at all
[07:14] <wgrant> Our work was to make the pickers not suck.
[07:15] <wgrant> Search was part of that.
[07:15] <wgrant> Displaying more relevant info was another.
[07:15] <wallyworld> hmmm. not sure how having the paginator at the top makes the pickers suck
[07:15] <wallyworld> i like it there
[07:15] <wallyworld> less mouse movement
[07:15] <wgrant> Indeed.
[07:15] <wgrant> But some disagree.
[07:16] <wallyworld> well then they are wrong :-P
[07:16] <wgrant> Indeed!
[07:16] <lifeless> FWIW, paginator can be above or below IMO; page #'s however... poor idea
[07:16] <lifeless> which number will your result be on?
[07:16] <wgrant> lifeless: Poor and pointless.
[07:16] <lifeless> its like a lottery
[07:16] <wgrant> If you
[07:17] <wgrant> If you have to click past the first page for a given person more than once, we have failed.
[07:17] <wallyworld> the only thing i see them adding any value for is to indicate how many results there are, but that can be done other ways
[07:17] <StevenK> WOW.
[07:17] <StevenK> When did we hit bug 800000?
[07:17] <wgrant> wallyworld: But it's limited now, so it's only useful for very small numbers.
[07:17]  * StevenK prods _mup_ 
[07:17] <wgrant> Huh, so we did.
[07:17] <wgrant> Just noticed I filed bug #800043
[07:17] <_mup_> Bug #800043: IRC nickname search in person picker is case-sensitive <disclosure> <person-picker> <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/800043 >
[07:17] <wgrant> 800000 must be private.
[07:17] <wgrant> Yeah.
[07:18] <lifeless> wallyworld: showing the result set size is generally uninteresting
[07:18] <wallyworld> should we have a 1000000 party next month?
[07:18] <wgrant> Not even I can see it.
[07:18] <lifeless> wallyworld: there are a very few specific cases when its anything other than geek chic
[07:18] <StevenK> bug 799999
[07:18] <wallyworld> lifeless: i think it adds value but that's just me
[07:18] <lifeless> wallyworld: consider the phone book; do you care how many booths there are in it ?
[07:18] <wallyworld> yes!
[07:18] <lifeless> wallyworld: and how many freds ?
[07:18] <wgrant> It gives a hint as to the selectivity of your search.
[07:19] <wgrant> Whether you're likely to find the person in the next few pages.
[07:19] <lifeless> yes, the magnitude matters
[07:19] <wallyworld> when searching, if there are too many results, it gives you a cue to be more specific, especially if you want to browse the results
[07:19] <lifeless> few/10s/100s/many
[07:19] <wallyworld> wgrant: +1. what i was trying to say
[07:19] <lifeless> the precise count doesn't matter most of the time.
[07:20] <lifeless> and magnitude estimation isn't one of those times.
[07:20] <wallyworld> agree with that too
[07:20] <wallyworld> we should do it as a slider :-)
[07:20] <wallyworld> as you move  the slider, the results pan past
[07:21] <wallyworld> that would be way cool imnsho
[07:21] <lifeless> vertical slider would be nice
[07:21] <wallyworld> yes
[07:21] <lifeless> even just vertical next/prev markers
[07:21] <lifeless> rather than horizontal for things that are laid out vertically.
[07:21] <lifeless> that always gets me.
[07:22] <wallyworld> and also doesn't really suit right-left locales either
[07:24] <lifeless> question
[07:24] <lifeless> are anonymous users None, or something else?
[07:25] <lifeless> in terms of LaunchpadView's self.user
[07:25] <wallyworld> i guess None but am not 100% sure
[07:25] <wallyworld> i recall some test code doing a self.user == None check
[07:26] <wgrant> None
[08:03] <wgrant> Bah.
[08:03] <wgrant> The email address prefix is useful :(
[08:03] <wgrant> For eg. "jon" won't catch jcsackett without it.
[08:04] <wgrant> Because his displayname is crazy.
[08:33] <rvba> wgrant: Hi! I'm sorry to bother you again with this but could you have a look at the multi parent branch? (https://code.launchpad.net/~rvb/launchpad/init-series-bug-789091-devel/+merge/63676)
[08:36] <wgrant> rvba: And what about sources?
[08:36] <wgrant> And are you regretting trying to do this yet? :P
[08:37] <rvba> Well, not yet :)
[08:37] <wgrant> Ah, good, Soyuz has got your soul already.
[08:38] <rvba> wgrant: So I suppose the same trick should be used for the sources then ...
[08:38] <wgrant> I guess so :/
[08:39] <wgrant> Also this is probably going to be very slow.
[08:39] <wgrant> But maybe not.
[08:39] <rvba> I'll estimate the overhead of this.
[08:44] <lifeless> wgrant: jcsackett working is a bit of a special case
[08:44] <wgrant> lifeless: It is, but it helps for some other cases too.
[08:44] <wgrant> Because name stemming is hard.
[08:44] <lifeless> wgrant: folk that don't make their metadata match the identity they tell their peers are going to be pretty hard to find
[08:53] <wgrant> lifeless: Thanks.
[08:56] <adeuring> good morning
[09:18] <rvba> wgrant: Fix pushed (tests added: test_binaryfile_already_in_archive/test_sourcefile_already_in_archive).
[09:32] <lifeless> grar
[09:32] <lifeless> serial conflicts
[09:32] <lifeless> *hates* on 4 hour test runs
[09:34] <StevenK> Then fix it, dear Eliza?
[09:35] <lifeless> StevenK: its in the pipeline
[09:35]  * StevenK is only trolling.
[09:36] <lifeless> I know
[09:55] <maxb> Morning all. How is the deployment report looking today?
[10:21] <jml> good morning Launchpadders
[10:21] <jml> I was getting productive email stuff done and thought, "why am I so productive"
[10:21] <jml> and then I realized my IRC client was off
[10:27] <wgrant> maxb: Somewhat dire.
[10:28] <wgrant> Still blocking on lots of reasonably nasty jtv QA in the middle of the 12000 line branch.
[10:28] <wgrant> And Red squad seems to not be here today.
[10:29] <wgrant> (your rev is after the 12000 line branch, its reversion, and its relanding, but there is another QA fix after that, and before that is jtv's stuff)
[10:40] <rvba> wgrant: Julian is ill. Jtv has trouble with irc. The rest of us is here ;)
[10:41] <wgrant> rvba: Do you know if he's working on his QA?
[10:42] <rvba> wgrant: jtv?
[10:42] <wgrant> rvba: Yes.
[10:42] <rvba> wgrant: I don't know ... He can be reached by email.
[10:43] <rvba> wgrant: I've fixed the problem we talked about earlier this morning (https://code.launchpad.net/~rvb/launchpad/init-series-bug-789091-devel/+merge/63676)
[10:44] <wgrant> rvba: I think we need to chat with Julian about this.
[10:44] <rvba> wgrant: ok.
[10:45] <wgrant> Hmmm.
[10:45] <wgrant> All domestic flights in south-eastern .au cancelled tomorrow. And all internationals delayed probably until Friday.
[10:46] <wgrant> This does not bode well.
[10:49] <StevenK> Indeed
[10:49] <jml> wgrant: Chile volcano?
[10:49] <huwshimi> jml: yeah
[10:50] <jml> huwshimi: you managed to escape though.
[10:50] <huwshimi> jml: There have been delays for the last week or so
[10:50] <nigelb> Wait, a volcano in Chile is affecting .au? o.O
[10:50] <huwshimi> jml: Yeah, just
[10:50] <wgrant> nigelb: The ash is everywhere.
[10:50] <wgrant> Well.
[10:50] <wgrant> Mostly above us now.
[10:50] <lifeless> nigelb: ash going west
[10:50] <wgrant> But still everywhere.
[10:50] <nigelb> Ahh. I forgot about the earth being round temporarirly.
[10:51] <jml> nigelb: yeah. all that hippy crap about us being interconnected beings on one planet turns out to be true
[10:51] <nigelb> jml: lol
[10:51] <nigelb> wgrant: Are you going to miss the sprint or rally or whatever its calle dnow.
[10:51] <nigelb> *called now
[10:51] <wgrant> nigelb: Hopefully not!
[10:52] <nigelb> :)
[10:52] <wgrant> I think it's still a Thunderdome.
[10:52] <wgrant> But I'm not sure.
[10:52] <wgrant> Maybe just an Epic.
[10:52] <wgrant> Which is colocated with the Platform Rally.
[10:52] <nigelb> Fun!
[10:53] <nigelb> jml: On reading the blog post about your depature, I first feared you were leaving Canonical :)
[10:54] <jml> nigelb: nope
[10:54] <jml> nigelb: very glad to be staying
[10:55] <nigelb> jml: :)
[10:55] <cjwatson> LP's loss is our gain :-)
[10:55] <nigelb> heh
[11:00] <lifeless> jelmer: hi
[11:01] <lifeless> jelmer: did you redefine the meaning of persisted enums in your code import patch?
[11:03] <jelmer> lifeless: hi
[11:04] <jelmer> lifeless: These were prematurely added constants according to mwhudson, never used in real life.
[11:05] <lifeless> k
[11:22] <lifeless> argh, the deploy queue just got riskier still
[11:22] <lifeless> jelmer: how would you feel about rolling back that code import autoupgrade thing?
[11:23] <jml> just came across https://dev.launchpad.net/LaunchpadHackingFAQ
[11:23] <jml> there's a blast from the past.
[11:23] <lifeless> jelmer: we've a few high risk things already in the queue, and with yours added we may be unable to deploy for days
[11:25] <lifeless> jelmer: if you're -really- confident in it, its fine.
[11:26] <lifeless> jelmer: I'm also curious why you didn't just fix the scanner to handle the new backup directory scheme bzr uses ( I think there is a code hosting bug on that)
[11:26] <lifeless> s/just//
[11:26] <wgrant> lifeless: s/days/even more days/
[11:27] <wgrant> But I think jelmer's fix looks good, FWIW.
[11:28] <jml> *sigh*
[11:29] <jml> https://dev.launchpad.net/Hacking is a fork of LaunchpadHackingFAQ
[11:35]  * jml sets about merging the two and deleting the latter
[11:41] <wgrant> cjwatson: Nothing of note this week that will prevent a couple of minutes' downtime for cocoplum services, while we update it for your germinate change?
[11:46] <lifeless> allenap: how is rabbit fixture looking ?
[11:47] <allenap> lifeless: I landed it on Saturday :) No failure so far (that I'm aware of) \o/
[11:47] <lifeless> \o/
[11:47] <lifeless> allenap: did you file a bug upstream?
[11:47] <cjwatson> wgrant: nope, please go ahead
[11:48] <allenap> allenap: No. I wonder if I should file it on Erlang or RabbitMQ.
[11:48] <lifeless> allenap: rabbit for starters
[11:48] <lifeless> they offer programs after all :)
[11:49] <allenap> lifeless: Okay.
[11:49] <lifeless> allenap: also, do you want to land my layer patch now the substrate is solid ?
[11:49] <allenap> lifeless: Yeah, good idea.
[11:53] <jml> do we have a standard wiki macro for "obsolete page"?
[11:54] <nigelb> jml: remember jorge's lightning talk? ;)
[11:54] <nigelb> Delete! Delete! Delete!
[11:55] <jml> nigelb: yeah, that was the Ubuntu wiki
[11:55] <jml> and I have deleted some stuff already
[11:55] <nigelb> I didn't know there was help on tal stuff till now.
[11:55] <nigelb> I went and read zope documentation for that and didn't understand much.
[12:00] <StevenK> Tal is quite ... opaque.
[12:01] <nigelb> StevenK: Interesting choice of words.
[12:30] <jelmer> lifeless, sorry, I missed that
[12:30] <jelmer> lifeless, bzr's scheme hasn't changed, but it has one method to backup an existing and one for renaming a directory out of the way
[12:31] <jelmer> they have different naming schemees. the second is only used by "bzr join" at the moment.
[12:52] <lifeless> jelmer: so how did we end up with the latter scheme named directories during the incident?
[12:57] <jelmer> lifeless: I called that method manually
[12:58] <jelmer> I don't think bzr should have two name schemes for backed up .bzr directories
[13:06] <lifeless> you're going to change join ?
[13:11] <jelmer> lifeless: I filed a bug about it
[14:24] <deryck> Hi, abentley and adeuring
[14:25] <abentley> deryck: hi.
[14:25] <deryck> abentley, adeuring -- so it's very noisy in this place.  Can we do an IRC standup?
[14:26] <abentley> deryck: sure.
[14:26] <deryck> let's wait on adeuring to ack before we start.
[14:27] <abentley> deryck: we could make a temporary channel, or use #launchpad-meeting, if you like.
[14:27] <adeuring> deryck: abentley: I'm here
[14:28] <deryck> abentley, sure, let's move to #launchpad-meeting to avoid too much noise here.
[14:28] <deryck> adeuring, hi.  changing channels ^^
[14:33] <jml> jelmer: you'll be in Dublin, right?
[14:33] <jelmer> jml:Yep
[14:40] <adeuring> deryck: could you please run this SQL statement on staging: http://paste.ubuntu.com/630399/ ?
[14:41] <deryck> adeuring, sure.... grabbing it now
[14:44] <abentley> adeuring: why "select 1"?  Doesn't that just return "1" always?
[14:44] <danilos> matsubara, hi, is there a way to easily search for any OOPSes beginning with "IntegrityError: duplicate key value violates unique constraint \"tm__potmsgset" across all of our systems?
[14:45] <adeuring> abentley: I have in idea yet. I guess that the idea is to see if the is any record matching the WEHER clause
[14:45] <matsubara> danilos, I can query the oops db using SQL. there's no UI to do such search in oops-tools
[14:46] <adeuring> s/in idea/no idea/
[14:46] <adeuring> abentley:  I even don't know yet where the query comes from in Python ;)
[14:47] <abentley> adeuring: I think SELECT 1 will always return 1.
[14:47] <danilos> matsubara, can you please do that for the above exception text? after "tm__potmsgset" there could be different things
[14:47] <adeuring> abentley: except if there are no result rows
[14:49] <danilos> matsubara, if LIKE "blah%" is too slow, you can look for actual constraints from https://bugs.launchpad.net/launchpad/+bug/603530/comments/5
[14:49] <_mup_> Bug #603530: Still violating tm__potmsgset__potemplate__language__no_variant__diverged__impo <lp-translations> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/603530 >
[14:50] <matsubara> danilos, thanks. LIKE syntax is not returning me any results
[14:50] <abentley> adeuring: Ah, I see.
[14:51] <deryck> adeuring, here you are.  with two runs, to warm the cache.  https://pastebin.canonical.com/48802/
[14:52] <adeuring> deryck: thanks!
[14:52] <deryck> np
[14:53] <adeuring> abentley: ^^^ So, now I'll stare for a while at the result (practically, I'll print it out so I can make notes with a pencil)
[14:53] <danilos> matsubara, cool, I think we can call that bug closed, so we just solved one critical bug :) yaay ;)
[14:53] <matsubara> danilos, not so fast
[14:54] <matsubara> danilos, https://devpad.canonical.com/~matsubara/danilo-integrity-error.txt
[14:54] <danilos> matsubara, oh, :(
[14:54] <danilos> matsubara, these are all still from last year, before this code was rolled out
[14:55] <danilos> ok, now there's a few new ones
[14:55] <matsubara> danilos, reload. the file was incomplete. it should show you 972 rows
[14:57] <danilos> matsubara, yeah, the final ones seem to be from March 1st
[14:58] <matsubara> danilos, hmm perhaps I should order that by date to make things easier
[14:58] <danilos> matsubara, yeah
[14:58] <danilos> matsubara, that'd be helpful :)
[14:59] <matsubara> danilos, ok, refresh and it'll be ordered
[15:03] <danilos> matsubara, thanks; considering they were happening every day multiple times until March 1st, I'll still call the bug fix released if it hasn't ever happened since
[15:03] <matsubara> danilos, sounds good
[15:03] <danilos> matsubara, also, I can't get to any of those OOPSes myself
[15:04] <danilos> matsubara, i.e. does https://lp-oops.canonical.com/oops.py/?oopsid=1886M2307 work for you?
[15:04] <matsubara> danilos, yeah, those are not referenced in the LP db, so the oops purge deleted them
[15:04] <danilos> matsubara, ah, ok, thanks
[15:06] <sinzui> deryck, can you run GTK_DEBUG=ALL ./bin/test -vv --layer=YUI 2>1 >  _test.log and send/pastebin the log for me
[15:07] <deryck> sinzui, definitely.  Thanks for continuing to work on this!
[15:07] <deryck> was going to ping you too :)
[15:09] <adeuring> abentley: There is a line "sort method: external merge" in the "explain analyze" output: That for the "UNION" statement, I assume. One of the two subqueries needs 13 seconds, and the other a few milliseconds. So, the first thing that could be changed is: Run the queries separately. that would save 7 seconds. Not enough, but it could be a start. Next thing I'll do is to figure out where the query is issued in Python.
[15:14] <deryck> sinzui, unfortunately, not much to see:  http://pastebin.ubuntu.com/630410/
[15:14] <sinzui> oh, I get huge amounts for data
[15:15] <sinzui> maybe my stderr redirect is mangled
[15:15] <abentley> adeuring: if it's just running an existence check, I wonder whether adding LIMIT 1 to the subselects would help.
[15:15] <adeuring> abentley: right, that could help. Lets' try it!
[15:17] <deryck> sinzui, I did 2>&1 > file, which I thought was the correct form.  but same output.
[15:17] <deryck> sinzui, maybe I need debug version of a package?
[15:17] <adeuring> deryck: could you please try another query: http://paste.ubuntu.com/630412/ ?
[15:17] <deryck> adeuring, sure.
[15:18] <sinzui> deryck, I fear that I can see the needed data because I am using development vrsions of gtk libvs
[15:18] <sinzui> deryck, I think your libs are compiled with debug off
[15:18] <deryck> sinzui, yeah.
[15:18] <deryck> sinzui, I don't mind compiling if you want, but I fear that might also fix the issue :)
[15:18] <sinzui> I get 2000 lines of output
[15:21] <huwshimi> deryck: Do you want to reschedule our call today? Sounds like things are a bit crazy where you are.
[15:21] <deryck> huwshimi, it's still top of next hour, right?
[15:22] <huwshimi> deryck: Yeah
[15:22] <deryck> huwshimi, I'll be fine for that.
[15:22] <huwshimi> deryck: OK sure, as long as it's easy enough for you
[15:22] <deryck> huwshimi, oh yeah, np.  I'll tell everyone else to go away in 40 minutes. :)
[15:23] <sinzui> deryck, you would need libgtk2*-dbg and libwebkitgtk-3*-dbg and I do not know if they replace your current libs
[15:23] <huwshimi> deryck: haha
[15:23] <deryck> sinzui, ok, let me apt-get install
[15:25] <deryck> adeuring, https://pastebin.canonical.com/48809/
[15:26] <adeuring> deryck: thanks!
[15:26] <deryck> np!
[15:27] <deryck> sinzui, I need to switch back to my main office.  be back online in 10.  and I'll finish this install and try again then.
[15:29] <adeuring> abentley: ^^^ so, some progress, but the sorting for the first subquery needs 4 seconds, even in the second run. I'll look now where the query is issued and will try to understand why it is executed.
[15:41] <deryck> sinzui, I'm back working on this.  dbg package for libwebkitgtk is taking forever to download.
[15:43] <sinzui> :(
[15:44] <sinzui> I wish one of my computers would show the segfault
[15:44] <sinzui> though my daughters are happy I stopped taking their computers to test this
[15:46] <deryck> sinzui, so nothing new in the log even after the dbg packages
[15:46] <sinzui> :(
[15:50] <nigelb> jcastro: woah, good one!
[15:50] <nigelb> argh
[15:56] <deryck> sinzui, can you paste the command you're using to get the log once more?
[15:57] <sinzui> New yucky attempt: strace -Ff -tt ./bin/test -vv --layer=YIU 2>&1 | tee _strace.log
[15:58] <deryck> now there's some noise :)
[15:58] <sinzui> deryck, old with noise: GTK_DEBUG=ALL ./bin/test -vv --layer=YUI 2>&1 | tee  _test.log
[15:59] <adeuring> abentley: The "bad query" is executed during Snapshot(ubuntu) in lp.app.browser.launchpadform.LaunchpadEditFormView.updateContextFromData(). So, a "regular property", don't know yet which one it is.
[15:59] <sinzui> I am familiar with the gtk output. strace will challenge my archeology skills.
[16:00] <huwshimi> deryck: Ready when you are. How do you want to do this?
[16:00] <deryck> huwshimi, 3 minutes and I'll meet you in mumble, cool?
[16:01] <sinzui> okay
[16:01] <huwshimi> deryck: Yeah that's fine
[16:02] <deryck> sinzui, heh, the paste is straining my browser to return control to me. :)
[16:02]  * deryck tries chromium
[16:05] <deryck> sinzui, I can't get a pastebin to load it, so I'm pushing it to my home on devpad as yui-strace.log.  15% now. :)
[16:05] <sinzui> okay
[16:05] <huwshimi> deryck: Do you want to just let me know when you're done. There's no hurry
[16:06] <deryck> huwshimi, joining mumble now
[16:06] <huwshimi> deryck: Sure
[16:06] <deryck> huwshimi, meet me in Orange 1 o 1.
[16:06] <huwshimi> deryck: no problems
[16:10] <adeuring> abentley: tracing through Snapshot.__init__() with pdb and watching the postgersql statement log, it seems that Distribution.has_published_sources issues the bad query.
[16:14] <gmb> adeuring: Ping for when you've got a second.
[16:14] <adeuring> gmb: yes?
[16:14] <gmb> adeuring: There's a question on answers.lp.n about deleting HWDB submissions; I have no idea about it. Could you take a look if you ahve the time: https://answers.launchpad.net/launchpad/+question/161972
[16:14] <gmb> ?
[16:15] <adeuring> gmb: sure
[16:15] <gmb> Thanks
[16:16] <flacoste> danilos: what's happening with the qa of bug 772754?
[16:16] <_mup_> Bug #772754: After better-bug-notification changes, list of bug subscribers is confusing <qa-needstesting> <story-better-bug-notification> <Launchpad itself:Fix Committed by gary> < https://launchpad.net/bugs/772754 >
[16:17] <flacoste> rvba, allenap: can one of you assess if we can deploy revision 13259, please?
[16:17] <danilos> flacoste, same as yesterday, it's qa-ok if r13258 is included in the deployment, but revisions in between are still in qa-needstesting; I've emailed jtv asking him to QA his 3 non-trivial revisions
[16:17] <gary_poster> flacoste, danilos, jtv replies saying that bigjools needed to do the qa
[16:18] <flacoste> danilos: the only needstesting that i see before 13258 are yours actually
[16:18] <gary_poster> but he is out
[16:18] <rvba> bigjools is not here today :(
[16:18] <danilos> flacoste, maybe they've done it in the last 30 mins or so
[16:18] <flacoste> rvba: i know, that's why i'm asking you :-)
[16:18] <flacoste> or allenap
[16:18]  * rvba looking
[16:18] <flacoste> that's related to what you guys have been working on
[16:19] <flacoste> danilos: what do we need to do to make the report happy, for you revision, do you know?
[16:19] <danilos> flacoste, they are all for 772754, and I've marked it as qa-ok now that it's all clear up to 13258
[16:19] <danilos> flacoste, wait for it to update now :)
[16:19] <flacoste> danilos: awesome!
[16:19] <flacoste> thanks
[16:19] <danilos> yw
[16:20] <timrc> jcsackett, hello, you there?
[16:23] <rvba> flacoste: just to make sure, you're talking about http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/13259 ?
[16:24] <flacoste> rvba: yes
[16:25] <rvba> Looks pretty safe to me, it's a simple change in a message displayed on the difference page.
[16:25] <flacoste> jcsackett: i think you made a mistake in your commit message
[16:25] <rvba> If DF is up to date I can even qa it.
[16:25]  * rvba checks.
[16:26] <flacoste> jcsackett: revision 13251 looks like it's still blocked, but I think your 13260 commit actually reverts it
[16:26] <flacoste> jcsackett: but it was tagged rollback-13521
[16:26] <flacoste> jcsackett: if that's the case, maybe changing the tag will make the qatagger script happy
[16:33] <flacoste> danilos: i think deployment is still blocked on jcsackett and rvba as we cannot deploy without the rollback of revision 13251
[16:33] <rvba> flacoste: I marked bug 798222 (fixed by 13259) as qa-ok because the fix is a one-liner fixing a simple 'display' bug.
[16:33] <_mup_> Bug #798222: +localpackagediffs should explicitly say "no diff available" <derivation> <qa-ok> <Launchpad itself:Fix Committed by julian-edwards> < https://launchpad.net/bugs/798222 >
[16:34] <rvba> flacoste: is that ok with you?
[16:34] <flacoste> rvba: fine withe me, thanks
[16:37] <poolie> gmb: can you pilot barry's patch to bug 797281?
[16:37] <_mup_> Bug #797281: LP API broken in oneiric with python-httplib2 0.7.0-1 <oneiric> <lazr.restfulclient:In Progress> <python-httplib2 (Ubuntu):Fix Released by barry> <python-httplib2 (Ubuntu Oneiric):Fix Released by barry> < https://launchpad.net/bugs/797281 >
[16:37] <gmb> poolie: Sure thing.
[16:40] <poolie> ta
[16:48] <LPCIBot> Project windmill-devel build #258: STILL FAILING in 41 min: https://lpci.wedontsleep.org/job/windmill-devel/258/
[16:55] <jcsackett> flacoste: sorry, didn't get msg updated when you pinged me.
[16:55] <flacoste> poolie, gmb: i'm actually on it
[16:55] <jcsackett> 13260 is indeed a rollback of 13251.
[16:56] <adeuring> deryck: could you try another query: http://paste.ubuntu.com/630443/ (probably not very much progress, but anyway...)
[16:56] <deryck> adeuring, sure.
[16:56] <deryck> sinzui, my strace is up on devpad now, btw.
[16:56] <gmb> flacoste: Oh. Bugger, I've just merged that and pushed it since it was r=.
[16:57] <flacoste> gmb: fine by me :-)
[16:57] <flacoste> gmb: technically, we should run the tests manually
[16:57] <flacoste> since there is no automated PQM test run there
[16:57] <flacoste> just to make sure
[16:57] <gmb> flacoste: yes, that thought occurred to me after I'd pushed it. I'll do that now.
[16:57] <flacoste> but i'm sure barry did it
[16:57] <flacoste> :-)
[16:57] <sinzui> deryck, thank. I pulled it a while ago
[16:58] <deryck> sinzui, ok, cool, thanks for the help!
[16:58] <deryck> adeuring, looks fast to me.  :)  https://pastebin.canonical.com/48812/
[16:59] <jcsackett> flacoste: i'm not sure what the tag issue is; looking at our qaprocess stuff in the wiki it's tagged appropriately. a bad commit tag for the bad revision, and all qa tags removed. thoughts on what it should be?
[16:59] <flacoste> jcsackett: the message was [rollback=13521]
[17:00] <adeuring> deryck: uh, yes, thanks! I assumed that we would have an ORDER BY which would slow down the query, but this is good eoungh, I think
[17:00] <deryck> adeuring, excellent.
[17:00] <adeuring> deryck: now I just need to duble-check that it was the right query :)
[17:01] <jcsackett> flacoste: that was the bad revno. qaprocess says rollback=badrevno, unless i'm being dense?
[17:01] <flacoste> Ursinha: how can we unblock the qatagger?
[17:01] <deryck> adeuring, so you need me to run it again?
[17:01] <adeuring> deryck: no, I just want to double-check if I did not make a copy_paste error or some other nonsense
[17:01] <flacoste> jcsackett: deployment-stable.html shows "[r=jcsackett][bug=707234][rollback=13521] " has the commit message
[17:01] <flacoste> which is not the correct revision
[17:02] <flacoste> but the tags are correct
[17:02] <jcsackett> flacoste: aaah, crap, yes i see.
[17:02] <deryck> adeuring, ah, ok.
[17:04] <flacoste> anyway, we should be good to deploy up to 13265
[17:04] <flacoste> so i'm going to ask for that
[17:04] <flacoste> after lunch
[17:05] <jcsackett> sounds good.
[17:14] <timrc> jcsackett, do you think you'll be able to attempt to ec2-land my changes again :)?
[17:15] <abentley> sinzui: I also get the segfault on my natty vm, now that I've properly updated it.
[17:16] <sinzui> abentley, does the vm install anything special? Is it natty + rocketfuel?
[17:17] <abentley> sinzui: Not special.  An X86-64 Ubuntu desktop.  I can provide a package list if useful.
[17:17] <abentley> sinzui: it does have libgtk2.0 on it.  Shall I pull that?
[17:17] <sinzui> oh
[17:18] <sinzui> deryck, are you 64bit?
[17:18] <sinzui> abentley, a package list would rock.
[17:19] <deryck> sinzui, indeed I am.
[17:19] <deryck> sinzui, I should have mentioned that.  it's important.  sorry.
[17:22] <jcsackett> timrc: sure, paste me the link, and i'll see to it in a moment. :-)
[17:23] <timrc> jcsackett, I pushed a new branch 4 days ago that fixed those test failures.. should I merge in trunk before attempting this again.
[17:23] <timrc> ?
[17:23] <timrc> (it's been 4 days)
[17:23] <timrc> https://code.launchpad.net/~timrchavez/launchpad/set_ppa_private_from_api_724740-4/+merge/64840
[17:23] <timrc> jcsackett^
[17:32]  * jml pulls stable, first time in a while
[17:34] <adeuring> gmb: fancy a review of a small MP: https://code.launchpad.net/~adeuring/launchpad/bug-799785/+merge/65373 ?
[17:34] <gmb> adeuring: Sure
[17:41] <LPCIBot> Project windmill-devel build #259: STILL FAILING in 40 min: https://lpci.wedontsleep.org/job/windmill-devel/259/
[17:42] <gmb> adeuring: Approved
[17:42] <adeuring> gmb: thanks!
[17:54] <Ursinha> flacoste: sorry, I was lunching and forgot to change my nick
[17:55] <Ursinha> let me read the backlog
[17:59] <jcsackett> timrc: you should basically always update from trunk before trying to land.
[18:02] <Ursinha> flacoste: if the problem is that the commit msg has the wrong number, quick workaround is remove the tag from the bug; proper solution is to fix bug 659629
[18:02] <_mup_> Bug #659629: qa metadata for commits is write-once and cannot be updated <qa-tagger:Triaged> < https://launchpad.net/bugs/659629 >
[18:17] <LPCIBot> Project db-devel build #652: STILL FAILING in 6 hr 10 min: https://lpci.wedontsleep.org/job/db-devel/652/
[18:23] <flacoste> Ursinha: you mean remove the bad-commit-13521 tag?
[18:23] <flacoste> err, bad-commit-13251
[18:23] <Ursinha> yes
[18:23] <Ursinha> if we know that is ok to land, I believe adding qa-ok would do the trick
[18:28] <LPCIBot> Project parallel-test build #56: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/parallel-test/56/
[18:28] <LPCIBot> Launchpad Patch Queue Manager: [r=lifeless][bug=797820, 800043] In ValidPersonOrTeamVocabulary,
[18:28] <LPCIBot> move non-exact non-FTI matches back down into the FTI range. Also
[18:28] <LPCIBot> match IRC nicknames case-insensitively.
[18:32] <jml> g'night all
[18:34] <Ursinha> night jml
[18:49] <m4n1sh> Isn't a wait for 18 hours  a bit too much for PPA build
[18:49] <m4n1sh> https://launchpad.net/~zeitgeist/+archive/ppa/+build/2582837
[18:51] <LPCIBot> Project windmill-db-devel build #412: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill-db-devel/412/
[18:51] <maxb> Undesirable, sure. The available resources just aren't there
[18:57] <LPCIBot> Project devel build #823: STILL FAILING in 6 hr 5 min: https://lpci.wedontsleep.org/job/devel/823/
[18:59] <m4n1sh> sad
[19:05] <abentley> m4n1sh: It appears we lost the borrowed builders on June 17 and the queue's been a little nuts since then.
[19:06] <m4n1sh> abentley: borrowed builders?
[19:07] <abentley> m4n1sh: A bunch of our builders are actually borrowed from another department.  Hardware enablement?  Can't recall.
[19:07] <m4n1sh> hmm
[19:07] <m4n1sh> never mind, can wait
[19:31] <abentley> sinzui: So much stuff depends on libgtk2.0-0...
[19:31] <sinzui> abentley, yeah
[19:35] <sinzui> abentley, I really suspect 64bit is the issue. Maybe deryck can confirm he is using 64bit
[19:35] <deryck> sinzui, I am
[19:35]  * deryck thought he confirmed that this morning
[19:37] <sinzui> deryck, sorry, I was being an idiot
[19:37] <sinzui> Now I need to get a 634bit install
[19:37] <deryck> sinzui, no, no worries.  Just couldn't completely recall myself. :)
[20:05] <flacoste> m4n1sh, abentley: yes, about half of the builders are taken for hardware enablement at critical points in the Ubuntu release cycle, it usually lasts a few days (though sometimes they forget to put them back in the main pool)
[20:18] <timrc> jcsackett, okay, merged trunk 39 minutes ago... (sorry I've been pulled 50 different directions)
[20:18] <timrc> jcsackett, https://code.launchpad.net/~timrchavez/launchpad/set_ppa_private_from_api_724740-4/+merge/64840
[20:18] <jcsackett> timrc: i saw when you did, i've sent it out.
[20:19] <timrc> jcsackett, great, thanks :) I will begin praying now
[20:50] <jcsackett> sinzui: have some time to chat?
[20:50] <sinzui> jcsackett, you request is timely. yes
[20:56] <bac> flacoste: i'm trying to do a collection assignment in the API/lplib but am getting NoBoundRepresentationError.  am trying archive.enabled_restricted_families = [arm] -- any hints?
[20:56] <bac> where arm is a proper IProcessorFamily object
[20:57] <flacoste> bac: we don't support that
[20:57] <flacoste> bac: that's why i suggested exporting the mutator as an operation
[20:57] <flacoste> setEnabledRestrictedFamilies(families)
[20:58] <bac> flacoste: i must've missed that suggestion
[20:58] <flacoste> or add/removeEnabledRestrictedFamily()
[20:58] <flacoste> i probably wasn't clear
[20:58] <flacoste> so get -> through the collection
[20:58] <bac> flacoste: or it flew over with all the other stuff we discussed
[20:58] <flacoste> set -> through operations
[20:58] <flacoste> one or many
[20:59] <flacoste> add/Remove/set
[20:59] <flacoste> i don't have a strong opinion
[20:59] <flacoste> set is probably fine
[20:59] <bac> flacoste: thanks!
[20:59] <flacoste> since they can get the collection, turn that into an array
[20:59] <flacoste> list
[20:59] <flacoste> and then call set with the changes
[21:37] <lifeless> moin
[21:57] <jcsackett> sinzui: have a moment?
[23:11] <lifeless> pop quiz
[23:12] <lifeless> whats a great micro-framework for python webapps, present (and usable) in lucid ?
[23:12] <lifeless> gary_poster: hi; are there docs on setting up a new buildout-as-we-use-it for a new project?
[23:14] <cody-somerville> lifeless, django? :P
[23:15] <lifeless> cody-somerville: *micro*
[23:21] <cody-somerville> lifeless, python-flask advertises its self as a micro framework but isn't available in lucid. However, in addition to python-django I did find the following in lucid: python-quixote, python-pylons, python-cherrypy3, python-turbogears2, and python-webpy
[23:29] <LPCIBot> Project parallel-test build #57: STILL FAILING in 1 hr 17 min: https://lpci.wedontsleep.org/job/parallel-test/57/
[23:31] <lifeless> cody-somerville: yeah, none of those are microframeworks
[23:31] <lifeless> except webpy kindof
[23:33] <lifeless> I think I'll give web.py a shot
[23:33] <lifeless> but first, lxc
[23:33] <LPCIBot> Project windmill-devel build #260: STILL FAILING in 1 hr 6 min: https://lpci.wedontsleep.org/job/windmill-devel/260/
[23:48] <lifeless> *hate* sample data.
[23:49] <lifeless> corrupt conjoined master row in the sample data.
[23:51] <wallyworld_> which table?
[23:52] <lifeless> bugtask
[23:52] <lifeless>  bug 3
[23:52] <_mup_> Bug #3: Custom information for each translation team <feature> <lp-translations> <Launchpad itself:Fix Released> <Ubuntu:Invalid> <mono (Ubuntu):Invalid> < https://launchpad.net/bugs/3 >
[23:52] <wallyworld_> very hard to get rid of sample data given how many tests use it
[23:52] <lifeless> shows 'status tracked in sarge'
[23:52] <lifeless> which means that the sarge row is a conjoined master
[23:53] <lifeless> but the sarge row is assigned to a milestone, and the master row is not.
[23:54] <wallyworld_> i assume that would never be allowed to happen in practice since our business logic would enforce the required ata integrity rules
[23:54] <lifeless> this makes bugsummary fail the distro portlet test because the sample data isn't consistent - the old code /may/ have queried series tasks
[23:54] <lifeless> I'm looking into the old code now :)
[23:56] <lifeless> right
[23:56] <lifeless> the prior code was counting milestones on either distro or distroseries