| leonardr | lifeless: here's the entire run: http://pastebin.ubuntu.com/498063/ | 00:40 |
|---|---|---|
| lifeless | leonardr: uhm, its normally a .gz file for good reason ;) | 00:43 |
| lifeless | leonardr: consider email in future? | 00:43 |
| * leonardr hates email, but ok | 00:43 | |
| lifeless | 42000 line pastebins make me sad | 00:44 |
| lifeless | leonardr: ah, is that why you're never on the lp-dev list ? ) | 00:44 |
| lifeless | leonardr: line 26213 of that pastebin | 00:45 |
| lifeless | jml's testfix issue | 00:45 |
| lifeless | AttributeError: 'NoneType' object has no attribute 'specific_job' | 00:45 |
| lifeless | leonardr: you can find this easily by 'gunzip -c log | subunit-filter | subunit2pyunit' | 00:45 |
| leonardr | lifeless: i see, it's an "error" not a "failure" | 00:45 |
| lifeless | leonardr: (or testr load) | 00:46 |
| leonardr | lifeless: for the record, you're right about email for such a long doc, the pastebin is a pain | 00:46 |
| leonardr | i hadn't actually used it | 00:46 |
| lifeless | I'm frankly impressed and a little terrified that it accepted it. | 00:47 |
| leonardr | lifeless: jml's testfix issue == the one he's trying to address with buildd-deferred-fo-sho? | 00:49 |
| lifeless | I guess | 00:49 |
| lifeless | anyhow, not your branch, not my patch :) | 00:49 |
| leonardr | lifeless: does that actually give me the option to land my branch, or is the line stopped? | 00:50 |
| lifeless | leonardr: was that the only error in the output? | 00:51 |
| lifeless | leonardr: if so, I'd land your branch, because we know that that error was from a different very unrelated patch | 00:51 |
| leonardr | lifeless: i've got two identical-looking windmill errors as well | 00:52 |
| leonardr | error: lp.registry.windmill.tests.test_add_bugtracker.TestAddBugTracker.test_adding_bugtracker_for_project [ multipart | 00:52 |
| leonardr | Content-Type: text/plain;charset=utf8 | 00:52 |
| leonardr | garbage | 00:52 |
| leonardr | 35 | 00:52 |
| leonardr | [<Thread(Thread-275, started daemon 47553913698064)>]0 | 00:52 |
| leonardr | ] | 00:53 |
| leonardr | well, i guess pastebin would have been good for *that* | 00:53 |
| lifeless | leonardr: I don't know enough to comment about them | 00:53 |
| leonardr | lifeless: ok, i'll wait until tomorrow | 00:53 |
| lifeless | leonardr: 5 lines isn't worth pastebin. personally I pastebin above ~10 lines and below thousands. | 00:53 |
| mars | leonardr, should be ignored | 00:54 |
| mars | by the test framework | 00:54 |
| leonardr | mars: hey, you're still around | 00:54 |
| mars | leonardr, for maybe 5 minutes | 00:54 |
| leonardr | mars: ok, i'm going to land the branch without lifeless's branch merged, since his branch hasn't been reviewed | 00:54 |
| lifeless | leonardr: it will fail | 00:55 |
| mars | leonardr, sure. I was just commenting about the windmill errors. I actually fixed that specific bug a while ago (or thought I had) | 00:55 |
| lifeless | leonardr: do not land it, you'll break bb | 00:55 |
| leonardr | lifeless: ok, then i'll wait until your branch has been reviewed and landed, and then i'll land this branch | 00:55 |
| lifeless | it was reviewed | 00:55 |
| leonardr | lifeless: i see, the status wasn't changed | 00:56 |
| lifeless | leonardr: besides which, if you needed it reviewed, its a) tiny and b) you're allowed to do reviews too. | 00:56 |
| leonardr | lifeless: ok, i am in a position to land both your branch and my branch. will *that* break bb (because of the bug jml is trying to fix)? | 00:56 |
| lifeless | leonardr: no, because your branch + my branch + devel only failed on what jml is fixing. | 00:57 |
| lifeless | s/no/very low probability/ | 00:57 |
| leonardr | ok, i'm going to do that | 00:57 |
| wgrant | spm: Are you sure there's only one LP person? There may be another one with an email address matching one of the SSO accounts. | 01:57 |
| spm | wgrant: 4 emails. 3 in the old; 1 in the new. | 01:57 |
| wgrant | There's a known bug there. | 01:57 |
| wgrant | spm: And the primary addresses for both SSO accounts are associated to the one Person? | 01:58 |
| spm | the two openid's both are in the same LP account; so if there's a new account; not sure how to find it. | 01:58 |
| spm | are associated to the one Person <== to the one LP account, yes. | 01:58 |
| wgrant | The OpenID identifiers sadly don't matter -- they will follow whichever Person the email addreess is associated with. | 01:58 |
| wgrant | Hmm. | 01:59 |
| * poolie is back | 02:09 | |
| poolie | lifeless: do you want a hand with the flags stuff at all? | 02:09 |
| lifeless | poolie: that would be lovely | 02:10 |
| lifeless | poolie: if you do 'make run' and visit bugs.launchpad.dev/bugs/1 | 02:10 |
| _mup_ | Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:In Progress by sabdfl> < | 02:10 |
| poolie | ok, let me answer this roadmap mail then i'll see what i can make of it | 02:10 |
| poolie | snort | 02:10 |
| lifeless | poolie: then look at the source, you should see the memcache flag evaluated | 02:11 |
| lifeless | if you do ++oops++ on that and look at the oops, you can see memcache calls are made. | 02:11 |
| lifeless | poolie: setting the rule in the db as I put in the bug, the scope is found, the flag still evaluates to None, and memcache calls are still made. | 02:11 |
| lifeless | poolie: its likely shallow, but I've been elbow deep in this bugtask perf patch. | 02:11 |
| poolie | k | 02:12 |
| rockstar | ec2 keeps failing my branch on tests that aren't failing locally and look to have absolutely nothing to do with my changes. | 02:35 |
| rockstar | I'm half tempted to just send it to PQM and see if it breaks there. | 02:36 |
| lifeless | rockstar: details? | 02:44 |
| rockstar | lifeless, what details do you want? The actual tests that failed? | 02:44 |
| lifeless | yes | 02:45 |
| lifeless | wgrant: https://code.edge.launchpad.net/~rockstar/launchpad/build-farm-job-constraint/+merge/36219 | 02:45 |
| lifeless | wgrant: how does that fit in the with the build farm refactoring stuff | 02:45 |
| rockstar | lifeless, that part better not get refactored. It just got refactored. | 02:46 |
| rockstar | lifeless, here's one: lp.soyuz.tests.test_buildpackagejob.TestBuildPackageJobScore.test_score_unusual_component | 02:47 |
| lifeless | rockstar: heh, yes. but wgrant has stared closely at this stuff a lot ;) | 02:47 |
| lifeless | rockstar: was it a missing/None attribute error? | 02:47 |
| lifeless | rockstar: if so, jml is meant to have fixed it | 02:47 |
| rockstar | lifeless, uh, how was he meant to have fixed it? | 02:47 |
| lifeless | he had a branch | 02:48 |
| rockstar | lifeless, basically, abentley noticed when doing the refactoring the PackageBuild that the interface and the branch didn't agree. | 02:48 |
| lifeless | him and bigjools landed some brokenstuff | 02:48 |
| lifeless | rockstar: ECONTEXT: The test failure | 02:48 |
| rockstar | lifeless, oh, maybe, except for that it failed the same tests yesterday. | 02:48 |
| lifeless | rockstar: paste the error? | 02:48 |
| rockstar | lifeless, http://pastebin.ubuntu.com/498129/ | 02:49 |
| lifeless | yes, thats jml/bigjools and jml was landing a patch | 02:51 |
| lifeless | https://lpbuildbot.canonical.com/waterfall | 02:51 |
| lifeless | rockstar: rev 11589 looks like it should fix it | 02:52 |
| lifeless | rockstar: so if you ec2 land it should work now | 02:52 |
| wgrant | rockstar: When did it get refactored? | 03:07 |
| rockstar | wgrant, the PackageBuild stuff? July. | 03:08 |
| wgrant | rockstar: Oh, that's just the first part of the refactoring. | 03:08 |
| wgrant | That part is staying, but the table you just fixed is being removed. | 03:08 |
| wgrant | Now that Translations has done their bit. | 03:08 |
| rockstar | wgrant, *groan* | 03:08 |
| rockstar | wgrant, as long as someone BESIDES code takes care of it. | 03:08 |
| wgrant | I believe that is the plan. | 03:09 |
| rockstar | This moving target thing is really hard when you're trying to finish a feature. | 03:09 |
| wgrant | Well, this wouldn't have been a problem if it had been designed properly in the first place :) | 03:09 |
| wgrant | But it's nearly there now. | 03:09 |
| wgrant | We have all the necessary tables. | 03:09 |
| wgrant | So now we just have to move stuff off the old classes and delete their tables. | 03:10 |
| wgrant | In summary: BuildFarmJob, PackageBuild etc. are staying. | 03:11 |
| wgrant | BuildQueue, SourcePackageRecipeBuildJob, BuildPackageJob, TranslationTemplatesBuildJob are being destroyed. | 03:11 |
| jtv | wgrant: setting a contact email will break bug mail!? | 03:19 |
| wgrant | jtv: It will send bugmail to the list. | 03:21 |
| jtv | wgrant: you mean the contact address? | 03:22 |
| wgrant | jtv: that. | 03:22 |
| jtv | grrrr | 03:22 |
| jtv | what a wonderful situation we just got dumped in | 03:23 |
| wgrant | What forced the change? | 03:23 |
| wgrant | Didn't you previously use a celebrity? | 03:24 |
| jtv | The change was one we were entirely unaware of, so I'm only now learning the details. | 03:25 |
| jtv | Apparently bzr needs a user id for every committer. | 03:25 |
| jtv | And apparently those ids used to be made up somehow (I don't know the details). | 03:25 |
| jtv | It was decided somewhere that this was wrong, and so the Launchpad code had to pass an email address when committing. | 03:26 |
| wgrant | isn't the author still the celebrity, though? | 03:26 |
| wgrant | Why can't it be the committer for now too? | 03:26 |
| jtv | No. These commits default to the branch owner. | 03:27 |
| jtv | There's a bug in that change such that if the branch owner doesn't have a preferredemail, boom. | 03:27 |
| wgrant | Hm, I thought they were "Launchpad Code Hosting" or something like that. | 03:27 |
| jtv | We've been _wanting_ to make this commits in the name of a celebrity for a long time, just like you say. | 03:27 |
| wgrant | But it was like that when it was first implemented... | 03:27 |
| wgrant | I even filed a bug. | 03:27 |
| wgrant | Bug #407266 | 03:28 |
| _mup_ | Bug #407266: Translations branch committer needs a better email address <code-integration> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/407266> | 03:28 |
| jtv | Ahhh | 03:28 |
| jtv | wgrant: thanks, that's a missing piece of the puzzle. | 03:29 |
| jtv | We would have liked to have a proper, recognizable celebrity for this. | 03:29 |
| jtv | And this bug report must have been the reason we wanted that. | 03:29 |
| wgrant | The thing is, it was previously a celebrity. A bad one, but still a celebrity. | 03:29 |
| wgrant | I don't remember a commit when that changed. | 03:30 |
| jtv | But evidently the Code code moved in a different direction without our knowledge. | 03:30 |
| wgrant | Yeah, maybe. | 03:30 |
| wgrant | Oh. | 03:30 |
| wgrant | I bet that was the default whoami. | 03:30 |
| lifeless | yes | 03:30 |
| jtv | Yes. | 03:30 |
| lifeless | it was the default whoami; | 03:30 |
| jtv | We left it uninitialized. | 03:30 |
| jtv | Then apparently it got changed to default to branch.owner. | 03:30 |
| lifeless | I proposed using the same logic Code uses to do changes files for recipe builds. | 03:30 |
| wgrant | I didn't consider that the gecos would be something like that. | 03:30 |
| wgrant | So thought it must have been in the code somewhere. | 03:31 |
| wgrant | jtv: can't you refactor it so you can pass in an arbitrary name and email? | 03:31 |
| wgrant | And do the celebrity thing. | 03:31 |
| jtv | wgrant: arbitrary? I don't like arbitrary. | 03:32 |
| wgrant | Since that's more correct. | 03:32 |
| wgrant | And it will work. | 03:32 |
| jtv | There's no need to refactor—we can pass in a user identitiy. | 03:32 |
| wgrant | Without creating a real DB celebrity? | 03:32 |
| jtv | AFAIK there's no such thing as a "real DB celebrity." The celebrities exist as a collection of items in the python code. | 03:33 |
| jtv | The items themselves are regular user identities, teams, language objects, etc. etc. etc. | 03:34 |
| spiv | Oh nice, codebrowse OOPSes are viewable finally: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1713CB6 | 03:34 |
| wgrant | Right. | 03:34 |
| mwhudson | spiv: hurrah | 03:35 |
| thumper | mwhudson: hey | 03:36 |
| thumper | mwhudson: congrats on the house | 03:36 |
| thumper | mwhudson: my branch-distro change has been reviewed by gmb, but I was wondering if you could cast your eye over it too? | 03:36 |
| mwhudson | thumper: thanks | 03:37 |
| wgrant | Insurers defeated? | 03:37 |
| thumper | https://code.edge.launchpad.net/~thumper/launchpad/branch-distro-avoid-scan/+merge/36103 | 03:37 |
| mwhudson | thumper: i think it looked fine, i'll have another quick look | 03:37 |
| mwhudson | wgrant: yeah | 03:37 |
| thumper | mwhudson: thanks | 03:37 |
| wgrant | Well done. | 03:37 |
| thumper | mwhudson: also, how do we QA this? | 03:38 |
| thumper | mwhudson: should we copy a bucket load of branches to staging? | 03:38 |
| mwhudson | thumper: hmm, yes, i guess you can run a query to delete 90% of the seriesbranch links for maverick on staging | 03:40 |
| mwhudson | thumper: the branch looks fine | 03:40 |
| thumper | cool | 03:40 |
| thumper | thanks | 03:40 |
| mwhudson | thumper: then get the ids of the branches that are still official, get a losa to copy the those branches to staging (they have a script for this) | 03:40 |
| mwhudson | then run the script on staging | 03:41 |
| * thumper nods | 03:41 | |
| mwhudson | think that should work fine | 03:41 |
| jtv | wgrant: one thing is clear—if someone hadn't changed the default from a celebrity to branch.owner, then this other bug wouldn't have bit us. It's infuriating. A combination of changes that we were unaware of. | 03:50 |
| jtv | And there wasn't even a Code bug for this that I could find. | 03:51 |
| wgrant | jtv: It didn't really change from a celebrity. | 03:55 |
| wgrant | bzr started requiring explicit whoami. | 03:55 |
| wgrant | So Code started setting it, overriding the default. | 03:55 |
| wgrant | Which happened to look like a celebrity. | 03:55 |
| wgrant | (I'm afraid that I filed the bug which caused bzr to require whoami) | 03:56 |
| jtv | wgrant: well, a "special user"—which is pretty close to being a formal celebrity | 03:57 |
| wgrant | Bug #549310 | 03:58 |
| _mup_ | Bug #549310: bzr should not try to guess username but require setting it with whoami <easy> <Bazaar:Fix Released by parthm> <https://launchpad.net/bugs/549310> | 03:58 |
| jtv | Easy indeed. | 03:59 |
| wgrant | Heh. | 03:59 |
| jtv | wgrant: thanks for digging this stuff up—we're only at the receiving end of this and don't have much of a grasp of the work that went into making it broken. | 04:02 |
| jtv | So to speak. | 04:03 |
| wgrant | jtv: This is the problem with having a thoroughly partitioned team, I suppose. | 04:10 |
| jtv | wgrant: that's definitely part of it, but we're not supposed to be this thoroughly partitioned. | 04:10 |
| jtv | In this case, ironically, the bzr and code teams worked together to fix the problems but communication between launchpad teams broke down. | 04:11 |
| jtv | phone call | 04:11 |
| spiv | lifeless: I see in your latest performance mail you used "@" rather than "at". That's what I call dedication! | 04:13 |
| lifeless | spiv: hah, was a marathon dive. I was a tad tired. | 04:27 |
| poolie | hello jtv | 04:28 |
| jtv | hi poolie | 04:28 |
| poolie | jtv i'm so glad we got to hang out briefly in .nl, i feel like i know you much better | 04:28 |
| jtv | poolie: likewise | 04:28 |
| lifeless | poolie: did you have any luck with flags<->memcache? | 04:29 |
| poolie | haven't got to it yet sorry | 04:29 |
| poolie | should soon | 04:29 |
| lifeless | no worries | 04:32 |
| lifeless | interested not panicing | 04:32 |
| * thumper takes kids swimming | 04:40 | |
| thumper | will be around later | 04:41 |
| poolie | zarro mail! i'll look at memcached now | 04:55 |
| poolie | lifeless: was that in devel? or db-devel? | 04:58 |
| lifeless | devel | 04:58 |
| poolie | k | 04:59 |
| lifeless | or db-devel, either will do | 04:59 |
| lifeless | but I've been landing this stuff on devel | 04:59 |
| * poolie runs it up | 05:00 | |
| poolie | could someone please sponsor landing of https://code.edge.launchpad.net/~mbp/launchpad/mbp-trivial/+merge/32173 | 05:14 |
| StevenK | poolie: I sure can, let me branch that | 05:18 |
| poolie | thanks | 05:18 |
| lifeless | poolie: sorry blah I've been meaning to do it | 05:18 |
| lifeless | grah | 05:19 |
| lifeless | ForbiddenAttribute: ('_getOfficialTagClause', <SourcePackage <Distribution 'Debian' (debian)> <DistroSeries u'woody'> <SourcePackageName 'mozilla-firefox'>>) | 05:20 |
| poolie | np, there's also https://code.edge.launchpad.net/~mbp/launchpad/flags-webapp/+merge/32967 | 05:21 |
| poolie | which is only doc changes and could arguably land without ec2 | 05:21 |
| === almaisan-away is now known as al-maisan | ||
| lifeless | garh I hate interfafces | 05:24 |
| lifeless | too dan opaque | 05:24 |
| poolie | hm i wish i'd added the ui to see the flag rules :) | 05:25 |
| poolie | lifeless: so istm that you're getting back None because there are no flag rules defined on production | 05:27 |
| lifeless | poolie: we added one to staging to teset | 05:29 |
| poolie | i don't see any there either | 05:30 |
| lifeless | https://bugs.edge.launchpad.net/launchpad-foundations/+bug/634342/comments/3 | 05:30 |
| _mup_ | Bug #634342: need a features 'scope' for page ids <flags> <qa-ok> <Launchpad Foundations:Fix Committed by lifeless> <https://launchpad.net/bugs/634342> | 05:30 |
| poolie | unless maybe it's gone now? | 05:30 |
| lifeless | deleted it afterwards | 05:30 |
| lifeless | see that comment, it has the sql that tom ran for me | 05:30 |
| poolie | ok, i'll test it locally | 05:30 |
| poolie | lifeless: ok, the sql was wrong | 05:44 |
| poolie | should have been 'pageid:BugTask:+index' | 05:44 |
| poolie | however, it is a bug that it's possible for you to so easily get it wrong | 05:45 |
| lifeless | garh | 05:52 |
| lifeless | and i wrote that code n all | 05:52 |
| poolie | np | 05:53 |
| poolie | silent fail is a poor policy | 05:53 |
| lifeless | well | 05:53 |
| poolie | i think we probably want to give warnings in the edit/view gui | 05:54 |
| poolie | not per page request | 05:54 |
| lifeless | yes, if we had one :P | 05:54 |
| poolie | soon/next | 05:54 |
| poolie | might go out for fresh air first | 05:54 |
| poolie | also we need standardization | 05:54 |
| poolie | you use 'disabled', soyuz uses 'off' | 05:54 |
| poolie | this will become chaotic | 05:54 |
| lifeless | I think some constants would be nice | 06:05 |
| lifeless | or enums | 06:05 |
| lifeless | I think we can survive with different values as long as its self documenting in some fashion | 06:06 |
| poolie | right, maybe something like a registry | 06:44 |
| poolie | i want something lightweight and that allows the db to be slightly out of sync with the code, without laying too mny traps | 06:45 |
| lifeless | yeah | 06:45 |
| lifeless | being out of sync is normal for this design :) | 06:45 |
| poolie | ok back to the gui now | 06:53 |
| StevenK | poolie: That MP I'm going to land is targeted to db-devel, did you want it tossed at devel? | 06:54 |
| poolie | i don't know! | 06:54 |
| poolie | where should it go | 06:54 |
| poolie | :) | 06:54 |
| lifeless | is it safe to deploy now? | 06:55 |
| StevenK | poolie: There's a simple rule for it. devel unless you touch the database | 06:55 |
| StevenK | lifeless: It only changes the test infrastructure | 06:56 |
| poolie | which one are we talking about, flags-webapp, or mbp-trivial? | 06:56 |
| lifeless | devel | 06:56 |
| StevenK | The latter | 06:56 |
| poolie | ok, mbp-trivial | 06:56 |
| poolie | in that case both are safe for devel | 06:56 |
| StevenK | I'm just fighting with my own branches as well | 06:56 |
| poolie | i was just thinking about adding a machine readable plain text view of the flags | 06:57 |
| poolie | this is probably less useful than a human usable editor | 06:58 |
| poolie | it might be an ok baby step towards it? | 06:58 |
| lifeless | its a good start | 06:58 |
| lifeless | secure it to duck + launchpad devs | 06:58 |
| lifeless | and we're able to start seeing whats up | 06:58 |
| poolie | yeah, that's a good policy question | 07:01 |
| poolie | the settings should be private? | 07:01 |
| poolie | i'm torn | 07:01 |
| poolie | in a sense, since the code is open, it shouldn't matter | 07:01 |
| poolie | otoh if we're dealing with a crisis, perhaps it is better to have it public | 07:01 |
| poolie | s//better not to | 07:02 |
| lifeless | I think users should see the settings that apply to them, in principle. | 07:03 |
| lifeless | Thats quite different from seeing all the settings. | 07:03 |
| lifeless | as an example | 07:03 |
| lifeless | if we have a private team | 07:04 |
| lifeless | which represents a customer | 07:04 |
| lifeless | and we want to give them a longer timeout | 07:04 |
| lifeless | google shouldn't index the fact they are a customer ;) | 07:04 |
| poolie | good example | 07:06 |
| poolie | wfm too | 07:06 |
| persia | Probably best to have most policy private: for the same reasons, probably best to push most of that to admin-adjustable configuration rather than code. | 07:06 |
| lifeless | persia: thats what we're doing | 07:06 |
| poolie | that's the whole point:) | 07:06 |
| persia | Indeed, just adding justification to the choice to make it private :) Please continue with your excellent work. | 07:06 |
| poolie | lifeless: and write access should be only ducks? | 07:08 |
| poolie | that would be ~admin? | 07:08 |
| StevenK | ~admins | 07:17 |
| poolie | right | 07:18 |
| lifeless | poolie: yes | 07:20 |
| lifeless | person.isAdmin | 07:20 |
| lifeless | or something like that | 07:21 |
| mtaylor | https://code.edge.launchpad.net/~mordred/+recipe/trunk-nightlies | 07:32 |
| mtaylor | that page crashes chromium for me | 07:32 |
| mtaylor | fwiw | 07:32 |
| StevenK | poolie: Your branch fails to merge against devel with a conflict | 07:32 |
| StevenK | poolie: Er, your mpb-trivial branch, that is | 07:33 |
| poolie | thanks, i'll update it | 07:33 |
| poolie | StevenK: i'm pushing an updated mbp-trivial now | 07:44 |
| poolie | StevenK: pushed | 07:47 |
| StevenK | poolie: Thanks, throwing at ec2 now | 07:49 |
| poolie | thanks and just to be sure, you mean ~launchpad-dev? | 07:51 |
| poolie | i guess even non-canonical staff in there will be quite trusted | 07:51 |
| lifeless | ~launchpad | 07:53 |
| lifeless | thats canonical only | 07:53 |
| lifeless | and is the one i meant | 07:53 |
| poolie | glad i asked | 07:56 |
| poolie | is it tasteful to test access control by checking the test browser raises an exception? | 08:12 |
| lifeless | not really :) | 08:26 |
| stub | Anyone else get the feeling they have lost responses from ec2 recently? | 08:29 |
| thumper | wallyworld__: around? | 08:31 |
| wallyworld__ | thumper: yes | 08:35 |
| thumper | wallyworld__: ETOOMANYUNDERSCORES :) | 08:35 |
| thumper | wallyworld__: skype? | 08:35 |
| wallyworld__ | ack | 08:35 |
| poolie | lifeless: uh, thanks, so what would be a tasteful way? | 08:41 |
| lifeless | generally: | 08:46 |
| lifeless | - security is on model objets (permits API exposure) | 08:46 |
| lifeless | - check from a unittest in the databasefunctionallayer that you cannot access the model objects | 08:46 |
| lifeless | other than as the user types you care about | 08:47 |
| lifeless | you may want to have two sets of model objects that talk to the same db or something? I'm not 100% sure here. | 08:47 |
| poolie | i'll look around a bit more | 08:49 |
| adeuring | good morning | 08:51 |
| lifeless | poolie: rephrasing: I think that getFeatureFlag is safe and narrow and anyone can use it; the deeper APIs shouldn't be exposed over the model etc to anyone but launchpad & admins. | 08:55 |
| poolie | hm, interesting | 08:56 |
| poolie | so i was imagining i would change the permission in the browser config | 08:56 |
| poolie | but perhaps it should be at a different level? | 08:56 |
| lifeless | yeah | 08:57 |
| lifeless | all security is meant to be at the model layer | 08:57 |
| lifeless | (because the API uses the model directly) | 08:57 |
| lifeless | this may be a mistake, but its not something I've thought deeply about yet. | 08:57 |
| jml | hello | 09:01 |
| poolie | hello jml! | 09:06 |
| jml | poolie, hi :) | 09:06 |
| jml | poolie, did I see you mention that dkim is working? | 09:06 |
| lifeless | jml: https://bugs.edge.launchpad.net/launchpad-registry/+bug/644977 | 09:06 |
| _mup_ | Bug #644977: ProjectMilestone is inconsistent, confusing ui, can we just delete it? <Launchpad Registry:New> <https://launchpad.net/bugs/644977> | 09:06 |
| poolie | lifeless, this is interesting, because it naively seems to mean that code running as me is allowed to read and summarize data that i'm not allowed to read myself | 09:07 |
| lifeless | jml: the things you find trying to improve performance | 09:07 |
| poolie | perhaps this is not surprising if we define "model" in the right way | 09:07 |
| poolie | jml, it's already working for mail other than creating new bugs | 09:07 |
| jml | poolie, ahh, nice. | 09:07 |
| poolie | also, i'm happy that our devops practice got a bit better, in that i can now see the log output myself rather than nagging a losa | 09:07 |
| jml | poolie, +1 | 09:08 |
| bigjools | good morning all | 09:08 |
| jml | poolie, we've got a lot of room for improvement in that area | 09:08 |
| lifeless | poolie: perhaps. zope security can be very granular and capable | 09:08 |
| poolie | if someone reviews/sponsors https://code.edge.launchpad.net/~mbp/launchpad/dkim/+merge/35985 for me then it will work for mail creating new bugs too | 09:08 |
| jml | poolie, lifeless may have mentioned once or twice that he has an interest in increasing transparency :) | 09:08 |
| poolie | i'm mildly amused that adding debug log messages caused on "omg what's happening?" moment :) | 09:09 |
| spm | jml: you've become a master of understatement lately? | 09:09 |
| poolie | 'cos of them being mailed by default | 09:09 |
| jml | spm, heh :) | 09:10 |
| jml | poolie, I'll take a look at your branch now | 09:14 |
| poolie | lifeless: so i need separate interfaces for "read feature flag rules" and "write them?" | 09:14 |
| jml | poolie, should I still also look at jam's lp-serve branch? | 09:14 |
| poolie | jml, i am a babe in the woods so please review thoroughly | 09:14 |
| lifeless | poolie: no, one interface | 09:14 |
| poolie | jml, jml's branch is pretty big but getting some review would be great | 09:14 |
| mrevell | Hello | 09:15 |
| poolie | it's a bit smaller than it looks because it's based off db-devel or something | 09:15 |
| lifeless | poolie: configure.zcml can specify what access (e.g. Launchpad.Edit) is needed for what attributes | 09:15 |
| lifeless | poolie: and you write a small policy adapter to say how e.g. Launchpad.Edit is determined for a given Model object. | 09:15 |
| poolie | can you point out a likely good example of doing this? | 09:16 |
| jml | poolie, look in lp/code/configure.zcml for IBranch, and in c.l.security for AccessBranch... | 09:17 |
| lifeless | ^ | 09:18 |
| poolie | ah i should have known that one would be elegant :) | 09:18 |
| lifeless | bigjools: hey | 09:20 |
| lifeless | wgrant: around? | 09:20 |
| bigjools | lifeless: good day | 09:20 |
| lifeless | hey bigjools | 09:20 |
| lifeless | so, your pet performance problem | 09:20 |
| lifeless | how reliable is the code? | 09:21 |
| bigjools | I don't have any pets, just problems | 09:21 |
| bigjools | which one? :) | 09:21 |
| jml | poolie, well, it's not exactly elegant, but it'll be a little easier to follow since you are probably very familiar with branch access. | 09:21 |
| lifeless | like, if I start madly shuffling am I likely to run into zomg moments? | 09:21 |
| bigjools | lifeless: which performance problem? I have many. | 09:21 |
| lifeless | ArchiveResource:Entry:sync or whatever it was | 09:22 |
| bigjools | ah the package copier | 09:23 |
| lifeless | like, if I were to do a spike to it like my soon-to-land BugTask:+index spike | 09:24 |
| lifeless | am I heading into a disaster, or just a moderate risk | 09:24 |
| bigjools | lifeless: it's an extremely sensitive area and I am not convinced that the test coverage is good. But it needs love. | 09:24 |
| bigjools | if the package copier doesn't do its job it has the potential to break the publisher | 09:24 |
| lifeless | ok, no hack n slash spike then/. | 09:25 |
| bigjools | but please don't let me put you off :) | 09:25 |
| bigjools | yeah you can't throw test hacks at it | 09:25 |
| lifeless | oh, I wasn't suggesting tests ;) | 09:25 |
| lifeless | just Refactoring. With a Capital R. | 09:26 |
| bigjools | lifeless: also I'd like to try and CP jelmer's b-m changes | 09:26 |
| bigjools | it may solve a metric asshat load of problems | 09:27 |
| lifeless | cool | 09:27 |
| bigjools | but I need a real quick way of backing it out in case of issues | 09:27 |
| lifeless | so, I suggest: put together a CP branch with just *that* in it, for Monday. | 09:27 |
| lifeless | I'll Cp up to 11565 tomorrow | 09:27 |
| lifeless | when you deploy, if there is aproblem the losas can rollback to the revision before with a single command. | 09:28 |
| lifeless | the time-to-restore would be about 30 minutes | 09:28 |
| bigjools | it needs a cron job too | 09:28 |
| lifeless | trivial to turn that on/off. | 09:28 |
| lifeless | how does that sound spm ? | 09:28 |
| mthaddon | he's EOD-ed | 09:29 |
| lifeless | ah | 09:29 |
| lifeless | mthaddon: how does that sound to you? | 09:29 |
| mthaddon | but it sounds somewhat cowboy to me - that we're thinking of CP-ing something we're not sure about | 09:29 |
| lifeless | mthaddon: its been QA'd AIUI. | 09:29 |
| lifeless | mthaddon: but its soyuz, we often have problems post major rollout with the builddmaster anyway. | 09:29 |
| bigjools | the problem is that we don't have a test build farm with 60 builders. We can *never* be sure about the buildd-manager. | 09:29 |
| bigjools | we can be confident, but not sure | 09:30 |
| lifeless | mthaddon: it makes sense to me to do a single change, with a single simple rollback rather than bundling it in with the massess in 3 weeks time | 09:30 |
| bigjools | +1 | 09:30 |
| lifeless | mthaddon: lower risk, shorter recovery. | 09:30 |
| mthaddon | and more losa time :) I'm just whining, don't mind me... | 09:31 |
| lifeless | mthaddon: yeah, I appreciate that. | 09:31 |
| lifeless | mthaddon: and that you're flat chat. | 09:31 |
| lifeless | mthaddon: this particular CP we're discussing is significant because it may make a lot better use ofa ll the builders | 09:32 |
| lifeless | mthaddon: which will reduce 'are were there yet' questions to you. | 09:32 |
| lifeless | :) | 09:32 |
| mthaddon | yep, I think I've seen chat about this one | 09:32 |
| lifeless | bigjools: ok, so rc=me for that when you put the cp branch together just ping me | 09:37 |
| bigjools | ok ta | 09:38 |
| lifeless | bigjools: if you get it fully organised friday | 09:38 |
| lifeless | then on monday, once stevenk starts, I'll ask spm to do it, so it can be running with data when you start. | 09:38 |
| bigjools | well | 09:38 |
| bigjools | hang on, OTP | 09:38 |
| lifeless | sure; or it can wait for you, i don't mind :) | 09:38 |
| lifeless | my main point is that we should not do it before the weekend ;P | 09:39 |
| StevenK | Yes, if we do it on Friday, it WILL break on Sunday | 09:39 |
| stub | Anyone know where all those rubbish ZCML load DEBUG log messages are coming from on script startup? They should be DEBUG2 or lower. | 09:49 |
| lifeless | sorry, no idea - I haven't seen them. | 09:50 |
| lifeless | jml: I have fixed up the expected test fallout | 09:52 |
| jml | lifeless, which expected test fallout? | 09:52 |
| lifeless | from my bugtask:+index | 09:52 |
| lifeless | mainly little things | 09:52 |
| jml | ahh. | 09:52 |
| lifeless | http://bazaar.launchpad.net/~lifeless/launchpad/bugtask+index/revision/11587 if you want to eyeball it | 09:52 |
| StevenK | wgrant: Did you end up playing with LP on 9.0? | 09:53 |
| bigjools | ok lifeless I am off TP. I will prepare a CP ready for Monday. I'd like to be around when it's rolled out though. We also need extra logs synced etc, so it will be a little complicated. | 09:56 |
| jml | lifeless, looking now | 09:56 |
| lifeless | bigjools: ok; document it all on LPS as normal :) | 09:56 |
| jml | lifeless, " # The view caches, to see see different scenarios, a refresh is needed." Two "sees"... | 09:59 |
| jml | lifeless, also, why the change to @property syntax in model/milestone.py? | 09:59 |
| lifeless | jml: see the change in lib/lp/registry/model/projectgroup.py | 10:00 |
| jml | lifeless, oh right. ugh. | 10:01 |
| jml | lifeless, presumably the vocabularies is the same | 10:01 |
| lifeless | jml: yes, I can add an XXX there, but one is really enough I think | 10:02 |
| jml | agreed. | 10:02 |
| lifeless | anyone wondering will find it pretty quickly. | 10:02 |
| jml | lifeless, I was just thinking... "you know you're abusing your fancy component architecture when..." | 10:02 |
| lifeless | jml: when you're using it ? :) | 10:04 |
| jml | lifeless, har har. | 10:04 |
| lifeless | jml: so was that revision ok? | 10:19 |
| lifeless | poolie: your lep update | 10:23 |
| lifeless | I think you had a public<->private typo | 10:23 |
| jml | lifeless, yeah. | 10:27 |
| jml | lifeless, I think it uncovers a fair amount of tech debt | 10:27 |
| jml | lifeless, but what can you do? | 10:27 |
| lifeless | jml: apply flamethrowers? | 10:27 |
| lifeless | halt()ing time I think | 10:34 |
| stub | jtv: Do you know what test_main_leaves_oops_handling_alone in test_translations_import.py is actually trying to test? | 10:35 |
| jtv | stub: nope | 10:35 |
| jml | lifeless, do you have a list of cronjobs that we are actually running in production? | 10:36 |
| jml | lifeless, or know how I'd find one? | 10:36 |
| lifeless | jml: its a losa question atm | 10:36 |
| jml | lifeless, ok, thanks. | 10:37 |
| lifeless | jml: I'd like to get this more managed and accessible by devs but it hasn't hit the top of my 'most leverage' list yet. | 10:37 |
| jml | lifeless, understood. | 10:37 |
| lifeless | mthaddon: thanks for progressing the new librarian stuff; I'm excited to see it getting close. | 10:37 |
| jml | lifeless, glad it's on your list, and agree re priority. | 10:37 |
| lifeless | gnight | 10:37 |
| mthaddon | o/ | 10:39 |
| wgrant | StevenK: No. I might over the weekend. | 10:49 |
| wgrant | bigjools: I'm reasonably confident in the latest b-m changes. | 10:49 |
| wgrant | My main fear is that it might be too slow. | 10:50 |
| wgrant | And we'll get a backlog of uploads. | 10:50 |
| bigjools | wgrant: that's good, and bad | 10:50 |
| bigjools | but I doubt we'll get a backlog | 10:50 |
| wgrant | I guess it's a whole lot faster due to the lack of initZopeless. | 10:50 |
| wgrant | So it should be OK. | 10:50 |
| bigjools | if we do, it doesn't matter | 10:50 |
| bigjools | they'll get processed eventually | 10:50 |
| wgrant | lifeless: You rang? | 10:50 |
| bigjools | we can keep an eye on it and figure out a way to throttle the b-m back if that happens | 10:51 |
| wgrant | I guess it can be no worse than it is now... not that that's saying much. | 10:51 |
| noodles775 | l | 10:57 |
| gmb | Anyone know how I get testrepository to just give me a list of the failing tests rather than all the output? | 11:46 |
| jml | gmb, if you're using trunk, testr failing --list | 11:50 |
| jml | gmb, if you aren't, headbutt lifeless until he does a release | 11:50 |
| jml | gmb, or... | 11:50 |
| jml | gmb, testr failing --subunit | subunit-ls | 11:50 |
| gmb | jml, I guess I'm not using the trunk. Thanks. | 11:51 |
| * gmb adds "headbutt lifeless" to his todo list. | 11:51 | |
| jml | gmb, I only added the support recently. | 11:51 |
| jml | still pending is my patch to make 'testr load' display output incrementally | 11:51 |
| gmb | Fair enough. | 11:51 |
| === mrevell is now known as mrevell-lunch | ||
| jml | bigjools, | 11:59 |
| jml | bigjools, https://code.edge.launchpad.net/~jml/launchpad/buildd-deferred-fo-sho/+merge/36188 | 11:59 |
| deryck | Morning, all. | 12:00 |
| jml | bigjools, https://code.edge.launchpad.net/~jml/launchpad/buildd-slavescanner-bustage/+merge/36187 is being tested in ec2 as we speak | 12:00 |
| jml | bigjools, http://paste.ubuntu.com/498394/ | 12:05 |
| jml | noodles775, have you disabled test_runAll_mails_oopses on devel? | 12:32 |
| noodles775 | jml: no, I landed the testfix on db-devel only. | 12:35 |
| jml | noodles775, I see. | 12:35 |
| jml | noodles775, the failure is affecting my branches that are targeted at devel | 12:35 |
| noodles775 | jml: can you reproduce it locally? or just on ec2 test? | 12:36 |
| jml | noodles775, I'll try to now. | 12:36 |
| noodles775 | if it's just on ec2, and its your only failure, why not merge the testfix rev and land your brach? | 12:36 |
| noodles775 | OK. | 12:36 |
| jml | noodles775, yeah, I might do that. | 12:37 |
| jml | noodles775, still don't know if it's my only failure, only kicked off the test run three hours ago. | 12:37 |
| wgrant | Bug 645127 is awkward. | 12:39 |
| _mup_ | Bug #645127: Release files list wrong architectures for maverick <Soyuz:New> <https://launchpad.net/bugs/645127> | 12:39 |
| jml | bigjools & I are just out for a couple of hours for lunch & errands. | 12:41 |
| bigjools | we are | 12:41 |
| noodles775 | jml: See lifeless' comment on bug 644984 too... might be worth checking whether your ec2 run included that rev. | 12:41 |
| _mup_ | Bug #644984: test_runAll_mails_oopses fails sometimes <Launchpad Foundations:New> <https://launchpad.net/bugs/644984> | 12:41 |
| noodles775 | Enjoy :) | 12:42 |
| gmb | Dear lib/lp/bugs/stories: Die in a fire. No love, Graham. | 12:47 |
| === al-maisan is now known as almaisan-away | ||
| wgrant | Erm. | 13:16 |
| wgrant | https://edge.launchpad.net/ubuntu/+source/firefox/3.6.10+build1+nobinonly-0ubuntu3/+build/1970234 | 13:16 |
| wgrant | Failed, but without a log or anything. | 13:16 |
| wgrant | What? | 13:16 |
| wgrant | Maybe failure counting. | 13:18 |
| stub | gmb: Can you think of anything in the checkwatches stuff that might be resetting the Python logging system? | 13:28 |
| === almaisan-away is now known as al-maisan | ||
| gmb | stub, Not off the top of my head. Can you give me more context on the problem? | 13:34 |
| stub | I'm reworking logging for all the LaunchpadCronscripts and checkwatches isn't playing nice. | 13:36 |
| stub | I see a debugger in my future | 13:36 |
| gmb | stub, Checkwatches uses the default LaunchpadCronscript logging stuff as far as I know. | 13:37 |
| stub | Yer, I can't see why things are misbehaving either. | 13:37 |
| stub | Maybe tomorrow with a fresh head | 13:38 |
| bac | hi jam. i just merged new devel with your branch and all of the previously failing tests pass locally. | 14:44 |
| bac | jam: if you could merge devel and push your branch back to LP i will send it directly to PQM | 14:44 |
| bigjools | wgrant: the b-m was restarted at that time, I've retried it | 14:45 |
| wgrant | bigjools: Thanks. | 14:46 |
| wgrant | Was killing my scripts. | 14:46 |
| bigjools | heh | 14:46 |
| wgrant | Why would it have ended up in that state, though? | 14:46 |
| bigjools | NFI | 14:46 |
| wgrant | A little concerning. | 14:48 |
| bigjools | yes | 14:48 |
| bigjools | but I'm not going to look into it since that aspect will be changing soon | 14:49 |
| wgrant | True. | 14:49 |
| mars | noodles775, ping re: your feature flags branch | 14:50 |
| noodles775 | mars: yup? Which one? | 14:50 |
| mars | noodles775, either of them :) | 14:51 |
| mars | noodles775, I was talking with Martin last night about a test helper for adding features | 14:51 |
| mars | I was looking at adding something to a new lp.features.testing module | 14:51 |
| mars | noodles775, do you already have code to do this, and if so, have the branches landed? | 14:51 |
| jam | bac: will do, though pqm merges into devel, right? | 14:52 |
| jam | (seems a bit spurious to merge devel to merge into devel) | 14:52 |
| noodles775 | mars: I emailed the dev list with the code I'm using to create the flag in my test... but lifeless also replied pointing out that the memcached test is a better one to base it on. | 14:52 |
| bac | jam; you're right | 14:52 |
| mars | noodles775, ok, then I'll copy the memcache test for my own helper. Are you landing your work today? | 14:53 |
| bac | jam: i usually do it anyway just to ensure there are no conflicts | 14:53 |
| bac | jam: but i've proven that locally | 14:53 |
| jam | yeah, I just tested it, no conflicts | 14:54 |
| jam | still want me to push that up? | 14:54 |
| noodles775 | mars: the example that I pasted in the email is already landed on db-devel, but I was going to update it in another branch... but I'll wait until your helper is there. | 14:54 |
| noodles775 | (my example was from lp.registry.browser.tests.test_series_views | 14:54 |
| noodles775 | ) | 14:54 |
| mars | noodles775, alright, that sounds good to me. I'll let you know and reply to the list thread once it is coded. | 14:55 |
| noodles775 | Great, thanks mars | 14:55 |
| mars | noodles775, did you file a bug for the buildbot test failure XXX this morning? | 15:06 |
| mars | leonardr, did your branch with lifeless patch land? | 15:08 |
| leonardr | mars, it didn't land last night because i screwed up the commit message | 15:08 |
| leonardr | let's see if it's landed now | 15:08 |
| jml | mars, yes, he did. It's https://bugs.edge.launchpad.net/launchpad-foundations/+bug/644984 | 15:11 |
| _mup_ | Bug #644984: test_runAll_mails_oopses fails sometimes <Launchpad Foundations:New> <https://launchpad.net/bugs/644984> | 15:11 |
| mars | thanks jml. Trying to coordinate the fix for this. leonardr has something landing that may do the trick. | 15:12 |
| leonardr | mars: i'm still in pqm | 15:15 |
| mars | out of curiosity, how long has it been there? | 15:15 |
| mars | leonardr, ^ ? | 15:16 |
| leonardr | mars, less than 30 minutes, i'd say | 15:16 |
| mars | ah, ok, np then | 15:16 |
| jml | mars, PQM is taking about 30 mins per branch | 15:17 |
| noodles775 | mars: yep, bug 644984 | 15:17 |
| _mup_ | Bug #644984: test_runAll_mails_oopses fails sometimes <Launchpad Foundations:New> <https://launchpad.net/bugs/644984> | 15:17 |
| mars | jml, yeah, that is why I was asking :/ | 15:17 |
| jml | mars, you should make it take less time | 15:18 |
| jml | mars, that would be rad | 15:18 |
| mars | lol | 15:18 |
| bac | hi matsubara, you were the last to upload the PPA for bzr-pqm to the launchpad PPA. would it be easy for you to push the new version up for maverick? | 15:38 |
| matsubara | bac, I copied from the lucid archive to the maverick one. let's see if that will work. in case it doesn't, I'll try to build it again for maverick | 15:42 |
| bac | matsubara: as usual, you rock! | 15:42 |
| cr3 | gary_poster: about what you said yesterday that z3c.recipe.scripts should be my one stop shop, or something along those lines, I should replace zc.recipe.egg with z3c but what about zc.recipe.testrunner? should I also try to just use z3c.recipe.scripts unless I have a really good reason? | 15:47 |
| gary_poster | cr3: I meant in comparison with zc.recipe.egg. zc.recipe.testrunner has also been updated, so it's good to use | 15:48 |
| gary_poster | cr3: I saw your email, but I kind of want to get to other tasks first. Lemme review now since you are hear to see if I have any flyby comments... | 15:49 |
| cr3 | gary_poster: ok, I started playing with it and I noticed a buch of repetitive lines in the array assigned to sys.path[0:0] | 15:49 |
| cr3 | gary_poster: when you're ready, no rush. at least I have a pretty good grasp of the problem now, so I can workaround to continue working and wait a bit for a real solution | 15:50 |
| gary_poster | ok great news cr3. But rereading now... | 15:50 |
| gary_poster | cr3: in regards to your patch, that code comes directly from your local site.py--which is at least a tiny bit odd TBH, because a clean Python generally does not ship with pkg_resources. Is this maverick? | 15:54 |
| cr3 | gary_poster: lucid | 15:55 |
| gary_poster | me too. Py 2.6? | 15:55 |
| cr3 | gary_poster: yep | 15:57 |
| gary_poster | weirrrd. | 15:57 |
| abentley | gary_poster, have you ever dealt with itertools.groupby and security proxies? It uses a custom iterator, so I had to return a redundant generator expression. | 16:01 |
| abentley | gary_poster, patch line 303: https://code.edge.launchpad.net/~abentley/launchpad/incremental-diff-driveby/+merge/36156 | 16:01 |
| cr3 | gary_poster: I'm starting to lean towards including pymodules within site.addsitepackages, but I'm not particularly comfortable with that | 16:01 |
| gary_poster | cr3: as a workaround, whatever, I guess. as anything that lasts longer than a week, "augh" and "horrible" come to mind. :-) | 16:03 |
| cr3 | gary_poster: what's making me particularly uncomfortable about all the *.recipe.* scripts is that they don't seem to behave the same, so if a script is built with zc.recipe.testrunner, it might run just fine, but another script built with z3c.recipe.scripts, might not run at all :( | 16:03 |
| gary_poster | cr3: they are built the same (they delegate in fact), so the difference is almost certainly configuration. As I said yesterday, your config was broken, and I only fixed a bit of it. | 16:04 |
| cr3 | gary_poster: I'll give the configuration a makeover then :) | 16:06 |
| gary_poster | abentley: I have not. why don't you want the custom iterator security proxied? (__iter__ is supposed to be always allowed, I think) | 16:06 |
| abentley | gary_poster, __iter__ was not allowed. | 16:07 |
| jml | gary_poster, hello. I have a question that is co-incidentally related to abentley's question. | 16:07 |
| gary_poster | abentley: can I put you in the queue or do you need this now? | 16:07 |
| jml | gary_poster, I would like to return Deferreds from things that are wrapped in the security proxy | 16:07 |
| abentley | gary_poster, I want the custom iterator to have the same behaviour as the generator expression does. | 16:07 |
| abentley | gary_poster, you can queue it. | 16:08 |
| gary_poster | jml, I repeat the same question I gave abentley. My stack is pretty deep right now, and I'd like to move to a queue instead :-) | 16:08 |
| gary_poster | thanks abentley | 16:08 |
| jml | but of course, when you try to use those Deferreds, you guess... ForbiddenAttribute: ('addErrback', <Deferred at 0xd4cef80 current result: ('BuildStatus.Building', 'OkSlave BUILDING')>) | 16:08 |
| jml | gary_poster, sure. I'll puzzle it out myself for the nonce. | 16:08 |
| gary_poster | I'll try to get back to you guys in just a few | 16:08 |
| bac | hi mrevell | 16:15 |
| mrevell | hey bac | 16:16 |
| dobey | on a bug when i "Target to release" and select multiple series for a project, how do i know which series a bug_task is for, when looking at the tasks on a bug in the API? | 16:16 |
| bac | hi mrevell, i need your wise cousel on some wording changes | 16:16 |
| bac | it was "3 active reviews or unmerged proposals". i found that to be a mouthful, cluttery, and it broke my portal. | 16:17 |
| bac | mrevell: i'd like to just say "3 active reviews" | 16:17 |
| jml | bigjools, http://paste.ubuntu.com/498561/ | 16:31 |
| gary_poster | OK, abentley. If you look for _iteratorChecker in eggs/zope.security-3.7.1-py2.6-linux-x86_64.egg/zope/security/checker.py you'll see what default iterator security checkers are provided to let iteration through. | 16:32 |
| gary_poster | You can provide your own for whatever builtins also--don't do it thoughtlessly, because it does have security implications, of course, but I think your example is perfectly fine--in lib/lp_sitecustomize.py for now. You'll see something similar there already for bzr bits. | 16:32 |
| gary_poster | If, as I understand, the problem you are having is with a Python builtin, that should actually go in zope.security eventually. If you would file a bug in https://bugs.edge.launchpad.net/zope.security I would appreciate it. | 16:32 |
| gary_poster | now moving on to jml... | 16:32 |
| jml | gary_poster, done :) | 16:32 |
| jml | gary_poster, well, sort of. | 16:32 |
| jml | gary_poster, but I'd love to hear your opinion. | 16:32 |
| jml | gary_poster, as I see it, there are two approaches: defining Deferred in our zcml as a class with allowed attributes, or doing something directly with checkers in lp_sitecustomize.py | 16:34 |
| jml | bigjools, ^^ | 16:34 |
| jml | (which, incidentally, I only just learned about) | 16:35 |
| jml | gary_poster, is either preferable to the other, really? | 16:35 |
| gary_poster | jml, for the original intended use case of the security system, I think we would need to think hard about whether things like addErrback and other mutation-y things should be allowed generically. In our case/usage, I think the clear answer is "yes." Therefore, I'd register something allowing access to the whole deferred API. My mechanism preference is ZCML because the deferred is not a builtin and not an oddba | 16:36 |
| gary_poster | "look, just allow all the bzr branch classes hierarchically please". | 16:36 |
| gary_poster | So, just for consistency, doing it in zcml is preferred IMO | 16:36 |
| jml | gary_poster, ok, thanks. | 16:37 |
| gary_poster | np | 16:37 |
| jml | gary_poster, fwiw, addCallback and addErrback are essentially necessary to actually use a returned Deferred object. | 16:37 |
| gary_poster | can't you look at the result without them? | 16:38 |
| gary_poster | the current result | 16:38 |
| jml | gary_poster, only if it has fired. | 16:38 |
| gary_poster | ah, of course | 16:38 |
| === gary_poster is now known as gary-lunch | ||
| jml | better is asynchronous when you are everything. | 16:39 |
| tyarusso | Okay, has *anyone* managed to get a production Launchpad instance up and running from the available code, including identity provider? I can't for the life of me get it all working from the READMEs...close, but no cigar. | 16:41 |
| === benji is now known as benji-lunch | ||
| === al-maisan is now known as almaisan-away | ||
| jml | bigjools, can you pls approve this here: https://code.edge.launchpad.net/~jml/launchpad/recipebuilder-expect-deferred/+merge/36336 | 17:16 |
| === EdwinGrubbs is now known as Edwin-lunch | ||
| dobey | hrmm, should i poke someone in particular re: bugs api? | 17:28 |
| rockstar | dobey, any one of the following: deryck, gmb, allenap, adeuring, bryceh, or bdmurray. | 17:29 |
| * rockstar is feeling all nostalgic at the PQM queue. | 17:29 | |
| dobey | heh | 17:29 |
| deryck | I was about to break for lunch. Maybe gmb or adeuring can help with the question. | 17:35 |
| deryck | but what was the question dobey? | 17:36 |
| dobey | on a bug when i "Target to release" and select multiple series for a project, how do i know which series a bug_task is for, when looking at the tasks on a bug in the API? | 17:36 |
| dobey | deryck: ^^ that :) | 17:37 |
| === Ursinha is now known as Ursinha-lunch | ||
| deryck | dobey, so how do you get from bugtask-->series via the API? | 17:37 |
| deryck | is that the question? | 17:37 |
| dobey | yeah. if there's a bug which affects multiple series of a project, the bug magic in tarmac doesn't work right, and i'm trying to fix it, but i don't see an obvious way to get the series id for the bug task | 17:38 |
| deryck | dobey, it's not exported, I don't think. Looking to confirm.... | 17:39 |
| bdmurray | at least with Ubuntu I believe it appears in the bug target name | 17:39 |
| bdmurray | but you have to parse the string which is rather lame | 17:40 |
| dobey | bdmurray: like "ubuntu/lucid"? | 17:41 |
| === gary-lunch is now known as gary_poster | ||
| deryck | yeah, it's definitely not exported. | 17:42 |
| bdmurray | task: upower (Ubuntu Maverick) | 17:42 |
| bdmurray | dobey: ^ | 17:42 |
| dobey | well that's the display name | 17:43 |
| dobey | hrmm | 17:43 |
| dobey | ok it looks like bug_task.bug_target_name has the information, but i have to parse it a bit and do some magic | 17:48 |
| bdmurray | yes, that's what I was saying | 17:50 |
| dobey | thanks | 17:51 |
| dobey | i suppose i should file a bug against malone to expose it properly, too | 17:51 |
| deryck | dobey, yes, please. Though I'm curious for such an obvious thing why it was never exported before. | 17:52 |
| deryck | maybe just oversight | 17:52 |
| === beuno is now known as beuno-lunch | ||
| === benji-lunch is now known as benji | ||
| === deryck is now known as deryck[lunch] | ||
| dobey | could be | 17:59 |
| jam | bac: \o/ it landed :) | 18:10 |
| jam | quick question to anyone, when does db-devel and devel get synchronized? | 18:18 |
| jml | jam: db-stable is merged into devel post-release | 18:25 |
| jml | jam: stable is merged into db-devel as soon as there's a change to stable. | 18:25 |
| dobey | ok, another question. how do i get the series for a merge proposal or branch, from the API? :) | 18:25 |
| jml | jam: https://dev.launchpad.net/Trunk | 18:26 |
| dobey | oh, probably have to parse branch.name perhaps? or the target bzr_identity? | 18:26 |
| jml | dobey, not all branches have a series | 18:27 |
| === Ursinha-lunch is now known as Ursinha | ||
| dobey | jml: yes, but for the ones that do? | 18:28 |
| dobey | any branch of a branch that has a series, has a series, right? :) | 18:28 |
| jml | no | 18:29 |
| dobey | ok. well for the proposals/branches that do have a series, how do i get the series id from the API for that proposal/branch? | 18:30 |
| jam | jml: in all fairness, I don't see where on that page it says when db-stable is merged into devel | 18:32 |
| jml | jam: oh, I think there's another page somewhere | 18:32 |
| jml | jam: sorry, I had meant to say "Here's where you can learn more", rather than "Here's where you should have checked" | 18:33 |
| jam | it seems to describe the forward links (devel => stable => db-devel => db-stable) | 18:33 |
| jml | jam: multi-tasking. | 18:33 |
| jml | https://dev.launchpad.net/Trunk/Glue | 18:33 |
| jam | which I think I did know, but was good to refresh | 18:33 |
| jml | maybe that mentions a thing. | 18:33 |
| jam | nope | 18:34 |
| jml | got wiki edit? | 18:34 |
| jam | I believe so, I'll put a quick bit in the "Where's trunk" blurb | 18:35 |
| jml | thanks. | 18:35 |
| jam | I don't think I have a good way of updating the graphs :) | 18:36 |
| jam | jml: thanks for the info, page updated | 18:38 |
| dobey | so i guess the answer is that it's impossible to get a series from a branch or proposal? :( | 18:46 |
| jml | dobey, I don't know, sorry. | 18:50 |
| bac | hey jam, in the future be sure to have a conversation with your reviewer about landing the branch. i think i just assumed you could do it. thanks again for the fix. | 18:51 |
| jml | dobey, if I were trying to figure it out, I'd look in the Launchpad codebase to figure out how bzr_identity works | 18:51 |
| jml | dobey, remember also that a branch can be linked to many series. | 18:51 |
| === beuno-lunch is now known as beuno | ||
| === deryck[lunch] is now known as deryck | ||
| lifeless | wgrant: I did | 18:53 |
| dobey | ugh | 18:54 |
| dobey | well that's no good | 18:54 |
| lifeless | sinzui: hey, in a bit I'd like to talk about 'project group milestones' | 19:13 |
| lifeless | sinzui: are you popping out early or anything? | 19:13 |
| sinzui | lifeless, no I will be unavailable for about 30 minutes in 1h to get children. We might extend project group milestones to include getting milestone assignees in a single query :) | 19:21 |
| === Edwin-lunch is now known as EdwinGrubbs | ||
| m4n1sh | which version of oauth does LP use? | 19:27 |
| m4n1sh | 1.0? | 19:27 |
| jam | anyone know why 'bin/run' in my working tree is adding lp-branches/devel/lib to the path rather than adding ./lib to the path? | 19:39 |
| jam | ok, that is just my fault running in the wrong directory. | 19:42 |
| * jam hides | 19:42 | |
| abentley | gary_poster, thanks, I was able to solve it with your tips. Filed as bug #645469 | 19:54 |
| _mup_ | Bug #645469: No checking policy for itertools.groupby <zope.security:New> <https://launchpad.net/bugs/645469> | 19:54 |
| mars | bac, ping | 20:00 |
| bac | hi mars | 20:00 |
| rockstar | Playing music with flash and doing `make schema` is a surefire way to crash X for me now. Happens every time. | 20:20 |
| mars | rockstar, you may want to hunt a bug # down for that. Or you could ask Bryce - he knows a bit about the topic ;) | 20:26 |
| rockstar | mars, yeah, these bugs only crop up when I have things to do, so I only notice them then. | 20:26 |
| rockstar | abentley, got a quick second to chat? | 20:32 |
| abentley | rockstar, sure. | 20:32 |
| lifeless | sinzui: hi | 20:39 |
| lifeless | sinzui: could we perhaps do voice? | 20:39 |
| lifeless | sinzui: ah, you're still out, mea culpa :P I shall ping again later | 20:39 |
| lifeless | gary_poster: I forgot one thing :) | 20:49 |
| lifeless | gary_poster: chameleon - have a look at jtv's landing last week-or-so for distroseries:+templates | 20:49 |
| lifeless | gary_poster: 7000 rows or something crazy - from db and rendered in 2 seconds. | 20:49 |
| lifeless | gary_poster: by avoiding canonical_url, and tales | 20:49 |
| mars | lifeless, do you have a moment to informally review some code for the features test helper I created? | 20:54 |
| lifeless | sure | 20:58 |
| mars | lifeless, http://pastebin.ubuntu.com/498725/, lines 91 and 92 are the meat of it | 20:59 |
| lifeless | scope seems unneeded | 21:00 |
| mars | wasn't sure | 21:00 |
| lifeless | its an orthogonal concern, it should be an orthogonal helper. | 21:00 |
| mars | ok | 21:01 |
| lifeless | it will confuse and mislead people I think | 21:01 |
| lifeless | the only code that is permitted to be concerned with scopes is the scope code itself | 21:01 |
| gary_poster | lifeless: cool | 21:01 |
| lifeless | all code being controlled by features has to be scope-ignorant | 21:01 |
| mars | fixed | 21:02 |
| lifeless | mars: you don't need to add them to the database you know, you can just use a in memory feature controller | 21:02 |
| jcsackett | does anyone know why calling fmt:link on a sourcepackage (e.g. replace=" structure sourcepackage/fmt:link") would seem to only provide an actual link if you're logged in as admin on launchpad.dev? | 21:02 |
| lifeless | but thats not really important either way. | 21:02 |
| mars | lifeless, yes, but for the first round I was just going to do this. But I agree in-memory would be much nicer. | 21:03 |
| mars | that is one advantage of the per_thread thing I guess | 21:03 |
| lifeless | that looks good | 21:03 |
| lifeless | mars: no, the per_thread thing is a workaround for us not having a consistently available 'context' throughout the system. | 21:04 |
| lifeless | mars: thanks for doing this ;) | 21:04 |
| lifeless | don't forget the 'from __future__ import with_statement' though | 21:04 |
| lifeless | we're still not python 2.6. | 21:04 |
| mars | lifeless, np. This only works for unit tests now. The API doesn't lend itself to setting and unsetting on views or doctests, again because of the per_thread thing. | 21:04 |
| mars | good poing | 21:04 |
| mars | point | 21:05 |
| Ursinha | sinzui, hi | 21:05 |
| lifeless | mars: if you use a Fixture (from fixtures import Fixture), then in a doctest you can do 'fixture = FeatureFixture('foo'='123'); fixture.setUp()' .... 'fixture.cleanUp()' | 21:05 |
| Ursinha | sinzui, about bug 540890, I'm not sure which oopses you want to have removed | 21:06 |
| _mup_ | Bug #540890: exclude robot posts from reports <OOPS Tools:Triaged> <https://launchpad.net/bugs/540890> | 21:06 |
| mars | lifeless, an in-memory controller would be nicer for that actually. MockFlagsController.set_flag() | 21:06 |
| lifeless | I should add a contextmgr->fixture adapter to fixtures | 21:06 |
| mars | lifeless, ah! I was wondering about that | 21:06 |
| mars | the fixtures bit | 21:06 |
| lifeless | and fixtures are context managers, so can also use with | 21:06 |
| lifeless | mars: one small thing | 21:07 |
| mars | ok | 21:07 |
| lifeless | rather than {dict of flags} | 21:07 |
| lifeless | hmmm | 21:07 |
| mars | foo(key=value) ? | 21:07 |
| lifeless | never mind, the apis aren't close enough | 21:07 |
| lifeless | yeah, but key can have . in it. | 21:07 |
| mars | yep | 21:07 |
| mars | or ':' | 21:07 |
| lifeless | might be able to do something with **kwargs magic, but its a little freaky. | 21:07 |
| mars | as you want to do with page IDs | 21:07 |
| lifeless | so lets not. | 21:07 |
| sinzui | Ursinha, The spam oopses in bugs (tcquery) and rdf oopses are caused by bots. We seem to have decided not to fix the spam inject attacks | 21:08 |
| lifeless | gary_poster: yeah, its cool; thought that it might be a nice reference point for how to make a page fly. | 21:08 |
| gary_poster | cool | 21:08 |
| Ursinha | sinzui, do we have useful caused-by-robots oopses? | 21:09 |
| matsubara | sinzui, crazy idea, how about removing all robot triggered oopses from the reports? | 21:10 |
| sinzui | I am not sure. | 21:10 |
| lifeless | Ursinha: yes, if they follow a local link | 21:10 |
| lifeless | matsubara: I'm not entirely keen on that. | 21:10 |
| sinzui | Ursinha, the attacks have no referer | 21:10 |
| matsubara | hmm | 21:10 |
| lifeless | sinzui: the spam injection stuff is on my radar. | 21:10 |
| mars | matsubara, think of it as free fuzz-testing for our site! | 21:10 |
| lifeless | sinzui: but I'm focusing on performance first | 21:11 |
| matsubara | ok, sounds like a good criteria then, all robots with no referrer shouldn't appear in the reports | 21:11 |
| sinzui | We fixed registry and answer spam vectors last December | 21:11 |
| lifeless | matsubara: anything without a referrer shouldn't appear. | 21:11 |
| lifeless | matsubara: for 404's. | 21:11 |
| matsubara | that way we keep the benefit of free fuzz-testing and ignore robots triggering oopses we don't care about | 21:11 |
| sinzui | Blueprints is also attacked once or twice a month | 21:12 |
| matsubara | lifeless, that's one of the fixes we've been working on | 21:12 |
| lifeless | matsubara: hang a second; are we talking 404s or all oopses. | 21:12 |
| lifeless | matsubara: because its *only* 404's that I'm talking about. Other oops are important to see. | 21:12 |
| matsubara | actually Ursinha just uploaded the branch with that fix | 21:12 |
| lifeless | I'm confused; could we start over? | 21:13 |
| matsubara | lifeless, any oopses triggered by a bot with no referrer header | 21:13 |
| lifeless | matsubara: I think thats too broad. | 21:14 |
| lifeless | matsubara: I would be happy with 'any NotFound with no referrer header'. | 21:14 |
| lifeless | matsubara: I don't think it matters whether its a bot or a human, do you? made up urls that don't exist are not interesting from a QA perspective. | 21:14 |
| matsubara | lifeless, filtering only NotFounds wouldn't help sinzui's use case as reported on https://bugs.edge.launchpad.net/oops-tools/+bug/540890 | 21:15 |
| _mup_ | Bug #540890: exclude robot posts from reports <OOPS Tools:Triaged> <https://launchpad.net/bugs/540890> | 21:15 |
| lifeless | looking | 21:16 |
| lifeless | matsubara: thats true, but the other exceptions are important. I disagree about us not fixing them. | 21:16 |
| lifeless | matsubara: we have many things we haven't fixed yet; those are definitely on the list-to-fix as far as I'm concerned. | 21:17 |
| sinzui | lifeless, matsubara. I would be equally happy with all the search vectors patched. I get tired of reading the monthly super barrage of attacks to all locations | 21:17 |
| lifeless | sinzui: getting rid of the 404's with no referrer will help, though it will leave the attacks in place. We will get to them. | 21:17 |
| jam | losa ping, I have some questions about deploying a new service as part of launchpad, and I want to make sure I've worked out what you guys need, etc. | 21:17 |
| mbarnett | jam: sure. hit me, and if i don't think i can give you a complete answer, i might ask you to email us so that everyone gets a chance to chime in. | 21:18 |
| jam | mbarnett: so I have this merge-proposal up: https://code.edge.launchpad.net/~jameinel/launchpad/lp-service/+merge/35877 | 21:19 |
| jam | which adds a new service as part of the "bzr+ssh" chain | 21:19 |
| jam | basically, it is something that can fork itself to provide better connection times | 21:19 |
| jam | rather than execing a new python process | 21:19 |
| mbarnett | right | 21:20 |
| jam | mbarnett: as such, it will be running on the same machine that runs the Conch server now (I believe that is crowberry) | 21:20 |
| lifeless | matsubara: sinzui: Unless there is a strong argument for why we will never have a successful attack via robots triggering exceptions, I really feel we should only filter NotFounds. | 21:20 |
| matsubara | lifeless, well, it's not that we're not going to fix, it's just that we won't list those specific oopses in the reports. I think one of the ideas is to make the reports more useful to the devels, and having thousands of oopses in the reports that are affecting a bunch of misbehaving bots shouldn't be a priority | 21:20 |
| mbarnett | jam: it is | 21:20 |
| jam | since it is a running service, it seems like something the losas need to know about, so I need to get documentation put somewhere | 21:20 |
| jam | I don't really know where that would be | 21:20 |
| jam | also, we'd like to work out a way to stage its deployment | 21:21 |
| sinzui | lifeless, I reported the bug on flacoste's behalf, as I said, I fixed the apps I have domain over | 21:21 |
| jam | namely, once this code lands, we would want to activate it on staging | 21:21 |
| jam | (via a lazr.conf setting) | 21:21 |
| jam | and then eventually roll that flag out to production | 21:21 |
| sinzui | lifeless, the attaches started in Nov 2009 | 21:21 |
| mbarnett | jam: yeah, we will need to know a few things.. a) how to monitor it to ensure it is functioning as intended b) expected performance characteristics (how to measure if it is succeeding and c) resource profile (what additional load it is expected to put on the server and and d) how do we make it not fork us to death :) | 21:21 |
| lifeless | I feel uncomfortable that the injection vectors are not totally fixed. | 21:22 |
| lifeless | I feel terrified at the idea of having that grow or change and not seeing it. | 21:22 |
| jam | mbarnett: well, should this be in documented form, or is irc chat sufficient :) | 21:22 |
| lifeless | I think that the exceptions should just be fixed, we shouldn't route around it : it is a bug, it is important. | 21:22 |
| jam | a) I did add support for making a 'hello' request on its socket | 21:22 |
| lifeless | NotFound w/no referred isn't a bug, and it isn't important (because we handled it successfully) | 21:23 |
| jam | I can have it report whatever information you would like | 21:23 |
| mbarnett | jam: that is an interesting question. I think it would be worth it to have it in a place other than scrollback. either email or a wiki page. | 21:23 |
| jam | which might be a good thing to integrate into the existing service reporting stuff (what is the name of it?) | 21:23 |
| jam | (Acorn or something like that?) | 21:23 |
| lifeless | sinzui: would it be ok for 'ProductSeries.milestones' to return the Product milestones too ? | 21:24 |
| gary_poster | EdwinGrubbs: hi. :-) does your OOPS format work address bug 635254, directly or indirectly? | 21:24 |
| _mup_ | Bug #635254: oops request timeline should be richer <oops-tools> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/635254> | 21:24 |
| jam | d) It will be logging to a file, and where should that file be located, and we want to make sure it gets sync'd to devpad like other log files | 21:24 |
| sinzui | lifeless, I do not think so, I can move a product series to a different product to move the milestones... and I have no intention of moving other milestones | 21:25 |
| jam | b) the service itself should be responsive within <1s I would expect, since it does very little before forking and handling the rest there. | 21:25 |
| lifeless | sinzui: ah. Then how about I add a 'vocabulary_milestones' to the milestone contract | 21:25 |
| sinzui | looks like the prescription spammer's mailer just hit the openjdk list | 21:25 |
| jam | however, I don't have a great idea about 'load'. I can say we usually have 20+ concurrent ssh connections, but I don't know the number of new connections/second | 21:26 |
| lifeless | sinzui: the vocab is doing too many queries; its one of the causes of slow | 21:26 |
| sinzui | yes, then optimising that would be a very good idea | 21:26 |
| jam | mbarnett: as an example, one graph right now: https://lpstats.canonical.com/graphs/CodehostingPerformanceStaging/ this should change that graph to be much lower | 21:27 |
| mbarnett | jam: heh | 21:27 |
| jam | (times locally show 2.5s to connect, dropping to 0.5s which seems 95% ssh overhead) | 21:27 |
| EdwinGrubbs | gary_poster: although I have been thinking about the different formats we will want for individual fields, my work mainly involves making it easier to separate different multiline fields. | 21:27 |
| gary_poster | EdwinGrubbs: so it's fair to say that your work will make these distinctions possible, even though that's not the primary focus of your work? If so, would it be ok to assign the bug to you? (If not, of course, I won't :-) ) | 21:29 |
| mars | lifeless, when you spoke of using a fixture for the feature flags, did you mean lp.testing.fixtures ? | 21:29 |
| mars | lp.testing.fixture | 21:29 |
| lifeless | mars: no, 'fixtures'. | 21:29 |
| mars | lifeless, hmm, bin/py says we don't have that module | 21:29 |
| lifeless | mars: then you have an old branch | 21:29 |
| mars | or goofed-up dependencies | 21:29 |
| lifeless | indeed | 21:30 |
| EdwinGrubbs | gary_poster: I don't think I will be allowed to work on it after I get my current branch landed. It's take surpisingly long as it is. | 21:30 |
| gary_poster | mars, have you communicated our shared confusion about feature flags, and do you now have knowledge that you can share with me at a later date? :-) | 21:30 |
| jam | c) resource profile => should actually decrease versus what we do today | 21:30 |
| EdwinGrubbs | s/take/taken/ | 21:30 |
| gary_poster | EdwinGrubbs: ack, fair enough. Thank you. | 21:30 |
| mars | gary_poster, yep, and I am writing the test helpers now so everything becomes easier | 21:30 |
| jam | the service itself should have low resources, <= 1 bzr serve process | 21:30 |
| jam | and it should save some load by forking rather than starting up a new process | 21:30 |
| * gary_poster cheers in mars' direction | 21:30 | |
| lifeless | matsubara: sinzui: on the oopses; if I haven't convinced you about the non-404's, can you perhaps mail the list so we can have a broad discussion. | 21:30 |
| jam | and having that process do all the IO of importing lots of python code | 21:31 |
| lifeless | I have to run out for a bit. I will be back soon. | 21:31 |
| jam | also, it does log the rusage() of its subprocesses, which might be good to hook into some sort of report, since it may help us figure out bzr+ssh overhead issues | 21:31 |
| mbarnett | jam: would you mind capturing what we chatted about in here in an email, and appending your operational questions (where to log to, etc..) and shooting that over? I think this is a significant enough change (since it affects everyone using codehosting) that it would be good to have this conversation in a more explicitly inclusive way... | 21:32 |
| jam | mbarnett: also, "email us" who is us and what is your email address :) | 21:32 |
| mars | gary_poster, I am having some trouble picking up the 'fixtures' package in the eggs directory. I have run 'make clean && make', but it still will not find the module. It is not in sys.path according to bin/py. Do you have moment to help debug this problem? | 21:45 |
| gary_poster | mars, sure. where's a branch? | 21:45 |
| mars | gary_poster, devel | 21:45 |
| gary_poster | oh? | 21:45 |
| gary_poster | ok | 21:45 |
| mars | gary_poster, actually | 21:45 |
| mars | wait a sec... | 21:46 |
| lifeless | k, back | 21:47 |
| mars | gary_poster, argh, it is something with the setup. This is in a lightweight checkout I have of devel. lp-branches/devel knows about the module. lp-branches/dev (my checkout) does not. | 21:47 |
| mars | stale .pyc files maybe? | 21:48 |
| gary_poster | mars, ? Don't know enough about what you are talking about. Do I need to care, or not? :-) | 21:48 |
| mars | I thought 'make clean' killed those | 21:48 |
| gary_poster | doesn't look like it | 21:48 |
| mars | ok! That is a likely candidate then | 21:49 |
| bdmurray | should getting ReturnToReferrerMixin to work require much effort? | 21:49 |
| gary_poster | but getting the pyc files out of whack involves having to do odd things like touching the pyc files, or changing the py file *really* fast | 21:49 |
| gary_poster | after it has been compiled | 21:50 |
| mars | gary_poster, ? Why not make the clean target nuke them all with 'find -iname *pyc -delete' ? | 21:50 |
| gary_poster | mars, you could I guess, only in lib, but Python is really supposed to handle that for you | 21:51 |
| mars | ah, wait | 21:51 |
| mars | make clean does kill them | 21:51 |
| lifeless | mars: try | 21:51 |
| lifeless | mars: a) check that versions.cfg lists it | 21:51 |
| * gary_poster repopens makefile | 21:51 | |
| lifeless | mars: run bin/buildout | 21:51 |
| mars | lifeless, heh, I thought you were advocating for empirical evidence: 'try running "make clean" and see what happens :) | 21:52 |
| lifeless | heh | 21:52 |
| mars | gary_poster, line 343 does it | 21:53 |
| gary_poster | mars yes it does, sorry. I was looking for pyc in Makefile but it is -name '*.py[co]' | 21:53 |
| mars | lifeless, so it is in the versions.cfg list - that means the code would not build if it could not find it | 21:53 |
| mars | ... this goes to a bad place - something wrong with z3c.recipe.scripts ? :( | 21:54 |
| lifeless | mars: now, run 'bin/buildout' no options. | 21:55 |
| gary_poster | mars, lifeless, versions.cfg only has to do with specifying versions | 21:55 |
| gary_poster | it has nothing to do with choosing software | 21:55 |
| lifeless | gary_poster: ok | 21:55 |
| gary_poster | that is done in setup.py | 21:55 |
| lifeless | gary_poster: thanks | 21:55 |
| gary_poster | versions.cfg is separate because it needs to handle dependencies as well | 21:56 |
| gary_poster | as well as recipes | 21:56 |
| gary_poster | and anything else buildout happens to tickle | 21:56 |
| lifeless | mars: I found that after running bin/buildout it works, when I first added it | 21:56 |
| thumper | gary_poster: want to have a quick catch up call? | 21:56 |
| gary_poster | sure thumper | 21:56 |
| gary_poster | ready any time | 21:57 |
| mars | lifeless, gary_poster, and now it works! On the third try! ARGH. | 21:58 |
| mars | lifeless, gary_poster, thank you for the help | 21:58 |
| cr3 | gary_poster: fyi, all is well with my buildout now | 22:00 |
| lifeless | thumper: so, how do you want to do this? | 22:01 |
| wallyworld_ | morning | 22:02 |
| === Ursinha is now known as Ursinha-afk | ||
| === salgado is now known as salgado-afk | ||
| lifeless | what fantastic thing should I do today | 22:24 |
| mars | cut the test suite runtime in half? | 22:27 |
| lifeless | hmm | 22:31 |
| lifeless | I wonder if I could do that | 22:32 |
| mars | lifeless, btw, here is the code as a FeatureFixture: http://pastebin.ubuntu.com/498766/ | 22:34 |
| lifeless | mars: thats a bit unidiomatic | 22:35 |
| mwhudson | lifeless: no downtime rollouts for cronscripts | 22:35 |
| lifeless | one sec and I'll give you an alternative | 22:35 |
| mars | lifeless, have an idiomatic example? I assume you mean the addCleanup bit | 22:35 |
| lifeless | mars: http://pastebin.ubuntu.com/498773/ | 22:37 |
| lifeless | mars: basically all the closures are unneeded | 22:38 |
| lifeless | mwhudson: that would be lovely. | 22:38 |
| mars | yep, as I thought | 22:38 |
| mars | oh neat, pulling it inside the loop like that | 22:39 |
| mars | if the loop blows up, then the cleanup still happens too | 22:39 |
| lifeless | well, if cleanUp gets called, but yes. | 22:39 |
| lifeless | its closer to being correct :) | 22:39 |
| lifeless | jml: where did we leave our parallel testing spike for lp | 22:40 |
| jml | lifeless, lp:~jml/launchpad/dirty-parry is the closest I've got | 22:40 |
| lifeless | I'm thinking of this as a strategy: | 22:40 |
| lifeless | - teach testrepository to run partitioned copies | 22:41 |
| jml | lifeless, but I've massively screwed with our ec2 tools since then | 22:41 |
| lifeless | - start working up parallel-safe layers, from db up - incrementally more capable. | 22:41 |
| jml | lifeless, parallel-safe == more than once on the same machine? | 22:43 |
| lifeless | yes | 22:44 |
| jml | https://bugs.edge.launchpad.net/launchpad-foundations/+bug/107371 | 22:44 |
| _mup_ | Bug #107371: Make the test suite able to be run in parallel on a single machine <build-infrastructure> <feature> <test-system> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/107371> | 22:44 |
| jml | lifeless, I think that is a win independent of testr improvements. | 22:44 |
| lifeless | I agree. | 22:44 |
| lifeless | however it will be easier to get a feel for the thing if I can run a single partitioned run :) | 22:45 |
| jml | fair enough. | 22:45 |
| lifeless | jml: I think I know why some tests don't run properly via testr after ec2 | 22:45 |
| jml | lifeless, why? | 22:46 |
| lifeless | stories have a test id that a) is mangled - the path thing we talked about , but b) doesn't represent a runnable test. | 22:46 |
| jml | It's because you haven't reviewed my incremental failure branch, isn't it? | 22:46 |
| thumper | lifeless: we have the UDD meeting shortly | 22:56 |
| thumper | lifeless: but after that we can skype to talk through the xmlrpc issue | 22:56 |
| lifeless | UDD meeting? | 22:57 |
| thumper | lifeless: have you not been told? | 22:57 |
| thumper | lifeless: you should be there I think | 22:57 |
| thumper | lifeless: on #ubuntu-meeting IIRC | 22:57 |
| wgrant | Can someone check buildd-manager logs to see what happened to https://edge.launchpad.net/ubuntu/+source/firefox/3.6.10+build1+nobinonly-0ubuntu3/+build/1970234? The state it's in is not one that can actually occur, and it be breaking my scripts. | 22:58 |
| wgrant | (plus it's not really awesome to have broken builds, since release is in two weeks) | 22:59 |
| lifeless | losa ping ^ where are these logs? | 23:00 |
| mwhudson | wgrant: surely it's ok for such an unimportant package! | 23:00 |
| * mwhudson runs away | 23:00 | |
| lifeless | on ppc | 23:00 |
| wgrant | lifeless: They're on devpad, from cesium. | 23:00 |
| lifeless | wgrant: after this meeting, yes. | 23:00 |
| wgrant | lifeless: Thanks. | 23:00 |
| mwhudson | wgrant: failed to build but with no log? | 23:01 |
| lifeless | wgrant: perhaps its the new das disable flag? | 23:01 |
| mwhudson | hilariously it looks like devpad has faceplanted | 23:01 |
| james_w | shouldn't affect powerpc? | 23:01 |
| wgrant | mwhudson: No log, or builder, or times. | 23:01 |
| lifeless | I thought ppc wasn't supported | 23:01 |
| lifeless | clearly I'm wrong | 23:01 |
| wgrant | It's not *supported*. | 23:02 |
| wgrant | But it is there. | 23:02 |
| wgrant | It is the only remaining community port. | 23:02 |
| mbarnett | what he said. | 23:02 |
| james_w | wgrant: maybe a repeated failure in dispatch? | 23:02 |
| james_w | I guess that's why you are asking for the logs...I'll shut up | 23:02 |
| lifeless | mbarnett: thanks | 23:03 |
| mwhudson | that code isn't deployed yet though is it? | 23:03 |
| mbarnett | :) | 23:03 |
| wgrant | mwhudson: It was in 10.09. | 23:03 |
| mwhudson | ok | 23:03 |
| === Ursinha-afk is now known as Ursinha | ||
| wgrant | lifeless: Do we have per-pageID timeouts on edge yet? | 23:13 |
| lifeless | no, matsubara's branch hasn't landed | 23:14 |
| bdmurray | should getting ReturnToReferrerMixin to work require much effort? | 23:15 |
| wgrant | :( | 23:15 |
| lifeless | james_w: when that 401 happens, does it perhaps take a long time to answer? | 23:57 |
| james_w | lifeless: no idea | 23:57 |
| lifeless | have you filed a bug ? | 23:57 |
| james_w | I've not seen it in interactive use | 23:57 |
| james_w | no | 23:57 |
| lifeless | could you? | 23:58 |
| james_w | -foundations? | 23:58 |
| james_w | lifeless: oh, I missed the response body at the top | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!