[00:03] wgrant, stevenK mumble> [00:17] Still no builders :/ [00:20] Project windmill-devel build #253: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-devel/253/ [00:32] sinzui, wgrant, stevenK, wallyworld: i have to run. have a good one! [00:42] is getUtility(IStoreSelector).get(MAIN_STORE, DEFAULT_FLAVOR) totally equivalent to IMasterStore(class) ? [00:42] lifeless: No. [00:42] MASTER_FLAVOR [00:42] so when should we use IMasterStore? [00:42] I'd like to kill getUtility(IStoreSelector) [00:43] I'd like to kill all of it [00:43] lifeless: IStoreSelector and I(Master|Slave)?Store are alternatives. [00:43] we have had performance bugs talking to both stores [00:43] wgrant: sure; but when should we use which one? [00:44] Project devel build #820: STILL FAILING in 5 hr 33 min: https://lpci.wedontsleep.org/job/devel/820/ [00:44] lifeless: There is no difference. [00:44] lifeless: Assuming you request the same flavour. [00:45] Is thre an IDefaultStore then ? [00:45] No, IStore [00:45] Project parallel-test build #52: STILL FAILING in 1 hr 16 min: https://lpci.wedontsleep.org/job/parallel-test/52/ [00:45] Right, DEFAULT_FLAVOR is IStore [00:45] right [00:46] so put another way, we probably need to do IStore everywhere and nuke the slave/master use outside of the policy setup [00:47] lifeless: Possibly. [00:47] why wouldn't we? [00:48] lifeless: Because in the past we have sometimes explicitly executed expensive queries on the slave. [00:49] in terms of db bloat, long transactions (> a few seconds) are bad on any replica [00:49] Load, not length. [00:50] yes, I know thats what you wrote [00:50] I'm picking it apart [00:50] in terms of memory footprint, queries that are large will spill to disk [00:51] in terms of cpu overhead, we've got more headroom on the master than on our slaves. [00:51] if its a script, I want them talking to appservers anyway. [00:52] 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] StevenK: http://paste.ubuntu.com/630105/ [01:25] Project windmill-db-devel build #407: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill-db-devel/407/ [02:13] wgrant: Mind having another look at https://code.launchpad.net/~stevenk/launchpad/db-add-bprc/+merge/64783 ? [02:19] sinzui: ping [02:27] StevenK: Reviewed. [02:29] wgrant: You mean the long description of IBPP? [02:29] Its docstring. [02:29] Yes, as in the 3 line bit of the docstring? [02:30] Yes. [02:31] * StevenK fixes that by removing it. [02:38] wgrant: with dest_file as tempfile.NamedTemporaryFile(): ? [02:43] Sigh, my knowledge of with sucks [02:55] StevenK: Other way around, but yeah. [03:44] -> buy a webcam for dublin [04:00] morning friends [06:09] lifeless: qas is more than four months old. Shall we restore? [06:23] wgrant: have you tried to ec2 anything lately? i'm getting loads of what appear to be unrelated (to my changes) errors [06:24] wallyworld: Not for a while. What's up? [06:25] wgrant: lots of stuff, from ImportError: cannot import name PackageBuild in soyez/model/archive.py to bug subscription errors, and much more [06:26] wallyworld: This isn't your superconflictfun branch, is it? [06:26] wgrant: no, i shelved the latter pipes and landed something based on earlier work [06:27] the diff in the mp looks as i expect [06:27] wallyworld: What if you merge devel? No crisscrosses? [06:27] 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] buildbot is not crying. So probably just you. [06:28] :-( [06:28] The subscription stuff crisscrossed and had to be reverted when it was landed. [06:29] I'd merge devel into your branch and then check the rancestor diff. [06:29] doesn't really explain the PackageBuild import error and some others [06:29] since none of my changes went near there [06:29] Exactly. [06:29] Crisscross. [06:30] Particularly if you merged any of the Bugs branches at any stage. [06:30] Or anything even slightly related to them. [06:30] i've only merged devel [06:30] Ever? [06:31] so far as i can recall [06:31] just merged in devel, no aparent problems [06:32] but then again, there weren't that many new changes from yesterday [06:59] wallyworld, StevenK: Do you see any reason to not restrict the email address search to (email = ? OR email LIKE ? || '@%%')? [06:59] I doubt searching for partial email addresses is common, except for just specifying a local part. [06:59] (and we get heaps of false prefix matches :/) [07:03] wgrant: i think that's a goof idea to implement [07:03] wgrant: bug 798847 [07:03] <_mup_> Bug #798847: Person picker search for partial IRC nickname doesn't return intended result

