| StevenK | lifeless: O hai? | 03:53 |
|---|---|---|
| lifeless | hai | 03:57 |
| StevenK | lifeless: I've been refactoring auditor | 03:57 |
| StevenK | lifeless: python setup.py test is very unhappy, and I've been trying to work out WTF for a bit | 03:58 |
| StevenK | lifeless: http://pastebin.ubuntu.com/1156558/ is a snippet, all 11 tests are very similiarly unhappy | 04:00 |
| StevenK | Well, that's ... handy | 04:04 |
| wgrant | Heh | 04:04 |
| mwhudson | what is ROOT_URLCONF set to in settings? | 04:08 |
| StevenK | mwhudson: '' | 04:10 |
| mwhudson | that would seem to explain the error message... | 04:10 |
| StevenK | Hmm | 04:11 |
| StevenK | mwhudson: That would indeed be it, thanks! | 04:11 |
| StevenK | (Read as, down to 7 errors) | 04:12 |
| lifeless | bah, NM fail. | 04:13 |
| lifeless | StevenK: you were saying | 04:13 |
| StevenK | lifeless: Since your internet is pure fail and you dropped off, mwhudson helped me. | 04:21 |
| lifeless | NM decided to associate to a random wifi point in the middle of nowhere | 04:22 |
| lifeless | StevenK: cool. What was wrong? | 04:23 |
| StevenK | lifeless: http://pastebin.ubuntu.com/1156576/ is what you missed. | 04:24 |
| lifeless | kk | 04:27 |
| StevenK | steven@undermined:~/auditor% bzr di | diffstat -s | 04:27 |
| StevenK | 11 files changed, 90 insertions(+), 200 deletions(-) | 04:27 |
| lifeless | cool | 04:31 |
| StevenK | lifeless: Do you want to eyeball the diff? | 04:32 |
| lifeless | Were there any surprises ? | 04:32 |
| StevenK | Only the ROOT_URLCONF gotcha in runtests that tripped me up. | 04:33 |
| StevenK | lifeless: http://pastebin.ubuntu.com/1156585/ just in case you have any suggestions | 04:34 |
| lifeless | StevenK: A copyright nod to where runtests came from might be nice. | 04:45 |
| lifeless | StevenK: A copyright nod to where runtests came from might be nice. | 04:52 |
| StevenK | lifeless: What was your plan with auditorfixture? | 05:09 |
| 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:10 |
| lifeless | how was the fixture ensuring it had auditor before ? | 05:12 |
| 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:13 |
| lifeless | but the basic approach is going to be unchanged | 05:14 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| StevenK | lifeless: So you were envisioning manage.py and settings.py in auditorfixture base directory? | 05:21 |
| lifeless | yes | 05:21 |
| 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:22 |
| 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:23 |
| 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. | 05:24 |
| === 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 | ||
| 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:48 |
| 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:49 |
| jtv | jam: this time I mostly wasn't, which is actually great news! | 09:50 |
| jam | jtv: yeah, very good to hear. | 09:50 |
| dpm | jam, sure, we can do it now, if you want. | 09:51 |
| 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:53 |
| === jelmer_ is now known as jelmer | ||
| === jelmer is now known as Guest57842 | ||
| 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 | 09:59 |
| 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:12 |
| dpm | jam, sorry for the delay, ready to start a hangout now | 10:19 |
| jam | dpm: https://plus.google.com/hangouts/_/fc76b32f50b23d671cf435628e74f3e79e11d871?authuser=2&hl=en# | 10:22 |
| stub | cjwatson: commented | 10:24 |
| === al-maisan is now known as almaisan-away | ||
| cjwatson | stub: thanks - yeah, a feature flag might make sense, I shall ponder that | 10:35 |
| rick_h_ | morning | 10:46 |
| smartboyhw | Er, hi, anyone here? | 10:56 |
| mgz | that question always asks for the response "no" | 10:56 |
| smartboyhw | mgz: Sorry | 10:57 |
| cjwatson | ... | 10:57 |
| mgz | I'm not succeeding at building the launchpad development community | 10:58 |
| wgrant | Well then | 10:58 |
| 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:09 |
| 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. | 11:10 |
| === 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 | ||
| deryck | Morning, all | 13:00 |
| czajkowski | deryck: morning | 13:01 |
| === al-maisan is now known as almaisan-away | ||
| === almaisan-away is now known as al-maisan | ||
| 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:47 |
| rick_h_ | abentley: heh ok. Hadn't gotten that when walking through. | 13:48 |
| rick_h_ | thanks for the heads up | 13:48 |
| abentley | rick_h_: np | 13:49 |
| jam | jelmer: did you get a chance to upload py2.6 to ~canonical-bzr/py27 ? | 14:34 |
| jelmer | jam: working on that atm | 14:40 |
| === al-maisan is now known as almaisan-away | ||
| mgz | why ~canonical-bzr? | 14:41 |
| jelmer | mgz: what would you suggest? | 14:42 |
| mgz | ~pythoneers | 14:43 |
| 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:44 |
| 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:45 |
| jelmer | I can mute mail from individual bugs, which isn't particularly helpful | 14:46 |
| mgz | ah, yeay for launchpad email. I just stick it all in a tag I don't look at... | 14:47 |
| 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:51 |
| 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:52 |
| 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:53 |
| jelmer | wgrant: but that means muting it for everybody, doesn't it? | 14:58 |
| 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 | 14:59 |
| jelmer | wgrant: hmm, but that means manually muting all 88 structural subscriptions of ~pythoneers manually? | 15:01 |
| 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:03 |
| wgrant | jelmer: Or convincing barry that team subscriptions are vile | 15:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| wgrant | Heh | 15:08 |
| 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:11 |
| 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:12 |
| 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:13 |
| wgrant | Basically I get to blame everything on firewalls and IS fixes it :) | 15:14 |
| sinzui | jcsackett: are you available to discussing allowing commercial admins to help setup project sharing? | 15:33 |
| === deryck is now known as deryck[lunch] | ||
| jcsackett | sinzui: sure. | 15:37 |
| === 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 | ||
| 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:21 |
| 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:29 |
| abentley | sinzui: landed in r15768, with wgrant as the reviewer. | 19:31 |
| sinzui | I agree that I see it in devel. I think the bug is fix released | 19:32 |
| 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:33 |
| sinzui | indexes would indeed be separate. | 19:34 |
| 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:37 |
| sinzui | abentley: I would change the bug title to be about schema and mark it fixed release. | 19:38 |
| sinzui | really | 19:38 |
| * sinzui is tempted to do it right now | 19:39 | |
| 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:42 |
| abentley | sinzui: Cool. | 19:45 |
| sinzui | abentley: np. | 19:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:51 |
| 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:56 |
| 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) | 19:57 |
| 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:07 |
| 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:21 |
| 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:22 |
| 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:25 |
| deryck | heh | 20:26 |
| rick_h_ | never use providers DNS, lesson I learned back on comcast days | 20:27 |
| sinzui | +1 | 20:27 |
| 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:28 |
| 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:29 |
| lifeless | sinzui: it is :P | 20:59 |
| === benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 4.0*10^2 | ||
| cjwatson | wgrant: https://dev.launchpad.net/Contributions ;-) | 21:40 |
| wgrant | cjwatson: Heh, well done | 22:14 |
| 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:49 |
| wgrant | sinzui: It's not truly fixed | 22:52 |
| 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:33 |
| StevenK | wgrant: Something must be wrong. You're at -502 and I'm at -1280 | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!