lifelesscan has review ? https://code.launchpad.net/~lifeless/python-oops-tools/amqp/+merge/7974903:53
=== elmo_ is now known as Guest35863
wgrantlifeless: Don't want to use logging (timestamps!) rather than print?04:50
=== almaisan-away is now known as al-maisan
lifelesswgrant: console debugging me04:51
lifelesswgrant: I don't see a use case (today) for it live04:51
wgrantYeah, but.04:51
wgrantlifeless: https://code.launchpad.net/~wgrant/launchpad/bug-735998/+merge/7990504:52
lifelesswgrant: btw I think the plan has changed over the last year04:52
=== wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 266
lifelesswgrant: prob with the table width changes04:52
wgrantlifeless: Probably, yes.04:53
wgrantThis timeout is reasonably new.04:53
wgrantAnd mostly affects #1.04:53
wgrantlifeless: thanks.04:57
lifelessnp, thank you04:57
StevenKstub: Hai! Could you look over https://code.launchpad.net/~stevenk/launchpad/db-packageupload-archive-index/+merge/79903 ?05:01
wgrantWe really should have (archive, status), or perhaps (archive, distroseries, status).05:02
StevenKAs well?05:03
StevenKHow that help the delete?05:03
wgrantstatus doesn't, but it helps process-accepted.05:04
stubStevenK: The immediate problem is deletion of rows? Those other indexes will be used for delete too.05:05
StevenKstub: CASCADE deletion from Archive05:05
stubWe delete archives now?05:06
StevenKWe were going to make an exception in this case. 53 unused PPAs owned by open teams05:07
stubWe already have an index on (distroseries, status). Does that become redundant with (archive, distroseries, status). ie. when we are deleting by (distroseries, status), do we always include an archive too?05:07
stubIf it is one off, we can just delete the packageupload rows first, then the cascade delete from archive05:07
wgrantThere are no packageupload rows.05:08
wgrantOr at least shouldn't be.05:08
wgrantBut there's no index to let it discover that within 2.5s.05:08
stubWhich isn't a problem for a select05:08
wgrantstub: Every query should specify an archive too. Except DistroSeries:+queue, which will do archive IN (1, 534).05:08
wgrantBut there shouldn't have been archiveless queries since 2007 :*(05:09
wgrantstub: Hm?05:09
wgrantstub: We preselect the archive IDs.05:09
wgrantThen try to delete them.05:09
stubSo we should drop the (distroseries status) index and add (archive, distroseries, status) which will help the immediate problem and make other stuff go faster too.05:09
wgrantWhich times out when looking for packageuploads to cascade to.05:09
stubWhat are the archive ids?05:09
StevenKstub: The query is on RequestLogging in the usual place05:10
StevenKRight, fixing the patch to drop and create an index05:10
wgrantWill need to be two separate patches.05:10
wgrantOne will be run live with CONCURRENTLY.05:10
wgrantThen drop the old index during downtime afterwards.05:11
=== al-maisan is now known as almaisan-away
wgrantBecause we can't create the index during downtime.05:11
wgrantToo slow.05:11
stubfound it05:12
StevenK-CREATE INDEX packageupload__archive__idx ON PackageUpload(archive);05:12
StevenK+DROP INDEX packageupload__distroseries__status__idx;05:12
wgrantStill need a patch to create the index.05:12
StevenKAssuming the index is created beforehand05:12
wgrant92-1 will create05:12
wgrant92-2 will drop05:12
wgrant92-1 will be applied live with CONCURRENTLY05:12
StevenKChanges pushing05:15
lifelessStevenK: why are we dropping that index?05:25
StevenKBecause we're creating one on archive, distroseries, status instead05:26
wgrant(distroseries, status) made sense until 2007.05:27
lifelessuhm, isn't it ordered differently ?05:27
lifelessI'm just flagging the 'btw this may break pages' aspect05:27
wgrantIf it does, the pages are buggy. We could perhaps delete in a few days after checking index usage numbers, though.05:28
lifelessGive you once chance to guess what I think of that :)05:28
wgrantI'd prefer to find the buggy pages :)05:29
StevenKstub: Thanks for the +1, I'll lp-land it against db-devel05:46
wgrantStevenK: Seen lifeless' comments?05:47
wgrantLike 6 lines ago.05:47
StevenKwgrant: I'd rather we find the buggy pages too05:48
wgrantYes, but this could entirely break them.05:48
lifelessgiven you guys are not on maintenance, and there is moderate risk triggering criticals...05:48
lifelessstub: do we have index utilisation info now ?05:49
wgrantIt's likely that some queries use (distroseries, status) now.05:49
wgrantSo the stats now won't be too useful.05:49
wgrantBecause distroseries, status is reasonably selective where status is 0 or 1, which is the common case.05:49
lifelesswgrant: the point being to get the new index up and see what moves across05:49
stublifeless: PG tracks hits on the indexes.05:49
lifelessstub: ok cool05:49
stubStevenK: I can create that index when the backups finish05:52
wgrantlifeless: Oh, sorry, I thought you were asking if we could get stats right now.05:53
StevenKstub: Excellent, thanks.05:53
StevenKwgrant: So should I land this or not?05:53
wgrantI'd land the first patch once the index is on prod, and the second once we know it's not being used significantly.05:54
stubNah... just keep them in the same branch and keep the mp open05:55
wgrantOr that, if you don't care about having prod patched with something out-of-tree for days.05:56
stubThe second patch will go through staging too so get to test there for major perf regressions05:56
wgrantOur trackrecord of catching that stuff on staging is... less than optimal.05:57
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
jtvlifeless: are you reviewing?  If so, I have a very brief MP for you: https://code.launchpad.net/~jtv/launchpad/bug-878115/+merge/7991907:10
=== rvba changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rvba* (allenap) | Critical bugtasks: 266
wgrantjtv: Approved.07:21
wgrantjtv: security.cfg changes are applied during nodowntime updates.07:21
jtvI thought PQM rejected any changes in database/schema for devel.07:22
wgrantOnly *-0.sql and fti.py, I believe.07:22
wgrantAnd both of those restrictions are pointless now.07:22
wgrantSo I will drop the check entirely when nobody is looking.;07:22
jtvNope.  I ran into it a few times while fixing lint in python.07:22
* wgrant checks.07:22
wgrantYeah, *-0.sql and fti.py are banned.07:23
wgrantEverything else is permitted.07:23
wgrant[ -z "$(bzr status -S database/schema/ | grep -e '\(-0\.sql\|/fti.py\)$')" ]07:24
jtvMaybe the lint I fixed was in fti.py then, but I think I touched more than one python file there.  Maybe the check's been updated already.07:24
wgrantIt was fti.py, yes.07:25
wgrantThe check hasn't been updated for a few months.07:25
wgrantIt used to be stricter.07:25
lifelesswgrant: they aren't pointless; there is a report needed before we drop them - in deployment thingy07:28
jtvOpenID, how many ways do I love thee?  Let me count the ways:07:28
jtvSession expired.  Please log in again.07:29
wgrantlifeless: Except that -0 patches don't exist any more.07:29
jtv404 no such page: /weird-openid-stuff-this-app-doesn't-handle07:29
nigelbjtv: OAuth is even more awesome.07:34
wgrantstub: Can I define a partial index in a CREATE TABLE, or must I do it afterwards?07:39
stubwgrant: It needs to be done after.07:40
lifelesswgrant: stub: it does?07:40
lifelessoh, depends on the definition of after07:41
lifeless... I mean 'same patch should be fine'07:41
lifelessstub: when would you like to catch up ?07:41
stubbut the sql syntax doesn't support it in the CREATE TABLE07:41
stublifeless: whenever :-)07:41
wgrantYeah, I meant just the syntax issue.07:41
jtvThat was clear from your question.07:42
jtvI have one for you:07:42
jtvdo you know how I find a particular recipe using launchpadlib?07:42
wgrantI was wondering when you'd ask about that.07:42
lifelessdo you mean search, or obtain the object for a known recipe?07:42
jtvWell, here we are.  :)07:42
jtvlifeless: a particular recipe.07:42
wgrantWhat lifeless said.07:42
wgrantAh, you know it?07:42
jtvThis one: https://code.staging.launchpad.net/~ubuntuone-hackers/+recipe/client-dailies07:43
wgrantAh, different issue.07:43
wgrantI see.07:43
wgrantI was hoping you were investigating the request-daily-builds failure.07:44
wgrantHowever, lp.people['ubuntuone-hackers'].getRecipe(name='client-dailies') should work.07:44
jtvAh, thanks!07:45
wgrantwallyworld_: We need to continue to permit nominations.07:46
wgrantwallyworld_: Nominations do not transcend pillar boundaries.07:46
wgrant(approving those nominations must be permitted, too)07:46
wgrantBut adding a new pillar to a bug, or transitioning the pillar of a task when there are series tasks, must be forbidden.07:47
wgrantSeries are not intended to be a privilege boundary, so such tasks shouldn't cause any issues with further disclosure implementation.07:49
wgrant(well, they are a weak privilege boundary: driver privileges can be granted within a single series)07:50
wgrantBut they are irrelevant for visibility.07:50
adeuringgood morning07:58
jtvwgrant: I'm trying to verify that bug 876594 is fixed on staging.  Are you privilege to run this, by any chance?  http://paste.ubuntu.com/713960/08:05
_mup_Bug #876594: rejected builds for synced packages send mail to Debian maintainer <derivation> <regression> <Launchpad itself:In Progress by jtv> < https://launchpad.net/bugs/876594 >08:05
wgrantI think that's the wrong bug.08:05
wgrantBut yes, I should be able to do that.08:06
jtvHow is the wrong bug?08:06
jtvIt just is.08:06
jtvToo many in progress.08:06
jtvHi bigjools08:06
jtvThe right bug is but 87013008:06
jtv*bug 87013008:06
_mup_Bug #870130: shortlist error requesting recipe build <easy> <oops> <qa-needstesting> <recipe> <Launchpad itself:Fix Committed by jtv> < https://launchpad.net/bugs/870130 >08:06
nigelbMorning bigjools08:07
jtvwgrant: any luck?08:07
wgrantjtv: >>> recipe.requestBuild(pocket='Release', distroseries=natty, archive=recipe.daily_build_archive)08:07
wgrant<source_package_recipe_build at https://api.staging.launchpad.net/1.0/~ubuntuone/+archive/nightlies/+recipebuild/87799>08:07
jtvwgrant: that sounds successful.08:08
jtvSuggests that the bug is indeed fixed.08:08
* jtv goes for a quick relocate08:10
* wgrant adds bug #3 to the list to delete tasks from next week.08:13
_mup_Bug #3: Custom information for each translation team <feature> <lp-translations> <Launchpad itself:Fix Released> <MTestZ:New> <Ubuntu:Invalid> <mono (Ubuntu):Invalid> < https://launchpad.net/bugs/3 >08:13
=== almaisan-away is now known as al-maisan
jtvStevenK, wgrant: w.r.t. bug 876594 I feel somewhat tempted to make get_recipients even cleverer, but I'd like to resist.09:02
_mup_Bug #876594: rejected builds for synced packages send mail to Debian maintainer <derivation> <regression> <Launchpad itself:In Progress by jtv> < https://launchpad.net/bugs/876594 >09:02
wgrantjtv: Ignore implementation, define requirements :)09:03
jtvThank you.  I need some words of encouragement.09:03
wgrantnotifications got where they are today because of gradual papering-over of bugs.09:04
StevenKThen they got a little bit better.09:04
StevenKWell, I like to think so.09:04
wgrantLet's see if we can work out what we actually want, and develop a consistent implementation :)09:04
jtvActually, in a way, developing an inconsistent implementation may be better.09:11
jtvAFAICS we could just choose not to use notify() from the syncing code at all, and do something that's tailored to syncing.09:11
jtvIt doesn't solve the existing mess, but at least it takes a chunk out of it and lets us design something that makes sense for do_copy.09:13
* wgrant preemptively vetoes more duplicated implementations.09:16
wgrantUnless you also schedule the removal of the old implementation.09:16
jtvDoesn't make it a duplicate implementation.09:16
jtvWe're currently notifying on copy just as if it were a regular upload.09:17
* wgrant looks disapprovingly at direct copies, delayed copies, and PackageCopyJobs.09:17
jtvI think we need a free rein to decide what's appropriate for copying, _not_ force "it must be the exact same code as upload notifications" onto the design a priori.09:18
wgrantIt could have different recipient determination code.09:19
wgrantBut the stuff to determine the content should be identical.09:20
wgrantFor values of "should" that tend towards "must"09:20
jtvPah.  That's content and I'm dealing with recipients.09:22
=== al-maisan is now known as almaisan-away
=== almaisan-away is now known as al-maisan
jtvbigjools: I just reported bug 878795 for those annoying failures we're getting from the archive uploader.  I don't _think_ it's Critical, but not sure.11:50
_mup_Bug #878795: InvalidEmailAddress in archive uploader <soyuz-upload> <Launchpad itself:Triaged> < https://launchpad.net/bugs/878795 >11:50
bigjoolsjtv: dupe :)11:50
jtvOh, with what?11:50
bigjoolsone that I filed earlier this week11:51
* bigjools looks11:51
bigjoolsI wish +reportedbugs would default to newest first11:51
jtvbigjools: find it, thanks.11:51
bigjoolsbug 87634811:51
_mup_Bug #876348: Soyuz upload processing bails out with an OOPS when encountering an invalid email address <oops> <soyuz-upload> <Launchpad itself:Triaged> < https://launchpad.net/bugs/876348 >11:51
jtvYeah.  Would you agree that it would make sense to treat this as an UploadError?11:52
bigjoolsit;s not an oops for sure11:52
bigjoolsneed to reply to the uploader11:52
bigjoolsthe only time we need not reply is if the signature is invalid11:53
jtvDoes UploadError imply an oops?11:53
jtvOh, you mean to say the original bug description (mentioning oopses) wasn't entirely right?11:55
jtvbigjools: it goes wrong in parseAddress, and its docstring says it will raise UploadError if parsing of the address fails for any reason.11:56
jtvWill that DTRT?11:56
bigjoolsjtv: the exception raising is correct, however the bit that generates oopses is crack12:00
jtvbigjools: the exception raising that I'm proposing, or the exception raising that already happens?12:01
bigjoolsthere's a catch-all at the top level in uploadprocess.py somewhere, it's not very intelligent12:01
bigjoolsalready happens12:01
jtvbigjools: I guess it's probably good though to be a bit specific about which exceptions are survivable.  I just attached a branch that makes it do what the docstring says; just one possible idea.12:06
bigjoolsjtv: specific is always good12:08
* bigjools → lunch12:08
=== gary-lunch is now known as gary_poster
=== al-maisan is now known as almaisan-away
deryckMorning, everyone.12:58
jtvhi deryck12:59
jtvbigjools: if you agree with the idea I attached to bug 876348, please let me know and I can put it up for review.  Otherwise, I'll treat it as just a suggestion.13:00
_mup_Bug #876348: Soyuz upload processing bails out with an OOPS when encountering an invalid email address <oops> <soyuz-upload> <Launchpad itself:Triaged> < https://launchpad.net/bugs/876348 >13:00
bigjoolsjtv: replied13:33
bigjoolsjtv: alteratively to what I said, use reject("msg")13:33
flacostehi danhg!13:34
flacostewelcome aboard!13:34
=== flacoste changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | Welcome danhg | On call reviewer: rvba* (allenap) | Critical bugtasks: 266
jtvbigjools: I guess I made a little thinko: “this email address is invalid → there is nobody we can notify.”13:35
bigjoolsjtv: wrong :)13:36
bigjoolsjtv: actually EarlyReturn is not ideal thinking about it13:36
bigjoolswe just need to add a rejection and let processing continue so it collects all the errors13:36
bigjoolsI really detest the upload processor13:37
=== jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | Welcome danhg | On call reviewer: rvba* (allenap), jcsackett | Critical bugtasks: 266
jtvbigjools: I guess it's two problems: one, “malformed email address and policy that says to create the user” does something very different from “unknown email address and policy that says not to create the user” or “malformed email address and policy that says not to create the user.”  Two, it'd be nice to have more robust handling of these error conditions.13:47
jtvDoes that make sense?13:48
rvbaHey jcsackett!13:49
jcsackettmorning, rvba. :-)13:50
bigjoolsjtv: no13:51
bigjoolsbut then I am trying to do 2 things at once here13:51
jtvOK — it's late here anyway, so we can leave this to ferment in the hindbrain for now.13:52
jcsackettrvba: looking at your review right now, is there a test or anything that demonstrates using repr resolves the problem?13:52
=== matsubara is now known as matsubara-lunch
gmbrvba, would you be so kind as to review https://code.launchpad.net/~gmb/launchpad/weirdness-bug-867529/+merge/79972?15:11
rvbagmb: sure.15:13
gmbrvba: Thanks.15:13
=== Guest35863 is now known as elmo
flacostegmb, gary_poster: where is our lp  -> leankit integration code lives?15:24
gary_posterflacoste on call.  danilo ^^15:25
gmbflacoste: http://launchpad.net/lp2kanban IIRC. Unless you mean, where does it run, in which case danilos  would know.15:25
rvbagmb: weird bug, I cannot reproduce it either ... the display does not seem to use floating elements except for "See full activity log15:26
gmbrvba: I know. It's weird. I can only reproduce it in Firefox and then only occasionally.15:27
rvbaThe screenshot is indeed of a firefox window.15:27
rvbaI /think/ (by the looks of the tabs we barely see)15:28
* rvba hits F515:28
rvbaagain and again15:29
rvbagmb: I've seen it!15:30
rvbaBut now it's fine again .... it was simply the browser 'lagging'.15:31
rvbagmb: maybe your fix will force the browser to update the display more quickly.15:31
gmbrvba: That's what I'm hoping. It seems to be some kind of lag in Firefox's rendering - it eventually sorts itself out.15:32
rvbagmb: did you see it be 'broken' and stay that way?15:32
gmbrvba: I saw it be broken for a short while, but scrolling up and down fixes it.15:32
gmbwell, in my experience.15:32
rvbagmb: ok, same thing here.15:32
gmbThis is like trying to nail jelly to a wall.15:33
rvbajcsackett: hey, my official mentor is off today so maybe you will be ok to double check this tiny mp https://code.launchpad.net/~gmb/launchpad/weirdness-bug-867529/+merge/79972 ?15:34
jcsackettsure, rvba.15:35
gmbrvba: Merci beaucoup.15:35
rvbajcsackett: btw I really wanted to make it up to you because you reviewed crazy branches last week and I was rather busy with a Critical bug ... so I'm the front line this week until I EOD ;)15:36
jcsackettrvba: thanks. :-)15:37
rvbagmb: welcome :)15:37
danilosgmb, which reminded me, now you've got email about lp2kanban set-up on yellow@, so whoever wants to pick it up, go for it :) (it is running on my own server)15:40
flacostethanks gmb, i was interested in the code location15:40
gmbdanilos: Okay. I'm goingt to wait for someone other than me to pick it up, since running it on my server has been historically somewhat flaky.15:41
danilosflacoste, if you need help in getting it going, you can still talk to me since I think I was the last person to shuffle the code around heavily :)15:41
flacostenaba from product-strategy might be interested by it15:42
flacostedanilos: ^^^15:42
flacosteso i'll point him your way if he has any hard questions ;-)15:42
danilosflacoste, sure, let them email me, but I hope config.ini and README should be good enough for starters as well15:42
* cjwatson grins at the blueprint person chooser saying "Pick me"15:42
jcsackettgmb, rvba: this is the most irritating bug to try and see ever.15:44
* gary_poster goes for lunch15:44
jcsackettgmb: i second rvba's approval, and have nothing to add.15:45
gmbjcsackett: Thanks.15:45
rvbajcsackett: Thanks for mentoring my review ;)15:45
jcsackettyou're quite welcome. :-)15:45
cjwatsonflacoste: would you be able to attend https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-image-build-pipeline, or suggest somebody from LP who would be useful there?  It has moderate overspill into LP, although I think I've established that Ubuntu Engineering will have resources to actually do the work, so it's sort of more flagging if we're insane15:48
cjwatson(One smallish piece of self-contained work; one rather larger job.)15:49
flacostecjwatson: sure, i'll attend15:49
flacostewould probably make sense for bigjools to attend virtually as well15:49
cjwatsonflacoste: thanks, subscribed you15:50
cjwatson... and bigjools15:50
* bigjools prepares for blueprint spam15:50
=== deryck is now known as deryck[lunch]
=== matsubara-lunch is now known as matsubara
=== rvba changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | Welcome danhg | On call reviewer: jcsackett | Critical bugtasks: 266
=== beuno is now known as beuno-lunch
=== deryck[lunch] is now known as deryck
sinzuijcsackett, I appear to have been off IRC all day. DId you need me for anything?17:07
=== beuno-lunch is now known as beuno
jcsackettsinzui: nope, been fine, doing the review thing and chatting about mockups.17:17
mrevellGuten nacht alles17:24
abentleyderyck, allenap: I get "SSL connection has been closed unexpectedly" on Lucid, too.17:24
sinzuijcsackett, do you believe this SQL is safe to run in production: https://pastebin.canonical.com/54678/17:28
jcsackettsinzui: looks fine by me.17:29
sinzuithank you. I may just fix the production issue today if the report has less than 50 teams17:29
deryckabentley, dang.  Hopefully allenap's fix will work for you.17:38
=== jcsackett_ is now known as jcsackett|mobile
=== jcsackett|mobile is now known as jcsackett
=== jcsackett_ is now known as jcsackett
=== jcsackett_ is now known as jcsackett
=== jcsackett|afk is now known as jcsackett
abentleyderyck: cache-batches now respects the search parameters and has merged the latest stable.19:26
deryckabentley, nice.  Thanks for the heads up/19:27
abentleyderyck: np19:27
abentleyderyck: it appears we're already running a fork of storm, so maybe allenap's changes should go in.19:29
deryckabentley, yeah, maybe so.  no since waiting when we can roll our own. :)19:29
abentleyderyck: wallyworld mentioned the idea of supporting infinite scrolling instead of batching.  I.e. when you're scrolling, it's loading batches via ajax.19:32
deryckabentley, I think infinite scrolling makes sense when you have an infinite (or near infinite) list.  i.e. streams like twitter or news feeds…..19:33
abentleyderyck: yes.19:33
deryckabentley, I'm not sure it makes as much sense when the thing being viewed is a list or set of lists like bugs.  mentally it just fits better in a numbered, ordered set of lists.19:34
deryckBut I could certainly be wrong about this.  just my gut feeling about it.19:35
abentleyderyck: I dunno.  I think the main value of batching bugs is that you don't get overwhelmed by their numbers.  I find it a pain to click through to the next batch.19:36
deryckyeah, maybe it doesn't matter.19:38
abentleyderyck: Anyhow, we don't have to use it for bugs, but any time we're doing batching, that's an alternative.19:39
deryckabentley, certainly.19:40
* deryck reboots, brb19:41
=== almaisan-away is now known as al-maisan
lifelessabentley: I think one bit of value in batch numbers is being able to say 'on page 5'... - but you could still do that with infinite scrolling19:44
lifelessabentley: with a little care19:44
lifelessabentley: (and its not a huge value)19:44
abentleylifeless: Yeah, little pale-grey "page-break" markers or something.  They could have permalinks.19:44
abentleyderyck: Is there a guide to documenting our javascript methods/functions?19:49
deryckabentley, at one time our style guide said the javadoc style that YUI uses.  No one really follows this, though.19:51
abentleyderyck: Okay.19:51
deryckabentley, I personally don't like that style, so it's hard for me to endorse. :)  But I guess we should be consistent.19:51
deryckabentley, we probably should raise it in some forum and get consensus on it.19:52
abentleyderyck: I'd like that.  I'm not very familiar with javadoc, so if we aren't really using it, I'll just document it as I see fit for now.19:52
deryckabentley, that works.19:53
=== al-maisan is now known as almaisan-away
=== jcsackett|afk is now known as jcsackett_
abentleyjcsackett_: could you please review https://code.launchpad.net/~abentley/launchpad/update-listings/+merge/79998?20:37
=== jcsackett_ is now known as jcsackett
abentleyjcsackett: thanks.  Also https://code.launchpad.net/~abentley/launchpad/cache-batches/+merge/80000 ?20:46
jcsacketti'll grab it next, abentley. :-)20:46
abentleyjcsackett: It's a follow-on.20:46
abentleyjcsackett: hey, look.  80000th merge proposal.20:47
jcsackettoh, nice!20:47
abentleythumper, rockstar: we just hit the 80000th merge proposal: https://code.launchpad.net/~abentley/launchpad/cache-batches/+merge/8000020:55
thumperabentley: do you have any bzr pipeline talks?21:02
thumperanyone know of launchpad talks?21:03
abentleythumper: No, I haven't given any talks on it.21:03
jcsackettabentley: two questions on your first MP. 1) i am correct in assuming that when you call stringify on query in get_view_url, it handle the case of query being undefined (i.e. it converts undefined to an empty string?)21:13
jcsackett2) is the use of config.io_provider in update_listing just for testing purposes?21:13
abentleyjcsackett: I don't think the query string can be undefined, just an empty string.21:14
jcsackettabentley: ah, fair. that does make sense. :-)21:14
abentleyjcsackett: it hasn't been an issue in local testing.21:15
abentleyjcsackett: config.io_provider is just for testing purposes.21:15
jcsackettabentley: cool, thanks. r=me on the first MP then.21:15
abentleyjcsackett: thanks.21:15
jcsackettabentley: and r=me on the second branch as well.21:25
abentleyjcsackett: thanks!21:25
jcsackettyou're welcome. :-)21:27
rockstarabentley, congrats on 80000!22:09
* mwhudson knows what this is about, i think22:18
wgrantlifeless: Your r12481 tests are spuriously broken in buildbot.22:20
wgrantlifeless: I saw it break once in ec2 a couple of days back.22:21
wgrantI can't work out why.22:21
wgrantI can't even find the preloading that seems to be broken...22:21
lifelesswgrant: win!22:30
lifelesswgrant: :(22:30
wgrantlifeless: Can you investigate that failure as a matter of urgency? It's broken both devel and db-devel builders now.23:17
wgrantAnd I can't see where the preloading happens.23:17
lifelessits been in since feb23:19
lifelessso this is broken by some other change23:19
lifelesswgrant: also I'm OTP23:20
wgrantYes, it's clearly broken by some other change.23:20
=== wallyworld_ changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | Welcome danhg | On call reviewer: wallyworld | Critical bugtasks: 266

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!