[00:15] <LPCIBot> Project devel build #983: STILL FAILING in 5 hr 47 min: https://lpci.wedontsleep.org/job/devel/983/
[00:17] <StevenK> !!!
[00:17] <StevenK> Jenkins is back!
[00:37] <LPCIBot> Project db-devel build #816: STILL FAILING in 5 hr 44 min: https://lpci.wedontsleep.org/job/db-devel/816/
[00:53] <gary_poster> Hello everybody.  I believe trunk is still broken.  This fixes the last test (monkey-see monkey-do from what wgrant submitted for fixing the other tests) but I don't know if it is correct.  http://pastebin.ubuntu.com/672811/ Can anyone verify?  If so, I'll do another testfix.
[00:54] <gary_poster> lifeless, wallyworld, are either of you around and able to verify correctness?
[00:54] <gary_poster> FWIW, this runs the failing test:
[00:54] <gary_poster> ./bin/test -cvvt lp.bugs.model.tests.test_bugtask.TestValidateTransitionToTarget.test_sourcepackage_to_sourcepackage_in_same_series_works
[00:55] <wallyworld> gary_poster: i'll have a look
[00:55] <gary_poster> thank you wallyworld
[00:55] <wallyworld> np
[00:55] <wallyworld> gary_poster:  i think wgrant submitted a test fix - are you saying it's still broken?
[00:55] <wallyworld> or is this a different issue?
[00:56] <gary_poster> yes wallyworld.  He missed one test.  I copied his fix pattern to the remaining one.
[00:56] <wallyworld> ah, right
[00:56] <wallyworld> perhaps we should nuke bb
[00:56] <StevenK> No LOSAs
[00:56] <wallyworld> still?
[00:56] <StevenK> Not in this timezone
[00:57] <gary_poster> s'alright.  If I land a testfix it will immediately run the next test, with only an email compaint.
[00:57] <gary_poster> I mean, immediately after the current one fails
[00:57] <gary_poster> so there shouldn't actually be any outage for you guys
[00:57] <wallyworld> ok, thanks!
[00:58] <wallyworld> the pastebin looks ok to my untrained eye. running the test to verify
[00:59] <gary_poster> wallyworld, I'll treat this effectively as an r= and then self-approve :-)
[00:59] <gary_poster> (once you run the test
[00:59] <gary_poster> )
[00:59] <wallyworld> ok, doing it now
[01:00] <gary_poster> wallyworld, I still intend to take you up on more of the PyCharm hints (like the bzr plugin).  Things have felt a bit up-in-the-air lately so I haven't attempted the full PyCharm switch yet
[01:01] <gary_poster> StevenK, btw, know that I would have begged for your assistance by name too had I remembered that you were around. ;-)
[01:01] <wallyworld> gary_poster: whenever on pycharm. bigjools likes it :-)
[01:01] <wallyworld> gary_poster: the test passes :-)
[01:01] <gary_poster> cool wallyworld :-)
[01:02] <wallyworld> thanks for fixing
[01:03] <gary_poster> test passing: great thanks wallyworld, and I'm taking that also as affirmation that, to your best guess, you think it is not making the test pass...by asserting broken functionality or something.  :-) OK, off to submit...
[01:03] <StevenK> gary_poster: Haha
[01:03] <gary_poster> :-)
[01:04] <StevenK> And here I was thinking that I was loud and annoying enough to not be forgotten.
[01:04] <wallyworld> gary_poster: well, don't take me as someone who knows about this bit of the product :-) so my best guess is not necessarily all that good
[01:04] <wallyworld> but the fix seems like it's in line with the observed failure
[01:05] <nigelb> FUUUUUUUUUU More test failures.
[01:05] <gary_poster> wallyworld, yeah.  Fair enough.  Here's hoping, then.  Right, and it looks like what wgrant did.
[01:05] <nigelb> I can't figure out what I broke
[01:05] <wallyworld> nigelb: what's up?
[01:05] <nigelb> wallyworld: two attempts at landing that branch and I have test failures
[01:06] <gary_poster> nigelb, trunk is broken fwiw, and was broken worse before.  If the errors look like "IllegalTarget: Package unique-from-factory-py-line3362-24070 not published in Distribution-24050" then wait a sec and then pull from trunk once I have the last fix in.
[01:06] <wallyworld> nigelb: some test failures occurred due recently due to some broken code elsewhere. perhpas you are seeing that issue
[01:06] <wallyworld> do you want to pastebin the failures?
[01:06] <nigelb> gary_poster: Indeeed it does!
[01:07] <StevenK> nigelb: It happens like that sometimes, sadly.
[01:07] <gary_poster> nigelb, well, good news, for some definition of good news. ;-)  I'll ping you when it's in.  Should be <5 min.
[01:07] <nigelb> \o/
[01:07] <nigelb> gary_poster: Thanks :)
[01:07] <StevenK> nigelb: Did you want your branch tossed at ec2 for the 3rd time?
[01:08] <nigelb> StevenK: sec, there's one failure that's fallout from me.
[01:08] <nigelb> let me fix that
[01:08] <nigelb> doctests *stab* *stab* *stab*
[01:08] <wallyworld> StevenK: if it's just the distro packaging failures we could lp-land it?
[01:10] <gary_poster> wgrant, any objections to http://pastebin.ubuntu.com/672811/ ?  About to land it?
[01:10] <StevenK> gary_poster: Only if you format sp2 correctly
[01:11] <StevenK> sp2 = self.factory.makeSourcePackage(
[01:11] <gary_poster> StevenK, bah, that's PEP8 compliant last time I checked :-P
[01:11] <StevenK>     distroseries=sp1.distroseries, publish=True)
[01:11] <gary_poster> If lint complains I'll do it...waiting...
[01:11] <wgrant> gary_poster: Huh, that mustn't have come up in the summary...
[01:11] <wgrant> Let me check.
[01:12] <gary_poster> StevenK, linter likes my code more than you do ;-)
[01:12] <gary_poster> Thanks wgrant
[01:12] <StevenK> gary_poster: Bah! :-)
[01:12] <wgrant> gary_poster: Argh, no, I just misread. thought it was part of TestValidateTarget.
[01:13] <gary_poster> wgrant, ok cool, so I'm assuming you approve of what I did.  I'm about to lp-land
[01:13] <wgrant> gary_poster: That diff looks fine.
[01:13] <wgrant> Thanks.
[01:13] <gary_poster> thank you
[01:21] <gary_poster> nigelp, merge trunk and all those other ones should go away.  good luck.
[01:21] <gary_poster> nigelb, even :-P
[01:23] <nigelb> hehe, okay
[01:35] <wgrant> wallyworld: 274	+        var filter_msg = Y.substitute(
[01:35] <wgrant> 275	+            'Showing <strong>{filter}</strong> matches for "{search_terms}".',
[01:35] <wgrant> 276	+            {filter: current_filter_value,
[01:35] <wgrant> 277	+            search_terms: this._search_input.get('value')});
[01:35] <wallyworld> yeees?
[01:36] <wgrant> wallyworld: It's not exploitable, as it's only displaying immediate user input, but it is wrong.
[01:36] <wallyworld> security issue?
[01:37] <wgrant> It would be, if search_terms didn't happen to come from a textbox.
[01:37] <wallyworld> so the problem is?
[01:37] <wgrant> Search terms involving HTML will break the world.
[01:38] <wgrant> And it's using a forbidden pattern which people will follow.
[01:38] <wallyworld> well if anyone types in html they deserve it to break
[01:38] <wallyworld> i just cargo culted the pattern myself
[01:38] <wgrant> Right.
[01:38] <wgrant> Let's not perpetuate this.
[01:38] <wallyworld> i dont' see this instance as a huge issue in this case
[01:39] <wallyworld> but yes, as a drive-by....
[01:40] <wgrant> In the current form it is barely exploitable, true.
[01:40] <wgrant> But it is a terrible pattern, and could very easily accidentally become exploitable.
[01:40] <wallyworld> sure, so next time someone is in the neighbourhood.....
[01:41] <wgrant> lifeless: https://code.launchpad.net/~wgrant/launchpad/fix-codebrowse-oopses/+merge/72515
[01:42] <StevenK> wgrant: r=me
[01:43] <nigelb> StevenK: could you land https://code.launchpad.net/~nigelbabu/launchpad/4595-upgrade-bug-linking/+merge/71575 again? :)
[01:43] <wgrant> StevenK: I want to wait for lifeless, as this was obvious enough from the logs that I think I might be missing some other issue.
[01:43] <nigelb> Third time's the charm I hope.
[01:55] <cjwatson> if anyone types in html> such as web browser developers looking for bugs involving certain kinds of HTML, for example ...
[01:55] <wgrant> cjwatson: Surely not!
[01:55] <wgrant> Nobody would ever do that.
[01:56] <wgrant> Web applications can break in bad ways in some cases.
[01:56] <wgrant> All good.
[02:16] <lifeless> wgrant: hi
[02:17] <wgrant> lifeless: I tried loggerhead locally and got a pretty obvious traceback. Did that not appear on prod?
[02:17] <wgrant> s/prod/qas/
[02:17] <lifeless> qas just ISE'd on us
[02:18] <lifeless> I prepped a monkey to get into pdb and see what is causing it -
[02:18] <lifeless> ok pages are ok
[02:18] <lifeless> but failing pages didn't seem to oops
[02:18] <lifeless> its in the -ops history
[02:18] <wgrant> http://paste.ubuntu.com/672845/
[02:19] <lifeless> hahhhhhhahhahahaha bloody ha ha
[02:19] <wgrant> Yes.
[02:19] <wgrant> That stuff didn't make it into qastaging's debug.log?
[02:19] <lifeless> no
[02:19] <wgrant> Yay
[02:19] <wgrant> Shall I land the fix, then?
[02:20] <lifeless> hell yes
[02:20] <lifeless> if thats s/oopsid/id/
[02:20] <wgrant> It is.
[02:20] <wgrant> It even works.
[02:20] <wgrant> Sad that this isn't tested.
[02:20] <lifeless> thank you & sinzui very much
[02:20] <wgrant> But let's unbreak it first.
[02:21] <wgrant> lifeless: Do I want a --rollback?
[02:21] <wgrant> Since it's already been fixed once, right?
[02:21] <wgrant> Let's see the report...
[02:23] <wgrant> Ah, there was no --rollback last time.
[02:23] <wgrant> I shall put it on this one.
[02:33] <StevenK> lifeless: O hai
[02:33] <StevenK> lifeless: Can you peer at http://pastebin.ubuntu.com/672806/ when you have a tick?
[02:34] <lifeless> wgrant: the cascade thing had me suspicious
[02:34] <lifeless> wgrant: I figured I could lp-land a no-op --rollback easier than unlanding one that didn't fix it
[02:34] <StevenK> lifeless: I'd like the query to return every BPR that has unexpired BPFs and doesn't already exist in BPRC.
[02:36] <lifeless> StevenK: what context is it running in?
[02:36] <StevenK> lifeless: Garbo job
[02:36] <lifeless> 18 seconds is tolerable to seed the job
[02:37] <StevenK> lifeless: wgrant's concern was that the performance is like that and BPRC only has 1 million rows on DF -- it's only going to get worse
[02:37] <lifeless> well
[02:38] <lifeless> the binarypackagereleasecontents_pkey index will allow fairly efficient determination of bpr's
[02:40] <lifeless> the merge join took most of the time
[02:40] <lifeless> whats thesecond query ?
[02:41] <lifeless> this is inefficient:  AND NOT EXISTS
[02:41] <StevenK> It's the same query, cold and hot
[02:41] <lifeless>     (SELECT BinaryPackageReleaseContents.binarypackagepath
[02:41] <lifeless>      FROM BinaryPackageReleaseContents
[02:41] <lifeless>      WHERE BinaryPackageReleaseContents.binarypackagerelease = BinaryPackageRelease.id)
[02:46] <StevenK> lifeless: Are you fiddling for something more efficient?
[02:46] <lifeless> yes
[02:52] <nigelb> ah, its wgrant's review day.
[02:52] <wgrant> So it is.
[02:52] <nigelb> StevenK: did you get a chance to land that? Should I poke wgrant into landing?
[02:53] <StevenK> 4595-upgrade-bug-linking => devel  [OK]     (up for 1:09:13.836563)
[02:54] <lifeless> StevenK: Time: 5.961 ms
[02:55] <lifeless> http://paste.ubuntu.com/672861/
[02:55] <lifeless> StevenK: this takes advantage of the fact that we expect:
[02:55] <lifeless>  - most rows to need analysis
[02:55] <lifeless>  - and we're walking a batch upward
[02:56] <lifeless> with analyze http://paste.ubuntu.com/672862/
[02:56] <nigelb> StevenK: aha, thanks :)
[02:56] <StevenK> lifeless: Why the first limit 1000?
[02:56]  * nigelb heads for caffeine and breakfast
[02:56] <lifeless> StevenK: thats large enough that we won't get lots of empty batches
[02:57] <lifeless> StevenK: its a guess. It just needs to be large enough that we'll get 1 (one is enough) rows most of the time
[02:57] <wgrant> lifeless: Won't an empty batch cause it to think it's done?
[02:57] <lifeless> yes, the driver logic needs tweaking
[02:57] <lifeless> it should say something like 'max id - last seen id < 1000'
[02:59] <lifeless> and/or
[03:00] <lifeless> always increments the last seen id by 20 if no results were found
[03:00] <lifeless> when it exceeds the max id, we're done-done.
[03:00] <lifeless> and can switch to a simpler plan using the highest ids and working back or whatever
[03:15] <jamesh> lifeless: in case you're interested, I added a first-go patch to https://code.djangoproject.com/ticket/16674 that makes django work with python-oops-wsgi
[03:22] <jtv> wgrant: have you had a chance to look at that buildbot failure?  With you, me, and the big J on the blamelist I guess it's not as easy as "oh it's packaging-related, I know who it is."  :)
[03:22] <wgrant> jtv: It was my fault. It is fixed.
[03:22] <jtv> Oh good, thanks.
[04:06] <lifeless> jamesh: I am
[04:07] <lifeless> jamesh: do we want a python-oops-django containing the django glue ?
[04:07] <jamesh> lifeless: ideally I'd like it if no glue was necessary
[04:07] <jamesh> hence the django bug report
[04:07] <lifeless> yeah
[04:07] <lifeless> me too
[04:08] <lifeless> jamesh: thanks for digging into this!
[04:08] <lifeless> I'm going to be hacking on more gpg extraction / gpgverifyd today
[04:08] <lifeless> but should be back on oopses tomorrow
[04:08] <lifeless> and probably on leave monday
[04:12] <wgrant> lifeless: On Monday, or from Monday?
[04:14] <jamesh> lifeless: you said that some other web frameworks had the same problem of hiding the exception context when producing an error page.  Perhaps the best solution would be to patch a few other popular ones and hope that python-oops-wsgi is compelling enough to convince others to patch the remaining ones
[04:14] <nigelb> jamesh: that's interesting.
[04:14] <nigelb> jamesh: I was just thinking the other day what it would take to use python-oops with django
[04:15] <nigelb> (after all the excitement lifeless was making with python-oops :P)
[04:18] <jamesh> nigelb: well, hopefully the patch in that bug (or a better version of the same) will make it into a future version of Django
[04:19] <jamesh> then the answer is just "wrap Django's WSGIHandler() with python-oops-wsgi and embed in your favourite WSGI container"
[04:19] <nigelb> :)
[04:20] <StevenK> nigelb: In reference to your G+ post: <ESC>:shell
[04:21] <nigelb> StevenK: I used byobu instead
[04:21] <nigelb> with a vertical split
[04:21] <StevenK> Cheater
[04:21] <nigelb> heh
[04:22] <nigelb> Its pretty nifty actually.
[04:22] <nigelb> I like commiting often and a terminal right below the editor helps
[04:23] <wgrant> Hmm.
[04:23] <wgrant> https://bugs.launchpad.net/launchpad/+bug/411409
[04:23] <_mup_> Bug #411409: AJAX "Link to a bug report" could be improved <confusing-ui> <disclosure> <javascript> <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/411409 >
[04:23] <wgrant> The attachment link there no longer works.
[04:24] <wgrant> (I always used to insert odd characters into attachment names to break things... but I think this one used to work)
[04:27] <wgrant> Interestingly it works locally.
[04:27] <StevenK> The number is the LFA?
[04:27] <StevenK> (In the URL, I mean)
[04:27] <wgrant> BugAttachment.id
[04:28] <nigelb> How much work is that bug?
[04:28] <nigelb> Its tempting to pick up
[04:28] <wgrant> http://launchpadlibrarian.net/30110664/what%3F.png works
[04:29] <wgrant> nigelb: Pickers are not something you want to get into.
[04:29] <wgrant> At least not yet.
[04:29] <nigelb> Hmm, ok.
[04:30] <StevenK> Yes, that picker sucks
[04:30] <wgrant> That's not even a picker.
[04:30] <wgrant> it should be.
[04:30] <StevenK> Do we even have a picker that can search by bug number?
[04:30] <wgrant> No.
[04:30] <wgrant> We want one that can search by ID/summary/description.
[04:31] <StevenK> True
[04:31] <StevenK> Can haz FDT now
[04:33] <StevenK> lifeless: So I need another number for {B,S}PPH indices -- is it another -1 and goes to db-devel?
[04:34] <wgrant> StevenK: That can be done live.
[04:34] <wgrant> Once the column is there.
[04:34] <wgrant> Wait until then, I suspect.
[04:34] <StevenK> Bleh
[04:35] <StevenK> We probably need more than just CREATE INDEX binarypackagepublishinghistory__binarypackagename__idx ON BinaryPackagePublishingHistory(binarypackagename) anyway
[04:35] <wgrant> Hah, yes.
[04:35] <StevenK> (And the correspending SPPH, of course)
[04:35] <StevenK> wgrant: Suggestions for what we want to index?
[04:35] <wgrant> Depends what you want to make fast.
[04:36] <StevenK> The DSP vocab
[04:36] <wgrant> The current indexes are pretty arbitrary and useless.
[04:36] <wgrant> StevenK: Do you have an example query?
[04:37] <wgrant> Given the
[04:37] <StevenK> Not handy
[04:37] <wgrant> possible new DSP cache table approach, this may all be irrelevant.
[04:37] <StevenK> wgrant: Yes, I wanted to talk about that too
[04:37] <wgrant> Since we'll have a cache table which has (archive, sourcepackagename, [binaries]) or so.
[04:37] <StevenK> We will?
[04:37] <wgrant> I hope so.
[04:38] <wgrant> Something like DistributionSourcePackageCache, except not stupid and less useless.
[04:38] <wgrant>  binpkgnames        | text         |
[04:38] <wgrant> Also without that.
[04:38] <wgrant> plural -> text
[04:38] <StevenK> And not like DistributionSourcePackageInDatabase? :-)
[04:38] <wgrant> Uh, yeah.
[04:39] <wgrant> StevenK: Have you, sinzui and bigjools discussed this at all?
[04:39] <wgrant> I saw bigjools decrying the idea that something could be in a distribution without a publication, but that's about it.
[04:39] <StevenK> The thing that sinzui and I have discussed is populating the DSP table for series older than maverick
[04:40] <wgrant> And for other series.
[04:40] <wgrant> It doesn't need populating for old series.
[04:40] <wgrant> It needs reconceiving, reworking, and reimplementing.
[04:40] <wgrant> Then you can think about populating it.
[04:45] <jtv> wgrant, are you reviewing today?  You might enjoy this one. https://code.launchpad.net/~jtv/launchpad/fix-some-utilities/+merge/72523
[04:46] <StevenK> wgrant: So we have DSP, DSPC, and DSPID. /wrists
[04:46] <wgrant> StevenK: Right. We need to talk about how this should work.
[04:46] <wgrant> jtv: Sure.
[04:46] <wgrant> jtv: The number of selfs in interfaces is disturbing.
[04:47] <jtv> Yes, maybe we should just add a grep to "make lint."  :-)
[04:47] <wgrant> StevenK: (DSPC is presently updated by a script that takes like 20 hours)
[04:48] <StevenK> And DSPID is perpuated by IPublishingSet.newSourcePublication()
[04:48] <wgrant> It's not quite clear what should happen to DSPID.
[04:48] <wgrant> It possibly still has a place in the world.
[04:49] <wgrant> jtv: Approved.
[04:49] <jtv> Thanks.
[04:50] <wgrant> StevenK: I think we need to take DSP, DSPC, DSPC and DSPID, all their users, and some other stuff and work out WTF we have and what we want.
[04:51] <wgrant> (no the two DSPCs are not a mistake: DistributionSourcePackageCache and DistroSeriesPackageCache)
[04:51] <wgrant> I can hear your wrists from here.
[04:52] <StevenK> That's funny, I didn't think blood pooling on the carpet was that noisy.
[04:54] <nigelb> Is StevenK slashing his wrists again? :P
[04:55]  * StevenK logs into the ec2 instance that is testing nigelb's branch and injects a few failures.
[04:56] <nigelb> gah!
[04:56] <wgrant> lifeless: https://bugs.launchpad.net/python-oops-wsgi/+subscriptions <- please unsubscribe launchpad-security
[04:56] <wgrant> Anyone can add the subscription, but only a team admin can remove it :)
[04:57] <nigelb> hm, isn't there something wrong with that?
[04:57] <StevenK> wgrant: So I think DSP is used by a *lot* of stuff -- and DSPID is tied directly into most of it. The two DSPCs, I don't really know
[04:59] <wgrant> Merging DSP and DSPID is going to be really fiddly and time-consuming, if it ever happens.
[05:00] <wgrant> It may be best to add a flag on DSPID indicating officialness.
[05:00] <wgrant> Or just assume that is presence is official.
[05:00] <wgrant> But then you'd also need to join against DSPC to do the binary lookup.
[05:00] <wgrant> DSPC has the complication that it has an archive.
[05:01] <StevenK> So I think you're right. It's a horrid horrid mess, and it needs to die.
[05:01] <wgrant> You know what would be cool?
[05:01] <wgrant> If Launchpad wasn't a monolithic monster with no separation or interfaces.
[05:02] <StevenK> Hah
[05:03] <StevenK> Right, DSP fills me with despair
[05:03] <wgrant> But if we can work this out, then Soyuz will be much closer to its own little world.
[05:03] <wgrant> s/world/insane asylum/
[05:03] <wgrant> Since Bugs will have no fingers left in the Soyuz pie.
[05:04] <wgrant> Oh, curses.
[05:04] <wgrant> Components.
[05:04] <wgrant> And bug nomination permissions.
[05:05]  * wgrant dies.
[05:05] <StevenK> Yes
[05:05] <StevenK> I'm making a list, and getting more depressed by the microsecond
[05:05] <wgrant> Anyway, let's see what still uses DSPC²
[05:05] <wgrant> I think most of its users are long-dead.
[05:06] <StevenK> Which DSPC?
[05:06] <wgrant> ²
[05:06] <wgrant> ie. both.
[05:06] <wgrant> They are similar.
[05:06] <wgrant> And have the same name.
[05:07] <StevenK> OH, WHAT THE
[05:07] <wgrant> ?
[05:07] <wgrant> The name is slightly different
[05:07] <wgrant> DistroSeries vs DistributionSource
[05:07] <StevenK> DistributionSourcePackage.getPersonsByEmail(email_addresses)
[05:07] <StevenK> SERIOUSLY?
[05:07] <wgrant> Pardon?
[05:07] <wgrant> lib/lp/registry/model/distributionsourcepackage.py:    def getPersonsByEmail(email_addresses):
[05:07] <StevenK> It's in there, and the DSP view calls it
[05:07] <wgrant> O_O
[05:07] <wgrant> You are correct.
[05:08] <wgrant> It will die before EOD.
[05:08] <StevenK> Can I kill it?
[05:08] <wgrant> brb, qannotate
[05:08] <StevenK>         the_changelog = '\n'.join(
[05:08] <StevenK>             [spr.changelog_entry for spr in sprs
[05:08] <StevenK>              if not_empty(spr.changelog_entry)])
[05:09]  * StevenK now feels depressed and ill
[05:09] <wgrant> That evil is somewhat necessary, unfortunately.
[05:12] <StevenK> Icky
[05:13] <wgrant> Debian changelogs are, yes.
[05:13] <StevenK> If we're logged in, pull every single e-mail address out of a constructed changelog, call that abomdination of a method, and then drop persons that have hidden mail addresses
[05:13] <StevenK> *Disgusting*
[05:16] <wgrant> It does seem to be the sort of thing that built up slowly over 5 years into an unfathomable monster, which could have been avoided if it had been redesigned half way through.
[05:16] <wgrant> Hmm, like something else...
[05:16] <wgrant> Launchpad!
[05:17] <lifeless> hang on
[05:17] <lifeless> why do we drop those people?
[05:17] <wgrant> Probably so we can show the email addresses, just unlinked because why.
[05:18] <lifeless> well
[05:18] <lifeless> couldn't we show the person and not show the email addresses ?
[05:18] <wgrant> The changelog is indexed by numerous other places.
[05:19] <wgrant> Anybody putting their email address in a changelog but wanting it to remain private is even more misguided than someone who wants their email address to remain private.
[05:19] <wgrant> And that is saying something.
[05:19] <lifeless> sure
[05:20] <lifeless> but thats a separate argument, AIUI we're currently not linking to the persons
[05:20] <lifeless> which seems bizarro
[05:20] <wgrant> Not necessarily.
[05:20] <wgrant> To link them would allow you to determine the owner of an address.
[05:20] <lifeless> you can probe for (many) by sending a comment to a bug with a custom from
[05:20] <wgrant> s/an address/a private address/
[05:20] <wgrant> Ja.
[05:20] <lifeless> over half our users in fact
[05:21] <wgrant> Hm?
[05:21] <lifeless> does 'private address' mean 'do not show', or 'do not link against from other data sources'
[05:21] <lifeless> I think its intended to be the former
[05:21] <wgrant> lalalala
[05:22] <lifeless> IIRC the UI says 'hide address' not 'pretend it does not exist'
[05:22] <wgrant>  Hide my email addresses from other Launchpad users
[05:22] <lifeless> right
[05:25] <StevenK> wgrant: And if we're going to attack DSP/DSPID, what about its bastard half-sibling, DSPR?
[05:25] <wgrant> StevenK: It's unrelated.
[05:25] <wgrant> It exists solely for the URL space.
[05:26] <StevenK> wgrant: Have you finished looking for DSPC usage?
[05:26] <wgrant> You distracted me.
[05:26] <StevenK> Heh
[05:27] <StevenK> I suppose screaming blue murder is a bit distracting.
[05:28] <lifeless> wgrant: how did l-s get subscribed ?
[05:28] <wgrant> lifeless: It's the bug supervisor.
[05:28] <wgrant> lifeless: Bug supervisors get a subscription by default, because someone likes to confuse people.
[05:29] <lifeless> aieee
[05:29] <lifeless> so there will be a few more to clean up
[05:29] <lifeless> is there a page showing all l-s's subscriptions
[05:29] <wgrant> Yes.
[05:29] <lifeless> and the docs need tweaking
[05:29] <wgrant> Possibly... I think it might ahave been cut.
[05:29] <wgrant> Let me try to find it.
[05:30] <lifeless> https://launchpad.net/~launchpad-security/+subscriptions
[05:30] <wgrant> Yeah./
[05:30] <lifeless> which mingles structural and explicit.
[05:30] <lifeless> or perhaps only shows concrete objects
[05:31] <lifeless> StevenK: indices on non-empty-or-close-enough tables are separate patches, yes.
[05:34] <lifeless> wgrant: cleaned up the ones i can remember making
[05:34] <wgrant> lifeless: Thanks.
[05:35] <wgrant> https://launchpad.net/~launchpad-security/+structural-subscriptions
[05:35] <lifeless> and the docs are updated
[05:35] <wgrant> Three left.
[05:35] <lifeless> I wonder
[05:35] <wgrant> Bug mail for Launchpad Security about Timeline is filtered; it will be sent only if it matches the following filter:
[05:35] <wgrant> This filter allows all mail through.
[05:35] <wgrant> Yay.
[05:35] <lifeless> can you subscribe an arbitrary team by setting bug-supervisor
[05:36] <lifeless> apparently I am in a team cxalled 'morfose'
[05:36] <wgrant> You used to be able to.
[05:36] <wgrant> I think only team members can now, though.
[05:36] <lifeless> fixed those as well
[05:36] <wgrant> Thankyou sir.
[05:37] <StevenK> wgrant: DSPC, or did lifeless distract you? :-)
[05:37] <wgrant> blargh dying
[05:37] <lifeless> wgrant: on and from
[05:38] <wgrant> lifeless: Monday?
[05:38] <lifeless> yes
[05:38] <wgrant> :(
[05:39] <lifeless> jamesh: re patching other frameworks. Perhaps ;) certainly though they must have some way of glueing in already and making users upgrade their platform isn't really a goal of python-oops-wsgi : so both hacking around, and doing the Right THing, is probably needed
[05:49] <StevenK> Surely we already have a method to return Persons given an iterable of e-mail addresses
[05:50] <wgrant> StevenK: I doubt it.
[05:50] <StevenK> wgrant: So, I hack the view to call IPersonSet.getByEmail(), but that strikes me as slow
[05:51] <wgrant> Impractically slow, yes.
[05:51] <wgrant> You need to introduce a sensible method to do it in one query.
[05:52] <StevenK> On IPersonSet, do you think?
[05:52] <wgrant> Next to getByEmail, yes.
[05:52]  * StevenK attempts to not swear in a branch name
[05:52] <wgrant> getByEmail becomes a convenience wrapper.
[05:53] <StevenK> Sounds like a plan
[05:53] <jamesh> lifeless: I wouldn't be surprised if other frameworks are as easy to fix as Django.
[05:54] <jamesh> lifeless: and for some there might be an option to disable error recovery, letting everything fall through to the wsgi container
[05:56] <lifeless> jamesh: sure
[05:57] <jamesh> lifeless: having some way to report the exception from deep in the stack might be enough to hack around frameworks that don't do the right thing: that is essentially how we're currently using wsgi-oops's logging support.
[05:58] <lifeless> wheee
[06:00] <lifeless> 831035 is a dupe isn't it ?
[06:09] <LPCIBot> Project devel build #984: STILL FAILING in 5 hr 54 min: https://lpci.wedontsleep.org/job/devel/984/
[06:10] <wgrant> lifeless: Fixed.
[06:13] <lifeless> pop quiz
[06:14] <lifeless> rewrite zeca as simple server, as a paste app, web.py, or keep it as twisted ?
[06:14] <wgrant> Should be pretty trivial to make it Paste/webpy, right?
[06:14] <lifeless> yes
[06:14] <wgrant> It's like 300 lines.
[06:14] <StevenK> Given a result set which returns two columns, can I call something on it to just return the first column and first row?
[06:15] <wgrant> StevenK: Do you have a more specific example?
[06:15] <lifeless> StevenK: slice it to get the first row; then call .values()
[06:15] <lifeless> StevenK: but better to decide what you want to query in the first place
[06:15] <StevenK> I have a query which returns (Person, EmailAddress), I want the first Person only
[06:16] <lifeless> for clarity, I like twisted, but its seems a heavy dep for this
[06:16] <lifeless> and I *hate hate hate* .tac files
[06:17] <wgrant> It is only a test dep, though, right?
[06:17] <nigelb>  \o/ TEST SUCCESS
[06:18] <lifeless> wgrant: yes
[06:18] <nigelb> StevenK: Thanks! :)
[06:18] <lifeless> but I need to extract ready service and a tonne of stuff
[06:19] <wgrant> True.
[06:19] <lifeless> ahh, wsgiref
[06:19] <wgrant> lifeless: It seems like porting it would be pretty easy.
[06:19] <lifeless> wgrant: onh for sure
[06:20] <lifeless> it raises the question that perhaps readyservice is needed for other tests
[06:20] <wgrant> And just about anything but Zope is lighter than Twisted.
[06:20] <wgrant> True.
[06:20] <lifeless> OTOH I think importing zcml is the problem.
[06:20] <lifeless> 'microservice' + 'zcml' are incompatible
[06:20] <wgrant> Heh.
[06:20] <wgrant> Not necesarily :)
[06:23] <StevenK> ProgrammingError: operator does not exist: text = bytea
[06:23] <StevenK> Sadface
[06:24] <wgrant> You fail at Unicode.
[06:24] <wgrant> And Python 2 doesn't help.
[06:24] <StevenK> Yes
[06:25] <StevenK> I think I have purged the evil
[06:26] <wgrant> Excellent.
[06:26] <StevenK> % bzr di | diffstat | tail -n 1
[06:26] <StevenK>  5 files changed, 23 insertions(+), 28 deletions(-)
[06:26] <wgrant> I'm still working out how best to fix DSP(C²|ID)?
[06:27] <wgrant> StevenK: diffstat -s
[06:28] <StevenK> I shall have to try and remember that.
[06:31] <StevenK> OPENID! STAB!
[06:36] <jtv> wgrant: what say you we make make lint grep for "self" in interface methods?
[06:38] <lifeless> some actually classes are in interface modules
[06:38] <lifeless> (and need to be)
[06:39] <lifeless> As long as they are catered for, it makes sense to me.
[06:39] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/dsp-getpersonsbyemail-stab-stab-stab/+merge/72528
[06:40] <jtv> lifeless: that's a nuisance.  Got any examples for me?
[06:40] <lifeless> not offhand
[06:40] <jtv> I can think of enums, but they don't have methods.
[06:41] <lifeless> jtv: stuff in bugs probably, and things raised in notify() are commonly in the interface (and thats a zope inherited idiom)
[06:41] <jtv> Thanks, that gives me something to look for.
[07:20] <jtv> StevenK, wgrant: do I remember correctly that you were scheming to add source package names to SPPH?
[07:27] <wgrant> jtv: The patch has landed.
[07:28] <jtv> wgrant: so… in db-devel now, to be rolled out RSN?  It may well be useful to what I'm doing right now.
[07:28] <wgrant> jtv: Yeah. Then we need to populate it and add indices and stuff.
[07:29] <wgrant> jtv: What are you up to? gina deletions?
[07:29] <jtv> Yup.
[07:29] <wgrant> Indeed, it would make that rather quick.
[07:29] <wgrant> However, after the first run it should only have like 20000 publications to consider.
[07:29] <wgrant> So it won't be that slow even without it.
[07:30] <jtv> I'm not too worried about the number of publications to consider—AIUI I only need to worry about ones where superseded is null, and that helps massively.
[07:30] <jtv> I'm worried about client-side memory.
[07:31] <wgrant> supersededby is not relevant here.
[07:34] <jtv> Why not?  I only need to delete SPPHs in "published" or "pending" statuses, right?  Can an SPPH be superseded yet be in one of those states?
[07:35] <wgrant> No.
[07:36] <wgrant> But supersededby does not determine supersededness.
[07:36] <wgrant> yes, anything with supersededby set is not Published or Pending, but it's not the correct discriminator.
[07:36] <lifeless> jamesh: around ?
[07:37] <jtv> wgrant: it doesn't have to be the correct discriminator and it doesn't need to determine supersededness.  It only needs to eliminate lots of SPPHs that I'm not interested in very effectively.
[07:37] <wgrant> jtv: Filter on status.
[07:38] <wgrant> status IN (1, 2)
[07:38] <wgrant> Done.
[07:38] <wgrant> That eliminates all the SPPHs you're not interested in, and is probably the most indexed column on the table.
[07:38] <jtv> Well of course I'm filtering by status.
[07:38] <jamesh> lifeless: yeah
[07:38] <wgrant> Then why are you interested in supersededby?
[07:39] <lifeless> jamesh: some of lp's gpghandler looks like things gpgme could sensibly have
[07:39] <lifeless> jamesh: what do you think ?
[07:39] <jtv> wgrant: like I said, I'm looking for ways to eliminate uninteresting SPPHs.  But if status does that well enough, then fine.
[07:39] <jtv> As I said, it's not important.
[07:40] <wgrant> jtv: You need to consider everything that is still active.
[07:40] <jamesh> lifeless: is this significantly different to the gpg utility thingee I'd remember from 2008, or something different?
[07:40] <lifeless> jamesh: doubt it
[07:41] <lifeless> jamesh: things like 'santizei a fingerprint'
[07:41] <jtv> wgrant: And you just said that this wouldn't affect that.  As I'm said, it's not that important.
[07:41] <lifeless> 'import a secret key' -> checks the key was imported, and only the one key
[07:41] <wgrant> jtv: Right, but your initial comment about "superseded is null" had me somewhat concerned.
[07:41] <lifeless> (and can disable the agent temporarily for tests)
[07:42] <jamesh> lifeless: okay.  Where abouts is this code?  If you're talking about some code I haven't seen then I can't sensibly answer the question.
[07:43] <lifeless> jamesh: I doubt it is different to what you've seen
[07:43] <lifeless> jamesh: I'll get you a url though, one sec
[07:43] <lifeless> jamesh: (I think the sense of my reply got inverted somehow)
[07:44] <jamesh> oh.  you meant you doubt it is different rather than doubt it is the same.
[07:44] <lifeless> yes :)
[07:44] <lifeless> 'is it different?' 'doubt it' :P
[07:44] <lifeless> jamesh: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/canonical/launchpad/utilities/gpghandler.py
[07:44] <lifeless> jamesh: I'm pulling out the for-test-only stuff into lp:gpgfixtures
[07:44] <lifeless> jamesh: e.g. making a GNUPGHOME dir
[07:44] <lifeless> jamesh: stashing test keys
[07:44] <lifeless> jamesh: running a test keyserver.
[07:45] <lifeless> jamesh: most of the rest looke like gpgme code to me. In the spirit of better-than-what-it-wraps.
[07:50] <lifeless> PymeUserId can just get deleted though
[07:50] <lifeless> and be replaced with a zope decl.
[07:50] <lifeless> or at least, its not a candidate for moving into pygpgme
[07:57] <adeuring> good morning
[07:58] <jtv> hi adeuring
[07:58] <adeuring> hi jtv!
[07:58] <jtv> All well?
[08:01] <lifeless> jamesh: so, your thoughts ?
[08:02] <jamesh> lifeless: I guess some of them might make sense.  The sanitisefingerprint one looks a bit mysql-ish the way it truncates long input
[08:03] <lifeless> jamesh: so, it clearly doesn't belong in LP :)
[08:03] <lifeless> jamesh: I could make a third library to wrap gpgme, but that seems an arbitrary split
[08:04] <jamesh> I'd be happy to include some helper utilities along side the extension module.
[08:04] <lifeless> whats your preference? Like I say, I want to gut (most of) this stuff from LP, and AFAICT its in three camps: test code, input handling, sane-default-wrappers-of-gpgme-things
[08:05] <jamesh> it'd be worth checking on a case by case basis whether the helpers make sense though.
[08:05] <lifeless> the test code -> gpgfixtures, because I think its inappropriate to impose that on every user of gpgme
[08:05] <lifeless> [though gpgme's test suite could well use gpgfixtures if you don't mind a test-only dependency]
[08:06] <jamesh> some of the checks it is doing are no longer necessary (e.g. explicitly checking for multiple signatures as a possible concatenated clear signed message attack, which gpg has errored out on for a while now)
[08:06] <adeuring> lifeless: could you also review my MP you already commented on?
[08:06] <lifeless> adeuring: sorry, no
[08:07] <wgrant> jamesh: Hm, does it really?
[08:07] <lifeless> adeuring: if you can't find another reviewer I will, but I have approx 24 hours work time to get microservices live, before I'm away for a while
[08:07] <wgrant> jamesh: Given a few recent vulnerabilities I've found, I'm not so sure about that.
[08:07] <adeuring> lifeless: ok, no problem
[08:07] <lifeless> jamesh: that wouldn't be harmful to handle though, would it? (In case of folk running old gpg)
[08:08] <jamesh> wgrant: I used to have tests for concatenated clearsigned blocks in the pygpgme test suite, and they stopped passing
[08:08] <wgrant> Hmm.
[08:08] <wgrant> Must be slightly different.
[08:08] <jamesh> lifeless: it'd be really old gpg though.
[08:09] <mrevell> Hey good morning#
[08:10] <lifeless> jamesh: so, its your call. I am going to extract what I need to test gpgverifyd from LP; thats definite. If you'd like it in gpgme as a place for others to reuse and iterate, I'd be delighted to add it there (with tests etc)
[08:10] <lifeless> jamesh: if you don't want it, no skin off my nose ;)
[08:10] <lifeless> jamesh: And if you do want it, I'll happily to modest tweaks to meet whatever style or other criteria you have.
[08:10] <jamesh> lifeless: the best option is probably to file bugs against pygpgme, and we can work from there.
[08:11] <lifeless> jamesh: that really doesn't work for me; I have a very short time to do a lot of stuff, so the round trips involved there would destroy any hope of getting what I need to get done done.
[08:11] <lifeless> jamesh: sorry
[08:16] <lifeless> jamesh: in case that came across as a bit dicky, I guess I mean I need to action it now, and can round trip in review etc, but doing a pre-flight-check on it all just seems to front load round trip discusssions that review will need anyhow.
[08:17] <jamesh> lifeless: I don't necessarily mean do it all individually.  If you've got an idea of what you would like to see moved, I'd be happy to review that all in one go.
[08:17] <jamesh> lifeless: that said, if all the helpers do is wrap StringIO()'s around the arguments, I'm not sure if that adds a lot of value
[08:18] <lifeless> well, they check for bytestrings, check how many signatures are found, sanitise input
[08:18] <jamesh> the gpghandler interface was originally wrapped around a different gpg interface, so there is a fair bit that would be different if pygpgme was the starting point
[08:19] <lifeless> pygpgme still exposes what gpgme does though right? its very up-to-the-user-to-interpret? [which most of this lp non-test-code is - interpretation]
[08:19] <jamesh> and I don't remember why the code configures "keyserver-options auto-key-retrieve" and also has code to directly download keys from the keyserver's http interface
[08:19] <lifeless> thats test code
[08:20] <lifeless> as I said, its not what I'm talking about
[08:20] <lifeless> that will be in gpgfixtures.GPGHomeFixture
[08:22] <lifeless> for pygpgme I am talking about: sanitizeFingerprint, getVerifiedSignature importPublicKey importSecretKey encryptContent(possibly) signContent(possibly)
[08:22] <lifeless> _submitKey might be intereseting
[08:23] <jamesh> okay.  It is just that most of the helpers include the http key download, which I would have thought was handled if your gpg config is for auto-key-retrieve
[08:23] <lifeless> the encrypt and sign stuff aren't really interesting to me at this point, and they probably need a lot more consideration
[08:24] <lifeless> jamesh: I can test that
[08:24] <lifeless> you're talking about the comment for handling of subkeys, yes ?
[08:25] <lifeless> which is in getVerifiedSignature
[08:25] <jamesh> everything that calls retrieveKey() is potentially doing an HTTP request
[08:26] <StevenK> Oh, bah.
[08:26] <lifeless> yes, which is only getV..S.. of the ones I listed
[08:26] <StevenK> Now it's +31/-28
[08:26] <StevenK> I am disappoint.
[08:26] <lifeless> StevenK: delete 3 random lines.
[08:28] <lifeless> jamesh: for the win : we don't test that subkey code path anyhow
[08:29] <lifeless> aieee http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/annotate/head:/lib/canonical/launchpad/utilities/gpghandler.py
[08:30] <lifeless> well, perhaps in gpg-signatures.txt. If that still exists
[08:32] <jamesh> I'd be hesitant to accept things like getVerifiedSignatureResilient(), fwiw :)
[08:32] <lifeless> jamesh: not on my list
[08:32] <lifeless> jamesh: noddy things are noddy
[08:33] <jamesh> right.  it is just things like that that make me nervous about you initially talking about merging gpghandler into pygpgme.  The smaller set of methods seems a lot more sane.
[08:36] <jamesh> wgrant: fyi, here's the CVE about the message concatenation issue: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1263
[08:37] <jamesh> you'd have to be using particularly old code to be vulnerable
[08:39] <wgrant> jamesh: Ah. Not the same thing, right. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1829 and a few related things are what I discovered. Only one signature, but some unsigned bits.
[08:41] <jamesh> ah.  I guess that is what happens when you roll your own gpg interface ...
[08:41] <wgrant> Inline signatures must die.
[08:41] <wgrant> Yes!
[08:42] <wgrant> LP/dak were similarly vulnerable.
[08:42] <wgrant> (mostly because the LP code was copied straight from dak)
[08:42] <wgrant> We need good libraries.
[08:43] <jamesh> prior to the CVE I linked, you couldn't distinguish between a single clearsigned document signed by two keys and two concatenated clearsigned documents signed with one key each using gpgme
[08:43] <jamesh> now you can because the second form errors out
[08:46] <lifeless> heh, so a quick test suggests that retrieveKey going to the keyserver is indeed needed
[08:46] <lifeless> digging further
[08:47] <lifeless> (I replaced the http lookup with a key search, but that doesn't find the key)
[08:47] <lifeless> so - verifying the signature just-in-time obtains the signing subkey, not the master key.
[08:49] <lifeless> ah, wants GPGME_KEYLIST_MODE_EXTERN
[08:51] <jtv> gmb: morning!  Can I trouble you for a review?  https://code.launchpad.net/~jtv/launchpad/pre-830890/+merge/72535
[08:58] <stub> Anyone fixing the merge conflict?
[09:05] <lifeless> jamesh: ok, so heres what a quick poke got me
[09:05] <lifeless> jamesh: the auto key retrieval only gets the specified key
[09:06] <lifeless> jamesh: some keyservers return the master, some don't (this I remember from way back :P)
[09:06] <lifeless> jamesh: setting context.keylist_mode = context.keylist_mode | gpgme.KEYLIST_MODE_LOCAL | gpgme.KEYLIST_MODE_EXTERN
[09:07] <lifeless> jamesh: does do an hkp lookup, but seems to not work - and there are mailing list messages asking about this same behaviour upsream
[09:07] <lifeless> jamesh: so it looks like some nontrivial debugging is needed to identify whats going on (possibly not very hard, but very much a yak I didn't plan on shaving)
[09:08] <jamesh> hmm.  The gpg man page also mentions an "include-subkeys" keyserver option, but it says "Note  that  this  option is not used with HKP key servers, as they do not support retrieving keys by subkey id"
[09:08] <lifeless> yes
[09:08] <stub> I've got the merge conflict - just looks like imports
[09:09] <jamesh> ah.  it is saying that hkp supports retrieving subkeys by subkey id, but not the whole keys by the subkey id
[09:09] <lifeless> anyhow, I think I need to keep the http lookup because the test case (which does still exist) does fail.
[09:09] <lifeless> jamesh: exactly, and we're running with hkp.
[09:09] <jamesh> fair enough.
[09:09] <lifeless> you have to do two requests, one for the subkey, and one for the master, and the 'obvious' way to make get_key do the retrival for us doesn't work.
[09:10] <jamesh> so the utilities would need to know about an http keyserver?
[09:10] <lifeless> e.g. just doing get_key(sig.fpr) barfs, with or without keylist_mode set
[09:11] <lifeless> jamesh: I think its fugly to have the python code doing the lookups
[09:11] <lifeless> jamesh: I don't know how deep the rabbit hole to avoid that is ;)
[09:12] <lifeless> its pretty clear that the Right Thing depends on whether the gpg.conf has a keyserver setup and whether it has auto-key-retrieval setup
[09:13] <lifeless> so certainly *some* degree of configuration is needed
[09:13] <lifeless> whether that should be supplied (Wrapper(keyserver=xxx)) or inferred by grepping gpg.conf, etc I dunno
[09:14] <lifeless> I think at this point I'm inclined to rename gpgfixtues to gpgsupport or gpgwrappers or something, bundle the http code and all into it
[09:14] <lifeless> and file a bug saying that this aspect is fugly and point in the right long term direction
[09:17] <gmb> jtv: Sure, I'll take a looks shortly
[09:18] <jtv> thx
[09:18] <lifeless> jamesh: what do you think?
[09:19] <jamesh> lifeless: that might be a good short term option.  I'm still open to moving parts that make sense to gpgme.
[09:19] <jamesh> pygpgme, even
[09:35] <gmb> jtv: Approved. Good stuff; I likes me a cleanup.
[09:35] <jtv> yay
[09:35] <jtv> thanks again
[09:35] <gmb> np
[09:48] <lifeless> jamesh: thanks
[09:56] <adeuring> gmb: could you review this MP: https://code.launchpad.net/~adeuring/lazr.batchnavigator/lazr.batchnavigator-fix-issues-for-unprecise-result-length/+merge/72473/+index ?
[09:58] <gmb> adeuring: Certainly
[09:59] <adeuring> thanks!
[10:02] <lifeless> night y'all
[10:04] <bigjools> nn
[10:05] <wgrant> Yay, loggerhead OOPSes work again.
[10:06] <wgrant> jelmer: I guess you were trying to QA stuff?
[10:06] <jelmer> wgrant, yep
[10:06] <wgrant> jelmer: Although the bzr-svn rev is much less interesting right now that the SafeBranchOpener one.
[10:07] <jelmer> wgrant, I'm looking at both - the SafeBranchOpener one was why I was asking about loggerhead
[10:07] <wgrant> Ah, of course.
[10:07] <wgrant> Thanks.
[10:32] <StevenK> wgrant: DistributionSourcePackage.createBug() makes me sad.
[10:32] <wgrant> StevenK: ... does anything use it?
[10:32] <StevenK> Yes, sadly.
[10:32] <wgrant> Ew what/
[10:33] <wgrant> Surely not +filebug.
[10:33] <wgrant> But it looks like it may.
[10:34] <StevenK> wgrant: Two soyuz tests, at least.
[10:34] <StevenK> wgrant: But there are a large amount of methods called createBug()
[10:34] <StevenK> Distribution and Distroseries have one, as does Product ...
[10:34] <wgrant> Looks like it's a standard IBugTarget method.
[10:38] <gmb> adeuring: Approved.
[10:38] <adeuring> gmb: thanks!
[10:38] <gmb> np
[10:50]  * gmb lunches
[10:59] <henninge> gmb: when you are back from lunch: I have a branch here that I hope you'll have as much reviewing, if you can, as I had writing the code. ;-) Seriously.
[10:59] <henninge> https://code.launchpad.net/~henninge/launchpad/bug-824435-failure-reporting-2/+merge/72546
[10:59] <henninge> it's slightly oversized, though.
[10:59] <henninge> s/slightly//
[11:57] <benji> nigelb: there were some test failures for https://code.launchpad.net/~nigelbabu/launchpad/4595-upgrade-bug-linking/+merge/71575
[11:57] <benji> I pasted them as a comment.
[12:02] <LPCIBot> Project devel build #985: STILL FAILING in 5 hr 52 min: https://lpci.wedontsleep.org/job/devel/985/
[12:10] <gmb> henninge: Sure, I'll take a look shortly
[12:11] <henninge> gmb: great, thank! ;-)
[12:11] <henninge> s
[12:26] <nigelb> benji: I fixed them and got it rebuild and merged.
[12:27] <nigelb> (retested)
[12:27] <benji> cool
[12:28] <nigelb> You would have caught it, except I gave you a useless diff yesterday :)
[13:05] <deryck> Morning, everyone.
[13:07] <gmb> henninge: Nice work! Approved.
[13:07] <henninge> gmb: Thank you! ;)
[13:10] <gmb> danilos, henninge, jtv: Can one of you help radifar over in #launchpad? He seems to be getting a weird error when trying to review a translation.
[13:10] <jtv> gmb: sorry, too far past EOD here.
[13:10] <gmb> jtv: No worries
[13:10] <jtv> Ta
[13:19] <bigjools> stub: still there?
[13:19] <stub> yo
[13:20] <bigjools> stub: patch-2208-78-1.sql won't apply on DF because there's loads of null owner columns - do you know if the production data was massaged outside of a patch?
[13:20] <stub> bigjools: There was a garbo job that cleaned the data
[13:21] <bigjools> crap
[13:21] <stub> bigjools: Which will be the standard way of doing data migration now, so need to get that running regularly on DF.
[13:21] <bigjools> *cry*
[13:21] <bigjools> ok
[13:22] <bigjools> thanks
[13:22] <stub> Should be able to fix the data with a single update if you don't want to chase the old garbo... hangon.
[13:22] <bigjools> yeah DF is not there to test bugs stuff so I don't care if I poke it with Joe Blogs
[13:23] <stub> update bugmessage
[13:23] <stub> set owner=message.owner
[13:23] <stub> from message
[13:23] <stub> where message.id = bugmessage.message;
[13:23] <bigjools> ta
[13:26] <bigjools> stub: should I run -daily or -hourly?
[13:28] <stub> bigjools: I don't think we have standardized which is needed for data migration - might need both (and soon -frequently too once the db-devel merge is unblocked), but you don't need to run them all that often.
[13:29] <bigjools> stub: well I was going to cron one in on DF to run late at night when nobody is using it so that I don't have to sit and wait again like I am now :)
[13:32] <deryck> henninge, ping for standup.
[13:33] <henninge> deryck, abentley: sorr y guys, my phone is acting up ...
[13:33] <henninge> need to reboot
[13:33] <deryck> henninge, np.  we'll start and join when you can.
[14:03] <bac> gmb when you have time could you look at https://code.launchpad.net/~bac/launchpad/bug-823490/+merge/72577
[14:03] <gmb> bac: sure
[14:19] <gmb> bac: Approved.
[14:19] <bac> thanks gmb
[14:46] <nigelb> qastaging is continously timing out.
[15:27] <gmb> nigelb: WFM. Can you give a specific URL?
[15:28] <nigelb> gmb: worked after continously abusing F5 ;)
[15:28] <gmb> Heh.
[15:28] <nigelb> bugs.qastaging.launchpad.net/bugs was what timed out for me :)
[15:39] <abentley> gmb: could you please review https://code.launchpad.net/~abentley/launchpad/bad-state-transition-2/+merge/72592 ?
[15:39] <gmb> abentley: Sure.
[15:39] <abentley> gmb: thanks.
[15:55] <gmb> abentley: approved
[15:55] <abentley> gmb: Thanks!
[15:55] <gmb> np
[16:04] <LPCIBot> Project db-devel build #817: STILL FAILING in 6 hr 22 min: https://lpci.wedontsleep.org/job/db-devel/817/
[16:56] <LPCIBot> Project devel build #986: STILL FAILING in 4 hr 54 min: https://lpci.wedontsleep.org/job/devel/986/
[17:04] <mrevell> G'night all!
[18:12] <jml> Are all the Virginians alright?
[18:12] <jml> And NCers too
[18:13] <benji> jml: yep, but we've used up this month's supply of adrenaline
[18:15] <nigelb> heh
[18:16] <jml> benji: heh. glad to hear all is well :)
[18:20] <bac> jml: people 7 miles north and 25 miles east of here felt it ... but there was nothing where i am.
[18:21] <bac> but that's ok, as we have a hurricane four days out
[18:24] <nigelb> heh
[18:24] <nigelb> we're happend to lend you adrenaline :P
[18:24] <nigelb> *happy
[18:26] <deryck> cr3, ping
[18:31] <cr3> deryck: pong, what's up?
[18:52] <bac> matsubara: what's the procedure for clearing out the staging/qastaging imap mbox?  it's pretty big and i'd be happy to zap it.
[18:53] <matsubara> bac, I thought there was a script running deleting those messages. Ursinha used to run it
[18:54] <matsubara> bac, I think old emails can be safely deleted from the mbox
[18:54] <bac> matsubara: ok
[18:54] <matsubara> or any bug email
[18:54] <matsubara> since those are the ones that takes the most space
[19:41] <lifeless> gary_poster: ping
[19:42] <gary_poster> lifeless, hi
[19:42] <lifeless> gary_poster: with buildout develop = ...
[19:42] <lifeless> gary_poster: is there a way to set that without editing a version controlled file in the LP tree ?
[19:44] <bac> abentley: an ec2 job just failed due to the new test_memory_hog_job.  have you seen any spurious failures with it before?  i can't reproduce locally
[19:44] <gary_poster> lifeless, should be, if I understand you.  ./bin/buildout section:key=value works IIRC, so ./bin/buildout buildout:develop=foo ought to work.  I'll go confirm with docs...
[19:45] <lifeless> gary_poster: that sounds great.
[19:45] <lifeless> I will edit our docs :)
[19:45] <abentley> bac: No, I haven't seen spurious failures before.
[19:46] <lifeless> gary_poster: this is the bit I was referring to - https://dev.launchpad.net/HackingLazrLibraries 'In this software's buildout.cfg, in the [buildout] section, look for a
[19:46] <lifeless> develop key. I'....
[19:47] <gary_poster> ah gotcha lifeless.  Yes, I remembered correctly, at least generally, and that ought to work for this specific case. (http://pypi.python.org/pypi/zc.buildout/1.5.2#command-line-usage fwiw)
[19:54] <lifeless> gary_poster: care to check my recording of it ? https://dev.launchpad.net/HackingLazrLibraries
[19:54]  * gary_poster looks
[19:58] <gary_poster> lifeless, do these contradict? "A reasonable option is to add it in the top-level directory of this software." vs "The best thing to do is to locate it in a sibling tree so that its separation is clear."  If so, let's settle on one; if not, it needs some clarity.
[19:58] <gary_poster> "but that will get committed and as such is rarely what you want": *really* rarely as long as bzr doesn't support externals ;-) Once we have externals, it can be nice in some cases.
[19:59] <gary_poster> "When you want to switch back to using an egg for that other component run bin/buildout build:develop=.": Actually, you should just need to run "bin/buildout".  You won't be overriding the set value anymore on the commandline, so...it should just work.
[20:05] <lifeless> gary_poster: ok, so one needs to keep supplying the key until done ?
[20:05] <gary_poster> yes lifeless
[20:06] <lifeless> gary_poster: I would like to delete the nesting options
[20:06]  * gary_poster on call
[20:07] <lifeless> gary_poster: given that we're using buildout for getting at stuff, one system is preferrable to three, all other things being equal
[20:10] <gary_poster> ack
[20:10] <lifeless> gary_poster: tweaked further, if you can let me know after your call that would be great
[20:10] <gary_poster> cool
[20:32] <sinzui> jcsackett, do you have time to mumble?
[20:32] <jcsackett> sinzui: sure.
[20:33] <jcsackett> sinzui: i hear you. i presume you cannot hear me.
[20:34]  * sinzui looks at sound preferences
[21:12] <gary_poster> lifeless, I just read the lazr page: looks good, thank you
[21:16] <lifeless> gary_poster: thanks
[21:24] <lifeless> jelmer: had you heard of 'python-gitdb' before its ITP ?
[21:24] <jelmer> lifeless: yeah, it's from the author of python-git
[21:24] <lifeless> jelmer: he didn't like your stuff ?
[21:24] <jelmer> lifeless: although I was a bit surprised to see the ITP - python-gitdb is EOL, and merged into python-git
[21:25] <jelmer> lifeless: python-git existed before dulwich, but was always more of a wrapper around git itself
[21:25] <jelmer> lifeless, he's only recently started looking at a pure-python implementation
[21:25] <lifeless> its a bit sad he's not using dulwich
[21:25] <jelmer> yeah
[21:27] <jelmer> lifeless: apparently python-git has support for multiple backends - gitdb being one of them, and dulwich and pygit2 (Python wrapper around libgit2) being other backends
[21:29] <lifeless> jelmer: interesting, though you have to wonder why gitdb is needed then ;)
[22:00] <LPCIBot> Project db-devel build #818: STILL FAILING in 5 hr 55 min: https://lpci.wedontsleep.org/job/db-devel/818/
[22:48] <LPCIBot> Project devel build #987: STILL FAILING in 5 hr 51 min: https://lpci.wedontsleep.org/job/devel/987/