[03:53] <StevenK> lifeless: O hai?
[03:57] <lifeless> hai
[03:57] <StevenK> lifeless: I've been refactoring auditor
[03:58] <StevenK> lifeless: python setup.py test is very unhappy, and I've been trying to work out WTF for a bit
[04:00] <StevenK> lifeless: http://pastebin.ubuntu.com/1156558/ is a snippet, all 11 tests are very similiarly unhappy
[04:04] <StevenK> Well, that's ... handy
[04:04] <wgrant> Heh
[04:08] <mwhudson> what is ROOT_URLCONF set to in settings?
[04:10] <StevenK> mwhudson: ''
[04:10] <mwhudson> that would seem to explain the error message...
[04:11] <StevenK> Hmm
[04:11] <StevenK> mwhudson: That would indeed be it, thanks!
[04:12] <StevenK> (Read as, down to 7 errors)
[04:13] <lifeless> bah, NM fail.
[04:13] <lifeless> StevenK: you were saying
[04:21] <StevenK> lifeless: Since your internet is pure fail and you dropped off, mwhudson helped me.
[04:22] <lifeless> NM decided to associate to a random wifi point in the middle of nowhere
[04:23] <lifeless> StevenK: cool. What was wrong?
[04:24] <StevenK> lifeless: http://pastebin.ubuntu.com/1156576/ is what you missed.
[04:27] <lifeless> kk
[04:27] <StevenK> steven@undermined:~/auditor% bzr di | diffstat -s
[04:27] <StevenK>  11 files changed, 90 insertions(+), 200 deletions(-)
[04:31] <lifeless> cool
[04:32] <StevenK> lifeless: Do you want to eyeball the diff?
[04:32] <lifeless> Were there any surprises ?
[04:33] <StevenK> Only the ROOT_URLCONF gotcha in runtests that tripped me up.
[04:34] <StevenK> lifeless: http://pastebin.ubuntu.com/1156585/ just in case you have any suggestions
[04:45] <lifeless> StevenK: A copyright nod to where runtests came from might be nice.
[04:52] <lifeless> StevenK: A copyright nod to where runtests came from might be nice.
[05:09] <StevenK> lifeless: What was your plan with auditorfixture?
[05:10] <lifeless> give it the django project (on the child side of the process boundary)
[05:10] <StevenK> lifeless: As in, I should embed an emptyish django project into auditorfixture? How do I then have buildout slap the egg into it?
[05:12] <lifeless> how was the fixture ensuring it had auditor before ?
[05:13] <StevenK> lifeless: It was in test_requires, and the buildout-written bin/auditor-manage did stuff to import the module
[05:13] <lifeless> so, same thing
[05:13] <lifeless> more or less - handwaving furiously.
[05:13] <lifeless> You could createa a django project on the fly if you wanted an alternative.
[05:14] <lifeless> but the basic approach is going to be unchanged
[05:17] <StevenK> lifeless: So I embed the effectively four files for a django project into the fixture and convince buildout to copy the unpacked auditor egg into it, and then call ../auditor-proj/manage.py runserver
[05:18] <lifeless> StevenK: I don't understand why you're talking about the egg
[05:18] <lifeless> StevenK: you didn't copy it around before, why would you now?
[05:18] <StevenK> lifeless: Because the django project needs to import it?
[05:19] <lifeless> StevenK: you'll have your own manage.py in fixture, thats django project stuff, you don't need manage in auditor....
[05:19] <lifeless> StevenK: how is that connected to copying it around ?
[05:20] <StevenK> lifeless: I thought django would want it in the same layout
[05:20] <lifeless> no, thats the point of apps, they just get located via import once they are listed in INSTALLED_APPS
[05:21] <StevenK> lifeless: So you were envisioning manage.py and settings.py in auditorfixture base directory?
[05:21] <lifeless> yes
[05:22] <lifeless> or something like that
[05:22] <lifeless> given all the variou scruft you'll be dealing with. manage.py might be something buildout writes for you, for instance.
[05:23] <StevenK> I was going to generate a django project and copy the two bits in
[05:23] <StevenK> Munging as I go
[05:23] <lifeless> sure, that sounds fine too
[05:23] <lifeless> I don't have an exact blueprint for you ;)
[05:24] <lifeless> the key bits were to get rid of the project level stuff from auditor, make a dedicate version of just the project stuff for staging and production deployments, and similar for the fixture.
[09:48] <jam> dpm: I saw that you fully opened the translations queue for Quantal. I'd like to go through the checklist here: https://wiki.canonical.com/Launchpad/Translations/UbuntuOpenings
[09:49] <jam> just to make sure everything got finished, or if we need to update the checklist for any changes (so the person doing it for R will have a clear checklist)
[09:49] <jam> If you could let me know when you could look at it with me, that would be great.
[09:49] <jam> jtv: ^^ in case you were involved as well.
[09:50] <jtv> jam: this time I mostly wasn't, which is actually great news!
[09:50] <jam> jtv: yeah, very good to hear.
[09:51] <dpm> jam, sure, we can do it now, if you want.
[09:53] <jam> dpm: so I left off around step 5 (jtv and I validated that the translation copy looked sane.)
[09:53] <jam> (would you rather do this on mumble/g+ ?)
[09:59] <dpm> jam, sure, g+ is fine? Give me 5 mins to have a quick look at the document and then we can jump into a call
[09:59] <jam> np
[10:12] <cjwatson> stub: Brad suggested that I should get you to look over https://code.launchpad.net/~cjwatson/launchpad/queue-filter-source/+merge/119225 for possible improvements
[10:12] <cjwatson> (There's an attempt at a performance analysis in the linked bug)
[10:19] <dpm> jam, sorry for the delay, ready to start a hangout now
[10:22] <jam> dpm: https://plus.google.com/hangouts/_/fc76b32f50b23d671cf435628e74f3e79e11d871?authuser=2&hl=en#
[10:24] <stub> cjwatson: commented
[10:35] <cjwatson> stub: thanks - yeah, a feature flag might make sense, I shall ponder that
[10:46] <rick_h_> morning
[10:56] <smartboyhw> Er, hi, anyone here?
[10:56] <mgz> that question always asks for the response "no"
[10:57] <smartboyhw> mgz: Sorry
[10:57] <cjwatson> ...
[10:58] <mgz> I'm not succeeding at building the launchpad development community
[10:58] <wgrant> Well then
[11:09] <cjwatson> Bug 1036597: would it seem reasonable to put UEFI signing keys for PPAs in <signing_keys_root>/uefi/<archive.owner.name>/<archive.name> (and get ops to generate them on a case-by-case basis - there should only be a handful of PPAs that ever care)?  That doesn't clash with anything else currently in signing_keys_root, and it's nicely outside the published PPA tree.
[11:09] <_mup_> Bug #1036597: No UEFI signing configuration for PPAs <uefi> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1036597 >
[11:10] <cjwatson> It does mean that any future horizontal scaling of the PPA publisher would have to keep those keys in sync, but that would have to keep signing_keys_root in sync anyway.
[13:00] <deryck> Morning, all
[13:01] <czajkowski> deryck: morning
[13:47] <abentley> rick_h_: On http://people.canonical.com/~rharding/app/project_home.html I get "The requested URL /api/devel/privatemockup was not found on this server."
[13:48] <rick_h_> abentley: heh ok. Hadn't gotten that when walking through.
[13:48] <rick_h_> thanks for the heads up
[13:49] <abentley> rick_h_: np
[14:34] <jam> jelmer: did you get a chance to upload py2.6 to ~canonical-bzr/py27 ?
[14:40] <jelmer> jam: working on that atm
[14:41] <mgz> why ~canonical-bzr?
[14:42] <jelmer> mgz: what would you suggest?
[14:43] <mgz> ~pythoneers
[14:44] <mgz> or whatever launchpad group cares about packaging
[14:44] <jelmer> mgz: I would like to force a rebuild of everything, so a new ppa is easier
[14:44] <jelmer> mgz: I'd like to leave ~pythoneers, it's adding to my daily spam
[14:44] <mgz> you can unsubscribe, no?
[14:45] <mgz> but this is a temporary measure so I guess it doesn't really matter, a throwaway ppa would be fine
[14:45] <jelmer> mgz: no, ~pythoneers has a bunch of structural subscriptions
[14:46] <jelmer> I can mute mail from individual bugs, which isn't particularly helpful
[14:47] <mgz> ah, yeay for launchpad email. I just stick it all in a tag I don't look at...
[14:51] <deryck> benji, hi there.  I have a branch for review.
[14:51] <wgrant> jelmer: You can mute team structsubs
[14:51] <wgrant> eg. on https://bugs.launchpad.net/launchpad-project/+subscriptions
[14:52] <wgrant> As long as the team doesn't have a contact address set (since in that case the email is sent before you're even considered)
[14:52] <benji> deryck: congratulations! you are the one millionth customer! you recieve a lifetime supply of diffs
[14:52] <deryck> benji, heh.  Long line today?
[14:52] <benji> nope, just in a goofy mood ;)
[14:52] <deryck> benji, ah nice :)
[14:53] <deryck> benji, it's here: https://code.launchpad.net/~deryck/launchpad/reauth-gpg-363916/+merge/120401
[14:53] <rick_h_> lol, I'll want to use that sometime. "lifetime supply of diffs"
[14:58] <jelmer> wgrant: but that means muting it for everybody, doesn't it?
[14:59] <wgrant> jelmer: I don't think so
[14:59] <wgrant> jelmer: That would be pretty useless
[14:59] <wgrant> Since the same could be achieved by removing the subscription
[15:01] <jelmer> wgrant: hmm, but that means manually muting all 88 structural subscriptions of ~pythoneers manually?
[15:03] <sinzui> flacoste: We will start the sharing beta within 24 hours. We are waiting for a important branch to land, qa, be for all out important branches to be released...
[15:04] <wgrant> jelmer: Or convincing barry that team subscriptions are vile
[15:05] <sinzui> flacoste: ...~launchpad's projects can take immediate advantage of the beta some of us are both members of ~launchpad and ~commercial-admins. We can invite other to participate in the beta a few days later when my work to change permissions allows project maintainers to configure projects using UI and API.
[15:05] <jelmer> wgrant: or just leaving ~pythoneers, which I shouldn't really be in anyway :)
[15:06] <jelmer> wgrant: I can see how team subscriptions make some sense in this case - you wouldn't want all ~pythoneers members to individually track the set of packages relevant for that team
[15:06] <sinzui> flacoste: I have a draft API script for OEM. They can reconfigure their projects after my permission changes are in place. I image they can participate in the beta with a day of receiving the script.
[15:06] <wgrant> If that's the entire point of ~pythoneers, indeed
[15:07] <flacoste> sinzui: thanks!
[15:07] <mgz> wgrant: well, it also contains some packaging ppas that we wanted to use for this ***** backporting of python2.7 to lucid thing
[15:08] <wgrant> Heh
[15:11] <sinzui> flacoste: once we enter beta, wgrant will close 10 bugs. I hope to see a drop in the predicted days to complete sharing
[15:11] <wgrant> I think there's a few more that get closed as well
[15:12] <sinzui> wgrant: I am off next week. I expect you to pass my bug closings for disclosure.
[15:12] <sinzui> sorry not pass but surpass
[15:12] <wgrant> We'll see :)
[15:13] <sinzui> You may need to hide from IS and not work on incidents like last week
[15:13] <wgrant> I think the last significant issue is being resolved as we speak.
[15:14] <wgrant> Basically I get to blame everything on firewalls and IS fixes it :)
[15:33] <sinzui> jcsackett: are you available to discussing allowing commercial admins to help setup project sharing?
[15:37] <jcsackett> sinzui: sure.
[19:21] <abentley> wgrant: why did you set bug #1032717 to "in progress"?
[19:21] <_mup_> Bug #1032717: blueprint data model doesn't support private projects <qa-ok> <Launchpad itself:In Progress by abentley> < https://launchpad.net/bugs/1032717 >
[19:29] <sinzui> abentley: maybe because it is not the devel branch yet?
[19:29] <sinzui> It can only be use on staging?
[19:29] <abentley> sinzui: I believe it's in devel.  It landed in db-devel more than a week ago.
[19:31] <abentley> sinzui: landed in r15768, with wgrant as the reviewer.
[19:32] <sinzui> I agree that I see it in devel. I think the bug is fix released
[19:33] <abentley> sinzui: I tend to agree.  I wondered whether wgrant was referring to the lack of an index, but that needs to be a separate bug.
[19:34] <sinzui> indexes would indeed be separate.
[19:37] <sinzui> abentley: maybe wgrant is thinking model as in code. Your branch provided schema. lp.blueprints.interfaces.specifications.py does not know about InformationType
[19:38] <sinzui> abentley: I would change the bug title to be about schema and mark it fixed release.
[19:38] <sinzui> really
[19:39]  * sinzui is tempted to do it right now
[19:42] <sinzui> abentley: I have revised the bug to make it clear it is about the schema, and since that change is in production, it is fix released.
[19:45] <abentley> sinzui: Cool.
[19:45] <sinzui> abentley: np.
[19:46] <lifeless> abentley: sinzui: there is an idiom wgrant has been using where successive landings for the same bug are used to add schema, tune, and then deliver the thing.
[19:46] <lifeless> Rather than bug per landing.
[19:46] <lifeless> This is a useful idiom because it makes it clear you can't land more than one branch at a time when you're doing the schema-code-schema-code etc dance.
[19:47] <lifeless> So I suspect he assumed you were doing the same, and was helping in that process.
[19:47] <lifeless> (its fine to do it differently, just explaining what I see that would line up)
[19:48] <czajkowski> is anyone else seeing an issue where you go to edit your mails and you're made relogin again ?
[19:48] <abentley> lifeless: In the past, I've found that multiple-landings-per-bug confused qa-tagger, so I actively avoid doing that.
[19:51] <cjwatson> I do it a fair bit, but you do have to careful to serialise things (and that isn't always appropriate), or else deal with a bit of QA confusion.
[19:51] <cjwatson> (Perhaps because I picked up LP development processes somewhat osmotically.)
[19:56] <sinzui> lifeless: I don't like that idiom. I will not QA someone else's bug if it has more than one branch associated because I cannot tell what the nuances of QA are. Aaron's branch adds value (specifically infrastructure for more than one developer to extend)
[19:57] <sinzui> Someone could land an index on the db in one branch, while I land a interface and model change that makes the feature work over API. (4 hours work for 2 independent developers)
[20:07] <lifeless> abentley: it should be fine unless you have >1 branch undeployed-but-landed at any time. Which you shouldn't with the db change sequence.
[20:07] <lifeless> sinzui: I'm agnostic, was only seeking to explain the behaviour.
[20:21] <rick_h_> welcome back deryck
[20:21] <deryck> rick_h_, thanks!  very frustrating.  it's like a once a week event here at the shop now.
[20:22] <rick_h_> what's the net at the new place?
[20:22] <rick_h_> gotta call ahead and get that fiber line run to the front door :P
[20:25] <deryck> rick_h_, it's cable.  pretty stable for my friend who telecommutes in the same neighborhood.
[20:25] <sinzui> Fiber is only as good at the vendor's own desire to keep a net work up. I loose DNS several times a week because Verizon sucks marginally less than Cox Cable (which name is a homonym for what I really think of them)
[20:26] <deryck> heh
[20:27] <rick_h_> never use providers DNS, lesson I learned back on comcast days
[20:27] <sinzui> +1
[20:28] <sinzui> I now add my own to keep the house running
[20:28] <rick_h_> yea, I run one on an ec2 box and use google as a backup
[20:29] <sinzui> I have yet to find a solution for U1 backups that incite Verizon to block my house. I suspect they think U1 is a warz site.
[20:59] <lifeless> sinzui: it is :P
[21:40] <cjwatson> wgrant: https://dev.launchpad.net/Contributions ;-)
[22:14] <wgrant> cjwatson: Heh, well done
[22:49] <sinzui> wgrant: Do we want to say this bug is closed when beta starts? This instance looks fixed by sharing, though the technical issue could still happen from untrusted users: https://bugs.launchpad.net/launchpad/+bug/900431
[22:49] <_mup_> Bug #900431: branch visibility queries do not consider visibility of stacked on branches <403> <branches> <disclosure> <privacy> <sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/900431 >
[22:52] <wgrant> sinzui: It's not truly fixed
[23:33] <StevenK> steven@undermined:~/launchpad/lp-branches/destroy-security-contact% bzr di | diffstat -s
[23:33] <StevenK>  14 files changed, 10 insertions(+), 713 deletions(-)
[23:33] <StevenK> Bloody hell, and I'm not done yet.
[23:59] <StevenK> wgrant: Something must be wrong. You're at -502 and I'm at -1280