[00:12] <cjwatson> https://dogfood.launchpad.net/ubuntu/precise/+source/cjwatson-pcj-testing/1.1 - qualified exclamation of glorious victory
[00:12] <cjwatson> The Builds link goes to the private archive - do we think that's a problem?
[00:14] <cjwatson> I think it's unrestricted the actual .debs though
[00:15] <cjwatson> Let's see what publishing that does
[00:28] <wgrant> cjwatson: That's normal.
[00:29] <wgrant> Indeed, it looks good.
[00:29] <cjwatson> Ah, that BPB is in fact public because BPB permissions are odd.
[00:31] <wgrant> Right, BPB.private === all(spph.archive.private for spph in bpb.spr.spphs)
[00:32] <cjwatson> So that's all good.
[04:42] <StevenK> wallyworld, wgrant: https://code.launchpad.net/~stevenk/launchpad/destroy-old-privacy-ui/+merge/112002
[04:43] <wallyworld> lots of LOC credit there
[04:44] <StevenK> It only hits -488
[04:44] <StevenK> Bug{Visibility,Security}Change are probably only worth another -20
[04:44] <StevenK> Er, -200
[04:49] <wallyworld> StevenK: field_names on BugSecrecyEditView doesn't need to be a property anymore
[04:52] <wallyworld> same with schema i think
[04:53] <StevenK> schema has to remain a property
[04:53] <StevenK> I think you're right, field_names = ['information_type'] should be fine
[04:54] <wallyworld> why does scheme need to be a property? lots of other places don't do it that way
[04:54] <wallyworld> it was only a property because of the logic involved
[04:55] <wallyworld> with the feature flag afaiui
[04:55] <StevenK> wallyworld: It needs to protect the class defined in it to not get eval'd too early.
[04:55] <StevenK> wallyworld: Keep in mind InformationTypeVocabulary() still has two feature flags that get read on initialize.
[04:56] <wallyworld> ah, ok. thanks
[04:56] <wallyworld> StevenK: these lines:
[04:56] <wallyworld> 159	- if not self.request.is_ajax:
[04:56] <wallyworld> 160	- return canonical_url(self.context)
[04:56] <wallyworld> 161	- return None
[04:56] <wallyworld> 162	+ return canonical_url(self.context)
[04:56] <wallyworld> i don't think they need to (or can be) changed
[04:57] <StevenK> We no longer do a AJAX call
[04:57] <wallyworld> really? ok
[04:57] <wallyworld> i guess we do a patch then?
[04:58] <wallyworld> it must be an xhr call of some sort though
[04:58] <StevenK> wallyworld: Sure, which is done in the JS
[04:58] <StevenK> Doesn't involve the form or its next_url in any way
[04:59] <wallyworld> you sure? many other places in the js do a post and reuse the same form at the backend
[04:59] <wallyworld> so the ajax check is required
[04:59] <StevenK> wallyworld: Yes. The JS uses ChoiceSource
[04:59] <wallyworld> and this was originally written to work that way
[05:00] <wallyworld> ok, so the choicesource widget must call lp_client.patch then i assume
[05:01] <wallyworld> which does a named_post
[05:01] <StevenK> Yes, which uses the *API*, not the form machinery.
[05:02] <wallyworld> yes
[05:05] <wallyworld> StevenK: so if the api is used, transitionToInformationType() returns True. the old ajax call returned the direct subscribers so the subscription portlet could be updated since changing info type also can mess with subscribers. how do we handle that now?
[05:06] <StevenK> wallyworld: We don't, currently. But I'm not sure we care since changing the information_type isn't going to mess subscribers soon.
[05:07] <wallyworld> StevenK: you sure? there's a card jc is looking at which will
[05:07] <wallyworld> bug 1014922
[05:08] <StevenK> wallyworld: The reason it updates subscibers is due to visibility, and the rule that subscription confers visibility is going away, so ...
[05:08] <wallyworld> StevenK: but you are not allowed to be subscribed to bugs you can't see
[05:08] <wallyworld> so if a bug is made private, some people don't be able to see the bug anymore, hence will be unsubscribed
[05:09] <wallyworld> plus making a bug private may add subscribers in defined roles
[05:09] <wgrant> No
[05:09] <wgrant> Well, only the person who is performing the action
[05:09] <wgrant> It won't add others.
[05:09] <wallyworld> defined roles definition may change sure
[05:10] <wallyworld> atm it adds bug supervisor or pillar owner etc
[05:10] <wallyworld> but the point is, the subscribers list changes and we seem to have a regression
[05:10] <wallyworld> in not updating the ui after a info type change
[05:10] <wallyworld> since before the ui change, it all worked as expected
[05:15] <wallyworld> StevenK: i think we can delete this entire block of code?
[05:15] <wallyworld> 371	- if (not bool(getFeatureFlag(
[05:15] <wallyworld> 372	- 'disclosure.show_information_type_in_ui.enabled')) and
[05:15] <wallyworld> 373	- extra_data.private):
[05:15] <wallyworld> 374	- if params.information_type == InformationType.PUBLIC:
[05:15] <wallyworld> 375	+ if extra_data.private:
[05:15] <wallyworld> 376	+ if params.information_type in PUBLIC_INFORMATION_TYPES:
[05:16] <StevenK> Nope, it's used, I think.
[05:16] <StevenK> There were one or two tests that depended on the behaviour at least.
[05:18] <wallyworld> StevenK: but won' the initial if condition in the original code always be false with the ff turned on? so the code will never be evaluated
[05:18] <StevenK> wallyworld: I can't recall the reason I added the guard there.
[05:18] <StevenK> It clearly shouldn't be.
[05:19] <StevenK> I think I had the guard when that function was expecting private/security_related to flow through the whole thing
[05:19] <wallyworld> perhaps with ff turned on extra_data.private is replaced by extra_data.information_type
[05:19] <StevenK> wallyworld: Sadly not
[05:21] <StevenK> extra_data.information_type should probably be added.
[05:24] <wallyworld> yes
[05:25] <wallyworld> StevenK: what text is printed out in place of this?
[05:25] <wallyworld> 843	- >>> print admin_browser.contents
[05:25] <wallyworld> 844	- <!DOCTYPE...
[05:25] <wallyworld> 845	- ...This is a private bug...Foo Bar...won&rsquo;t be notified...
[05:25] <wallyworld> do we need to fix the test so it checks?
[05:25] <StevenK> That is looking for a notification that is no longer printed.
[05:25] <wallyworld> ok
[05:26] <StevenK> wallyworld: That test sucked to debug. The notification isn't in the contents so the doctest prints out the 400 lines of contents
[05:27] <wallyworld> yeah, i hate that too
[05:29] <wallyworld> StevenK: in this case though, can't we check for the new info type text?
[05:29] <wallyworld> 985	- ... "This bug report should be private").selected = False
[05:30] <StevenK> wallyworld: Ah, we're setting it back so we don't fuck up the next test in the doctest, no longer needed.
[05:30] <wallyworld> of course, silly me
[05:37] <wallyworld> StevenK: r=me with a comment to raise a bug for the regression
[05:40] <StevenK> wallyworld: Right, okay. But that bug might end up being marked as Invalid :-)
[05:41] <wallyworld> what am i missing?
[05:41] <wallyworld> the subscribers list can change, no?
[05:41] <wallyworld> at the very least, the person marking the bug private will be subscribed
[05:41] <wallyworld> so the subscribers list will need updating
[05:42] <StevenK> wallyworld: Oh, your second comment is related to extra_data.private -- there's a test around for that -- I'll ignore that bit for now, and mention to Curtis if it is actually used at all
[05:42] <wallyworld> ok
[05:42] <wallyworld> the second one was more of a request just to see what might be needed
[05:46] <StevenK> wallyworld: https://bugs.launchpad.net/launchpad/+bug/1017818
[05:46] <_mup_> Bug #1017818: subscriber list does not update after changing information type <disclosure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1017818 >
[05:46] <StevenK> Oh sure, *now* _mup_ answers.
[05:46] <wallyworld> StevenK: thanks. i hope i'm not missing something stupid asking for that bug to be raised
[05:47] <StevenK> wallyworld: Well, as you say, the person doing the action may end up subscribed
[05:47] <wallyworld> and *possibly* others removed
[05:47] <wallyworld> as per jc's card
[05:48] <StevenK> Right
[05:48] <StevenK> Stuff might happen, as it were.
[05:48] <wallyworld> StevenK: so we may need to undelete the code that constructs the json data struct :-)
[05:49] <StevenK> Ew
[05:49] <StevenK> It will probably have to be in JS, rather than in the form
[05:49] <wallyworld> well, ideally we wouldn't make a 2nd xhr call
[05:49] <wallyworld> so the call to update the info type would return the data needed to update the ui
[05:50] <StevenK> Maybe.
[05:50] <wallyworld> or at least update the request cache
[05:50] <StevenK> That sounds okay
[05:50] <wallyworld> which would also eliminate a 2nd call
[05:50] <wallyworld> whatever works :-)
[05:51] <StevenK> wallyworld: This branch has been through ec2 twice, but since it's so large I'm going to toss it for a third run.
[05:51] <wallyworld> good idea :-)
[07:22] <jelmer> 'morning
[07:38] <jelmer> jam!
[07:38] <jam> jelmer: !
[07:38] <jam> cjwatson: you're on the blame list for buildbot failing. http://lpbuildbot.canonical.com/builders/lucid_lp/builds/2182
[07:38] <jam> It looks unrelated (celery failure,  I believe)
[07:43] <cjwatson> Yeah, no way that's related to my change.  -ops suggested it's already been forced
[07:47] <jelmer> gmb: https://code.launchpad.net/~jelmer/launchpad/no-revhistory-1/+merge/112018
[07:48] <adeuring> good morning
[07:54] <StevenK> cjwatson: Yes, twice, in fact.
=== almaisan-away is now known as al-maisan
=== gmb changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: gmb (sprinting, so YMMV) | Firefighting: - | Critical bugs: 3.47*10^2
[09:26] <jelmer> gmb: http://paste.ubuntu.com/1060456/
[09:28] <gmb> jelmer, https://lists.launchpad.net/yellow/msg00938.html
[09:29] <jelmer> gmb: gracias
[10:04] <wgrant> adeuring: That patch should land on devel if it's been applied live.
[10:04] <wgrant> adeuring: Not db-devel
[10:04] <wgrant> adeuring: That is a live patch, so it's probably been applied live already or should be soon.
[10:04] <adeuring> wgrant: no, flacoste asked me to back it out.
[10:05] <adeuring> wgrant: and since the bug is really old, it does not matter if the brach is merged a few days sooner or later ;)
[10:06] <wgrant> adeuring: I saw, but I think he misunderstood.
[10:06] <wgrant> https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess
[10:06] <wgrant> "For hot patches the target is lp:launchpad, but for cold patches it should be lp:launchpad/db-devel. "
[10:06] <wgrant> And that looks like a hot patch
[10:06] <wgrant> stub: Has the ftq patch been applied anywhere yet?
[10:07] <stub> wgrant: no, not that I'm aware of
[10:07] <stub> IIRC it is a hot patch, no need for downtime
[10:07] <adeuring> wgrant: yes, you're right -- but I'll simply merge the branch now into db-devel ;)
[10:07] <wgrant> Right, => devel
[10:07] <wgrant> adeuring: No!
[10:07] <wgrant> db-devel is for cold patches
[10:07] <adeuring> why?
[10:07] <stub> I don't care where it lands but I'm not the shephard
[10:08] <wgrant> If you merge it into db-devel, all it means is I have to merge db-stable into devel an extra time tomorrow
[10:08] <wgrant> It achieves nothing other than delays :)
[10:08] <wgrant> db-devel is the downtime queue
[10:08] <wgrant> This doesn't need downtime, so it does not belong on db-devel.
[10:08] <adeuring> wgrant: so just wait until a merge is necessary anyway ;)
[10:09] <wgrant> Simplest solution is to ask stub to apply it now and then land to devel in 5 minutes when it's applied everywhere :)
[10:10] <stub> point me at the patch/mp
[10:10] <adeuring> stub: https://code.launchpad.net/~adeuring/launchpad/bug-29713/+merge/111212
[10:11] <adeuring> tjhough that one is meanwhile reverted
[10:11] <adeuring> stub: https://code.launchpad.net/~adeuring/launchpad/bug-29713-db-dev/+merge/112043
[10:17] <stub> adeuring:  I'll apply the db patch in https://code.launchpad.net/~adeuring/launchpad/bug-29713-db-dev/+merge/112043 now.
[10:17] <adeuring> stub: great, thanks!
[10:20] <stub> Gah. Whitespace munging, cut & paste, urgh
[10:25] <stub> adeuring: done
[10:25] <adeuring> stub: thanks
[10:28] <adeuring> stub: you ran the patch on qastaging, right?
[10:28] <stub> adeuring: No, just production
[10:28] <stub> I'll do qastaging now
[10:28] <adeuring> stub: ok
[10:30] <stub> Done on qastaging
=== matsubara is now known as matsubara-lunch
=== rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: gmb (sprinting, so YMMV), rick_h | Firefighting: - | Critical bugs: 3.47*10^2
=== al-maisan is now known as almaisan-away
=== matsubara-lunch is now known as matsubara
[12:39] <cjwatson> wgrant: https://code.launchpad.net/~cjwatson/launchpad/remove-single-custom-upload-exception/+merge/112093
[12:42] <wgrant> cjwatson: Thanks
=== benji___ is now known as benji
[13:05] <ivory> rick_h_: abel said you could maybe help me with a problem in html (if you got time for it)?
[13:05] <rick_h_> ivory: sure thing
[13:06] <ivory> rick_h_: http://bazaar.launchpad.net/~ivo-kracht/launchpad/bug-806660/revision/15436
[13:06] <ivory> rick_h_: i created a seperate form but the "Add" button is offset and i dont know why
[13:07] <ivory> rick_h_: oh this is the bug i amworking on https://bugs.launchpad.net/launchpad/+bug/806660
[13:07] <_mup_> Bug #806660: "Add a new address" in e-mail settings does the wrong thing when pressing Enter <easy> <ui> <Launchpad itself:In Progress by ivo-kracht> < https://launchpad.net/bugs/806660 >
[13:07] <rick_h_> loading
[13:08] <rick_h_> ivory: so the add button is offset in the initial html? You're wanting to get rid of that offset?
[13:10] <ivory> rick_h_: no the new one is offset to the right and i want it to be like theold one was
[13:12] <rick_h_> ivory: so what I would do is colspace the <td> and then using padding-left to get it where you want it.
[13:12] <rick_h_> ivory: now that it's not connected to the rules of the other form, it won't really line up automatically and it's splitting the width 50/50 usually by default
[13:12] <rick_h_> the wide content of the second <td> in the upper form was pushing the button over for you
[13:13] <rick_h_> honestly, they should probably be defined in some way so that it's consistant. So with a common width set for that first <td> on both forms
[13:13] <ivory> ah ok i just wondered why it did that, thank you for helping
[13:14] <rick_h_> np
[13:34] <sinzui> rick_h_, Do you agree with my assessment...should this bug be marked wontfix? https://bugs.launchpad.net/launchpad/+bug/383943
[13:35] <rick_h_> loading
[13:37] <rick_h_> sinzui: right, it's the API
[13:37] <rick_h_> sinzui: I mean we could, via getter/setter ATTRS try to mirror things for easier API usage
[13:37] <rick_h_> but seems like more work than it's worth
[13:47] <Laney> can I haz database patch number for bug #1016776 please?
[13:47] <_mup_> Bug #1016776: Users are offered updates to packages in the -proposed staging area pre-release <feature> <launchpad> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1016776 >
[13:48] <cjwatson> Argh, I hate DB security
[13:52] <rick_h_> cjwatson: so ummm, I assume this branch is part of stuff you've been working with the ppa pros on?
[13:52] <rick_h_> cjwatson: so you need this to land by wed in production? or the prev code is scheduled to be tested there then?
[13:53] <cjwatson> rick_h_: Which one, sorry?
[13:54] <rick_h_> cjwatson: sorry, the one in review with your deletions for the unembargo code
[13:54] <rick_h_> https://code.launchpad.net/~cjwatson/launchpad/remove-unembargo-package/+merge/112044
[13:54] <cjwatson> rick_h_: No, I was noting an intent not to land it until after I've made sure that the ubuntu-security team can use the new code that should hopefully be deployed tomorrow
[13:55] <cjwatson> There's no rush on remove-unembargo-package; was just getting it in for review early, that's all
[13:55] <rick_h_> ok, so I'll make a comment that review will pend the test
[13:55] <cjwatson> Right, that's what I thought I'd written in my cover letter :-)
[13:55] <cjwatson> Well, there's no harm reviewing it earlier
[13:55] <rick_h_> right, well you said you won't land it, but as the reviewer I'll punt it until after entirely if that doesn't block you at all
[13:55] <cjwatson> But sure
[13:55] <rick_h_> it's not exactly my wheel house, but I don't want to hold you up if you needed this
[13:55] <cjwatson> Not at all, was just getting stuff off my disk
[13:56] <rick_h_> ok, cool
[13:56] <rick_h_> Laney: let me pull that down and get you an id
[13:57] <cjwatson> What is a bit more urgent is my r15491, which I've just marked qa-bad; should I revert that?  I think it's just a security.cfg patch to fix it, but I do need to figure out a test
[13:58] <rick_h_> cjwatson: hmm, so I don't think there will be a deploy by us today. So if you can get the fix in I'd go for the fix
[13:59] <rick_h_> if it'll be tomorrow or tonight (when the aussies get going) I'd revert it out
[13:59] <cjwatson> Should be soon - couple of phone calls coming up but let's see what I can do
[14:00] <rick_h_> cjwatson: ok, sounds like a plan
[14:02] <rick_h_> sinzui: with that nth child, it's just grabbing the submit button right? I wonder if it could just be changed to grab based on name/etc? Or am I misreading that
[14:03] <sinzui> rick_h_, yes, name would also work in this case.
[14:03] <rick_h_> ah, they don't have names so that they're not submitted I'd imagine
[14:05] <sinzui> oh, right <button>
[14:05] <rick_h_> but they have classes I think he could use, so commenting.
[14:05] <rick_h_> thanks for bringing that up
[14:05] <sinzui> I really need to fix the button css so that it looks more like a platform button
[14:13] <Laney> rick_h_: thanks
[14:14] <jelmer> gmb: https://code.launchpad.net/~jelmer/launchpad/no-revhistory-2/+merge/112119
[14:17] <jcsackett> sinzui: free to chat a bit?
[14:18] <sinzui> yes
[14:18] <jcsackett> cool.
[14:22] <jcsackett> sinzui: i've started a hangout.
[14:29] <rick_h_> Laney: ok, claimed 2209-25-1 for you
[14:30] <Laney> excellent, ty
[14:31] <jelmer> gmb: https://code.launchpad.net/~jelmer/launchpad/no-revhistory-3/+merge/112123
[14:31] <cjwatson> rick_h_: https://code.launchpad.net/~cjwatson/launchpad/copy-custom-uploads-fix/+merge/112122 fixes that regression
[14:32] <rick_h_> cjwatson: looking now
=== cr3_ is now known as cr3
[14:35] <rick_h_> cjwatson: ok, r=me
[14:37] <cjwatson> Thanks
[14:37] <cjwatson> I'll get that landed then
[14:38] <cjwatson> And hopefully re-QA that tonight
[14:42] <ivory> rick_h_: could you review this? https://code.launchpad.net/~ivo-kracht/launchpad/bug-806660/+merge/112125
[14:42] <rick_h_> sure thing ivory
[14:42] <ivory> rick_h_: thank you
[14:42] <sinzui> jcsackett, http://pastebin.ubuntu.com/1060851/
[14:52] <rick_h_> ivory: r=me
[14:53] <rick_h_> flacoste: so part of this yui gallery bit is signing their CLA. Should I just sign as an individual, or can I sign this as "Canonical" the organization?
[14:54] <flacoste> do they have a formal process for organization?
[14:54] <flacoste> i don't think it's possible
[14:54] <rick_h_> it's the same form, just with the org filled in and my title added
[14:54] <flacoste> for example, for the Canonical CLA, only individuals can sign them
[14:54] <rick_h_> but there is a checkbox to choose so I wanted to make sure I was going this the right way
[14:54] <rick_h_> https://secure.echosign.com/public/hostedForm?formid=A9PFU5T58653A
[14:55] <rick_h_> ok, I can do individual without worry if that's cool and easier to do
[14:55] <flacoste> yep
[14:56] <flacoste> i think that's the best move forward
[14:56] <rick_h_> ok, thanks
[15:15] <Laney> Just noticed checkmarkable on the dev wiki. I can't use it (forbidden). Should I be able to? :-)
[15:52] <cody-somerville> Why is it taking so long for PPAs to publish built binaries these days?
[15:53] <czajkowski> sinzui: what is the difference of the tag hardening and say privacy ?
[15:54] <sinzui> hardening was a phase of work where we wanted to control *who* has permission. privacy is largely about *what* is and is shown as private
[15:54] <sinzui> hardening is a feature tag.
[16:01] <czajkowski> sinzui: ah ok, thank you
=== matsubara is now known as matsubara-afk
[16:17] <mgz> gmb: https://code.launchpad.net/~gz/launchpad/py27_test_scriptmonitor_logging_1017981/+merge/112160
[16:23] <gmb> mgz: https://dev.launchpad.net/EC2Test
=== deryck is now known as deryck[lunch]
[16:24]  * czajkowski waves at gmb 
[16:25] <czajkowski> gmb: working without you is rather quiet
[16:25] <czajkowski> :s
[16:25]  * gmb waves at czajkowski 
[16:25] <gmb> Haha.
[16:25] <gmb> Eh, well, I'll be in the office for an afternoon Thursday fortnight, if that's any help.
[16:25] <czajkowski> yarp can be indeed
[16:25] <czajkowski> going in Friday this week as there is after work drinks
=== beuno_ is now known as beuno
[17:25] <czajkowski> maxb: cjwatson may know
=== deryck[lunch] is now known as deryck
[18:02] <rick_h_> gmb: can you review this please? https://code.launchpad.net/~rharding/launchpad/yui35_test/+merge/111911
[18:02] <rick_h_> gmb: if the sprint has you busy I'll bug deryck next :)
[18:02] <czajkowski> rick_h_: I think he's EOD he's sprinting
[18:03] <rick_h_> czajkowski: yea, why I ping'd. Didn't update topic/is still in irc, but expecting to bug deryck in a sec
[18:03] <deryck> rick_h_, I can do a review here shortly.  About to do call with abentley
[18:03] <rick_h_> deryck: rgr, no rush. Thank you
=== czajkowski changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: rick_h | Firefighting: - | Critical bugs: 3.47*10^2
[18:22] <cjwatson> czajkowski: hmm?
[18:42] <lifeless> sinzui: have we had any more user confusion about 'contact this user' since the last round of tweaks ?
[18:50] <sinzui> lifeless, The only remark on irc and bugs that I have seen was from our own abentley regarding mass team admin emails.
[18:51] <sinzui> lifeless, I think this is a team hierarchy issue.
[18:51] <sinzui> maas team, not mass team
[18:54] <lifeless> cool
[18:54] <lifeless> sounds like we might have put the monster to rest
[19:29] <maxb> cjwatson: I was wondering on #launchpad if there was a way to ask LP for which Ubuntu series it currently accepted PPA uploads
[19:29] <maxb> czajkowski moved the conversation here thinking you more likely to be around here :-)
[19:31] <abentley> lifeless: Are you aware of any issues with codehosting that prevent opening more than 4 branches in rapid succession?  I see it on qastaging and launchpad.dev, but not production.
[19:33] <maxb> Although.... something seems to have changed in that department, since LP just accepted an upload for edgy (and then failed to build it, of course)
[19:38] <cjwatson> I believe (from the code) that PPAs allow you to upload to any suite that exists, probably because of PES.
[19:38] <cjwatson> edgy is a bit weird; edgy-* exist on ftpmaster.internal but not edgy itself
[19:38] <cjwatson> You can certainly upload to anything currently supported or in-development by Ubuntu.  Anything else is probably best regarded as at-risk.
[19:39] <cjwatson> (But I'm not really a PPA guru, this is just my impression)
[19:41] <cjwatson> As it happens at the moment I rather suspect dapper + feisty-quantal should work provided that the distroarchseries has a working chroot_url; but we've been talking about clearing some of those dists subdirectories off ftpmaster at some point, which will break that.
[19:53] <lifeless> abentley: bzr+ssh ?
[19:53] <lifeless> abentley: or sftp, or $unknown ?
[19:54] <lifeless> abentley: I'm not aware of any intrinsic limits, no. are the opens serialised, or do you have 4 clients concurrently hitting it ?
[19:54] <abentley> lifeless: bzr+ssh and probably sftp
[19:54] <abentley> lifeless: Serialized.
[19:55] <abentley> lifeless: https://pastebin.canonical.com/68914/
[19:56] <lifeless> abentley: whats the failure you get ?
[19:57] <abentley> lifeless: No explicit failure.  It hangs after "bzr+ssh://bazaar.qastaging.launchpad.net/+branch-id/8633".
[19:59] <abentley> lifeless: When I run it locally, it works.  But on devpad, it fails.
[19:59] <abentley> i.e. hangs.
[20:00] <lifeless> do you have ssh master connection use on ?
[20:00] <lifeless> lsof / netstat / strace may help you determine what it is hanging on
[20:01] <lifeless> abentley: if you drop into pdb (ctrl-\ IIRC), what is bzr trying to do ?
[20:01] <abentley> lifeless: No, I don't have ssh master connection use on.
[20:02] <abentley> lifeless: This is a script, so ctrl-\ doesn't drop to pdb.
[20:03] <lifeless> abentley: import bzrlib.breakin; bzrlib.breakin.hook_debugger_to_signal()
[20:03] <lifeless> abentley: should enable that
[20:06] <abentley> lifeless: Thanks.  Backtrace: http://pastebin.ubuntu.com/1061439/
[20:08] <lifeless> its waiting for ssh to exit
[20:08] <lifeless> hmm
[20:09] <cjwatson> wgrant,StevenK: Dear NDT cabal: I've QAed my follow-up fix to bug 231371 (rick_h advised that I could land that rather than reverting as long as I was quick enough that it'd be in devel by the time you folks woke up).  QA notes in the bug.  I haven't marked it qa-ok yet because (a) it's not on qastaging and (b) there are several revisions between the bad one and the fix, so I guess you need to be aware not to deploy ...
[20:09] <_mup_> Bug #231371: support dist-upgrader-all pocket copy <feature> <lp-soyuz> <qa-bad> <soyuz-publish> <Launchpad itself:Fix Committed by cjwatson> < https://launchpad.net/bugs/231371 >
[20:09] <cjwatson> ... r15491 without r15499.
[20:10] <cjwatson> It'd be nice if at least up to r15489 could be deployed tomorrow, since I have a window with the security team tomorrow to production-test r15486.
[20:17] <lifeless> abentley: sorry am OTP will ping you soon
[20:37] <lifeless> abentley: so, ssh isn't exiting
[20:38] <lifeless> abentley: we've seen this before I think; one common case is master connections, but also..
[20:38] <abentley> lifeless: The function assumes that closing stdin/stdout will terminate ssh.
[20:39] <abentley> lifeless: in recent versions of bzr, a socket is used.
[20:40] <lifeless> abentley: I'd poke around with lsof on the ssh process its waiting for
[20:40] <lifeless> abentley: see what it thinks is up
[20:44] <abentley> lifeless: It still has a tcp connection: "TCP localhost.localdomain:44533->launchpad.dev:5022 (ESTABLISHED)", and two sockets.
[20:46] <abentley> lifeless: http://pastebin.ubuntu.com/1061512/
[21:06] <bac> hi james_w, did you get my email request regarding your tarmac scripts?  if not, i'd really like to have a look if you have time to sanitize and send them.
[21:06] <james_w> bac, I did
[21:06] <james_w> bac, I
[21:06] <james_w> 'll sanitise now
[21:07] <bac> james_w: thanks a lot!
[21:17] <timrc> Any idea how I get a list of persons subscribed to a private PPA via the api (akin to +subscriptions in the web ui)?
[21:19] <timrc> I'm seeing https://launchpad.net/+apidoc/devel.html#archive_subscriber, but not sure how to access it
=== salgado is now known as salgado-afk
[21:39] <james_w> bac, lp:~james-w/+junk/tarmac-puppet
[21:40] <bac> got it james_w, thanks
[21:58] <wgrant> jelmer: Have you tested that this Branch.revision_history excision attempt will be less catastrophic than the previous one?
[21:58] <wgrant> cjwatson: Ergh, OK
[21:59] <jelmer> wgrant: Yes - it's also less ambitious
[21:59] <jelmer> wgrant: this one doesn't try to improve performance in any way, it just copes with the fact that bzr has deprecated these two functions but keeps O() the same
[22:00] <jelmer> wgrant: in other words, it won't help with bug 808930
[22:00] <_mup_> Bug #808930: Timeout running branch scanner job <escalated> <linaro> <oops> <Launchpad itself:In Progress by abentley> < https://launchpad.net/bugs/808930 >
[22:06] <wgrant> jelmer: Right, sounds good. Thanks.
[22:11] <jelmer> I do want to improve that bit some time, but not now :)
[22:16] <sinzui> wgrant, https://dev.launchpad.net/Projects/Disclosure
[22:34] <sinzui> StevenK,  https://dev.launchpad.net/Projects/Disclosure
[22:37] <cjwatson> timrc: Right now, I don't think you can.  ArchiveSubscriber only seems to be exported as the return type of Archive.newSubscriber.
[22:37] <cjwatson> *newSubscription
[22:38] <timrc> cjwatson, :/
[23:17] <rick_h_> huwshimi: heads up, got permission to submit the morph module to the YUI Gallery so submitted that today.
[23:17] <huwshimi> rick_h_: Awesome! Nice work :)
[23:18] <rick_h_> huwshimi: I hear you wrote most of it, I've got a branch of it here: https://github.com/mitechie/yui3-gallery/tree/add_morph/src/gallery-anim-morph
[23:18] <rick_h_> updated to all YUI specs and all that jazz. So if we go to reuse it in the future (once this gets approved/merged) it'll be considered the upstream to sync up with.
[23:19] <huwshimi> rick_h_: Nice one :)
[23:19] <huwshimi> rick_h_: I'll have to make sure we replace it in MAAS too.
[23:19] <rick_h_> yea, hopefully going to work on getting more generic stuff up into the gallery
[23:20] <rick_h_> and try to keep apps sync'd using hte gallery versions of things
[23:20] <rick_h_> huwshimi: yea, at some point we can look at that. This adds an API chance we needed for the other project and some more tests, docs, etc.