[02:05] danilos: Hi, what's happening with https://code.launchpad.net/~danilo/launchpad/bug-1000148/+merge/105962? [03:00] wgrant: http://pastebin.ubuntu.com/1061930/ [03:02] StevenK: :( [03:03] StevenK: the methods take iterables for a reason :) [03:03] Precisely to avoid loops like that. [03:05] wgrant: I need the artifact anyway, so .ensure() doesn't get out of it [03:06] StevenK: Hm? [03:06] ensure() returns all the AAs. [03:06] So one call can get all the AAs for the batch [03:08] wgrant: Sure, but then I need to match up the AA to the branch [03:09] StevenK: that's roughly one generator expression away [03:18] * wgrant disables test_find_missing_ready [03:22] Oh, is that the one that keeps failing horribly on buildbot, but passing on ec2? [03:22] Yes. [03:23] Not reproducible locally. [03:23] But happens fairly often on buildbot. [03:34] wgrant: Does http://pastebin.ubuntu.com/1061964/ make you happier? [03:36] StevenK: Still O(chunksize) queries, but only for branch.subscriptions for which there is no batch API, so I no longer hate you. [03:38] Yeah, and I'm not writing one just for a garbo job. :-P [03:45] Laney: Please set a description for your MP [04:04] wgrant: https://code.launchpad.net/~stevenk/launchpad/populate-branch-aag/+merge/112264 [04:08] StevenK: Looks mostly OK, but we still don't know what we want to do about owners [05:25] wgrant: What else did I have to sort out? [05:26] StevenK: Well, we need to think about owners. [05:26] Because they should have access except when they should not. [05:26] Oh, I need to fix the job stuff to deal with branches too? [05:27] Right, that's something that only touches on ownership, so it's probably sensible to work on now. [05:31] Oh good, it's SharingJob, so I don't have to kill wallyworld. [05:31] """Job classes related to the sharing feature are in here.""" [05:31] On second thoughts ... [05:38] wgrant: I can recall their being two, is RemoveBugSubscriptionsJob the winner? [05:40] * StevenK stabs buildbot more [05:41] StevenK: There's now only one. [05:41] They were merged into RBSJ [05:42] So I should write a seperate RBranchSJ? [05:44] StevenK: Possibly. I don't know if it's better to duplicate or extend in this case. [05:46] wgrant: Extending involves a rename :-( [05:47] StevenK: Is that a problem? [05:47] I don't think the name is stored [05:47] Just an integer. [05:48] Right, not really [05:48] * StevenK greps for 'are in here' and sighs [05:49] wgrant: RBSJ -> RemoveArtifactSubscriptionsJob ? [05:50] StevenK: Maybe [05:52] wgrant: You seem very unsure these past two days :-P [05:53] If I was sure of the solutions they'd be done already :) [05:53] wgrant: Oh, what's the plan to keep AAG up to date WRT branch after the garbo job? [05:54] The job will remove subscriptions, but what adds and removes AAGs? [05:55] StevenK: See Bug.subscribe and Bug.unsubscribe [05:55] Ah, _reconcileAccess [05:55] We need one for branch, no? [05:55] No [05:55] _reconcileAccess is separate [05:56] It maintains AA and APA [05:56] And is already in place for Branch. [05:57] Oh, service.ensureAccessGrants() [05:57] Both Bug and Branch make use of that [05:58] Hm [05:58] wallyworld must have already done that bit [05:58] Sneaky [05:58] I did the branch bit [05:59] It's not done in unsubscribe, though. [05:59] ... Details? :-) [06:01] StevenK: Bug.unsubscribe removes grants, Branch.unsubscribe does not [06:04] wgrant: Yes, I get that, I was making a joke. [06:04] wgrant: In either case: http://pastebin.ubuntu.com/1062089/ [06:05] StevenK: Probably, yeah. [06:24] wgrant: Would you like to review https://code.launchpad.net/~stevenk/launchpad/branch-unsubscribe-revokes/+merge/112272 ? Happy enough to leave it for someone else to pick up. [06:24] StevenK: Juggling three other things right now, so I might not get to it today. [06:24] wgrant: Like I said, happy enough to leave it. [06:50] lifeless: do you have any time to chat about bug #879589 ? [06:50] <_mup_> Bug #879589: adding/removing user/team subscriptions to bug reports edits date_last_updated