< https://launchpad.net/bugs/798847 > [07:03] wgrant: do we really want to search on partial irc nicks [07:03] wallyworld: I saw that and considered won'tfixing it. [07:03] It's a barrel of worms. [07:03] i agree [07:03] Can of worms. [07:04] Whatever the idiom is. [07:04] barrel of monkeys too [07:04] especially since the example was 'jools' and the user was searching for 'bigjools' [07:05] normally one would enter a prefix, not the last characters in a name [07:05] That really requires tokenising IRC nicks further. [07:05] And uh, no. [07:05] you mean you search for partial suffixes? [07:06] wgrant: sure [07:07] 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] So... no. [07:08] Kill it. [07:08] wgrant: yes, that's why i said i agree we shouldn't do it :-) [07:08] * wgrant won'tfixes. [07:09] Or perhaps I should wait for sinzui. [07:11] wgrant: i was going to ask him about that and also the picker batch widget bug but he had already EOD [07:11] i should say the pagination control bug 798772 [07:11] <_mup_> Bug #798772: Pagination in person picker should appear after the results, not before

< https://launchpad.net/bugs/798772 > [07:12] wallyworld: We probably want to completely rework that. [07:12] wallyworld: Remove the page numbers and stuff. [07:12] 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] wallyworld: Since it makes lifeless war on batchnav very hard. [07:12] So if we're going to move it to the bottom and break from lazr-js, we should really change it. [07:13] well, one step at a time perhaps [07:13] don't want too much scope creep [07:13] i'm wondering how that bug got tagged disclosure anyways [07:14] Which? [07:14] the paginator one [07:14] It was discovered during exploratory testing of the new shiny. [07:14] above ^^^ [07:14] So it's our problem unless we decide it isn't. [07:14] sure, but it's been there forever and is not related to our work [07:14] at all [07:14] Our work was to make the pickers not suck. [07:15] Search was part of that. [07:15] Displaying more relevant info was another. [07:15] hmmm. not sure how having the paginator at the top makes the pickers suck [07:15] i like it there [07:15] less mouse movement [07:15] Indeed. [07:15] But some disagree. [07:16] well then they are wrong :-P [07:16] Indeed! [07:16] FWIW, paginator can be above or below IMO; page #'s however... poor idea [07:16] which number will your result be on? [07:16] lifeless: Poor and pointless. [07:16] its like a lottery [07:16] If you [07:17] If you have to click past the first page for a given person more than once, we have failed. [07:17] 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] WOW. [07:17] When did we hit bug 800000? [07:17] wallyworld: But it's limited now, so it's only useful for very small numbers. [07:17] * StevenK prods _mup_ [07:17] Huh, so we did. [07:17] Just noticed I filed bug #800043 [07:17] <_mup_> Bug #800043: IRC nickname search in person picker is case-sensitive

