[00:14] <wallyworld> wgrant: is one supposed to review a mp with a conflict or wait/ask for the conflict to be resolved?
[00:16] <wgrant> wallyworld: That's one of the great unanswered questions of the modern age.
[00:16] <wallyworld> hah
[00:17] <wgrant> Are there more conflicts than just sourcecode.cache
[00:17] <wgrant> ?
[00:17] <wallyworld> the other issue is the mp was resubmitted (after the susperceded one was approved) so perhaps the original approver should be the one to look at the new one
[00:17] <wgrant> That seems to be it.
[00:17] <wallyworld> no, no other conflicts
[00:18] <wallyworld> i could easily remove them when running locally
[00:18] <wallyworld> just wondering as a matter of policy
[00:18] <wgrant> It was last reviewed two months ago; I'm not sure that bac would have significantly more context than you at this point.
[00:19] <wallyworld> sure. i'll jump in then
[00:34] <mwhudson> wallyworld: what happens now with https://code.launchpad.net/~mwhudson/launchpad/ChoiceSource-flexibility/+merge/73611, does it need to be mentored?
[00:34] <wallyworld> mwhudson: i'm thinking for such a small change it's ok
[00:34] <mwhudson> wallyworld: can you land it then please?  I don't think i have all the relevant bits set up
[00:35] <mwhudson> i guess it needs a commit message
[00:35] <wallyworld> mwhudson: sure, i was just about to ask you if you wanted me tyo do that
[00:35] <mwhudson> and uh, a bug report?
[00:35] <wallyworld> mwhudson: yes, a bug report if you want to be able to qa it before it gets released
[00:35] <mwhudson> i think that would be a good idea :)
[00:35] <wallyworld> just to be sure nothing breaks
[00:36] <mwhudson> there are semi related problems to do with the zIndex of the blocking div that prettyoverlay creates
[00:36] <mwhudson> but they can wait for another day :)
[00:38] <poolie> i'm getting persistent oopses on https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/835153
[00:38] <_mup_> Bug #835153: oosplash.bin crashed with SIGSEGV in XSetForeground() <amd64> <apport-crash> <oneiric> <running-unity> <libreoffice (Ubuntu):Triaged by bjoern-michaelsen> < https://launchpad.net/bugs/835153 >
[00:38] <mwhudson> wallyworld: ok, should be good to land now
[00:38] <wallyworld> mwhudson: cool. onto it
[00:38] <mwhudson> thanks
[01:04] <G> allenap: thanks for those two suggestions for the 61428 merge
[01:04] <wallyworld> wgrant: looks like a buildbot test has hung. i assume we just force a new build in this case? i think this happens occasionally?
[01:19] <wgrant> wallyworld: It's a regression in the last couple of weeks, but yes.
[01:22] <G> allenap: I just made the change that you suggested on my MP (https://code.launchpad.net/~dev-nigelj/launchpad/bug61428/+merge/73632) so it should be good to land now
[01:30] <LPCIBot> Project devel build #1,022: STILL FAILING in 4 hr 55 min: https://lpci.wedontsleep.org/job/devel/1022/
[02:11] <jtv> hi wallyworld!
[02:27] <nigelb> Morning!
[02:53] <nigelb> oh oh.
[02:53] <nigelb> 503 error from loggerhead.
[02:56] <jtv> hi nigelb… sorry, never got around to looking at your MP yesterday.
[03:00] <nigelb> jtv: hehe, np, I asked the OCR. I'm fixing test failings in it now :)
[03:00] <jtv> OK great
[03:18] <nigelb> What is the solution if the result of the doctest is > 78 characters?
[03:24] <nigelb> wgrant: about?
[03:32] <wgrant> nigelb: Unless you're using -NORMALIZE_WHITESPACE, you can just add newlines wherever you want.
[03:33] <nigelb> Does this look fine?
[03:33] <nigelb>     >>> browser.getControl('Title').value = 'Extension Manager '
[03:33] <nigelb>     ...     'System Upgrades'
[03:33] <nigelb> because lint complains for that.
[03:35] <wallyworld> jtv: hi. sorry missed your ping. my stupid irc client doesn't pop up notifications for very long and then I miss them if i am afk eating or something :-(
[03:35] <wgrant> nigelb: Oh, that's not the result... I'd do this:
[03:35] <wgrant>     >>> browser.getControl('Title').value = (
[03:36] <wgrant>     ...     'Extension Manager System Upgrades')
[03:36] <nigelb> Ah.
[03:37] <jtv> wallyworld: I was just saying good morning.  As you know I don't think you need any further mentoring, and since I can't find any further procedural notes, I hereby formalize your graduation.
[03:37] <jtv> Note to mailing list to follow.
[03:37] <nigelb> congrats wallyworld!
[03:37] <wallyworld> jtv: cool :-) i did a largish review this morning but it needs fixing so i didn't ping you yet. but i guess now i don't need to
[03:38] <wallyworld> nigelb: thanks
[03:38] <jtv> That's right.
[03:39]  * wallyworld goes back to fixing some failing tests !@%@!%@$!
[03:39] <nigelb> haha
[03:41] <nigelb> If my code passes tests, does it automatically get merged?
[03:41] <nigelb> passes tests from ec2land.
[03:41] <wallyworld> nigelb: yes, unless pqm is in testfix mode
[03:42] <wallyworld> due to a buildbot breakage
[03:42] <nigelb> hrm, I don't think my branch last night merged, despite tests passing.
[03:42] <wgrant> buildbot was broken for a while.
[03:42] <wallyworld> nigelb: check your email - there should be one saying it merged or else something like 0 tests blah blah
[03:42] <mwhudson> nigelb: whoever ran ec2 land should have an email in that case
[03:43] <mwhudson> heh, simultaneous contradiction!
[03:43] <wgrant> The signer gets the PQM email.
[03:43] <wallyworld> oops. i forgot that someone else would have landed it
[03:43] <wgrant> Both parties get the EC2 email.
[03:44] <nigelb> ok, I'll poke danilos later when he gets on.
[03:44] <nigelb> mwhudson: Did you find configobj helpful? :)
[03:57] <mwhudson> nigelb: i haven't gotten around to looking at it yet
[03:58] <mwhudson> nigelb: i'd blanked on the fact that bzr used an external library for this sort of thing though
[03:58] <mwhudson> well sort of external
[03:58] <nigelb> :)
[03:58] <nigelb> There are lots of things in ConfigParser which really irritate me
[03:59] <nigelb> argh, doctests.
[03:59] <nigelb> How do I reduce this one to less than 78
[03:59] <nigelb>     'http://blueprints.launchpad.dev/firefox/+spec/extension-manager-upgrades/+edit'
[04:00] <StevenK> http://blueprints...dev/firefox/+spec/exten.../+edit
[04:00] <poolie> nigelb: do you have to silence the lint complaint?
[04:00] <poolie> i don't know if doing so would be a good use of time
[04:00] <poolie> hi, btw
[04:00] <nigelb> poolie: Well, I can always ignore it :D
[04:01] <StevenK> I didn't think we cared about 78 char limit in doctests ...
[04:01] <nigelb> poolie: Morning! :)
[04:01] <nigelb> StevenK: \o/
[04:01] <poolie> hi there
[04:16] <nigelb> Can someone kick this back into ec2? https://code.launchpad.net/~nigelbabu/launchpad/specification-validation-59301/+merge/73631
[04:18]  * nigelb also notes the /topic needs updation
[04:23] <nigelb> jtv: "to a vicious shark who will go as deep as it takes to find out what's wrong with your branch" -- you've trained him well :P
[04:23] <wgrant> Does anybody know of a Unicode explosion character?'
[04:23] <wgrant> Or something similar?
[04:24] <jtv> wgrant: an invalid UTF-8 sequence will usually do the trick :-P
[04:24] <jtv> nigelb: thanks  ☺
[04:24] <wgrant> jtv: The graph in the topic will need it soon :(
[04:25] <jtv> ☢ ?
[04:25] <nigelb> Ha, that's why.
[04:25] <wgrant> jtv: That works.
[04:25] <wgrant> There are 257 tasks :(
[04:25] <jtv> I take it the counter's been running the wrong way then?  Otherwise you'd be looking for ☮
[04:25] <wgrant> But 6 of them are private.
[04:26] <wgrant> So webnumbr says we are safe and the world has not ended.
[04:26] <jtv> ☠
[04:26] <jtv> Who is webnumbr?
[04:26] <wgrant> http://webnumbr.com/launchpad-critical-bugs
[04:26] <nigelb> wgrant: http://www.fileformat.info/info/unicode/char/1f4a3/index.htm
[04:27] <wgrant> That is worryingly far outside the BMP. I wonder how widely supported it is.
[04:27] <wgrant> But that looks helpful, thanks.
[04:27] <wgrant> Hah.
[04:27] <wgrant> Introduced in Unicode 6.
[04:27] <wgrant> ie. 10 months ago.
[04:27] <nigelb> Only 2 fonts support it.
[04:34] <nigelb> wallyworld: Hi, I had a few test failures yesterday from this MP. Would you mind re-reviewing and kicking it back into ec2? https://code.launchpad.net/~nigelbabu/launchpad/specification-validation-59301/+merge/73631
[04:34] <wallyworld> nigelb: sure
[04:35]  * wallyworld looks
[04:35] <nigelb> I should have commited test fixes and then fixed lint.
[04:35] <nigelb> gah.
[04:38] <StevenK> wallyworld: Nice work!
[04:39] <wallyworld> StevenK: thanks. how's the battle scenario modelling going?
[04:39] <StevenK> More painting :-P
[04:41] <wallyworld> remember, i want to see a photo when it's done :-)
[04:41] <StevenK> I've been linking you photos in privmsgs, you didn't comment :-P
[04:42] <wallyworld> StevenK: ah bollocks. didn't notice :-(  Under Unity, quassell notifications aren't very obvious to me anymore for some reason so i miss them
[04:43] <wallyworld> StevenK: so they start out blue? so you still have some work to do on those ones?
[04:44] <StevenK> wallyworld: They start out grey and on a sprue
[04:44] <wallyworld> nigelb: ec2 is off and running the tests
[04:44] <StevenK> So I need to cut them out, assemble them and then paint them fully
[04:44] <nigelb> wallyworld: thanks
[04:44] <nigelb> StevenK: battle scenario modelling?
[04:45]  * wallyworld types into google "define: sprue"
[04:45] <wallyworld> nigelb: that was my made up term
[04:45] <wallyworld> not sure what the official name for it is
[04:45] <nigelb> What is he making? :)
[04:47] <wallyworld> nigelb: painting little figurines of warriors and the like for display in a battle field scenario
[04:48] <wallyworld> StevenK:  not sure if that's the correct description? ^^^^
[04:48] <nigelb> Oooooh.
[04:48] <StevenK> Close enough
[04:49] <nigelb> StevenK: You made those? O_O
[04:49] <nigelb> like, from scratch?
[04:49] <StevenK> wallyworld, nigelb: http://wedontsleep.org/~steven/IMG_2807.JPG is what they start out like.
[04:50] <nigelb> ah, not entirely from scratch.
[04:50] <StevenK> That is for a different army, but you get the idea.
[04:50] <nigelb> But still, excellent work.
[04:50] <wallyworld> StevenK: oh, i didn;t realise you had to glue them together before painting
[04:50] <nigelb> You manage to do stuff that does not involve computers during paid vacation.
[04:50] <StevenK> wallyworld: That's the colour they start out as well.
[04:50]  * wallyworld nods
[04:51] <StevenK> That blue colour on them is 4 different blues
[04:51] <nigelb> how do you attach them?
[04:51] <nigelb> melt?
[04:51] <nigelb> or glue?
[04:51] <StevenK> nigelb: Plastic glue
[04:51]  * wallyworld wonders how StevenK is typing with all his fingers stuck together
[04:52] <StevenK> Plastic glue doesn't affect skin, it washes off easily
[04:52] <nigelb> If his fingers do get stuck, I know which key it will be on.
[04:52] <nigelb> ('Del')
[04:52]  * G fears StevenK's army
[04:53] <StevenK> Pft, I use vim, so it would be d
[04:53] <nigelb> heh
[04:59] <G> ohhh I may have spied on a another bugfix :)
[04:59] <nigelb> G: You're +1200?
[04:59] <G> nigelb: yep
[05:00] <nigelb> Two people with first names Nigel and we're both not British? Talk about breaking stereotypes  :P
[05:00] <G> in way of ancestry I'm mainly British
[05:01] <nigelb> Ah.
[05:01] <G> but I'm also partly Swede etc as well
[05:22] <poolie> hooray for wallyworld!
[05:22] <poolie> congratulations on your asterectomy
[05:22] <nigelb> asterectomy sounds painful :P
[05:23] <nigelb> "define asterectomy" got spell corrected to "define hysterectomy" making me LOL :)
[05:32] <wallyworld> poolie: thanks
[05:32] <poolie> the removal of his "i'm not a real reviewer" star
[05:32] <nigelb> Ah.
[05:33] <nigelb> aww wallyworld changed it, wgrant put a better /topic ;)
[05:37] <LPCIBot> Project devel build #1,023: STILL FAILING in 4 hr 7 min: https://lpci.wedontsleep.org/job/devel/1023/
[05:58] <jtv> wallyworld: gratifying that your graduation did not go unnoticed, no?  ☺
[05:58] <wallyworld> jtv: i was hoping to sneak under the radar and keep it quiet. but you put an end to that ambition :-P
[05:59] <jtv> Why would you want to do that?
[05:59] <wallyworld> jtv: i don't like attention :-)
[05:59] <wallyworld> i'm shy
[05:59] <jtv> Tip #1 for a reviewer: be feared.  Otherwise people start bothering you for reviews even when they have other options.
[05:59] <wallyworld> hah. good advice :-)
[05:59] <jtv> The attention comes in the one form or the other.  Trust me, you got the better deal.
[06:00] <wallyworld> lol
[06:00] <wallyworld> jtv: i notice you have a repuation as a feared reviewer
[06:00] <wallyworld> now i know why
[06:00] <jtv> "fascist" is the more common term, but alright
[06:01] <wallyworld> jtv:  well, if hard questions are asked and you get good answers, then that's good
[06:01] <jtv> I rejected a sentence added to an HTML page the other day.
[06:01] <G> all this discussion about fearing reviewers when I want to run something by... :)
[06:01] <jtv> wallyworld: see?  ^^
[06:01] <wallyworld> G: i don't bite, but jtv does
[06:01] <wallyworld> i think i need more mentoring therefore :-)
[06:01] <jtv> I'm doing my best for you, wallyworld.  Don't throw it all away.
[06:02] <G> wallyworld: well it's lucky I also don't fear people generally :)
[06:02] <jtv> Repeat afer me: I bite.  I'm a shark.  I'll go as deep as it takes to find what is wrong with your branch.
[06:02]  * wallyworld repeats I bite.  I'm a shark.  I'll go as deep as it takes to find what is wrong with your branch.
[06:02] <wallyworld> jtv: why the rejected sentence?
[06:03] <jtv> Sorry, is this _still_ not clear to you?
[06:03] <jtv> Fear.
[06:03] <wallyworld> ah, right.
[06:03]  * wallyworld needs to grow a pair
[06:04] <jtv> You don't have to be online who you are in real life though.  Ever seen BjornT and bigjools face off in the two arenas?  The outcomes are very different, I tell you.
[06:04] <G> wallyworld: putting your self proclaimed fearsome-ness to the test... I'm looking at https://bugs.launchpad.net/launchpad/+bug/793670 and found the issue ln 1819 of lib/lp/registry/browser/person.py runs setPreferredEmail(None), but a reactivation doesn't know which e-mail to set preferred again
[06:04] <_mup_> Bug #793670: User account missing preferred email after suspension/reactivation <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/793670 >
[06:04] <jtv> wallyworld: What we have online is you with a huge automatic weapon.
[06:04] <jtv> No go get 'em.  :)
[06:04] <G> wallyworld: would the right way be to create a new EmailAddressStatus such as "OLDPREFERRED" to save that detail?
[06:05] <wallyworld> G: i'll look, give me a second
[06:05] <wallyworld> jtv: will do
[06:05] <jtv> :)
[06:07] <G> wallyworld: so maybe something like setSuspendedPreferredEmail() which changes the status of the current preferred e-mail to OLDPREFERRED and then does _setPreferredEmail(None)
[06:07] <nigelb> G: jtv doesn't bite. Be makes you bite yourself after seeing his reviews.
[06:07] <nigelb> *But he
[06:07] <jtv> Well _if possible_ obviously I like to avoid even that bit of the work.  :)
[06:09] <G> wallyworld: rationale for a new Status, is that otherwise the question is "which VALIDATED e-mail should become the new PREFERRED e-mail"
[06:09] <jtv> StevenK, wgrant: we don't import binaries from debian, do we?  I suddenly wonder if there's still any need for gina to import binaries at all.
[06:11] <wgrant> jtv: We don't use gina's binary importer at the moment, no.
[06:11] <wgrant> jtv: But removing it right before we start migrating derivative distros onto LP would be somewhat foolish, I think.
[06:12] <wallyworld> G: another option is to modify the preferredemail property on person to check the account status before returning the email object
[06:12] <wallyworld> G: that seems cleaner to me
[06:12] <G> wallyworld: ahhh now that is a good idea
[06:13] <wallyworld> G: it's a smaller, more localised change with a smaller footprint
[06:13] <G> wallyworld: but I think the logic to removing the preferred e-mail address is to avoid cases where it may not go through the preferredemail property?
[06:14] <wgrant> G, wallyworld: This is a pretty difficult and all-encompassing issue.
[06:14] <wgrant> we need to make person status explicit, and fix a lot of code that checks for preferredemail instead.
[06:14] <jtv> wgrant: so when are we going to start using gina's binary importer?  What tells us that it will still work properly when we do?  What work have we done to verify that there are no harmful interactions between the binary importer and derived distributions?
[06:14] <wgrant> DB queries and stuff that doesn't use the property.
[06:14] <wgrant> jtv: None, but it will probably need to be done this year and deleting it is not a good idea.
[06:14] <wgrant> G: So, in summary, "run away".
[06:15] <wgrant> G: This is a deep rabbit hole.
[06:15] <wallyworld> wgrant: you would hope there's a single piece of logic to do "get the email address to send stuff to for this person"
[06:15] <wgrant> wallyworld: Hee hee hee.
[06:16] <jtv> wgrant: so we have something that we don't use, and won't use, and may do some kind of unknown damage.  Therefore we can't delete it shortly before the point where it may start doing that damage.  Does that sum it up?
[06:16] <wgrant> wallyworld: So, no, there isn't. And the preferred address is used not just for finding the preferred address, but also for checking whether the account is active.
[06:16] <G> wgrant: so essentially noone understands the logic so run away?
[06:16] <wallyworld> wgrant: that's dumb. account status should be via an "status" property of some sort
[06:17] <G> wgrant: thats what I'm saying... introduce a new ENUM option "OLDPREFERRED" and set the PREFERRED to that instead of VALIDATED on suspension
[06:17] <wgrant> jtv: gina is known to not be in a good state. I hope nobody is crazy enough to run it in anything except source-only Debian mode without first extensively checking the code.
[06:17] <wallyworld> not piggybacked onto another property
[06:17] <wgrant> G: But the account status is unrelated to email addresses.
[06:17] <wgrant> G: It should be a property of the person.
[06:17] <jtv> wgrant: so what else would we use it for?
[06:17] <wgrant> jtv: Migrating Linaro and OEM and $OTHER_DERIVATIVES to LP.
[06:17] <wgrant> wallyworld: You. Would. Think.
[06:18] <wgrant> wallyworld: There is Account.status, but very little uses it, and Account needs to burn anyway.
[06:18] <wallyworld> yeah, clearly i'm still too idealistic wrt lp code cleanliness
[06:18] <G> wgrant: but isn't: make it so LOSA's don't have as much work to do, and "re-implement everything sanely" two different issues?
[06:18]  * jtv gives up on wgrant
[06:18] <wgrant> jtv: Hm? We've just enabled LP to handle derivative distributions.
[06:18] <wgrant> jtv: We have several derivative distributions that need to be moved into LP.
[06:19] <wgrant> The way to migrate a distribution to LP is to use gina on it, importing binaries too.
[06:19] <wallyworld> G: you should talk to someone like cutis (who is on leave till next week). he know a lot about our email infrastructure i think
[06:19] <wgrant> gina needs significant repairs to be able to do that properly nowadays, but deleting the code is hardly going to make it better.
[06:20] <wgrant> G: Not really. Adding a new email address status is just perpetuating the insanity.
[06:20] <wgrant> G: We should fix this properly.
[06:20] <spm> G: fwiw. "so LOSA's don't have as much work to do" is a ... funky way of phrasing it. better would be "so losas can spend THAT time on other tasks equally valuable"
[06:21] <spm> it's not like we're sitting around on our hands waiting to be pinged :-)
[06:21] <G> spm: actually that is a better way of putting it :)
[06:21] <spm> :-)
[06:21] <G> spm: I should have said "So they don't have to worry about that issue anymore" :)
[06:22] <G> or something like that :)
[06:22] <G> wgrant: but yes, I see your point
[06:23] <G> wgrant: and obviously the solution would be to find everything that generates and e-mail and make sure that it someway or another goes through a proper method to get the e-mail address, that also checks if the account is active
[06:23] <wgrant> G: Roughly.
[06:24] <wgrant> jtv: So, am I still given up on? I'm not quite sure what's so controversial about not deleting code that we will probably have to revive to bring this feature into use.
[06:25] <G> and I'd imagine doing that, and all the subsequent tests to make sure it's working properly would be quite a lot :)
[06:26] <jtv> wgrant: sorry, I get frustrated sometimes.  I now realize that you meant to give the right answer, but because you never answered the direct question, I completely misinterpreted the rest of what you said.  So for confirmation I posed that "so we're not going to use this code," but you didn't deny it.  After all that, it was a very disorienting realization that you meant the exact opposite of what I was getting all along.
[06:27] <jtv> I asked a composite question, which in retrospect maybe I shouldn't have done, and so when you talked about "None" and "it," that left a lot of room for interpretation.
[06:27] <wgrant> jtv: We are going to use the code, but not in its current state.
[06:27] <wgrant> It was last used in mid-2007. People know not to use it now, so it is not harmful.
[06:28] <jtv> You really know how to scare me!
[06:28] <wgrant> But when we want to move distros onto LP, we will have to revive it and verify its correctness.
[06:28] <jtv> That's the part I was curious about: I got the impression that this was basically no more than a leftover from the original Ubuntu import.
[06:28] <wgrant> It *is* basically no more than a leftover from the original Ubuntu import.
[06:29] <wgrant> But it was used 18 months later to import partner too, because it still mostly worked, and didn't break too much.
[06:29] <jtv> Well one thing more, apparently: the start of derived-distros import.
[06:29] <wgrant> And I imagine it will be used against soon.
[06:29] <wgrant> again
[06:29] <wgrant> Right.
[06:29] <wgrant> But it's still just a leftoer.
[06:29] <wgrant> Just one that will be reincarnated.
[06:29] <wgrant> gina itself was just a leftover from the Ubuntu import.
[06:29] <wgrant> It got reincarnated and fixed up to import Debian.
[06:29] <wgrant> Some years later.
[06:30] <jtv> I don't know how many changes it went through; usually I advocate ditching poorly-understood custom code over reviving it after a long period of falling out of touch with the working application.  It'd do this code a world of good, but I can see the point for not rewriting this kind of stuff on a whim.
[06:31] <jtv> But oh, the stuff I keep prying out.
[06:32] <wgrant> gina's not huge, and it's pretty awful, but given the way LP goes it's tempting not to throw away roughly working code.
[06:32] <wgrant> Because it would naturally take at least 18 months to get a replacement working :/
[06:32] <jtv> I finally figured out that some very hard-to-read code with practically untyped data was really iterating over a dict's elements in alphabetical key order.
[06:33] <wgrant> Yeah, there is a bit of that sort of stuff.
[06:33] <jtv> A bit, he says.
[06:33] <wgrant> But it's normally possible to untangle.
[06:33] <wgrant> Eventually.
[06:33] <wgrant> ... occasionally by rewriting it and seeing what differs when you import an archive.
[06:33] <jtv> That's what I did with the dominator: a huge sql-laden mega-method turned out to be a few completely independent, easily-described methods.
[06:34] <jtv> Which reminds me: ran a full test domination of Debian on dogfood.  Seems to have gone pretty well, apart from the known problem with pre-existing publication records.
[06:34] <jtv> I wonder why we have all this support for deleting a source package without its binary packages though.
[06:34] <jtv> (Well, requesting deletion of a publication of a source package without doing the same for the publications of its binary packages)
[06:35] <jtv> Things could be a whole lot simpler and faster without that ability.
[06:35] <wgrant> SPPH<->BPPH links are special.
[06:35] <wgrant> ie. implied and varying.
[06:36] <jtv> Oh.
[06:36] <jtv> Oh God no.
[06:36] <jtv> Please no.
[06:36] <jtv> Remember that complicated code that iterated over a dict's keys?
[06:36] <jtv> That was for source packages.
[06:36] <wgrant> And?
[06:37] <jtv> It has a near-exact counterpart for binary packages.
[06:37] <wgrant> Ah yes.
[06:37] <wgrant> That also happens a bit.
[06:37] <jtv>         for binary in sorted(packages_map.bin_map[archtag].values(),
[06:37] <jtv>                              key=lambda x: x.get("Package")):
[06:38] <jtv> —where packages_map.bin_map[archtag] is, of course, keyed by x["Package"].
[06:38] <wgrant> Heh.
[06:38] <wgrant> I'm glad to see you cleaned up the dominator more.
[06:38] <wgrant> I did a bit a yearish ago.
[06:38] <wgrant> But it was still pretty awful.
[06:39] <wgrant> I didn't get all the way up to judgeSuperseded and judgeAndDominate... just the lower-level stuff.
[06:39] <wgrant> You seem to have fixed the rest up nicely, however.
[06:40] <jtv> Thanks.  Didn't even change much in terms of complexity, just moved large blocks of code.
[06:40] <wgrant> And simplified the setdefault/sort/reverse mess.
[06:40] <jtv> Oh, that :)
[06:40] <wgrant> With the creative variable name 'L'.
[06:41] <jtv>             package_name = binary.get("Package", "unknown")
[06:41] <wgrant> Erm.
[06:41] <jtv>  ^^ after all that trouble reconstructing the dict key, which is binary['Package']
[06:42] <wgrant> s/.*/raise DebianIsInsaneError/
[06:42] <jtv> I'll catch your DebianInsaneError and raise you a personal sanity failure.
[06:46] <nigelb> danilos: Hi, around?
[06:46] <wgrant> Oops.
[06:46] <wgrant> I made the mistake of using qannotate to check the dominator's history.
[06:46] <wgrant> Forgetting the qt apps now hang X.
[06:47] <wgrant> Thanks unity :)
[06:47] <nigelb> Excellent.
[06:47] <nigelb> Aren't you going to go the extra mile and blaim thumper for it?
[06:47] <wgrant> Nah, I've already done that once this week.
[06:48] <nigelb> *blame
[06:55] <wgrant> jtv: Launchpad is really good at consistency, isn't it?
[06:56] <jtv> We're getting better.  I think squads are a step forward.
[06:56] <wgrant> Even within a squad.
[06:56] <wgrant> Consider the ?PPH state transitions from PUBLISHED.
[06:56] <wgrant> supersede(), setDeleted() and requestObsolescence().
[06:56] <jtv> Well, setDeleted is purely an internal support method.
[06:57] <wgrant> Three different tenses, three different prefixes.
[06:57] <wgrant> True.
[06:57] <jtv> That part makes sense.  The real comparison I think is {requestDeletion, requestObsolescence} and those look consistent to me.
[06:57] <wgrant> Indeed, I'd forgotten that setDeleted had not entirely replaced requestDeletion.
[06:58] <jtv> It was never meant to.
[07:03] <jtv> wgrant: here's a thought about debian domination.  I can make retireDeadSourcePublications find the latest source publication for each package; request deletion for that one and supersede the rest.
[07:04] <wgrant> jtv: That would work.
[07:04] <jtv> Oh, gotta help out with something else now.
[07:04]  * wallyworld is off to see Australia vs Thailand in a soccer World Cup qualifier :-)
[07:07] <adeuring> good morning
[07:31] <stub> StevenK: So tell me about our Storm branch. Is there stuff in there that hasn't or cannot land upstream?
[07:32] <wgrant> stub: Has with_ landed upstream?
[07:32] <wgrant> The main issue apart from that is that storm now converts Date to a Python date, rather than a datetime.
[07:33] <stub> I dunno. I think this happened while I was on leave.
[07:33] <wgrant> which breaks tests and some code.
[07:33] <stub> Do we have bugs open on Launchpad or Storm?
[07:34] <wgrant> I don't recall. lifeless did the Date -> date revert initially.
[07:34] <wgrant> StevenK and I just updated the branch later with fixes we'd landed on trunk.
[07:34] <stub> ok. I'll trawl some bugs.
[07:46] <jelmer> wallyworld, hey, congrats on becoming a reviewer and thanks for using your newly found powers to review my code-imports-ui branch !
[07:47] <lifeless> is someone fixing the merge conflict?
[07:48] <stub> I can get there in a minute
[07:49] <lifeless> \o/
[08:12] <nigelb> danilos: Aha, thanks for merging! I was about to poke you. :)
[08:17] <mrevell> Hello
[08:18] <danilos> nigelb, you are welcome (it failed to merge yesterday because we hit "testfix" mode: a mode which stops further landings from happening when someone merges a branch that fails the test suite)
[08:21] <nigelb> hey mrevell :)
[08:21] <nigelb> danilos: ah! that makes sense :)
[08:28] <danilos> hum, how does one update sourcedeps.cache without doing it manually?
[08:28] <jelmer> danilos, ./utilities/update-sourcecode ?
[08:29] <danilos> jelmer: oh, thanks :)
[08:41] <G> hmmm I was looking at the list of trivial Launchpad bugs, and found: https://bugs.launchpad.net/launchpad/+bug/137373 the funny thing is, now it seems the blacklist deosn't exist, and you can 'register' a project named 'codeofconduct' without error, but be generated to the code of conduct page
[08:46] <mrevell> G: that sounds odd. Let me try that.
[08:47] <G> mrevell: I just did a grep around, and can only see the error message in relation to person/team names
[08:47] <mrevell> G: on staging,I get the message "The name 'codeofconduct' has been blocked by the Launchpad administrators."
[08:47] <G> it's as if the concept of blacklisting project names went into a void/black hole
[08:48] <G> mrevell: on my rocketfuel setup LP, it just proceeds like nothing happened
[08:49] <mrevell> G: Weird. On product it's blocked. I did notice that initially it tried to give me a project name of "codeof", though.
[08:49] <G> haha and now it says "codeofconduct is already used by another project" so the registration obviously worked
[08:49] <nigelb> G: did you check if the blacklisting is in the db?
[08:50] <nigelb> I'm just guessing. It is possible that its a table of some sort.
[08:50] <mrevell> I'm not sure how the blacklisting works. Any ideas wgrant?
[08:51] <G> for people/teams it's done in python in: ./lib/lp/registry/interfaces/person.py (class PersonNameField(BlacklistableContentNameField)
[08:51] <StevenK> That's a person, not a project
[08:51] <G> StevenK: I said that :)
[08:52] <G> my point is, greping around in my checkout, I can't find anything similar for projects
[08:53] <G> ohhh except I know what I mayhave done wrong
[08:54] <nigelb> case?
[08:59] <danilos> mrevell, I am pretty sure blacklisting is a table in the DB
[08:59] <StevenK> G: ^
[08:59] <G> hmmm okay, theory didn't work out
[09:00] <G> I created a user that didn't belong to any teams in the DB and it still worked w/o error
[09:00] <danilos> mrevell, "psql launchpad_dev" and then "\d nameblacklist" :)
[09:01] <G> danilos: ahhh ha
[09:01] <G> and select * from nameblacklist; doesn't include a regex that matches codeofconduct
[09:02] <nigelb> Which is why it worked for you.
[09:02] <StevenK> It's in the production database
[09:03] <G> yep, okay that makes sense now
[09:03] <StevenK> SELECT regexp from nameblacklist where regexp like '%code%'; => ^codeofconduct$, ^code$, ^decode$
[09:03] <nigelb> \o/
[09:03] <nigelb> Test results: specification-validation-59301 => devel: SUCCESS
[09:04] <nigelb> Oh. I just landed 2 successive branches.
[09:05] <nigelb> Achivement Unlocked.
[09:06] <G> so what would be a better way to put it? "The name (foo) has been blacklisted in Launchpad, please select another project name" ?
[09:06] <G> nigelb: I'm catching you up ;)
[09:06] <nigelb> G: Which is still winning. We're making Launchpad better.
[09:07] <nigelb> :)
[09:07] <G> exactly, not a race either
[09:07] <nigelb> Well, it is a race, except we're trying to beat wgrant, not each other :D
[09:09]  * wgrant forces a /Contributions update.
[09:12] <wgrant> Not bad, not bad.
[09:13] <nigelb> Climbed up to two digits in a leap.
[09:13] <wgrant> It was 10 before.
[09:13] <wgrant> Hmm.
[09:13] <nigelb> well, 10 was today as well.
[09:13] <wgrant> Ah, right.
[09:16] <wgrant> It appears that the race may be on, and I may have competition :(
[09:17] <G> wgrant: but aren't you a Canonical employee now?
[09:17] <nigelb> wgrant: I also love that you can't compete
[09:17] <wgrant> G: Yes :(
[09:17] <nigelb> G: He is, his numbers are static.
[09:17] <nigelb> (Those are pre-Canonical numbers)
[09:17] <G> oh I get it, that is just tracking the pre-employment commits?
[09:17] <wgrant> So I have a 130 branch head start, but no velocity.
[09:17] <wgrant> Right.
[09:17] <wgrant> Everything post-employment is with my Canonical address, so is conveniently excluded.
[09:21] <G> okay, I think I've come up with another good tiny bug to kill, one that actually confused me :) https://bugs.launchpad.net/launchpad/+bug/306569
[09:21] <_mup_> Bug #306569: Link to https://help.launchpad.net/Code from project branch listing page <lp-code> <trivial> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/306569 >
[09:42] <nigelb> wow
[09:42] <nigelb> OOPS-2071AT29
[09:42] <nigelb> when I propose a merge
[09:43]  * nigelb kicks _mup_ 
[09:46] <LPCIBot> Project devel build #1,024: STILL FAILING in 4 hr 8 min: https://lpci.wedontsleep.org/job/devel/1024/
[09:47] <wgrant> nigelb: I find it encouraging that timeouts surprise you now.
[09:47] <nigelb> wgrant: Well, it does. LP has been fairly untimeouting except for staging and qastaging.
[09:48] <nigelb> wallyworld: can I add https://code.launchpad.net/~nigelbabu/launchpad/merge-review-mail-824487/+merge/73765 to your list as well?
[09:49] <wgrant> I hope wallyworld is not still here.
[09:49] <nigelb> In which case, adeuring would you review this branch ^^
[09:49] <adeuring> nigelb: sure
[09:50] <nigelb> thanks!
[09:53] <adeuring> nigelb: nice work, r=me
[09:53] <adeuring> should I land it?
[09:53] <nigelb> adeuring: Yes, please :)
[09:53] <adeuring> ok
[10:04] <danilos> anyone feels like reviewing a simple loggerhead branch?
[10:13] <jelmer> danilos, might as well
[10:13] <danilos> jelmer, cool, https://code.launchpad.net/~danilo/loggerhead/bug-839395/+merge/73766
[10:14] <danilos> jelmer, actually, got a review from jam in the meantime
[10:14] <jelmer> actually, it looks like jam beat me to it :)
[10:15] <danilos> jelmer, yeah, though his vote was not registered by LP
[10:16] <jelmer> danilos, he's hanging out in #bzr
[10:23] <gary_poster> A bit of insomnia has me noticing that buildbot is unhappy.  The failing tests are all bzr bits and bobs, which no-one seemed to have touched.  Has anyone investigated?  I might try running some of the failing tests locally, and if they pass, I might force a build.
[10:28]  * jelmer has touched some bzr bits recently
[10:29] <jelmer> I'll have a look
[10:29] <wgrant> jelmer: We've had several lots of spurious bzr (particularly puller and import) failures since your recent series of branches.
[10:30] <wgrant> They've always been fragile, but they were mostly sorted for the last 6 months.
[10:31] <jelmer> well, I did reenable some that were supposedly going to be fixed with the new version of twisted
[10:32] <gary_poster> jelmer, thanks.  FWIW, they do pass locally, so it sounds like it is fragility
[10:33] <jelmer> actually, it looks like these are not the tests I was expecting to fail
[10:34] <jelmer> these are all failing with "no such module bzrdir", which is pretty weird
[10:36] <gary_poster> all sent by the server too
[10:36] <gary_poster> rather than in the main process
[10:37] <jelmer> yeah
[10:39] <gary_poster> would be nice if we could dupe locally :-/
[10:39] <jelmer> I wonder if somehow the system bzrlib gets loaded
[10:40] <gary_poster> Lemme see if I can find out how that subprocess is started...
[10:41]  * jelmer has to run off for lunch, back in ~30
[10:41] <danilos> adeuring, hi, a very simple branch up for review on https://code.launchpad.net/~danilo/launchpad/bug-839395/+merge/73779
[10:42] <adeuring> danilos: ok, I'll look
[10:42] <danilos> adeuring, thanks
[10:44] <gary_poster> FWIW, all tests using ForkingServerForTests failed
[10:45] <adeuring> danilos: r=me
[10:52] <gary_poster> Going to ask for some diagnostics from the bb machine
[10:57] <danilos> adeuring, thanks, landing already :)
[11:10] <bac> hello adeuring
[11:13] <adeuring> hi bac
[11:17] <jelmer> gary_poster: ah, interesting
[11:20] <jelmer> gary_poster: I wonder if we're using bzrlib.bzrdir somewhere but don't do "import bzrlib.bzrdir" in the forking service
[11:25] <stub> gary_poster: Is this an intermittent problem? I just resolved a merge conflict between stable and db-devel dealing with bzrlib imports
[11:28] <gary_poster> stub, yes intemittent, AFAICT
[11:29] <stub> so this might go and infect db-devel now
[11:29] <gary_poster> jelmer, sorry, I have to do morning things with children now.  Will be back in < hour
[11:29] <stub> gary_poster: Interestingly, the imports where the same but the order was different.
[11:30] <nigelb> Is Julian away today?
[11:30] <jelmer> gary_poster: np, talk to you later
[11:33] <wgrant> nigelb: Yes.
[11:33] <wgrant> nigelb: He will return next week.
[11:33] <nigelb> Ah, ok. I found a few bugs he'd opened which doesn't seem reproducible.
[11:34] <wgrant> nigelb: Link?
[11:34] <nigelb> Let me hunt them down.
[11:35] <nigelb> bug 814696, bug 814697
[11:35] <_mup_> Bug #814696: Link to show inline diffs in merge proposals should be green <code-review> <trivial> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/814696 >
[11:35] <_mup_> Bug #814697: Inline diffs in merge proposals don't have a spinner when it's waiting for the diff <code-review> <trivial> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/814697 >
[11:36] <nigelb> Inline diffs in an MP is green. And there's no spinner since it just points to the diff further down in the page.
[11:36] <wgrant> He may mean inline diffs *for* MPs.
[11:36] <wgrant> eg. on branch, bug pages.
[11:36] <wgrant> But they are also green and have a spinner.
[11:37] <nigelb> Right.
[11:37] <wgrant> It was broken due to a partial revert for a few hours a month or so ago... not sure if the timelines coincide.
[11:37] <nigelb> It was filed a little over a month ago.
[11:37] <nigelb> So, entirely possible.
[11:38] <nigelb> Hrm, is bug 787798 trivial?
[11:38] <_mup_> Bug #787798: Launchpad should use Google web fonts for the Ubuntu font <css> <trivial> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/787798 >
[11:38] <nigelb> I tend to think not.
[11:40] <wgrant> nigelb: Why not?
[11:40] <wgrant> It's basically one line of HTML.
[11:40] <wgrant> Although it needs a bit of thought as to which subset of the font we want.
[11:40] <wgrant> Probably all of it.
[11:40] <nigelb> One line of HTML and another line of CSS.
[11:40] <wgrant> Oh?
[11:40] <nigelb> It might end up looking ugly for monospace.
[11:41] <wgrant> We already use the Ubuntu font in our CSS.
[11:41] <nigelb> AH!
[11:41] <nigelb> one line of HTML then
[11:41]  * nigelb grabs
[11:43] <nigelb> hrm, interestingly. I have no idea which is the page template thing for LP.
[11:45] <wgrant> nigelb: base-layout.pt
[11:46] <nigelb> Interesting.
[11:58] <nigelb> \o/ 4 branches in a day? I'm aiming for my personal best today.
[11:59] <jelmer> nigelb: whoa
[11:59]  * jelmer is glad if he manages one lp branch in a day
[12:00] <nigelb> jelmer: 2 of them got merged only today. I worked on them for 2 days
[12:00] <nigelb> the other 2 are small fixes :)
[12:07] <nigelb> wgrant: Does this need tests?
[12:07] <nigelb> (is there a way to test this?)
[12:12] <bac> go nigelb, go!
[12:13] <nigelb> bac: heh thanks! And for that, can you review https://code.launchpad.net/~nigelbabu/launchpad/ubuntu-font-787798/+merge/73793
[12:13] <bac> nigelb: would be glad to, in just a bit.  i'll claim it now.
[12:14] <nigelb> cool!
[12:37] <gary_poster> jelmer, I'm back, but assuming that you are on the test failure.
[12:37] <gary_poster> jelmer, heh
[12:37] <jelmer> hah, brain wave sync. or something. :)
[12:37] <gary_poster> :-)
[12:38] <jelmer> I haven't found much yet, other than that previous hypothesis is almost certainly wrong.
[12:38] <gary_poster> jelmer, the bzrdir not imported idea you had is reasonable, though I would have expected...heh, ok
[12:40] <nigelb> bac: That article about checklists was "enlightening"!
[12:40] <bac> i should re-read it.  saw it when it first appeared in the NYKR
[12:40] <gary_poster> jelmer, I'm not sure where to go with this one.  site.py is where we set up paths, and it is obviously working fine for the main process, and the environ passed to the forked server subprocess on my system was correct
[12:40] <gary_poster> I looked at site.py on buildbot and it was fine...
[12:41] <gary_poster> Everything was also OK here before 2.4.x so that's the most obvious smoking gun
[12:41] <gary_poster> but I certainly would not like to roll that back, and I'm sure you feel even more strongly that way
[12:42] <jelmer_> yeah
[12:42] <jelmer_> gary_poster, db-devel has had 2.4 for a while
[12:42] <gary_poster> If I could dupe that would sure be nice.  I tell you what jelmer, I'm going to ask for a screen session on the buildbot and try running the tests there and see if I learn anything.  Are you around for awhile?
[12:43] <jelmer_> gary_poster: I'll be out for about an hour soon, but should be able to help after that
[12:44] <gary_poster> ack thanks jelmer_
[12:56] <nigelb> Is buildbot temporarily broken?
[12:57] <StevenK> Testfix
[12:57] <gary_poster> nigelb, we are in testfix
[12:57] <gary_poster> nigelb, I'm working on it
[12:57]  * gary_poster has to step away for 20
[12:59] <nigelb> Ah!
[13:11]  * gary_poster back
[13:20] <bac> hi nigelb, thanks for the font fix.  i'm not sure making the change in the base page template is the right place to put it.  there are still other fonts being used, on buttons for example.
[13:20] <bac> nigelb: i'd like to talk to sinzui to get his thoughts
[13:21] <nigelb> bac: I'm only making sure google web fonts get included.
[13:21] <nigelb> The font gets changed to Ubuntu wherever the font is set as 'Ubuntu'
[13:25] <nigelb> Also, hrm, I was looking for sinzui the other day as well. Has he not been around?
[13:25] <bac> nigelb: i don't know his schedule
[13:26] <bac> there is a US holiday on monday though, so if he isn't around today it'll be tuesday before he comes back
[13:26] <StevenK> sinzui has been on holidays this week, like I have.
[13:26] <nigelb> Ah!
[13:26] <nigelb> I'll wait for next week :)
[13:26] <bac> nigelb: ok, sorry to put a speed bump in your mojo today!  :)
[13:27] <nigelb> heh
[13:27] <nigelb> no worries!
[13:29] <nigelb> I'll applaud sinzui for *really* being away when he's suspposed to be away.
[13:29]  * nigelb glances at StevenK and wgrant.
[13:34] <nigelb> mrevell: Might be interesting to you - http://nigelb.me/ubuntu/launchpad/2011/09/02/some-new-improvements-to-lp.html
[13:45] <wgrant> nigelb: Heh.
[13:48] <danilos> adeuring, bac: anyone eager to pick up a branch for review: ://code.launchpad.net/~danilo/launchpad/bug-302449/+merge/73813
[13:48] <bac> danilos: sure
[13:56] <LPCIBot> Project devel build #1,025: STILL FAILING in 4 hr 9 min: https://lpci.wedontsleep.org/job/devel/1025/
[14:00] <danilos> bac, thanks :)
[14:00] <mrevell> thanks nigelb
[14:07] <bac> danilos: why does 'make lint' not report problems for you?  i see it complaining about the use of a==b in storm clauses with no spaces.
[14:07] <danilos> bac, I thought I fixed that
[14:07] <danilos> bac, :/
[14:07] <bac> oh, maybe you didn't push
[14:08] <danilos> bac, actually, I didn't even commit :)
[14:08] <danilos> bac, pushing now
[14:08] <bac> you need the 'bzr-telepathic' plugin
[14:14] <danilos> bac, heh, I thought I had that
[14:14] <bac> danilos: done.  thanks.
[14:22] <stub> https://code.launchpad.net/~stub/launchpad/dboptions/+merge/73824 needs a review. I can deal with it in 15 mins, or tomorrow so schedule accordingly :-)
[14:37] <bac> stub: done
[14:47] <stub> bac: ta
[15:00] <nigelb> I just got an interesting comment :)
[15:01] <nigelb> "Do you know how to make lp sexy? MAKE A DESCRIPTION HOW TO CLONE REPO! "
[15:01] <G> actually, I was thinking about that myself
[15:02] <nigelb> There is instructions here - https://code.launchpad.net/~launchpad-pqm/launchpad/devel
[15:02] <nigelb> Get this branch: bzr branch lp:launchpad
[15:02] <G> I was looking at https://bugs.launchpad.net/launchpad/+bug/306569 and thinking of fixing it
[15:02] <_mup_> Bug #306569: Link to https://help.launchpad.net/Code from project branch listing page <lp-code> <trivial> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/306569 >
[15:02] <G> because I must admit, it is sometimes a bit vague
[15:03] <gary_poster> jelmer_ or abentley, I'm about to submit a diagnostic hack for when the forked server might fail again.  The output when we have an error will be something like this. http://pastebin.ubuntu.com/680623/  Unfortunately, you'll notice that the message, delivered straight from bzr, does not give me a  traceback for where this bad flafla import was (it was in the lpserve plugin).  Is there a way to make it give me one?
[15:03] <nigelb> G: Oooh, good one
[15:04] <gary_poster> -v does not
[15:04] <abentley> gary_poster: yes.  From the commandline, you'd use -Derror.  I don't know what the equivalent in bzrlib is.
[15:04] <G> nigelb: I just assigned it to $me :)
[15:04] <gary_poster> abentley, would it hurt anything to start lpserve up in that way for the tests?
[15:04] <gary_poster> I can try :-)
[15:05]  * gary_poster does
[15:05] <abentley> gary_poster: I think that would be fine.  There's a small chance that a test is expecting the non-Derror output.
[15:10] <jelmer_> gary_poster: from bzrlib import debug; debug.debug_flags.add("error") is the python equivalent of using -D
[15:11] <gary_poster> jelmer_, cool, thanks.  The forking server uses subprocess to run lpserve on the commandline, so -Derror works fine.  So far tests  are passing with the change and the error message is much more informative, as you'd expect.
[15:26] <gary_poster> abentley, thanks that worked well.  Could you take a glance at https://code.launchpad.net/~gary/launchpad/testfix/+merge/73840 before I submit it to see if you have any better ideas that I can implement now or later?
[15:28] <abentley> gary_poster: what does "we are not on a testcase" mean?
[15:29] <gary_poster> abentley, it is supposed to mean that self is not a testcase
[15:29] <gary_poster> which is where the "addDetail" lives
[15:31] <gary_poster> abentley, better?
[15:31] <gary_poster> We cannot use the "addDetail" method because this class is not a TestCase and does not have access to one.  It runs as part of a layer.
[15:32] <abentley> gary_poster: I'm seeing that now.
[15:32] <abentley> gary_poster: Since it's part of the layer, we can't even pass a TestCase in.
[15:32] <jml> fixtures have addDetail, or something similar
[15:33] <gary_poster> right, abentley.  jml, this is a tool used by a Zope layer.  Our layers are not fixtures, right?
[15:33] <jml> gary_poster: some of them are almost fixtures. The LibrarianLayer, for example.
[15:34]  * gary_poster goes base class hopping...
[15:37] <abentley> gary_poster: I guess I wonder whether the return value isn't a sufficient test by itself.
[15:38] <gary_poster> abentley, that's what I had initially.  It wasn't sufficient practically: the return value was None.  The process hadn't completely died yet.  I could do a time.sleep before the poll, but I thought the error string check was the lesser of those two evils.
[15:42] <abentley> gary_poster: I'm mildly surprised that Popen.wait doesn't accept a timeout.
[15:45] <gary_poster> ack abentley, me too.  It looks like the underlying C module, exposed as _subprocess, takes either a 0 or INFINITE timeout.  Maybe it has other options, but that's all that subprocess.py uses.
[15:46] <gary_poster> ah, no, that's windows...
[15:46] <abentley> gary_poster: So it seems okay to me.  Perhaps you could check for success, rather than failure, which might look a bit less kludgy.
[15:49] <gary_poster> abentley, ok thanks.  I thought about checking for success, but it seemed more fragile.  The success output is this:
[15:49] <gary_poster> Preloading 0 modules
[15:49] <gary_poster> Listening on socket: /var/tmp/launchpad_forking_service.sock
[15:49] <gary_poster> well, not 0 modules
[15:49] <gary_poster> but anyway
[15:49] <gary_poster> the first line seems to happen no matter what
[15:49] <gary_poster> but I could be wrong
[15:50] <gary_poster> abentley, if you feel stongly about it, I'll do it.  I don't.  Otherwise I'll land as is.
[15:51] <gary_poster> ("I don't" == I don't feel strongly about it.)
[15:51] <abentley> gary_poster: I don't feel strongly.  I was just trying to help you find a solution that made you happier.  My theory is that success is predictable, but failure can take many forms.  So if you don't get something you recognize, it's a failure.
[15:52] <gary_poster> Hm, yeah, there's something to that abentley.  OK, I'll maybe look for "Listening on socket" and fall over if not found.  Thank you very much.
[15:52] <abentley> gary_poster: np.
[21:14] <LPCIBot> Project devel build #1,026: STILL FAILING in 4 hr 55 min: https://lpci.wedontsleep.org/job/devel/1026/