< https://launchpad.net/bugs/879589 > [07:05] jam: not tonight really [07:05] jam: perhaps tomorrow? [07:05] lifeless: k, prob means we won't be working on it this week, then. [07:05] lifeless: If not today, then any time works [07:05] we'll just get to it on rotation. [07:06] If I have time later tonight I'll ping you [07:06] so, my ec2 land from yesterday finished without sending me email [07:07] jml: you had an issue like this at the start of the month, do you remember if you changed something to get it working? [07:08] lifeless: np === matsubara-afk is now known as matsubara [07:14] okay, it seems that not having my password in bazaar.conf makes it break [07:14] using the canonical smtp server (which has a global password) is what works of most people [07:15] mgz: Right, the ec2 instance isn't going to have a huge amount of luck authenticating without knowing the password. [07:15] checking that before setting up might be... nice [07:36] wgrant, on https://code.launchpad.net/~danilo/launchpad/bug-1000148/+merge/105962, I am waiting for skaet (Kate Stewart) from Ubuntu to give me a go-ahead to land it (as if they are having second thoughts for Ubuntu) [07:42] danilos: You've not heard anything? [07:43] good morning [07:53] wgrant, I have a call on Friday to settle that once and for all [07:53] wgrant, will likely land then === frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: rick_h, frankban* (rvba) | Firefighting: - | Critical bugs: 3.47*10^2 [08:00] danilos: Great, thanks. [08:00] StevenK: ack, done, thanks [08:01] morning [08:16] stub: Is there a good way to stop a psql script based on a query? [08:16] I'm looking here: If your query requires result count verification, write that into your script. [08:16] here: https://wiki.canonical.com/InformationInfrastructure/OSA/RequestLogging/LP/SQL [08:16] and it says the above line. [08:16] In this particular case, there is a count which should be 0 [08:17] Can anyone in soyuz land come up with a better name for https://code.launchpad.net/~laney/launchpad/db-proposed-not-automatic-pre-release/+merge/112134 ? [08:17] jam: If you start needing anything advanced, switch to a Python script. [08:18] stub: well, I want a while loop, and a stop-if-not-zero. It seems a bit much to go to a python script for that [08:18] but certainly I could. [08:18] jam: The facilities you are looking for are there in pl/pgsql but then you are running in a single transaction [08:19] stub: My suggestion would be to just make it proposed_not_automatic [08:19] stub: The pre-release bit can be handled by unsetting the flag on release :) [08:19] There is a separate suggestion from mpt to have this behaviour post-release too. It's not clear if we want it, but if we do then the two wouldn't necessarily be conflated. [08:20] jam: It doesn't have to be a pretty python script. Import psycopg2, connect, cur.executes() & cur.commits()... [08:20] con.commit I mean [08:20] stub: sure [08:20] I think that is fair enough [08:23] jam: You can also cheat. Assuming your statement is a noop if you repeat it a few hundred times with no data to change, just cut and paste it a few hundred times... but there are no constructs apart from basic variable substitution in psql scripts - it is designed as an interactive interpreter. [08:24] stub: np, thanks [08:24] it just seems so close [08:25] yes. I think future versions of PG are looking at solving this by allowing stored procedures and anonymous code blocks access to the transaction machinery - at the moment, they are always invoked inside a transaction. [08:29] jam: cursor.rowcount lets you know the number of rows affected by the last execute btw. It is the most convenient way of terminating a loop like I suspect you are writing. [08:29] stub: thanks. The first thing is actually to check that there is nothing 'pending', but the second thing is to loop until empty [09:24] is this normal looking for an ec2 land in progress? [09:24] [09:24] mgz: Doesn't load for me; it might be firewalled. [09:26] mgz: The summary.log for my run currently in progress looks like this: http://people.canonical.com/~cjwatson/tmp/summary.log [09:27] Is there any plan for an NDT deployment today? [09:28] cjwatson: ah, sorry, hadn't realised the secgroup was set to allow only from ip block [09:28] thanks for the example to compare against === almaisan-away is now known as al-maisan === matsubara is now known as matsubara-lunch [11:02] cjwatson: There were a few buildbot failures. [11:02] cjwatson: Hopefully tomorrow [11:04] wgrant: Oh, blast. I'll have to reschedule with security [11:05] Ah well [11:05] cjwatson: Well, let's see [11:05] cjwatson: buildbot will be done in 10 minutes. [11:06] Let's see where QA is... [11:06] Mm, there's a bunch of bzr stuff to QA [11:06] Ah yeah [11:06] And that's the stuff that's broken production once already [11:06] You always want a completely clear report, rather than just a clear head? [11:07] cjwatson: You don't need the custom upload stuff? [11:07] Not with any particular urgency [11:07] Then let's deploy now. [11:07] * wgrant deploys now [11:07] In fact if that lands tomorrow it can get the copy-only-copyable-custom-uploads branch as well so it will OOPS less (harmlessly, but still). [11:08] Yeah. [11:10] YAY [11:10] buildbot failed again [11:10] FFS [11:10] For a different reason, though [11:10] Since I disabled the usual intermittent test [11:11] That freaked me out for a moment since I have a branch sitting around locally (but not pushed anywhere) that goes near that test. [11:11] * wgrant forces, will convince ops to pull it manually tomorrow. [11:11] Yeah, I was going to blame you but then realised all your recent changes there were well past buildbot. === matsubara-lunch is now known as matsubara [11:43] hi diogo [11:43] bac, hi === rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: frankban* (rvba) | Firefighting: - | Critical bugs: 3.47*10^2 [12:09] frankban: rvba if you get a chance to peek at https://code.launchpad.net/~rharding/launchpad/listingnav_yui35/+merge/112334 please [12:09] frankban: rvba sorry for the line count, but only the top of the files were changed, the main body is indenting/moving each test suite to tests. [12:09] so it looks scarier than it is [12:10] only actual tests change is the addition in the tearDown() noted in the MP comments [12:11] rick_h_: on a call now, will look ASAP [12:11] frankban: no rush, ty much [12:31] hmm [12:31] does launchpad-dev discard or silently moderate mail from non-subscribers? [12:35] Laney: Launchpad mailing lists in general silently drop emails from addresses that aren't registered in Launchpad [12:35] I don't see anything in the moderation queue [12:35] wgrant: I sent it from laney@u.c. [12:35] <20120627103638.GB1489@raleigh> [12:39] Laney: ./vette:Jun 27 10:36:22 2012 (14313) Discarding forged message-id: <20120627103638.GB1489@raleigh> [12:39] Odd [12:40] Laney: Huh [12:40] Laney: That seems to trigger only if the sender address is the list address. [12:40] https://lists.launchpad.net/launchpad-reviewers/msg01120.html has the relevant diff. [12:41] That's the first time that message has shown up in a long time. [12:41] Huh, indeed. [12:41] Date: Wed, 27 Jun 2012 11:36:38 +0100 [12:41] From: Iain Lane [12:41] To: launchpad-dev@lists.launchpad.net [12:41] Laney: Can you try again, maybe Bccing me so I can see what's actually happening? [12:42] Jun 27 11:36:10 cripps postfix/cleanup[2751]: 14CCB20424: message-id=<20120627103638.GB1489@raleigh> [12:42] Jun 27 11:36:11 cripps postfix/qmgr[13900]: 14CCB20424: from=, size=4401, nrcpt=1 (queue active) [12:42] wgrant: Sure, doing now. [12:44] wgrant: Done. (Bcc: …@c.c) [12:44] Laney: Oh [12:44] Laney: launchpad-dev is in the Reply-To that you sent. That might be relevant [12:45] could be [12:45] It's fairly standard practice to do that though. [12:46] Evidently not LP mailing lists :/ [12:46] Mailman/Defaults.py.in:SENDER_HEADERS = ('from', None, 'reply-to', 'sender') [12:46] That is a little odd. [12:55] :/ [13:06] said test kipple: http://pastebin.ubuntu.com/1062517/ [13:09] wgrant: I'll just send it without reply-to. [13:12] Laney: join the list, just modered your mail [13:12] czajkowski: I'd rather not get any more email :P [13:13] You could whitelist me if you like [13:15] gmb: https://code.launchpad.net/~gz/launchpad/py27_test_scriptmonitor_logging_1017981/+merge/112160 [13:21] czajkowski, Laney, you are white listed a day after your message is approved from the moderation queue [13:21] ack, cheers [13:22] frankban: could you take a look at this? https://code.launchpad.net/~ivo-kracht/launchpad/bug-824292/+merge/112352 [13:22] ivory: I am doing another review, I will be happy to review your branch if you can wait a couple of minutes [13:23] czajkowski, look at this page: https://launchpad.net/~laney/+review [13:23] frankban: no problem,take your time [13:24] * Laney wonders what's on that page … [13:24] sinzui: oh yes [13:24] sinzui: not seen that been used before good to know [13:24] cheers [13:25] czajkowski, standing is an incomplete feature. it was to permit non-subscribers to lurk and posts to lists. [13:25] sinzui: ah interesting [13:26] czajkowski, Lp will notice laney's approved moderation later today and change something so that laney can always post to our list... [13:26] ph I just changed it manually :/ [13:26] ...but changing his standing to good will permit him to post to any Lp list I believe [13:27] standing is probably a candidate to remove since no one has commitment to finish it [13:27] grand changed it to that [14:18] jam: lp:~yellow/charms/oneiric/buildbot-master/trunk and lp:~yellow/charms/oneiric/buildbot-slave/trunk [14:25] sinzui: what should I do about https://answers.launchpad.net/launchpad/+question/201362 [14:26] ha [14:26] you saw it too [14:26] I just fixed it. https://code.launchpad.net/~vcs-imports/amanda/trunk [14:26] I types the URL wrong [14:26] I typed "typed" wrong too [14:27] sinzui: I do tend to read all your mails :) [14:27] not that I don't read the tohers [14:27] *others! [14:28] czajkowski, We can always ask a webops to make a new series called trunk and link the new branch to it. [14:29] maybe we should ask the webops to make ~registry the maintainer so that we can fix the project up [14:29] * sinzui think ~ registry should own it until someone with time can maintain it [14:32] adeuring, https://plus.google.com/hangouts/_/ec0208c347513d03aa007b4b4114ae823e80b7a8?authuser=0&hl=en [14:38] hi folks, how should I go about making a private PPA become public? [14:39] czajkowski: Did it post? I don't see it on https://lists.launchpad.net/launchpad-dev/ [14:43] Laney: I moderated it no sign yet. [14:43] oh woe [14:44] I did noticed a massive delay on mails yesterday 50 mins in some cases [14:44] Date: Wed, 27 Jun 2012 14:11:52 +0100 [14:44] 1.5 hours [15:00] jamestunnicliffe, danilos, flacoste, czajkowski, matsubara: https://plus.google.com/hangouts/_/181ae1d3328f2435b903d2a6cdc3395f400ac837? [15:00] jamestunnicliffe, danilos, flacoste, czajkowski, matsubara: Actually, would Skype work for all of you? [15:00] mrevell, heh, I got this just as I was creating another one, let me kill mine [15:00] mrevell, yep [15:01] mrevell, dude! [15:02] mrevell: i prefer skype [15:02] mrevell, I am on skype now, ready to go [15:02] jamestunnicliffe, What's your Skype id? Feel free to PM it [15:03] mrevell: Erm, I would have to install it first... [15:03] jamestunnicliffe, I can dial you in on a landline [15:03] mrevell: Actually, if we are doing voice, I have skype on my phone. [15:04] mrevell: user=dooferlad [15:04] jamestunnicliffe, Great, yeah voice only [15:05] jamestunnicliffe, Can you please allow me to see your availability? I'm matthewrevell [15:05] abentley: you have a sec? [15:05] rick_h_: Sure. [15:06] mrevell: Done. === abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: frankban* (rvba), abentley | Firefighting: - | Critical bugs: 3.47*10^2 [15:08] abentley: so are you benchmarking the branch scanner? [15:10] jam: No, I'm making some changes to the way branch paths are resolved. [15:10] jam: So I'm benching how long it takes to open a branch. [15:11] abentley: sorry, network issues, hangout went boom [15:12] rick_h_: ack [15:13] jam: Actually ran into an odd SSH connection management bug that I'll file. [15:21] abentley: yea, so now the test fails and the ATTR isn't read only so going to patch that up. [15:22] gotta love it [15:23] rick_h_: I think it was only testing to see that the BugListingConfigUtil version was read-only. [15:24] abentley: ah ok, and with the refactor the test itself is just not valid? [15:25] since buglistingconfigutil doesn't have that attribute any longer, only the model does [15:25] rick_h_: Yes, I think so. [15:25] that makes sense [15:25] ok, thanks, a delet'ing I will go [15:28] sinzui: The video in your latest post is small, making it hard to see what's happening, and there's no full-screen option. [15:30] I was thinking of remaking it. That was ian's example [15:30] * Laney gives in and joins ~launchpad-dev :P [15:31] Laney: hah [15:32] sinzui: Am a bit unsure as to if this is something I am to do or web ops are to do https://answers.launchpad.net/launchpad/+question/201542 [15:33] um that is confusing [15:33] ah good [15:33] czajkowski, https://launchpad.net/python-virtkey/+admin [15:33] I like you're confused also [15:34] this is tricky [15:34] It is impossible to change the Lp Id (name) and alias at the same time [15:34] czajkowski, remove the alias, save [15:34] done [15:34] admin again and change the name to the alias and save [15:35] admin again and change the alias to the old name [15:35] and change the name to what though [15:36] czajkowski, virtkey [15:36] we want to switch the text in the two field, but Lp is going to make us submit the for 3 times to do it [15:36] it;s not letting me [15:37] alias python-virtkey Name virtkey [15:37] right, three steps, not one [15:37] remove the alias [15:37] then change the name [15:37] then add the alias [15:38] ahh [15:38] *headdesk* [15:39] There is contention in the db tabled when we make the change, so the site needs to make the change is small steps [15:39] sinzui: nods [15:39] just complicated and not straight forward, used to doing one simple change [15:39] thanks for the help [15:42] jcsackett, This is the bug that the feature flag works with. We want to fix enough of the problem so that we can say it is fixed and the flag is gone https://bugs.launchpad.net/launchpad/+bug/885672 [15:42] <_mup_> Bug #885672: Users make bugs private because they cannot hide comments

