[03:53] lifeless: O hai? [03:57] hai [03:57] lifeless: I've been refactoring auditor [03:58] lifeless: python setup.py test is very unhappy, and I've been trying to work out WTF for a bit [04:00] lifeless: http://pastebin.ubuntu.com/1156558/ is a snippet, all 11 tests are very similiarly unhappy [04:04] Well, that's ... handy [04:04] Heh [04:08] what is ROOT_URLCONF set to in settings? [04:10] mwhudson: '' [04:10] that would seem to explain the error message... [04:11] Hmm [04:11] mwhudson: That would indeed be it, thanks! [04:12] (Read as, down to 7 errors) [04:13] bah, NM fail. [04:13] StevenK: you were saying [04:21] lifeless: Since your internet is pure fail and you dropped off, mwhudson helped me. [04:22] NM decided to associate to a random wifi point in the middle of nowhere [04:23] StevenK: cool. What was wrong? [04:24] lifeless: http://pastebin.ubuntu.com/1156576/ is what you missed. [04:27] kk [04:27] steven@undermined:~/auditor% bzr di | diffstat -s [04:27] 11 files changed, 90 insertions(+), 200 deletions(-) [04:31] cool [04:32] lifeless: Do you want to eyeball the diff? [04:32] Were there any surprises ? [04:33] Only the ROOT_URLCONF gotcha in runtests that tripped me up. [04:34] lifeless: http://pastebin.ubuntu.com/1156585/ just in case you have any suggestions [04:45] StevenK: A copyright nod to where runtests came from might be nice. [04:52] StevenK: A copyright nod to where runtests came from might be nice. [05:09] lifeless: What was your plan with auditorfixture? [05:10] give it the django project (on the child side of the process boundary) [05:10] 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] how was the fixture ensuring it had auditor before ? [05:13] lifeless: It was in test_requires, and the buildout-written bin/auditor-manage did stuff to import the module [05:13] so, same thing [05:13] more or less - handwaving furiously. [05:13] You could createa a django project on the fly if you wanted an alternative. [05:14] but the basic approach is going to be unchanged [05:17] 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] StevenK: I don't understand why you're talking about the egg [05:18] StevenK: you didn't copy it around before, why would you now? [05:18] lifeless: Because the django project needs to import it? [05:19] StevenK: you'll have your own manage.py in fixture, thats django project stuff, you don't need manage in auditor.... [05:19] StevenK: how is that connected to copying it around ? [05:20] lifeless: I thought django would want it in the same layout [05:20] no, thats the point of apps, they just get located via import once they are listed in INSTALLED_APPS [05:21] lifeless: So you were envisioning manage.py and settings.py in auditorfixture base directory? [05:21] yes [05:22] or something like that [05:22] given all the variou scruft you'll be dealing with. manage.py might be something buildout writes for you, for instance. [05:23] I was going to generate a django project and copy the two bits in [05:23] Munging as I go [05:23] sure, that sounds fine too [05:23] I don't have an exact blueprint for you ;) [05:24] 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. === lifeless_ is now known as lifeless === adeuring changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 4.0*10^2 === almaisan-away is now known as al-maisan [09:48] 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] 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] If you could let me know when you could look at it with me, that would be great. [09:49] jtv: ^^ in case you were involved as well. [09:50] jam: this time I mostly wasn't, which is actually great news! [09:50] jtv: yeah, very good to hear. [09:51] jam, sure, we can do it now, if you want. [09:53] dpm: so I left off around step 5 (jtv and I validated that the translation copy looked sane.) [09:53] (would you rather do this on mumble/g+ ?) === jelmer_ is now known as jelmer === jelmer is now known as Guest57842 [09:59] 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] np [10:12] 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] (There's an attempt at a performance analysis in the linked bug) [10:19] jam, sorry for the delay, ready to start a hangout now [10:22] dpm: https://plus.google.com/hangouts/_/fc76b32f50b23d671cf435628e74f3e79e11d871?authuser=2&hl=en# [10:24] cjwatson: commented === al-maisan is now known as almaisan-away [10:35] stub: thanks - yeah, a feature flag might make sense, I shall ponder that [10:46] morning [10:56] Er, hi, anyone here? [10:56] that question always asks for the response "no" [10:57] mgz: Sorry [10:57] ... [10:58] I'm not succeeding at building the launchpad development community [10:58] Well then [11:09] Bug 1036597: would it seem reasonable to put UEFI signing keys for PPAs in /uefi// (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 < https://launchpad.net/bugs/1036597 > [11:10] 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. === Guest57842 is now known as jelmer === benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: benji | Firefighting: - | Critical bugs: 4.0*10^2 === almaisan-away is now known as al-maisan [13:00] Morning, all [13:01] deryck: morning === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [13:47] 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] abentley: heh ok. Hadn't gotten that when walking through. [13:48] thanks for the heads up [13:49] rick_h_: np [14:34] jelmer: did you get a chance to upload py2.6 to ~canonical-bzr/py27 ? [14:40] jam: working on that atm === al-maisan is now known as almaisan-away [14:41] why ~canonical-bzr? [14:42] mgz: what would you suggest? [14:43] ~pythoneers [14:44] or whatever launchpad group cares about packaging [14:44] mgz: I would like to force a rebuild of everything, so a new ppa is easier [14:44] mgz: I'd like to leave ~pythoneers, it's adding to my daily spam [14:44] you can unsubscribe, no? [14:45] but this is a temporary measure so I guess it doesn't really matter, a throwaway ppa would be fine [14:45] mgz: no, ~pythoneers has a bunch of structural subscriptions [14:46] I can mute mail from individual bugs, which isn't particularly helpful [14:47] ah, yeay for launchpad email. I just stick it all in a tag I don't look at... [14:51] benji, hi there. I have a branch for review. [14:51] jelmer: You can mute team structsubs [14:51] eg. on https://bugs.launchpad.net/launchpad-project/+subscriptions [14:52] 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] deryck: congratulations! you are the one millionth customer! you recieve a lifetime supply of diffs [14:52] benji, heh. Long line today? [14:52] nope, just in a goofy mood ;) [14:52] benji, ah nice :) [14:53] benji, it's here: https://code.launchpad.net/~deryck/launchpad/reauth-gpg-363916/+merge/120401 [14:53] lol, I'll want to use that sometime. "lifetime supply of diffs" [14:58] wgrant: but that means muting it for everybody, doesn't it? [14:59] jelmer: I don't think so [14:59] jelmer: That would be pretty useless [14:59] Since the same could be achieved by removing the subscription [15:01] wgrant: hmm, but that means manually muting all 88 structural subscriptions of ~pythoneers manually? [15:03] 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] jelmer: Or convincing barry that team subscriptions are vile [15:05] 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] wgrant: or just leaving ~pythoneers, which I shouldn't really be in anyway :) [15:06] 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] 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] If that's the entire point of ~pythoneers, indeed [15:07] sinzui: thanks! [15:07] wgrant: well, it also contains some packaging ppas that we wanted to use for this ***** backporting of python2.7 to lucid thing [15:08] Heh [15:11] 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] I think there's a few more that get closed as well [15:12] wgrant: I am off next week. I expect you to pass my bug closings for disclosure. [15:12] sorry not pass but surpass [15:12] We'll see :) [15:13] You may need to hide from IS and not work on incidents like last week [15:13] I think the last significant issue is being resolved as we speak. [15:14] Basically I get to blame everything on firewalls and IS fixes it :) [15:33] jcsackett: are you available to discussing allowing commercial admins to help setup project sharing? === deryck is now known as deryck[lunch] [15:37] sinzui: sure. === salgado is now known as salgado-lunch === beuno is now known as beuno-lunch === matsubara is now known as matsubara-lunch === salgado-lunch is now known as salgado === beuno-lunch is now known as beuno [19:21] wgrant: why did you set bug #1032717 to "in progress"? [19:21] <_mup_> Bug #1032717: blueprint data model doesn't support private projects < https://launchpad.net/bugs/1032717 > [19:29] abentley: maybe because it is not the devel branch yet? [19:29] It can only be use on staging? [19:29] sinzui: I believe it's in devel. It landed in db-devel more than a week ago. [19:31] sinzui: landed in r15768, with wgrant as the reviewer. [19:32] I agree that I see it in devel. I think the bug is fix released [19:33] 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] indexes would indeed be separate. [19:37] 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] abentley: I would change the bug title to be about schema and mark it fixed release. [19:38] really [19:39] * sinzui is tempted to do it right now [19:42] 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] sinzui: Cool. [19:45] abentley: np. [19:46] 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] Rather than bug per landing. [19:46] 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] So I suspect he assumed you were doing the same, and was helping in that process. [19:47] (its fine to do it differently, just explaining what I see that would line up) [19:48] is anyone else seeing an issue where you go to edit your mails and you're made relogin again ? [19:48] lifeless: In the past, I've found that multiple-landings-per-bug confused qa-tagger, so I actively avoid doing that. [19:51] 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] (Perhaps because I picked up LP development processes somewhat osmotically.) [19:56] 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] 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] 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] sinzui: I'm agnostic, was only seeking to explain the behaviour. [20:21] welcome back deryck [20:21] rick_h_, thanks! very frustrating. it's like a once a week event here at the shop now. [20:22] what's the net at the new place? [20:22] gotta call ahead and get that fiber line run to the front door :P [20:25] rick_h_, it's cable. pretty stable for my friend who telecommutes in the same neighborhood. [20:25] 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] heh [20:27] never use providers DNS, lesson I learned back on comcast days [20:27] +1 [20:28] I now add my own to keep the house running [20:28] yea, I run one on an ec2 box and use google as a backup [20:29] 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] sinzui: it is :P === benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 4.0*10^2 [21:40] wgrant: https://dev.launchpad.net/Contributions ;-) [22:14] cjwatson: Heh, well done [22:49] 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> < https://launchpad.net/bugs/900431 > [22:52] sinzui: It's not truly fixed [23:33] steven@undermined:~/launchpad/lp-branches/destroy-security-contact% bzr di | diffstat -s [23:33] 14 files changed, 10 insertions(+), 713 deletions(-) [23:33] Bloody hell, and I'm not done yet. [23:59] wgrant: Something must be wrong. You're at -502 and I'm at -1280