[00:02] <spm> wgrant: what's the script name? (sorry getting pulled via about 3-4 diff conversations, + phone, + doorbell....)
[00:03] <wgrant> spm: parse-ppa-apache-access-logs.py
[00:04]  * mwhudson splorfs at the test failure
[00:04] <wgrant> mwhudson: Which? The one that will hit only today and tomorrow?
[00:04] <wgrant> Or a real failure?
[00:04] <mwhudson> registry/tests/../stories/milestone/object-milestones.txt
[00:04] <wgrant> Yeah, that one.
[00:04] <mwhudson> i think it'll fail from today onwards won't it?
[00:04] <spm> wgrant: out of curiosity; how many guess do I get to work out what that script does?
[00:05] <wgrant> spm: One.
[00:05] <sinzui> I think it will only fail for the next two days
[00:05] <spm> Oooo. tricky...
[00:05] <wgrant> mwhudson: Won't it start working once the date passes?
[00:05] <mwhudson> wgrant: maybe
[00:05] <wgrant> Or once somebody changes it to year 3000. Whichever is sooner.
[00:05] <sinzui> mwhudson, None-the-less, someone should ellipsis the dates
[00:05] <mwhudson> yeah
[00:06] <mwhudson> sinzui: want to be that person?
[00:06] <mwhudson> or i can, i guess
[00:06] <wgrant> If the release had been a few hours later, this could have been very inconvenient.
[00:06] <mwhudson> hooray for easter being when it is this year?
[00:06] <sinzui> If this had been the usual release with last minute landings this would have been a disaster
[00:07] <wgrant> Yep.
[00:07] <sinzui> mwhudson, I can submit branch for the test. I wasn't planning on landing anything until PQM opens though
[00:08] <spm> wgrant: I can't find any ref to a script of that name; so i suspect it hasn't been requested yet. Or! it hasn't yet been sorted into an RT queue we have access to. But that's likely only for stuff in the past few hours max.
[00:08] <mwhudson> oh right yeah, we're not in 10.04 yet
[00:08] <wgrant> sinzui: Doesn't production-devel need it?
[00:08] <wgrant> Or we won't be able to CP critical stuff like the checkwatches fix for days.
[00:09] <sinzui> wgrant, right.
[00:09] <wgrant> spm: Damn, I guess we'll be waiting a week then. Thanks.
[00:11] <sinzui> I think the solution is obvious. The next person that has to land a branch verifies that the tests passes, and if not makes a trivial fix. ec2 will certainly tell us, and the test fails is dev so there should be no surprise
[01:41]  * mwhudson stabby
[01:50] <thumper> mwhudson: ?
[01:50] <mwhudson> thumper: oh, test environment fun
[01:53] <mwhudson> also, the tests concerned are the codehosting acceptance tests so very very slow
[01:57] <wgrant> spm: AARNet agreed!?
[01:57] <wgrant> Yay.
[01:58] <spm> wgrant: to be AU offical? technically they asked; not agreed. :-)
[01:58] <thumper> mwhudson: yeah they are
[01:58] <mwhudson> are tests allowed to depend on the hostnames being set up?
[01:59] <mwhudson> i.e. on bazaar.launchpad.dev being in /etc/hosts ?>
[01:59] <spm> wgrant: The guy who is their tech manager, for want of a better description, is a good mate (as well as of mbp too); and they get impressive benefits to their network costs by doing all this mirroring.
[01:59] <wgrant> spm: Did they also agree to be a push mirror?
[01:59] <wgrant> Very convenient.
[02:01] <spm> not sure tbh; but they are *very* keen to look into ways to better handle mirroring. so win win.
[02:01] <wgrant> Excellent.
[02:02]  * mwhudson would like a pushConfig that works cross-process
[02:08] <wgrant> Can I whip up a branch that replaces the near-constant "Development"
[02:08] <wgrant> ... status in branch listings with the MP status, if present?
[02:10] <ctrlsoft> wgrant: doesn't that assume there's at most one mp status?
[02:11] <wgrant> ctrlsoft: Yes.
[02:11] <wgrant> Which is a false assumption, but a rare case in which I'm tempted to just revert to the branch status.
[02:11] <ctrlsoft> wgrant: It's possible for a branch to be proposed for merging into multiple other branches
[02:11] <ctrlsoft> wgrant: Hmm
[02:12] <wgrant> Not optimal, but still much better than the current situation which is completely useless.
[02:12] <ctrlsoft> wgrant: I agree the current status is a bit pointless, but I'm not convinced this is the best fix
[02:13] <wgrant> If I have a couple of WIP MPs, https://code.edge.launchpad.net/~wgrant/launchpad does not help me.
[02:13] <wgrant> I have to go through all of the branches with MPs to find them.
[02:14] <ctrlsoft> wgrant: my branch listing page is useless anyway, I tend to only use +activereviews
[02:14] <wgrant> ctrlsoft: +activereviews doesn't help with inactive reviews, though :(
[02:15] <ctrlsoft> (although it's a bit better now that destroySelf() is exposed over the API :-))
[02:15] <ctrlsoft> wgrant: yeah, we need +reviews :-)
[02:15] <ctrlsoft> I'd also be nice to see reviews related to teams I'm in on that page
[02:16] <wgrant> ctrlsoft: https://code.edge.launchpad.net/~jelmer/launchpad isn't that bad.
[02:17] <wgrant> But I guess since you care about lots of other projects, it's not as useful.
[02:18] <ctrlsoft> wgrant: true, but that's mainly because I've done quite a bit of housekeeping lately
[02:18] <ctrlsoft> wgrant: I had about 3.5k branches registered, all set to development
[02:19] <wgrant> ctrlsoft: ...
[02:19] <wgrant> Whhhhhhy?
[02:30] <thumper> mwhudson: you up for a 15 min max pre-mid-impl call?
[02:32] <thumper> ctrlsoft: trying to hide?
[02:36] <ctrlsoft> thumper: Now that Branch.selfDestroy() is available over the web API I've deleted most of them :-)
[02:36] <thumper> ctrlsoft: cool
[02:36] <thumper> ctrlsoft: james_w is exposing code import registration
[02:36] <thumper> ctrlsoft: so you could create git imports :)
[02:37] <ctrlsoft> thumper: (that should also be a significant part of your remote branches gone)
[02:37] <thumper> \o/
[02:37] <ctrlsoft> thumper: (-:
[02:37] <wgrant> Wasn't the remote branch UI going to die at some point?
[02:38] <ctrlsoft> thumper: It'd be interesting to use the Vcs-* headers in Debian packages to set up automatic imports for all Debian packages once Launchpad starts supporting code imports for packaging branches
[02:38] <lifeless> ctrlsoft: they aren't sufficient to do packaging improts
[02:39] <ctrlsoft> lifeless: not as the canonical branch perhaps, but it'd be interesting to have them around and be able to merge from them
[02:40] <wgrant> It would be nice if there was some consistency in package version control.
[02:40] <wgrant> Nobody in Debian seems sure whether they are meant to be versioning debian/ or everything.
[02:40] <wgrant> Or whether they are based on the upstream branch or not.
[02:41] <mwhudson> thumper: sure
[02:41] <thumper> wgrant: how broken is the build branch into source package job?
[02:41] <wgrant> thumper: It works perfectly.
[02:41] <thumper> mwhudson: although I'm about to run and get a coffee before collecting the girls from school
[02:41] <wgrant> We've run it on DF.
[02:41] <thumper> wgrant: I heard that there were bugs
[02:41] <mwhudson> thumper: ok, ping me when you get back i guess
[02:41] <thumper> when bigjools tried recently
[02:41] <thumper> mwhudson: ok
[02:42] <wgrant> thumper: There were issues testing it on DF because of firewalls and broken slaves.
[02:42] <wgrant> Oh, right, there are two sorta-bugs.
[02:42] <thumper> ah, but on the whole it is good?
[02:42] <wgrant> 1) Scoring isn't implemented.
[02:42] <wgrant> 2) Things crash if you set it to non-virtualized.
[02:42] <wgrant> But the latter should never happen.
[02:43] <wgrant> Right, apart from those couple of minor things it works fine.
[02:43] <wgrant> The second one may well be magically fixed in the model rework.
[02:43] <wgrant> The first we have no algorithm for.
[02:44]  * thumper really afk for coffee run
[03:05] <wgrant> So, cron.publish-ftpmaster now timestamps all of its steps nicely. Can I get hold of the log for a couple of runs to work out where I can cut out more time?
[03:06] <james_w> ctrlsoft: that's exactly my plan for doing the work
[03:07] <ctrlsoft> james_w: great :-)
[03:07] <ctrlsoft> gmta ;-)
[03:07]  * james_w is wondering how to get Debian to adopt Vcs-*-upstream:
[03:08] <ctrlsoft> james_w: wasn't there some talk about half a year ago about having that in debian/watch ?
[03:08] <ctrlsoft> (I prefer a control header as well, though)
[03:08] <james_w> yeah, I think so
[03:09] <james_w> but every time you propose a new control header people complain about it bloating the size of the Sources file etc.
[03:15] <ctrlsoft> james_w: I wouldn't mind debian/watch if it didn't have such an obscure syntax
[03:15] <james_w> yeah
[03:15] <james_w> we'd need a new watch file format to do it properly
[03:16] <thumper> mwhudson: ping
[03:18] <wgrant> thumper: Also, bug #552976
[03:18] <mup> Bug #552976: SourcePackageRecipeBuild security needs work <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/552976>
[03:18] <thumper> mwhudson: yeah, was just reading that in my inbox
[03:19] <mwhudson> thumper: hi
[03:19] <thumper> mwhudson: skype?
[03:19] <mwhudson> thumper: unless you want to try mumble, sure
[03:20] <thumper> mwhudson: haven't tried mumble
[03:20] <thumper> what do I need to do?
[03:20] <mwhudson> ah you need to get an account from IS
[03:20] <mwhudson> skype it is then i guess
[03:20] <wgrant> Why not use Jabber?
[03:21] <wgrant> Empathy XMPP video chat works fine these days.
[03:21] <wgrant> s/video/audio/
[03:21] <thumper> ETOOMANYOPTIONS
[03:25] <wgrant> What's the official plural of 'series' these days?
[03:26] <wgrant> I thougt it was recently changed to 'serieses'
[03:26] <wgrant> But I don't see that used anywhere.
[03:43] <thumper> wgrant: series
[03:43] <thumper> wgrant: all the serieses were changed to series
[03:43] <wgrant> Oh.
[03:43] <mwhudson> i think if you use anything else mpt kills you in your sleep
[03:43]  * wgrant goes back to 'for das in archseries:'
[04:00] <thumper> Total: 26259 tests, 54 failures, 6 errors in 224 minutes 52.774 seconds. ;-(
[04:00] <thumper> best fix them then
[04:01] <thumper> ah
[04:02] <thumper> I wondered if there'd be much fallout from that
[04:02] <thumper> glock tweak
[04:08] <thumper> hmm, lots of breaks
[04:14] <mwhudson> ah yeah
[04:18]  * thumper afk for pizza
[04:50] <thumper> man some doc tests are slooooow
[05:43]  * thumper is still fixing tests
[06:02] <thumper> what was the solution to the GpgmeError ?
[06:02] <thumper> GpgmeError: (32, 176, 'Unknown error code')
[06:02]  * thumper tries make clean build
[06:03] <wgrant> thumper: Patch pygpgme.
[06:03] <thumper> ?!?
[06:03] <thumper> why do I have to?
[06:03] <wgrant> Because the fix hasn't landed yet.
[06:03]  * thumper sighs
[06:03] <wgrant> It's an incompatibility with the new gpg in Lucid.
[06:03] <thumper> where is the reference to the fix?
[06:04] <wgrant> https://code.edge.launchpad.net/~jelmer/launchpad/new-gpgme/+merge/22093
[06:04] <wgrant> http://bazaar.launchpad.net/~launchpad-pqm/pygpgme/devel/revision/46.1.23 is the actual diff.
[06:07] <thumper> ta
[06:09]  * thumper just merges jelmers branch
[06:17] <thumper> ok, now it should pass
[06:17]  * thumper runs the test again
[06:17] <thumper> :(
[06:17] <thumper> ImportError: No module named _gpgme
[06:17] <thumper> gah
[06:18] <wgrant> make?
[06:18] <thumper> yeah, doing that now
[06:19] <thumper> this branch has become the one that won't die
[06:19] <thumper> or perhaps
[06:19] <thumper> the branch that won't pass the freaking tests
[06:19] <thumper> \o/ passing now
[06:19] <thumper> at least that one
[06:19] <wgrant> Which branch?
[06:24] <thumper> https://code.edge.launchpad.net/~thumper/launchpad/all-code-review-email-using-jobs/+merge/22439
[06:24] <wgrant> Ah, yay.
[06:28]  * thumper stops for now
[07:39] <jtv> wgrant: coming across one problem when simulating build slaves...  I think python-asn1 just dropped into universe.
[07:40] <wgrant> jtv: What is that and why is it important?
[07:41] <jtv> wgrant: it seems to be indirectly required by launchpad-buildd.
[07:41] <jtv> And the slave's sources.list is set up for main only.
[07:42] <StevenK> jtv: I can't find a package with that name at all
[07:42] <wgrant> jtv: The slave's sources.list doesn't matter, except for translations jobs which don't override it.
[07:42] <wgrant> StevenK: Same here.
[07:42] <jtv> StevenK: sorry, python-pyasn1
[07:42] <jtv> wgrant: ahhh
[07:42] <StevenK> It's been universe since .
[07:42] <wgrant> Ah, right.
[07:44] <wgrant> It's been in universe forever, yeah.
[07:44] <wgrant> conch requires it.
[07:44] <wgrant> and twisted requires conch.
[07:44] <wgrant> Hmmm.
[07:47] <wgrant> jtv: Do you know of any further changes that will be necessary for the translations slave? lamont wants to push out a new lp-buildd tomorrow.
[07:48] <wgrant> I would also appreciate a review of my get-translations-jobs-working, so the buildd hunk can be included in tomorrow's buildd rollout.
[07:48] <noodles775> wgrant: did bigjools re-paste that buildd crash? Apparently I can't access the paste either ;) If not, I'll repaste it once I get access.
[07:49] <wgrant> noodles775: bigjools was gone. lamont poked me a few hours ago and we worked it out.
[07:49] <noodles775> wgrant: ah, great.
[07:49] <jtv> wgrant: I can review that for you today, sure.  With pleasure, in fact.
[07:49] <wgrant> jtv: Thanks. It's tiny.
[07:49] <jtv> Okay, make that lots of pleasure.
[07:49] <noodles775> wgrant: what was the issue?
[07:49] <wgrant> noodles775: Running post-Wellington code with a pre-Wellington buildd-slave.tac.
[07:50] <noodles775> Ah.
[07:50] <wgrant> Easy to do, because buildd-slave.tac is copied in by a non-standard target.
[07:50] <jtv> wgrant: I don't have any further changes for launchpad-buildd in the pipeline right now, but this one would be important.  I can file a bug and work on it today.
[07:52] <wgrant> jtv: While I remember: the branch that you create on the wiki page caused an odd crash in the slave, so I ended up using a real source tree, which worked fine.
[07:52] <adeuring> good morning
[07:52] <noodles775> morning adeuring
[07:52] <wgrant> Morning adeuring.
[07:52] <adeuring> hi noodles775, wgrant!
[07:52] <jtv> wgrant: the branch that I create on the wiki page?
[07:53] <wgrant> jtv: The wiki page gives a sequence of commands to create a branch to pass to the slave.
[07:53] <noodles775> wgrant: I spoke with bigjools yesterday about the schema change, and updated the MP with his comments if you're interested. https://code.edge.launchpad.net/~michael.nelson/launchpad/db-build-generalisation-db-changes/+merge/22527
[07:54] <jtv> wgrant: ah... it's a pretty minimal setup, probably not sufficient.  It's never mattered in the past because things would break before it could.
[07:54] <wgrant> noodles775: Hmm, I don't like BuildBase.
[07:54] <noodles775> wgrant: why not?
[07:54] <noodles775> (There's already a interface/class for it, it's just not yet a db-table)?
[07:54] <jtv> wgrant: if we pick a sample branch from LP that people could just pull and then push locally, that'd work too.  Do you know of a conveniently small one?
[07:55] <wgrant> jtv: No. I ended up hacking configure.ac or similar in hello to contain the GETTEXT_PACKAGE line that pottery looks for.
[07:55] <wgrant> I couldn't find one that worked OOTB.
[07:56] <wgrant> Though I didn't look hard.
[07:56] <wgrant> noodles775: BuildBase seems a lot less obvious that BuildFarmJob.
[07:56] <wgrant> s/that/than/
[07:56] <wgrant> I've always regretted calling it that.
[07:56] <wgrant> It is ugly.
[07:57] <noodles775> wgrant: It is, but only because it should really be called simply "Build" right?
[07:57] <jtv> wgrant: there has to be at least one that works out of the box, or I'll feel terribly pointless.  :)
[07:58] <noodles775> And the only reason we don't call it Build right from the start is because that table already exists and will need to exist until we've got all the changes finished (in the pipeline of branches).
[07:58] <noodles775> So we could rename it to simply Build at the end?
[07:58] <wgrant> noodles775: A SourcePackageRecipeBuild shouldn't have a Build.
[07:58] <wgrant> That's going to be terribly confusing.
[07:59] <noodles775> wgrant: huh? It needs to have a build doesn't it? Now I'm confused. If a SPRecipeBuild is to have a date_started etc., that info is coming from the underlying build? Hrm, do you want to call about this and explain? or prefer IRC.
[08:00] <wgrant> BuildFarmJob makes it abundantly clear what it is, and where it runs.
[08:00] <noodles775> Yes, which is why I initiall suggested ServerFarmBuild (but from what you're saying, that's not nice either).
[08:01] <jtv> wgrant: bug 553077
[08:01] <mup> Bug #553077: Build slave needs universe package <buildfarm> <Launchpad Translations:In Progress by jtv> <https://launchpad.net/bugs/553077>
[08:02] <wgrant> noodles775: These jobs needn't all be builds. If we call them jobs, we are more generic *and* we avoid confusion when talking about the concrete build types.
[08:02] <wgrant> jtv: I am confused
[08:03] <wgrant> jtv: Why does the slave's sources.list matter?
[08:03] <wgrant> One doesn't install the slave in the slave.
[08:03] <jtv> wgrant: ah, of course!  We're not emulating the chroot inside the chroot!
[08:04] <jtv> This all gets so confusing
[08:04] <jtv> No wait
[08:04] <noodles775> wgrant: OK, so some jobs are builds, others may not be. OK.
[08:04]  * noodles775 remembers the discussion at the sprint now.
[08:05] <jtv> wgrant: we _are_ running launchpad-buildd on the slave, and that needs universe.
[08:05] <wgrant> jtv: But the slave host's sources.list is out of our control.
[08:05] <wgrant> We only control the one in the chroot, where we don't need to install launchpad-buildd.
[08:06] <jtv> wgrant: okay, but launchpad-buildd started breaking for me.  It's gotta be pretty recent.
[08:06] <wgrant> jtv: What's it breaking with?
[08:07] <jtv> wgrant: no installable candidate
[08:07] <jtv> referenced by another package but not available
[08:07] <jtv> so I guess one of the packages we depend on in lucid sprouted a universe dependency in the past few weeks.
[08:07] <wgrant> It's possible that python-twisted's dependencies have been strengthened lately.
[08:08] <wgrant> I have to wonder if lp-buildd really needs more than python-twisted-core.
[08:08] <jtv> yes... iirc it pulls in something like python-twisted-conch which in turn depends on python-pyasn1
[08:08] <noodles775> wgrant: is this the same crash as earlier? bug 553068
[08:08] <mup> Bug #553068: buildd-retry-depwait.py crashing <Launchpad itself:New> <https://launchpad.net/bugs/553068>
[08:09] <wgrant> noodles775: No, completely unrelated. It's code I've touched recently... but it hasn't landed yet.
[08:09]  * wgrant looks.
[08:10] <wgrant> But... what.
[08:12] <wgrant> Oh, I think I recall that code changing around the middle of 10.03.
[08:12]  * wgrant checks.
[08:12] <wgrant> It shuffled in there from another private method.
[08:12] <wgrant> Come on, annotate...
[08:12] <StevenK> blame!
[08:13] <wgrant> qannotate, actually.
[08:13] <StevenK> I wonder if gblame works too
[08:13] <StevenK> Er, qblame
[08:13] <wgrant> Yay it crashed.
[08:13] <jtv> wgrant: looking at your branch... these are changes I looked at a bit yesterday, in fact.  Tip for this kind of MP: explain why each of the problems can't be integration-tested (or if you can't, well...  ;-)
[08:14] <jtv> Saves lots of potential back-and-forth on the review, and sometimes leads to testing breakthroughs
[08:14] <wgrant> Good point.
[08:16] <wgrant> ctrlsoft: /win 5
[08:16] <wgrant> Oops.
[08:17] <wgrant> StevenK: Ahahaha
[08:17] <wgrant> You are to blame.
[08:17] <wgrant> Nice of you to suggest it :P
[08:18] <StevenK> Oh crap, I am?
[08:18] <wgrant> Yeah.
[08:18] <wgrant> 10565
[08:18] <wgrant> er, 10566
[08:19] <wgrant> It was the one I thought.
[08:19] <wgrant> You probably meant selectFirstBy. selectOneBy raises an exception if there's more than one.
[08:20] <wgrant> StevenK: But why did you change from the list comprehension at all?
[08:20]  * StevenK is looking for the branch locally
[08:21] <wgrant> StevenK: http://pastebin.ubuntu.com/407455/
[08:22] <wgrant> The test which used to catch that sort of thing is... gone.
[08:22] <StevenK> wgrant: I thought ArchiveDependency only had one thing in it, though?
[08:22] <wgrant> StevenK: It maps an archive to zero or more dependency archives.
[08:23] <StevenK> I saw all through the ArchiveDependency code that only 1 depends is supported
[08:23] <wgrant> One dependency per dependency archive.
[08:23] <wgrant> That is, UNIQUE (dependent, dependency)
[08:23] <wgrant> Not just UNIQUE (dependent)
[08:24] <StevenK> Getting that test back would be nice, or was that I removed because it used expanded_archive_dependencies?
[08:25] <wgrant> I'm not entirely sure why you removed it.
[08:25] <wgrant> Why you removed expanded_archive_dependencies, that is.
[08:26] <StevenK> There was a bug about it
[08:26] <StevenK> cprov said it was only used by one bit and should die
[08:26] <wgrant> Bug #300004
[08:26] <mup> Bug #300004: Archive.expanded_archive_dependencies() is obsolete and should be removed <qa-untestable> <tech-debt> <trivial> <Soyuz:Fix Committed by stevenk> <https://launchpad.net/bugs/300004>
[08:26] <wgrant> It seems odd that it's not used by the sources.list code.
[08:36] <StevenK> Right, I have a diff. But I'm unhappy that the tests didn't pick it up
[08:36] <wgrant> Well.. you removed them :P
[08:37] <StevenK> The test was calling a method I removed, so ...
[08:37] <wgrant> Indeed.
[08:40] <jtv> oh damn, I just realized: we're not getting any launchpad-buildd fixes in today unless it's RC.
[08:42] <wgrant> jtv: lamont already has a change on top of trunk.
[08:42] <wgrant> As long as they're reviewed and noodles is happy, he is happy.
[08:44]  * jtv likes happy
[08:53] <jtv> hi henninge
[08:53] <henninge> Hi jtv! ;)
[08:56] <jtv> henninge: we're a lot closer to working buildfarm jobs... wgrant is working on integration-testing the tarball uploads, and I'm working on an accidental new dependency of launchpad-buildd on a universe package.
[08:57] <wgrant> jtv: So, I think just try relaxing the dep to twisted-core, remove the rest, and see what happens.
[08:57] <henninge> jtv: great! what can I work on?
[08:57] <henninge> oh, the auto-approval ...
[08:58] <henninge> ;-)
[08:58] <jtv> henninge: enjoy :-P
[08:58]  * wgrant wondered why it wasn't auto-approved.
[08:58] <jtv> wgrant: that's what I'm trying... except: what is "the rest"?
[08:59] <wgrant> jtv: python-twisted*
[08:59] <wgrant> Anything that python-twisted depends upon.
[09:00] <jtv> gah:
[09:00] <jtv>   File "/usr/share/launchpad-buildd/canonical/buildd/slave.py", line 20, in <module>
[09:00] <jtv>     from twisted.web import xmlrpc
[09:00] <jtv> exceptions.ImportError: No module named web
[09:00] <wgrant> Depend upon python-twisted-web.
[09:00] <jtv> So we may have to add some twisted "sub-packages" as well
[09:00] <henninge> Hi wgrant! ;)
[09:00] <wgrant> Morning henninge.
[09:01] <jtv> wgrant: there wasn't any other python-twisted* AFAICS
[09:02] <wgrant> jtv: python-twisted-web has existed since at least Dapper.
[09:03] <jtv> No I mean, I saw no other python-twisted dependencies in launchpad-buildd besides python-twisted.
[09:03] <wgrant> jtv: Right, because python-twisted depends upon python-twisted-*
[09:03] <jtv> And that was where I got confused about the "remove the rest."  :-)
[09:04] <wgrant> Hmm.
[09:04] <wgrant> But.
[09:04] <wgrant> Actually, this may not be a problem.
[09:04] <jtv> yay, launchpad-buildd is running!
[09:04] <wgrant> jtv: I meant to actually remove those packages from your system.
[09:04] <jtv> oh
[09:04] <jtv> I'm working in a chroot
[09:04] <wgrant> jtv: grep around for any more twisted imports.
[09:05] <jtv> And for this I set up a fresh one
[09:05] <jtv> good idea.
[09:05] <wgrant> It turns out that this wasn't actually our bug at all; it's archive brekage.
[09:05] <wgrant> But we should do this dependency minimalisation anyway.
[09:05] <wgrant> (python-pyasn1 is a new dependency, and hasn't been promoted yet. it probably will be on Monday)
[09:05] <mrevell> Morning.
[09:05] <wgrant> StevenK: Is that known ^^?
[09:05] <jtv> twisted.application, twisted.python, twisted.internet
[09:05] <jtv> hi mrevell!
[09:06] <wgrant> jtv: All of those are core.
[09:06] <wgrant> Morning mrevell.
[09:06] <jtv> great.
[09:06] <jtv> And from my despot days I seem to remember a rule: keep your slaves lean.  If you find yourself with a fat slave, unless it's your food taster, you have a problem.
[09:07] <wgrant> jtv: Heh.
[09:07] <wgrant> So, yes, this was unnecessary, but a good idea anyway.
[09:07] <StevenK> wgrant: I can't recall seeing it. Does it have an MIR?
[09:08] <jtv> wgrant: I don't think it's unnecessary per se...  transient breakage in dev test setups is still a nuisance.
[09:08] <wgrant> StevenK: Ah, yeah. Bug #552863
[09:08] <mup> Bug #552863: [MIR] please promote pyasn1 <pyasn1 (Ubuntu):New> <https://launchpad.net/bugs/552863>
[09:10] <StevenK> wgrant: Right, so the person to bug next is pitti.
[09:10] <wgrant> StevenK: Well, the longer it stays broken the more likely we are to fix the excessive deps...
[09:14] <StevenK> wgrant: I can promote before the MIR is approved, I just don't like doing it
[09:14] <wgrant> StevenK: I think my last statement was in support of making it take as long as possible.
[09:15] <StevenK> Sorry, I misread it
[10:31] <jtv> wgrant: just found one more twisted import in buildd... twisted.mail.  Is that in core?
[10:31] <wgrant> jtv: It's not, but isn't that only used by sequencer.py?
[10:32] <jtv> Yes.
[10:32] <jtv> It wasn't installed with the rest of the stuff on the slave, which is why I didn't see it before.
[10:32] <wgrant> Yeah, that is part of a very ancient master.
[10:32] <wgrant> It probably hasn't been run in years.
[10:32] <jtv> I don't see it being used anywhere...
[10:32] <wgrant> And isn't part of the buildd, so it doesn't matter.
[10:32] <jtv> Maybe we should kill the file at some point then?
[10:33] <wgrant> I have a buildd cleanup campaign planned. And partly implemented.
[10:33] <jtv> yay
[10:33] <wgrant> At the moment it's a mess of slave code, non-slave code, obsolete slave docs, obsolete non-slave docs...
[10:33] <jtv> btw please let me know when that last test is pushed.  I'm itching to approve that MP!
[10:33] <wgrant> jtv: Yeah, got distracted again. Just committed it now.
[10:36] <wgrant> noodles775: Ah, I just realised why you had to ask about the buildd crash earlier. I sent an email several hours ago explaining that lamont had poked me, but it was still sitting in my outbox for no obvious reason.
[10:38]  * jtv just had his fs go read-only again and is about to disappear for a while.
[10:38] <noodles775> wgrant: heh, yep, the last email I had was you saying you didn't have access to the paste :)
[10:38] <wgrant> jtv: That started happening to me again yesterday.
[10:38] <jtv> noodles775: I have to leave to deal with various broken systems, but would very much appreciate review: https://code.edge.launchpad.net/~jtv/launchpad/bug-553077/+merge/22599
[10:38] <noodles775> jtv: yep, one of us will do it asap :)
[10:38] <wgrant> It happened twice, around a failed suspend. I hadn't had a suspend failure in years before then, so I'm not really sure which is the cause and which is the effect.
[10:39] <jtv> wgrant: for a while I thought it was just the temperatures...  I had one HD operating in a room that was about 40°C and it broke, and another broke while in a room that must have been around 10°C.  But now it's happening more randomly AFAICS
[10:39] <jtv> noodles775: thanks
[10:39] <wgrant> jtv: Yeah, it's been happening to me since mid-December. But it only happened a couple of times between Wellington and yesterday.
[10:40] <wgrant> And it's fortunately only /, so /home doesn't get horribly corrupted.
[10:40] <wgrant> Also, those new tests are pushing... slowly...
[10:40] <jtv> "only a couple of times"?  Ted T'so was sitting right in front of me at the bzr session, I could easily have whacked him over the head.  He even gave me an excuse.
[10:40] <jtv> Spilt milk I guess.
[10:40] <wgrant> Hahaha.
[10:40] <jtv> yes, bzr has slowed down a lot it seems.
[10:41] <wgrant> It's a combination of LP and bzr.
[10:41] <wgrant> And crappy upstream bandwidth.
[10:42] <jtv> that reminds me to go buy that new switch
[10:42] <jtv> ...and fsck
[10:43] <wgrant> Plymouth has this really nice feature where it breaks if your filesystem needs a manual fsck, like mine tends to after one of those.
[10:43] <wgrant> s/Plymouth/mountall/, I guess.
[10:44] <jtv> Guess what I'm about to do again...
[10:46] <wgrant> jtv: It's not actually an FS problem, AFAICT.
[10:46] <wgrant> The actual block device is read-only.
[10:46] <wgrant> I am on LVM - are you?
[10:46] <jtv> wgrant: your diff just updated; thanks for extending FakeMethod.  I had this feature in an early iteration but no use-case for it yet.  One tiny thing more: a full stop at the end of your assertion string.  :)
[10:47] <jtv> No, not on LVM AFAIK
[10:47] <wgrant> Hm. Damn.
[10:47] <jtv> (I haven't used LVM for a while... never really liked ti)
[10:47] <jtv> *it
[10:49] <wgrant> jtv: Full stop added.
[10:49] <jtv> wgrant: and approved.  Thanks again!
[10:49] <jtv> And now, off to deal with everything being broken
[10:49] <jtv> NO CARRIER
[10:50] <wgrant> noodles775, jtv: Thanks for the reviews.
[10:50] <jtv> pleasure
[10:51] <wgrant> noodles775: Can you please mark https://code.edge.launchpad.net/~wgrant/launchpad/bug-549340-fix-buildqueue-destruction/+merge/22286 as Rejected?
[10:51] <wgrant> Apparently I cannot.
[11:03] <deryck> Morning, all.
[11:13] <noodles775> wgrant: no problem, and done.
[11:24] <wgrant> noodles775: Thanks.
[11:46] <henninge> What could be the reason for the test framework to fail with "no module named meliae" and "No module named setproctitle" ?
[11:48] <wgrant> henninge: bin/buildout
[11:48] <wgrant> 'make' might do it too, but didn't in a couple of branches here.
[11:48] <henninge> oic
[11:49] <henninge> wgrant: yes, that's what I would have assumed.
[11:49] <henninge> now this:
[11:49] <henninge> Error: There is a version conflict.
[11:49] <henninge> We already have: zope.interface 3.5.3
[11:49] <wgrant> henninge: Lucid?
[11:49] <henninge> yup
[11:50] <wgrant> henninge: I resolved that by installing Karmic's 3.5.2.
[11:50] <wgrant> It probably needs some buildout god to fix it.
[11:50] <wgrant> Or we just upgrade Launchpad to use 3.5.3.
[12:00] <henninge> wgrant: thanks.
[12:12] <ctrlsoft> is there a particular reason the buildd slave package lives in the main launchpad branch ?
[12:12] <ctrlsoft> it seems like it would be quite easy to split off
[12:12] <wgrant> ctrlsoft: You are the third person to say that today.
[12:12] <wgrant> It depends on the rest of Launchpad for two things: testing infrastructure, and tachandler.
[12:13] <wgrant> I believe jml was looking at that. Although that may not have ended up happening.
[12:13] <jml> everything I look at withers under my gaze
[12:13] <wgrant> Hm, is USSO meant to be read-only?
[12:18] <jml> wgrant, I didn't do anything about it, I just got pissed off and wrote an angry note in my todo lists. I've got two branches on my plate now, which is basically my limit.
[12:19] <wgrant> jml: Heh.
[12:20] <jml> ctrlsoft, but I think it would be quite easy to split off.
[12:20] <jml> the toughest bit is deciding whether to extract the shared dependencies between it and LP, or whether to just duplicate them
[12:21] <jml> and if the former, deciding what to do.
[12:42] <ctrlsoft> jml, wgrant: ah, ok
[12:59] <jml> so, in case you weren't following on #twisted
[12:59] <jml> they think that tachandler is a bad idea, but that something like it could be achieved by giving twistd more of an API
[13:00] <jml> (something which has been a goal for twistd for ages)
[13:02] <jml> if I were doing the buildd split, I would just copy tachandler.
[13:02] <wgrant> jml: Note that Translations' odd obsession with not having tonnes of untested code means that lp-buildd now has test dependencies on LP.
[13:04] <jml> wgrant, which bits?
[13:05] <wgrant> jml: TestCase, FakeMethod and TestCaseWithFactory from lp.testing.
[13:05] <wgrant> The last sounds awkward.
[13:06] <jml> wgrant, I'm saying this in total ignorance of the code, but...
[13:06] <jml> wgrant, I reckon we could come up with a better testing strategy.
[13:06] <wgrant> Almost definitely.
[14:00] <leonardr> is anyone else having time-sensitive test failures for registry/stories/milestone/object-milestone.txt?
[14:01] <sinzui> yes
[14:01] <salgado> leonardr, it's been fixed on db-devel already
[14:58] <gary_poster> noodles775: does your release-critical landing fix the existing failure in the branch that is running?
[14:58] <gary_poster> well, disable :-)
[14:59] <noodles775> gary_poster: yes, it disables the test and I created bug 553259.
[14:59] <mup> Bug #553259: buildd-slave.txt has a timing issue <Soyuz:Confirmed> <https://launchpad.net/bugs/553259>
[14:59] <gary_poster> thank you noodles775, great
[15:21] <sinzui> bac: ping
[15:21] <bac> yes, sinzui?
[15:21] <sinzui> bac: I am looking at the end of tests/product-views and the start of product-portlet-packages-views ...
[15:22] <sinzui> product-views doesn't seem to be doing much, and what it does is already tested in product-portlet-packages-views
[15:22] <sinzui> bac: do you agree?
[15:23] <bac> let me look
[15:23]  * sinzui was looking for a test that the form creates a Packaging object
[15:24] <bac> sinzui: yes that looks like a c-n-p error where the cut didn't happen
[15:24] <sinzui> as I thought. I will remove it now
[15:38] <Ursinha> sinzui, hi, do you know what's this oops about? https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1551O2750
[15:41] <sinzui> Ursinha, someone using wget is trying to automate launchpad. He is not passing a referer so we do not trust him
[15:41] <sinzui> Ursinha, gary_poster know the issue well. The user should be using API
[15:42] <Ursinha> sidnei, hmm, I see
[15:42] <gary_poster> Ursinha: yes, that should not be an OOPS
[15:42] <Ursinha> gary_poster, want me to file a bug for that?
[15:42] <sidnei> Ursinha, good to know! *wink*
[15:42] <Ursinha> sidnei, sorry :)
[15:43] <gary_poster> Ursinha: yes, thank you
[16:07] <Ursinha> gary_poster, I have another oops here, do you know what's happening?  https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1552C764
[16:09] <salgado> Ursinha, looks like someone attempting to login while login.lp.net was down.  (it was scheduled to go down for a few minutes at around 9:00UTC today)
[16:10] <salgado> Ursinha, care to file a bug asking for better error handling when the OP is down?
[16:10] <Ursinha> salgado, I see
[16:10] <Ursinha> salgado, sure, will do that
[16:10] <gary_poster> thanks salgado
[16:10] <Ursinha> salgado, thanks
[16:13] <salgado> np
[16:33] <Ursinha> sinzui, have you seen this oops before: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1552A1029
[16:35] <sinzui> Ursinha, maybe. I think this is cause by a deactivated product that is linked to a package...this should not happen, but I recall seeing this once in production and I reactivated the product
[16:36] <sinzui> Ursinha, yes! that is the case. I will fix activate the project, or remove the link and report a bug that this is happening.
[16:37] <Ursinha> thanks sinzui
[16:39] <sinzui> Ursinha, I can get a report of this cases in production from the staging db on Sunday,  can fix the data issues. We will need a code change to ensure projects linked to packages cannot be deactivated.
[16:40] <Ursinha> right
[16:40] <Ursinha> sinzui, want me to file the bug
[16:40] <Ursinha> ?
[16:40] <sinzui> I am doing that now
[16:41] <Ursinha> ok
[16:54] <Ursinha> Chex, gary_poster, rockstar, bigjools, danilos, sinzui, allenap, production meeting @ Freenode #launchpad-meeting in 5 minutes
[16:55] <gary_poster> thanks
[16:55] <sinzui> me
[16:55] <maxb> leonardr: Can I trouble you to add a missing tag to the launchpadlib branch? I've checked the branch against the tarball to verify the revision. command: bzr tag -d lp:launchpadlib -r revid:leonard.richardson@canonical.com-20100304202437-68ykm4fpbio8jdid 1.5.6
[16:56] <leonardr> max, sure
[16:56] <leonardr> i now have a scirpt that tags releases as part of the release process btw
[16:56] <leonardr> done
[16:59] <Ursinha> stub, are you joining us in the meeting? I'm not expecting that :)
[17:00] <stub> I just emailed my bit :)
[17:00] <Ursinha> stub, thanks
[17:00] <stub> I am supposed to be enjoying myself somewhere right about now...
[17:00] <Ursinha> stub, go for it then :)
[17:01] <Ursinha> Chex, gary_poster, rockstar, bigjools, danilos, sinzui, allenap, production meeting @ Freenode #launchpad-meeting now :)
[17:02] <Ursinha> al-maisan, hi, want to join us in prod. meeting in behalf of bigjools? :)
[17:02] <al-maisan> Ursinha: sorry but I am not part of the launchpad team any more.
[17:04] <Ursinha> al-maisan, oh oh sorry, it's true
[17:05] <maxb> thanks leonardr
[17:05] <leonardr> np
[17:06] <al-maisan> Ursinha: :)
[17:27] <kfogel> adeuring: got a sec?
[17:31] <kfogel> intellectronica: test suite question for you, got a minute?
[17:33]  * kfogel rotates around the members of his team
[17:33] <kfogel> gmb: test suite question for you, got a minute?
[17:40] <sinzui> did someone add distroseries data to sampledata?
[17:42]  * sinzui is seeing a tremendous amount of insane packaging data now. This crack cannot be created using the UI
[18:09] <gary-lunch> Ursinha: fix for https://launchpad.net/bugs/547054 ("AssertionError: Don't try to render this page when the user is logged in.") was not in roll-out; will be in CP
[18:09] <mup> Bug #547054: AssertionError: Don't try to render this page when the user is logged in. <oops> <Launchpad Foundations:Fix Committed by salgado> <https://launchpad.net/bugs/547054>
[18:10] <Ursinha> gary-lunch, ah, cool, thanks!
[18:10] <gary-lunch> :-)
[18:13] <adeuring> kfogel: sorry, i was away. how can i help?
[18:14] <kfogel> adeuring: ah, well, I think I've found a workaround, but in a minute I'll present you with a paste that contains the question
[18:14] <kfogel> adeuring: (just need to run a test first)
[18:15] <adeuring> kfogel: ok, no hurry ;)
[18:21] <kfogel> adeuring: ok, so http://paste.ubuntu.com/407667/ works (note the branch has code changes already committed, this is just about the test suite).
[18:22] <kfogel> adeuring: but http://paste.ubuntu.com/407669/ does NOT work
[18:22] <kfogel> adeuring: I'm wondering why I can't reuse bug_11.messages.  I realize its value might be out-of-date by now and I'd need to refresh it, but I shouldn't be seeing the failure I am seeing, AFAIK.
[18:27] <adeuring> kfogel: without having had a look at the complete test file: Did you perhaps call logout(9 before the failing line?
[18:27] <kfogel> adeuring: yep
[18:27] <kfogel> adeuring: I mean, I didn't call it, but pre-existing code does, to be preice
[18:27] <kfogel> precise
[18:28] <adeuring> kfogel: OK, so, a login() might help :)
[18:30] <kfogel> adeuring: thanks.  Now that I understand what was going on, I think I'll stick with my existing method for finding the last index, which works fine too and doesn't require a login.
[18:30] <adeuring> kfogel: yes, makes sense
[18:33] <adeuring> kfogel: but: I think the test would be even better if you showed that the admin user _has_ accesss to the URL you are opening in user_browser. The "not Found" message might have completely different causes than what you want to test.
[18:40] <kfogel> adeuring: can do
[18:46] <kfogel> adeuring: why do our tests no longer seem to show +actual output?
[18:46] <kfogel> adeuring: or am I doing something wrong?
[18:47] <adeuring> kfogel: I didn't notice this problem yet...
[18:49] <kfogel> adeuring: I run bin/test -vvct foo, with dummy expected output, but when the test fails, it just shows the "-" lines, no "+" lines
[18:49] <kfogel> adeuring: you see + lines?
[18:50] <kfogel> adeuring: for example http://paste.ubuntu.com/407679/
[18:50] <adeuring> kfogel: admittedly, I did not ran failing doc tests todays
[18:50] <adeuring> let me try...
[18:51] <kfogel> adeuring: oh, I think I might be making a braino, hold on
[18:51]  * kfogel hates on the way every experiment costs 30 seconds
[18:52] <adeuring> ;)
[18:52] <kfogel> yeah, braino
[18:59] <kfogel> adeuring: okay, I'm baffled
[19:00] <kfogel> I'm trying lots of ways to match the output, but I can't.
[19:00] <kfogel> http://paste.ubuntu.com/407683/
[19:00] <kfogel> adeuring: you can see the failure, with expected vs actual, and at the very end you can see the relevant part of the diff
[19:02] <jml> g'night all
[19:03] <adeuring> kfogel: admin_browser.contents contains the enitre HTML page. You want to use extract_text(...)
[19:03] <kfogel> adeuring: erp
[19:03] <kfogel> adeuring: thank you.  It's been great having you help me today, my first day ever programming Launchpad, or Python for that matter.
[19:04] <kfogel> Where's the on/off switch on this thing, now...?
[19:04] <adeuring> kfogel: there are these days, where everything fails :) Usually a sgin that you need some holidays ;)
[19:05] <kfogel> adeuring: "Holiday".  I've heard people use that word a few times in the last few days.  Is it defined in the internal wiki somewhere?
[19:06] <kfogel> Oor should I just google it?
[19:06] <adeuring> kfogel: probably ;)
[19:30] <kfogel> deryck: how did bug #544843 get filed in Launchpad Bugs?  It seems like a change in Apport's behavior to me (and I'm not sure whether it's a bug or not, though the fact that Martin Pitt thinks it is is persuasive).
[19:30] <mup_> Bug #544843: Bug reports with +storeblob now attach the raw file <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/544843>
[19:31] <deryck> kfogel, it is our bug.
[19:31] <deryck> kfogel, something gmb did with the recent storeblob work for processing large data files offline has changed so that we store the raw file when previously we just did the attachments
[19:32] <kfogel> deryck: it sounds like there's some structure to these blobs that I don't know about :-)
[19:32] <deryck> kfogel, yeah.  was this on the easy bugs backlog?
[19:32] <kfogel> deryck: yep, it's next in line
[19:34] <deryck> kfogel, I think I was thinking this should be simple for gmb who will know exactly what he did wrong.
[19:35] <kfogel> deryck: ok.  I'll look at something else, in the interests of efficiency.  I can watch for gmb's change later to see what it was, anyway.
[19:36] <deryck> kfogel, yeah, good call.  might be a bit much for an afternoon's work.
[19:36] <deryck> sorry to mislead you there earlier.
[19:36] <kfogel> deryck: I know it was intentional, you don't have to pretend.
[19:37] <deryck> kfogel, getting you back for your collusion in this god-awful april fools holiday the web takes.
[19:38] <kfogel> deryck: btw, I sent this review to abel, but if you want to do it it'd probably be quick (he's off now I think):
[19:38] <kfogel> https://code.edge.launchpad.net/~kfogel/launchpad/546943-really-hide-hidden-bug-comments/+merge/22647
[19:38] <kfogel> deryck: then I can move my card along :-)
[19:38] <deryck> ah, you get me with my secret passion.
[19:38] <deryck> kfogel, sure.  looking now.
[19:39] <kfogel> deryck: oh urgh diff still updating even now -- taking a while
[19:40] <kfogel> there, done
[19:53] <deryck> kfogel, done.  r=me.
[20:00] <kfogel> deryck: thx
[20:00] <deryck> np
[20:31] <deryck> kfogel, could you help me test a theory please?  (visiting a page on lp to subscribe me to something)
[20:55] <deryck> kfogel, (when you see this) never mind.  Found what I needed.
[21:10] <kfogel> deryck: sorry, was afk
[21:10] <deryck> kfogel, no worries.
[21:19] <deryck> later on, everyone...
[21:51] <kfogel> barry: still on?
[21:52] <kfogel> http://paste.ubuntu.com/407748/   <<--  sinzui, if you're on: I seem to have h0rked my devel tree (I discovered this while trying to link-external-sourcecode for another very old tree that I hadn't updated in a while)
[21:52] <kfogel> sinzui: trying to figure out how to get back to buildability
[21:57] <kfogel> bfiller: know much about launchpad development?
[21:58] <bfiller> kfogel: played with launchpadlib api in python a bit
[21:58] <kfogel> bfiller: ah, cool.  Okay, I won't hit you up for advice on why my build is broken right now, then :-)
[21:58] <bfiller> kfogel: yeah, I wouldn't know about that :)
[22:01] <salgado> kfogel, just call link-ext-s passing the path to the parent branch to it.  after that you can 'make build'
[22:02] <kfogel> salgado: except if you're in devel, and you pass devel, you lose
[22:02] <kfogel> salgado: search://"infinite binary loop"/ :-)
[22:03] <salgado> kfogel, oh, in that case you have to pass /path/to/lp-sourcedeps I think
[22:03] <kfogel> salgado: let me see
[22:03] <james_w> how do I change the person making the requests in webservice doctests?
[22:04] <kfogel> salgado: it worked!
[22:04] <kfogel> salgado: thank you.
[22:04] <salgado> np
[22:04] <kfogel> james_w: show me which file
[22:04] <kfogel> james_w: (not that I will necessarily know the answer, but I can try...)
[22:04] <james_w> lib/lp/code/stories/webservice/xx-code-import.txt, but I don't know if it will be in your tree yet
[22:05] <james_w> but anything in that dir should be similar
[22:05] <james_w> I want to do a webservice.named_post() from someone other that 'sal<PING AVOIDANCE>gado'
[22:05] <kfogel> james_w: so login() and logout() are usually the way...
[22:06] <james_w> ok
[22:06] <james_w> and I can pass a person object?
[22:06] <kfogel> james_w: oh, I may be misunderstanding -- I don't know what named_post is
[22:06] <kfogel> james_w: IOW, you're not doing this through direct URL requests?
[22:06] <salgado> james_w, that's not easy, unfortunately
[22:07] <james_w> damn
[22:07]  * kfogel listens to what salgado says to james_w
[22:07] <james_w> I guess I can dig into sampledata to find a team that the default user is and isn't part of then
[22:07] <salgado> james_w, there are only a couple users setup to use the webservice
[22:08] <james_w> or add them to a team I create?
[22:09] <salgado>     test.globs['webservice'] = LaunchpadWebServiceCaller(
[22:09] <salgado>         'launchpad-library', 'salgado-change-anything')
[22:09] <salgado>     test.globs['public_webservice'] = LaunchpadWebServiceCaller(
[22:09] <salgado>         'foobar123451432', 'salgado-read-nonprivate')
[22:09] <salgado>     test.globs['user_webservice'] = LaunchpadWebServiceCaller(
[22:09] <salgado>         'launchpad-library', 'nopriv-read-nonprivate')
[22:10] <salgado> actually
[22:10] <salgado> I think I lied to you
[22:10] <salgado> webservice_for_person() in lib/canonical/launchpad/testing/pages.py seems to be what you want, no?
[22:10] <salgado> yeah, it does the oauth dance for you
[22:11] <james_w> looks like it, thanks
[22:19] <kfogel> barry: in a launchpad.dev environment, how does one test bug email notification?
[22:19] <kfogel> barry: I've instrumented BugNotificationBuilder.build(), but it doesn't even seem like it's ever invoked when I make a change to a bug.
[22:20] <kfogel> maxb: ^^ if you know answer to my above question to barry, let me know
[22:34] <maxb> kfogel: sorry, no. I've barely got any insight into how LP code actually works... too much time spent poking karmic/lucid upgrade issues instead :-)
[23:19] <james_w> has anyone used webservice_error?
[23:19] <james_w> is there a knack to it?
[23:19] <james_w> my tests are reporting it not to work as I thought
[23:26] <james_w> and in fact there's a code test asserting that it has the behaviour that I don't expect
[23:27] <james_w> BranchMergeProposalExists has webservice_error(400), but when it is raised in the webservice tests the response code is 500
[23:29] <wgrant> There's no knack to it.
[23:29] <wgrant> It just works.
[23:29] <wgrant> It's not inherited or anything?
[23:36] <james_w> aha!
[23:36] <james_w> I think I know what it is
[23:37] <james_w> said exceptions aren't imported by canonical.launchpad.interfaces
[23:37] <wgrant> Ah. Of course. Import them into lp.code.interfaces.webservice