< https://launchpad.net/bugs/885672 > [15:42] sinzui: right, that's the one i was mentioning wallyworld was on. [15:45] sinzui: so, cleanup, the two regressions, and then simplifying the flagged code and removing the flag. [15:48] yes, in that order [15:49] jcsackett, I think you reported a bug that the comment hiding ui is intrusive. maybe you can find a way to make only appear when it is needed [15:52] Laney: got the mail :) [15:53] czajkowski: Good! So, seems like mail from non-subscribers doesn't work so well === salgado is now known as salgado-lunch === al-maisan is now known as almaisan-away === nhandler is now known as StaffUnicorn === frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugs: 3.47*10^2 === salgado-lunch is now known as salgado === matsubara is now known as matsubara-afk [17:13] Hmm, buildbot failed again on the same test [17:14] cjwatson: oh? is that failure a repeat? [17:14] Yeah [17:19] If it's a regression, it's somewhere in -r15495..15502 [17:21] Which is staging replication stuff, bzr API modernisation, my copy_packages DB security fix, your "Add new address" form, my removal of the "single custom upload" hack, and another buildbot fix [17:25] OK, it's not quite the same, the previous failure was 13 tests later in the same class [17:26] No, make that one test earlier [17:29] All the previous google hits I can find for this seem to be related to bzrlib [17:29] But those weren't leaking storm postgres connections [17:52] abentley: if you get a chance can you peek at the JS branches I've got in the queue? [17:52] rick_h_: sure. [17:52] abentley: ty much [17:58] czajkowski: for some reason these pics made me think of you. desktop material? :-P http://kottke.org/12/06/birds-with-arms [18:10] rick_h_: "That's the bulk of the LoC diff as it moves the tests under the tests. object."? [18:16] abentley: ah, because it's tests.suite vs just suite. [18:17] abentley: so it made sense when I wrote it :) [18:17] rick_h_: I get ya. [18:22] rick_h_: I assume the rest of the changes are mechanical, so r=me. Oh, and the copyright statement doesn't need a comma after the year. [18:23] abentley: ok cool [18:28] rick_h_: Both of your LoC rationales require a waiver from flacoste or lifeless. Do you have one? [18:28] rick_h_: I mean, for https://code.launchpad.net/~rharding/launchpad/bug_yui35_one/+merge/112399 [18:29] abentley: no, I can bring it up. Or work on the other branches that should remove lines and get me the 15 I need [18:30] actually, hold off abentley. Once the branch working through buildbot lands I'll be able to use this new module to reduce lines and get this down to neutral. [18:30] rick_h_: landing lp:~rharding/launchpad/lpnames_yui35 would give you sufficient LoC credit. [18:30] I'll just make the update onto that [18:31] abentley: ah ok cool yea. Actually I should write these out. I've got a series of small ups and downs as I move through these files [18:33] rick_h_: The copyright date on test_buglisting_utils.js should be 2011-2012. [18:34] abentley: ah ok, thuught I'd seen them just get replaced [18:34] rick_h_: No, the copyright date for unmodified code need to be retained. [18:35] abentley: makes sense, will udpate [18:35] err update [18:37] rick_h_: r=me with those changes [18:37] abentley: ty much [19:50] lifeless, registry.upcoming_work_view.enabled team:linaro [19:51] ^ that is the UI for the feature [19:59] flacoste: ^ that too (thanks for catching that sinzui !) [20:06] jcsackett: love the pics! [20:06] czajkowski: thought you might. :-P [20:07] jcsackett: have you see this weeks dekstop :) [20:07] i have not. must have missed the tweet. [20:09] jcsackett: https://plus.google.com/photos/102921374554385564572/albums/5730819334465556225/5757878649532660674 [20:09] that is an unhappy bird. [20:10] jcsackett: it's a monday desktop :) [20:11] mondays do tend to provoke that reaction. [20:12] indeed [20:12] jcsackett: it's been a fun thing to do on a monday though, leads to some very odd reactions [20:13] really? i wouldn't think people would respond too oddly. === StaffUnicorn is now known as nhandler [20:14] yeah G+ people get rather vocal, twitter folks have fun and interact back [20:17] abentley: about bug #1018477, it may be the forking-service interfering with things. [20:17] <_mup_> Bug #1018477: repeatedly opening bzr+ssh connections to LP instances hangs < https://launchpad.net/bugs/1018477 > [20:18] which would be really useful in debugging why it wasn't successful deploying it to production, as I haven't seen that failure before. [20:18] czajkowski: huh. g+ seems to largely be filled with passive observers from my side. [20:18] of course, as a passive observer, my viewpoint might be slightly skewed. [20:18] jam: Oh, we're not using forking-service in production, but are using it on qa-staging? [20:19] abentley: everywhere but production, AIUI [20:19] jcsackett: ah I do try and interact a bit on there, very useful for photography which I'm trying to learn more about [20:20] jam: It seems plausible. Do I recall correctly there's a way of running codehosting locally without the forking service? [20:20] abentley: you could try just flipping the config switch [20:20] use_forking_server IIRC [20:23] * sinzui bangs head on desk [20:24] abentley: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/configs/development/launchpad-lazr.conf#L50 [20:24] use_forking_daemon: False there [20:24] * czajkowski passes the bottle of wine to sinzui [20:24] jam: Yes, I found it, and setting it False fixes the bug. [20:24] As much as I want to add bug tag completion to advanced bug search, this is hard to do because of the very old bug that that hand craft page is invalid because of duplicate ids [20:25] sinzui: ugh, dupe ids ftl [20:25] abentley: sorry to have caused the problem, but thank you for giving some insight into why it was failing in production. [20:25] sinzui: and can't add in a spare css class to hook into easy enough? [20:26] rick_h_, I think I can make a tighter selector based on several attrs [20:26] ugh, hate attrs even more but whatever works I guess [20:26] jam: I suspect this should be treated as two bugs: 1. bzr fails to terminate ssh, 2. launchpad does something wrong when using forking daemon. [20:26] I know back in the day I was doing load testing, and wasn't seeing this, but if you can reproduce it reliably, I must have been doing something different. [20:27] jam: yes, it's been consistent. [20:27] jam: I'll bet you were using possible_transports. [20:27] it is possible that the 1-process thing is important. I think I was load testing with N workers [20:27] abentley: no, I think I just was doing 1 connection per process [20:28] jam: That would do it too. I was able to work around the problem by forking before branching. [20:28] for n in `seq 100`; do bzr info $branch &; done [20:28] jam: s/branching/opening the branch/ [20:41] abentley: how do you create a real branch to test this? or are you just using a non-existant branch? [20:42] (name16 doesn't seem to have a password, and I can't create a user via the test-openid provider) [20:42] jam: I'm using a non-existant branch. [20:42] jam: I typically push branches up as ~mark, which is specifically configured in my .ssh/config. [20:43] jam: I believe there's a script to create new users. [20:43] jam: I don't think password authentication is supported. It should be possible to add an ssh key for name16. [20:43] abentley: right, I should poke at that. In the mean-time, your script passes for me... :( [20:44] even bumping it up to 10 [20:44] though it pauses for a bit at 3 [20:45] jam: What platform? [20:45] abentley: Precise running in a VM [20:45] um [20:45] When did bug titles get a max length of 66 characters? [20:46] jam: I'm on Precise on bare metal (BM?) [20:46] I can see if I can reproduce on bare metal, but yeah so far no love. [20:46] weird. nvm. refreshing fixed it [20:46] abentley: more than one cpu? [20:46] (may or may not matter) [20:46] jam: 4 cores, pretending to be 8. [20:47]