< https://launchpad.net/bugs/800043 > [07:17] 800000 must be private. [07:17] Yeah. [07:18] wallyworld: showing the result set size is generally uninteresting [07:18] should we have a 1000000 party next month? [07:18] Not even I can see it. [07:18] wallyworld: there are a very few specific cases when its anything other than geek chic [07:18] bug 799999 [07:18] lifeless: i think it adds value but that's just me [07:18] wallyworld: consider the phone book; do you care how many booths there are in it ? [07:18] yes! [07:18] wallyworld: and how many freds ? [07:18] It gives a hint as to the selectivity of your search. [07:19] Whether you're likely to find the person in the next few pages. [07:19] yes, the magnitude matters [07:19] 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] few/10s/100s/many [07:19] wgrant: +1. what i was trying to say [07:19] the precise count doesn't matter most of the time. [07:20] and magnitude estimation isn't one of those times. [07:20] agree with that too [07:20] we should do it as a slider :-) [07:20] as you move the slider, the results pan past [07:21] that would be way cool imnsho [07:21] vertical slider would be nice [07:21] yes [07:21] even just vertical next/prev markers [07:21] rather than horizontal for things that are laid out vertically. [07:21] that always gets me. [07:22] and also doesn't really suit right-left locales either [07:24] question [07:24] are anonymous users None, or something else? [07:25] in terms of LaunchpadView's self.user [07:25] i guess None but am not 100% sure [07:25] i recall some test code doing a self.user == None check [07:26] None [08:03] Bah. [08:03] The email address prefix is useful :( [08:03] For eg. "jon" won't catch jcsackett without it. [08:04] Because his displayname is crazy. === jamesh_ is now known as jamesh [08:33] 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] rvba: And what about sources? [08:36] And are you regretting trying to do this yet? :P [08:37] Well, not yet :) [08:37] Ah, good, Soyuz has got your soul already. [08:38] wgrant: So I suppose the same trick should be used for the sources then ... [08:38] I guess so :/ [08:39] Also this is probably going to be very slow. [08:39] But maybe not. [08:39] I'll estimate the overhead of this. [08:44] wgrant: jcsackett working is a bit of a special case [08:44] lifeless: It is, but it helps for some other cases too. [08:44] Because name stemming is hard. [08:44] 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] lifeless: Thanks. [08:56] good morning [09:18] wgrant: Fix pushed (tests added: test_binaryfile_already_in_archive/test_sourcefile_already_in_archive). [09:32] grar [09:32] serial conflicts [09:32] *hates* on 4 hour test runs [09:34] Then fix it, dear Eliza? [09:35] StevenK: its in the pipeline [09:35] * StevenK is only trolling. [09:36] I know === gmb changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugs: 205 - 0:[######=_]:256 [09:55] Morning all. How is the deployment report looking today? [10:21] good morning Launchpadders [10:21] I was getting productive email stuff done and thought, "why am I so productive" [10:21] and then I realized my IRC client was off [10:27] maxb: Somewhat dire. [10:28] Still blocking on lots of reasonably nasty jtv QA in the middle of the 12000 line branch. [10:28] And Red squad seems to not be here today. [10:29] (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] wgrant: Julian is ill. Jtv has trouble with irc. The rest of us is here ;) [10:41] rvba: Do you know if he's working on his QA? [10:42] wgrant: jtv? [10:42] rvba: Yes. [10:42] wgrant: I don't know ... He can be reached by email. [10:43] 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] rvba: I think we need to chat with Julian about this. [10:44] wgrant: ok. [10:45] Hmmm. [10:45] All domestic flights in south-eastern .au cancelled tomorrow. And all internationals delayed probably until Friday. [10:46] This does not bode well. [10:49] Indeed [10:49] wgrant: Chile volcano? [10:49] jml: yeah [10:50] huwshimi: you managed to escape though. [10:50] jml: There have been delays for the last week or so [10:50] Wait, a volcano in Chile is affecting .au? o.O [10:50] jml: Yeah, just [10:50] nigelb: The ash is everywhere. [10:50] Well. [10:50] Mostly above us now. [10:50] nigelb: ash going west [10:50] But still everywhere. [10:50] Ahh. I forgot about the earth being round temporarirly. [10:51] nigelb: yeah. all that hippy crap about us being interconnected beings on one planet turns out to be true [10:51] jml: lol [10:51] wgrant: Are you going to miss the sprint or rally or whatever its calle dnow. [10:51] *called now [10:51] nigelb: Hopefully not! [10:52] :) [10:52] I think it's still a Thunderdome. [10:52] But I'm not sure. [10:52] Maybe just an Epic. [10:52] Which is colocated with the Platform Rally. [10:52] Fun! [10:53] jml: On reading the blog post about your depature, I first feared you were leaving Canonical :) [10:54] nigelb: nope [10:54] nigelb: very glad to be staying [10:55] jml: :) [10:55] LP's loss is our gain :-) [10:55] heh [11:00] jelmer: hi [11:01] jelmer: did you redefine the meaning of persisted enums in your code import patch? [11:03] lifeless: hi [11:04] lifeless: These were prematurely added constants according to mwhudson, never used in real life. [11:05] k [11:22] argh, the deploy queue just got riskier still [11:22] jelmer: how would you feel about rolling back that code import autoupgrade thing? [11:23] just came across https://dev.launchpad.net/LaunchpadHackingFAQ [11:23] there's a blast from the past. [11:23] 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] jelmer: if you're -really- confident in it, its fine. [11:26] 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] s/just// [11:26] lifeless: s/days/even more days/ [11:27] But I think jelmer's fix looks good, FWIW. [11:28] *sigh* [11:29] https://dev.launchpad.net/Hacking is a fork of LaunchpadHackingFAQ [11:35] * jml sets about merging the two and deleting the latter [11:41] 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] allenap: how is rabbit fixture looking ? [11:47] lifeless: I landed it on Saturday :) No failure so far (that I'm aware of) \o/ [11:47] \o/ [11:47] allenap: did you file a bug upstream? [11:47] wgrant: nope, please go ahead [11:48] allenap: No. I wonder if I should file it on Erlang or RabbitMQ. [11:48] allenap: rabbit for starters [11:48] they offer programs after all :) [11:49] lifeless: Okay. [11:49] allenap: also, do you want to land my layer patch now the substrate is solid ? [11:49] lifeless: Yeah, good idea. [11:53] do we have a standard wiki macro for "obsolete page"? [11:54] jml: remember jorge's lightning talk? ;) [11:54] Delete! Delete! Delete! [11:55] nigelb: yeah, that was the Ubuntu wiki [11:55] and I have deleted some stuff already [11:55] I didn't know there was help on tal stuff till now. [11:55] I went and read zope documentation for that and didn't understand much. [12:00] Tal is quite ... opaque. [12:01] StevenK: Interesting choice of words. === benji_ is now known as benji [12:30] lifeless, sorry, I missed that [12:30] 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] they have different naming schemees. the second is only used by "bzr join" at the moment. [12:52] jelmer: so how did we end up with the latter scheme named directories during the incident? [12:57] lifeless: I called that method manually [12:58] I don't think bzr should have two name schemes for backed up .bzr directories [13:06] you're going to change join ? [13:11] lifeless: I filed a bug about it [14:24] Hi, abentley and adeuring [14:25] deryck: hi. [14:25] abentley, adeuring -- so it's very noisy in this place. Can we do an IRC standup? [14:26] deryck: sure. [14:26] let's wait on adeuring to ack before we start. [14:27] deryck: we could make a temporary channel, or use #launchpad-meeting, if you like. [14:27] deryck: abentley: I'm here [14:28] abentley, sure, let's move to #launchpad-meeting to avoid too much noise here. [14:28] adeuring, hi. changing channels ^^ [14:33] jelmer: you'll be in Dublin, right? [14:33] jml:Yep [14:40] deryck: could you please run this SQL statement on staging: http://paste.ubuntu.com/630399/ ? [14:41] adeuring, sure.... grabbing it now [14:44] adeuring: why "select 1"? Doesn't that just return "1" always? [14:44] 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] 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] danilos, I can query the oops db using SQL. there's no UI to do such search in oops-tools [14:46] s/in idea/no idea/ [14:46] abentley: I even don't know yet where the query comes from in Python ;) [14:47] adeuring: I think SELECT 1 will always return 1. [14:47] matsubara, can you please do that for the above exception text? after "tm__potmsgset" there could be different things [14:47] abentley: except if there are no result rows [14:49] 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 < https://launchpad.net/bugs/603530 > [14:50] danilos, thanks. LIKE syntax is not returning me any results [14:50] adeuring: Ah, I see. [14:51] adeuring, here you are. with two runs, to warm the cache. https://pastebin.canonical.com/48802/ [14:52] deryck: thanks! [14:52] np [14:53] 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] matsubara, cool, I think we can call that bug closed, so we just solved one critical bug :) yaay ;) [14:53] danilos, not so fast [14:54] danilos, https://devpad.canonical.com/~matsubara/danilo-integrity-error.txt [14:54] matsubara, oh, :( [14:54] matsubara, these are all still from last year, before this code was rolled out [14:55] ok, now there's a few new ones [14:55] danilos, reload. the file was incomplete. it should show you 972 rows [14:57] matsubara, yeah, the final ones seem to be from March 1st [14:58] danilos, hmm perhaps I should order that by date to make things easier [14:58] matsubara, yeah [14:58] matsubara, that'd be helpful :) [14:59] danilos, ok, refresh and it'll be ordered [15:03] 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] danilos, sounds good [15:03] matsubara, also, I can't get to any of those OOPSes myself [15:04] matsubara, i.e. does https://lp-oops.canonical.com/oops.py/?oopsid=1886M2307 work for you? [15:04] danilos, yeah, those are not referenced in the LP db, so the oops purge deleted them [15:04] matsubara, ah, ok, thanks [15:06] 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] sinzui, definitely. Thanks for continuing to work on this! [15:07] was going to ping you too :) [15:09] 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] sinzui, unfortunately, not much to see: http://pastebin.ubuntu.com/630410/ [15:14] oh, I get huge amounts for data [15:15] maybe my stderr redirect is mangled [15:15] adeuring: if it's just running an existence check, I wonder whether adding LIMIT 1 to the subselects would help. [15:15] abentley: right, that could help. Lets' try it! [15:17] sinzui, I did 2>&1 > file, which I thought was the correct form. but same output. [15:17] sinzui, maybe I need debug version of a package? [15:17] deryck: could you please try another query: http://paste.ubuntu.com/630412/ ? [15:17] adeuring, sure. [15:18] deryck, I fear that I can see the needed data because I am using development vrsions of gtk libvs [15:18] deryck, I think your libs are compiled with debug off [15:18] sinzui, yeah. [15:18] sinzui, I don't mind compiling if you want, but I fear that might also fix the issue :) [15:18] I get 2000 lines of output [15:21] deryck: Do you want to reschedule our call today? Sounds like things are a bit crazy where you are. [15:21] huwshimi, it's still top of next hour, right? [15:22] deryck: Yeah [15:22] huwshimi, I'll be fine for that. [15:22] deryck: OK sure, as long as it's easy enough for you [15:22] huwshimi, oh yeah, np. I'll tell everyone else to go away in 40 minutes. :) [15:23] deryck, you would need libgtk2*-dbg and libwebkitgtk-3*-dbg and I do not know if they replace your current libs [15:23] deryck: haha [15:23] sinzui, ok, let me apt-get install [15:25] adeuring, https://pastebin.canonical.com/48809/ [15:26] deryck: thanks! [15:26] np! [15:27] 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] 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] sinzui, I'm back working on this. dbg package for libwebkitgtk is taking forever to download. [15:43] :( [15:44] I wish one of my computers would show the segfault [15:44] though my daughters are happy I stopped taking their computers to test this [15:46] sinzui, so nothing new in the log even after the dbg packages [15:46] :( [15:50] jcastro: woah, good one! [15:50] argh [15:56] sinzui, can you paste the command you're using to get the log once more? [15:57] New yucky attempt: strace -Ff -tt ./bin/test -vv --layer=YIU 2>&1 | tee _strace.log [15:58] now there's some noise :) [15:58] deryck, old with noise: GTK_DEBUG=ALL ./bin/test -vv --layer=YUI 2>&1 | tee _test.log [15:59] 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] I am familiar with the gtk output. strace will challenge my archeology skills. [16:00] deryck: Ready when you are. How do you want to do this? [16:00] huwshimi, 3 minutes and I'll meet you in mumble, cool? [16:01] okay [16:01]