[00:01] <thumper> wgrant: I have a branch in progress that sends the email on needs review
[00:01] <thumper> wgrant: but it is blocked on two others
[00:01] <thumper> wgrant: to avoid the horrible edge cases
[00:01] <thumper> wgrant: one of them is done
[00:01] <thumper> wgrant: the one that adds a description to the MP
[00:02] <thumper> wgrant: the other isn't too hard
[00:02]  * thumper waves at beuno
[00:03]  * beuno waves back at thumper 
[00:06] <wgrant> thumper: Great.
[00:13] <wgrant> thumper: Do you know about the Zopeless email thing I asked earlier?
[00:20] <thumper> wgrant: didn't see your question
[00:25] <wgrant> thumper: Where do Zopeless emails go in the dev config? I cannot find them anywhere.
[00:25] <thumper> wgrant: haha, I remember looking for it too
[00:25] <thumper> wgrant: root@localhost I think
[00:26] <wgrant> thumper: Normal emails go there.
[00:26] <wgrant> But not Zopeless ones.
[00:26] <thumper> really?
[00:26] <wgrant> AFAICT.
[00:27] <wgrant> Which is perhaps not surprising, since it looks like Zopeless uses SMTP directly, and there is a zopeless/send_email config key which is set to false.
[00:27] <wgrant> Hmmm.
[00:27] <wgrant> How annoying.
[00:45] <wgrant> AAAAAAA
[00:45]  * wgrant stabs ISD in the face repeatedly.
[00:45] <wgrant> Gnarnrewwfwfew
[00:46] <jml> please don't.
[00:46] <jml> they are very nice people.
[00:46]  * ajmitch detects some rage there
[00:48] <thumper> hi jml
[00:48] <thumper> jml: how's pycon?
[00:49] <jml> thumper, great!
[00:49] <jml> thumper, I'm at the Twisted sprint now
[00:49] <jml> thumper, it's exciting to be able to personally fix multiple bugs in a single day :)
[00:50] <wgrant> (bug #525556, for anybody ISDish)
[01:00] <thumper> jml: :)
[01:02] <lifeless> jml: \o/
[01:53]  * thumper wonders how often the staging scanner is running
[02:07] <mwhudson> thumper: */15 i think?
[02:08] <wgrant> The production scanner seems to be pretty slow at the moment.
[02:08] <wgrant> (or maybe the puller)
[02:48] <wgrant> beuno: Since you seem to have access, can you have a look at bug #525556?
[02:50] <beuno> sure
[02:50] <wgrant> It seems like it should be fairly critical.
[02:51]  * beuno facepalms
[02:51] <wgrant> That's what I said.
[02:52] <beuno> spm, if you or any other losa is around ^
[02:52] <beuno> just to be aware, I know you can't do anything about it
[02:53] <wgrant> beuno: Thanks.
[02:54] <beuno> wgrant, thanks for raising it, I'll make sure the appropriate people know ASAP
[02:54] <wgrant> Great.
[02:56] <beuno> elmo, ^
[04:58] <wgrant> I'm trying to write a Storm query to return a resultset of objects ordered by a column on an optional reference.
[04:59] <wgrant> ie. I have a BinaryPackageReleaseDownloadCount, which has an optional Country associated.
[04:59] <wgrant> I want to order them by Country.name.
[04:59] <wgrant> any hints?
[04:59] <mwhudson> do a leftouterjoin on country
[04:59] <mwhudson> then sort on country.name
[05:00] <wgrant> yes, but how do I do that in Storm?
[05:00] <mwhudson> maybe coalesced with something depending on which end of the results you want things without country to end up at
[05:00] <wgrant> Hm, I guess a more manual select with a DecoratedResultSet might work.
[05:01] <wgrant> http://paste.ubuntu.com/381372/ is the code at the moment, but it of course doesn't return objects with a NULL Country.
[05:06] <mwhudson> wgrant: http://paste.ubuntu.com/381376/ or similar i think
[05:07] <wgrant> mwhudson: Oh, yes, of course.
[05:07] <wgrant> Thanks.
[05:25]  * thumper settles down again
[05:28] <mwhudson> thumper: hi, i have some reviews for you :-)
[05:28] <thumper> mwhudson: sure, paste the links
[05:29] <mwhudson> https://code.edge.launchpad.net/~mwhudson/launchpad/smarter-code-import-scheduling-bug-236973/+merge/19841
[05:29] <mwhudson> thumper: https://code.edge.launchpad.net/~mwhudson/launchpad/incremental-code-imports-bug-512683/+merge/19674
[05:31]  * thumper looks now
[05:32] <thumper> mwhudson: are you around for a question?
[05:33] <mwhudson> thumper: just about, i should stop pretty soon
[05:33] <thumper> mwhudson: why does the interdiff for the incremental imports actually change anything?
[05:34] <mwhudson> thumper: because the tearDown raises NotImplementerError
[05:34] <thumper> mwhudson: and that does what?
[05:34] <mwhudson> thumper: and this is the signal to the zope test runner to not run any more tests in that process
[05:34] <lifeless> so bad
[05:34] <lifeless> so very very bad
[05:34] <lifeless> have I mentioned bad?
[05:34] <mwhudson> thumper: it's what the functionallayer (i.e. the one that sets up the component architecture) does
[05:35] <mwhudson> lifeless: hey, if bzr supported unloading plugins...
[05:35] <thumper> mwhudson: so because the teardown isn't implemented, the test runner starts another process?
[05:35] <mwhudson> thumper: it seems so yes
[05:35] <mwhudson> thumper: i just cargo culted from layers.py
[05:35] <lifeless> mwhudson: why do you need to unload plugins? [and it does to an extent]
[05:35] <thumper> mwhudson: can you add a comment saying as much?
[05:35] <lifeless> mwhudson: I'd really like to avoid you needing this feature. Can we discuss?
[05:36] <mwhudson> lifeless: right now, no we can't
[05:36] <thumper> lifeless: some of our other tests fail if the plugins are loaded
[05:36] <mwhudson> thumper: ok
[05:36] <thumper> lifeless: some tests need it
[05:36] <thumper> lifeless: we'd like to be able to have plugins loaded for only some tests
[05:36] <lifeless> is there a doc somewhere explaining this, so I don't en up playing twenty questions?
[05:36] <thumper> lifeless: probably not
[05:37] <lifeless> so, lets play twenty questions.
[05:37] <lifeless> why do some tests fail
[05:37]  * thumper shrugs
[05:37] <thumper> lifeless: probably worth playing 20 questions when mwhudson is working tomorrow
[05:37] <thumper> lifeless: as mwhudson is trying to finish up
[05:37] <lifeless> mwhudson: can you ping me at a good time tomorrow?
[05:37] <thumper> lifeless: and I won't know answers to your questions
[05:37] <mwhudson> lifeless: ok
[05:37] <lifeless> mwhudson: thanks
[05:43]  * mwhudson EODs
[05:43] <lifeless> good idea
[05:52] <wgrant> thumper: Whatever happened to my branch?
[05:52] <thumper> wgrant: not heard anything
[05:53]  * thumper checks ec2 thingy in firefox
[05:53] <thumper> wgrant: I have one instance that is terminated
[05:53] <thumper> wgrant: I submitted yours and one of mine
[05:53] <wgrant> So it hates my branch again :(
[05:53] <thumper> wgrant: heard from one...
[05:54] <wgrant> I ec2tested a branch last night and it emailed me OK.
[05:55] <thumper> wgrant: check your email
[05:55] <thumper> wgrant: id emails you not me
[05:56] <thumper> wgrant: I double checked, and it at least started off right
[05:56] <thumper> wgrant: there was a test fix issue
[05:56] <thumper> wgrant: so I'm resubmitting mine
[05:57] <thumper> wgrant: interesting
[05:57] <thumper> wgrant: I didn't get an email from ec2 either
[05:57] <thumper> wgrant: even though it submitted mine to pqm
[05:57] <thumper> wgrant: I should have got one but didn't
[05:58] <wgrant> I haven't had an ec2 success notification since mid-December, although I have had successful submissions since then.
[05:59] <thumper> wgrant: your branch hasn't landed if that helps...
[06:00]  * wgrant looks through mail server logs.
[06:04] <wgrant> thumper: It doesn't look like it tried to email me.
[06:04] <thumper> wgrant: sorry dude, no idea at all
[06:04] <wgrant> thumper: Thanks for trying.
[06:04] <wgrant> Lots of branches have been going missing lately.
[07:37] <wgrant> noodles775: Morning. Do you have access to buildd-manager logs? It seems to have stopped dispatching builds about an hour ago.
[07:39] <noodles775> wgrant: Yeah, but a losa will need to restart it I'd say.
[07:39]  * noodles775 checks logs
[07:40] <noodles775> wgrant: ouch, another job without a builder: http://pastebin.ubuntu.com/381433/
[07:41] <wgrant> Gnarrrgh.
[07:41] <wgrant> There are also two builders stuck (the usual two: samarium and bohrium), but that's probably unrelated.
[07:42] <wgrant> Do we have no LOSAs today? I thought there was a Nagios check for that.
[07:42] <noodles775> yeah, there should be... I'm just checking the bug and then I'll try to find someone.
[07:43] <thumper> wgrant: they are sprinting this week in europe
[07:43] <thumper> noodles775: morning
[07:43] <noodles775> Hi thumper
[07:43] <wgrant> thumper: Ahh.
[07:43] <thumper> noodles775: I'm working on a wiki page BuildBranchToArchiveUI/InitialCut
[07:44] <thumper> noodles775: nothing there yet, but I'm working on it
[07:44] <noodles775> Great.
[07:45] <thumper> noodles775: actually I just hit save, but I'm still editing :)
[07:46] <noodles775> thumper: sure. Do you think it wasn't clear enough on the other pages? (ie. what wouldn't be included in the initial cut?)
[08:06] <noodles775> wgrant: the buildd-manager should be dispatching again now (as of a min. ago).
[08:07] <noodles775> wgrant: thanks for the heads-up.
[08:07] <thumper> noodles775: I'm going to have a little more detail
[08:07] <thumper> noodles775: ordering of work
[08:07] <noodles775> thumper: ah, great.
[08:07] <wgrant> noodles775: Thanks.
[08:08] <thumper> noodles775: stuff broken up into ready to code chunks
[08:08] <thumper> noodles775: something where I can say "hey <dev>, do this chunk" and it has what they need to know
[08:08] <thumper> noodles775: at least, that's the plan :)
[08:09] <noodles775> thumper: yeah, I was hoping the list of urls required could be turned into bugs for that reason, but you're right, they're a bit too coarse grained (and have interdependencies).
[08:09]  * thumper nods
[08:20] <adeuring> good morning
[09:02] <mrevell> Morning
[09:49] <danilos> bigjools, hey, good morning :)
[09:49] <bigjools> hey danilos - what do you want? :)
[09:49] <danilos> bigjools, ha!
[09:49] <danilos> bigjools, do you know if there have been any firewall rules set up to allow access to our bzr branches from the build farm?
[09:50] <danilos> bigjools, is that something build-from-recipe requires as well, or are translations special in that regard :)
[09:51] <bigjools> danilos: no, BFB needs it too.  So far I have it set up on dogfood so we can test stuff, but it's not done in production.
[09:51] <danilos> bigjools, ok, I am considering writing up an RT, but I am sure you can give me a few pointers on how to best word it so IS actually understands it :)
[09:52] <danilos> bigjools, i.e. what machines need what privileges :)
[09:52] <bigjools> danilos: you don't need it yet
[09:52] <wgrant> Do we actually know that it works on dogfood?
[09:52] <danilos> bigjools, heh, ok, if you say so :)
[09:52] <bigjools> and you won't get it until you've testing on DF :)
[09:52] <wgrant> It didn't after the first reuqest.
[09:52] <bigjools> s/testing/tested/
[09:52] <bigjools> wgrant: huh?
[09:52] <danilos> bigjools, ok, makes a lot of sense, then I'll get on with the next phase to actually do it, and then we can see what happens
[09:53] <bigjools> danilos: in all seriousness, dogfood is the way to go here so that we can establish that stuff works before altering production
[09:53] <wgrant> bigjools: I remember that codehosting access from DF was supposedly set up during the sprint, but it didn't work.
[09:53] <bigjools> wgrant: I don't remember us even trying at the sprint!
[09:53] <danilos> bigjools, of course, I am not disagreeing
[09:54] <bigjools> it was all on your laptop
[09:54] <bigjools> danilos: I'm always right.... 'cept when I'm wrong.
[09:54] <wgrant> bigjools: We didn't try the code, but we tried branch access in anticipation.
[09:54] <bigjools> wgrant: we only opened up access for the builders IIRC
[09:55] <wgrant> bigjools: Isn't that what we're discussing?
[09:56] <bigjools> wgrant: I just tried and it works fine
[09:56] <wgrant> OK, great.
[09:56] <bigjools> I even remember testing it at the time it was done
[09:57] <wgrant> Hm. I remember you had to make a second request, but didn't remember if that was resolved.
[09:57] <bigjools> I don't remember that but then I don't remember at lot of things at my age :)
[09:57] <wgrant> Haha.
[10:09] <wgrant> BjornT: Can you please re-review that branch know that we've clarified that ILFA isn't exportable?
[10:09] <wgrant> s/know/now/
[10:11] <stub> Anyone used the with statement in a doctest yet?
[10:11] <stub> I think I need to inject some flags somewhere
[10:12] <wgrant> stub: Why not just use the import?
[10:12] <stub> Because it doesn't work
[10:12] <wgrant> Ah. Good rationale.
[10:14] <stub> I think it is http://www.python.org/dev/peps/pep-0264/, but no english translation in the __future__ or doctest bits of the reference manual.
[10:18] <BjornT> wgrant: sure, done.
[10:20] <wgrant> bigjools: No violent objections to https://code.edge.launchpad.net/~wgrant/launchpad/export-das-chroot/+merge/19759?
[10:20] <BjornT> stub: have you tried putting the __future__ import in the test harness (i.e., the file that sets up the doctest)?
[10:21] <BjornT> stub: or maybe in the test runner, although that's a very big hammer...
[10:21] <danilos> bigjools, btw, does BFB already have the code which checks the branch out?
[10:21] <stub> BjornT: Looks like more than that. I need to do the import at the top of the harness, and then pass a globs={'with_statement': with_statement} when constructing the suite.
[10:21] <stub> icky
[10:22] <wgrant> danilos: It's done by bzr-builder, so it's probably not useful for your purposes.
[10:23] <danilos> wgrant, right, so it's outside the LP tree?
[10:24] <wgrant> danilos: Yes, and inside a script that takes a recipe.
[10:25] <bigjools> wgrant: one sec
[10:25] <bigjools> danilos: it's done in the builder code
[10:27] <danilos> bigjools, wgrant: ok, excuse me for not being certain where to look now, but... is there some code in LP I could generalize and reuse for translations?
[10:27] <wgrant> danilos: If you really want to look at it, try sourcecode/bzr-builder. But it's probably just as easy for you to do it yourself.
[10:27] <bigjools> danilos: nothing in LP - as wgrant says it's done in bzr-builder
[10:28] <danilos> bigjools, wgrant: ok, thanks, that clarifies it
[10:33] <bigjools> wgrant: MP is ok, I commented on it
[10:33] <stub> bzr pish
[10:44] <wgrant> Is the branch scanner broken?
[10:44] <wgrant> I pushed a new rev 7 minutes ago.
[10:45] <wgrant> It has still not scanned.
[10:49] <wgrant> BjornT/bigjools: Branch finally scanned -- can one of you please check the new revs and land it?
[10:51] <bigjools> sure
[10:52] <wgrant> bigjools: Thanks. Do you have a moment to talk about those test changes you requested last week?
[10:53] <bigjools> wgrant: sure
[10:56] <wgrant> bigjools: So, regarding your last comment on https://code.edge.launchpad.net/~wgrant/launchpad/p-u-sprb-handling/+merge/19380...
[10:56] <wgrant> The security is there so the storeUploadLog test works.
[10:56] <wgrant> It just needs some declaration of writeability. It does not care what.
[10:57] <wgrant> The tests will fail if the security is removed, and I'm not sure it can be usefully tested otherwise.
[10:59] <bigjools> wgrant: ah ok, so there is a test :)  In that case, please document that fact on the test.
[11:00]  * bigjools is about to order a new Thinkpad
[11:01] <bigjools> would love to get one w/Ubuntu pre-installed but the stuff at LinuxEmporium is all old models :(
[11:01] <wgrant> :(
[11:01] <bigjools> windows tax here I come
[11:01]  * wgrant removes the security to work out which test it was.
[11:02] <deryck> Morning, all.
[11:02] <adiroiban> danilos: can you give me a hint for how can I make a TranslationMessage to be the current translation? Basically I have this test http://paste.ubuntu.com/381520/, and the contributors for makeTranslationMessages are listed in the POFile details page, but not on the language global statistics
[11:02] <bigjools> hi deryck
[11:07] <adiroiban> jtv: hi. when you have time, can you please test the fix for bug #127171 ?
[11:07] <mup> Bug #127171: Rosetta experts not allowed to "Change translators" <qa-needstesting> <Launchpad Translations:Fix Committed by adiroiban> <https://launchpad.net/bugs/127171>
[11:08] <danilos> adiroiban, looking at your test
[11:09] <danilos> adiroiban, fwiw, a lot of that data is maintained through triggers or nightly scripts, so that might be part of the problem
[11:11] <danilos> adiroiban, so, list of top contributors is based on karma, and karma is updated only with a nightly script
[11:11] <adiroiban> hm... how do you suggest I should write that test?
[11:16] <stub> You need to populate the relevant Karma and KarmaCache tables. I don't think there are factory methods for that though :-/
[11:25] <jtv> adiroiban: hang on, some high-priority stuff going on :)
[11:26] <jtv> adiroiban: ah, I guess danilos took care of it while I was otp  :)
[11:27] <danilos> adiroiban, I am not exactly sure what would be the best way to do it
[11:33] <danilos> adiroiban, you can just add a method which updates karma for one particular user, or you can fake it by adding it directly
[11:58] <bigjools> wgrant: hmmm, I am thinking about your security zcml
[11:59] <bigjools> The upload processor is zopeless and doesn't need security, so what is falling over exactly?
[12:00] <wgrant> bigjools: The test that I added the comment to. It appears to run in that semi-secure mode which doesn't care about users.
[12:00] <bigjools> wgrant: your diff has got merge conflict markers in it
[12:00] <bigjools> in the spr model
[12:01] <wgrant> bigjools: Argh.
[12:01]  * wgrant fixes.
[12:02] <bigjools> wgrant: which test?  the comment was on the zcml itself
[12:02] <bigjools> testSetsBuildAndState?
[12:02] <wgrant> bigjools: I added a comment at both ends.
[12:02] <wgrant> Yes, IIRC.
[12:02] <bigjools> ah I see it
[12:02] <wgrant> The one that tests UploadProcessor
[12:02] <bigjools> buried in other comments :)
[12:02] <wgrant> Indeed.
[12:02] <bigjools> hmmm
[12:03] <wgrant> Remember that Soyuz's Build has the same sort of thing, with little explanation. It would be nice to work out both.
[12:04] <bigjools> hmm yes
[12:04] <bigjools> it's very odd
[12:04] <bigjools> ah I know I think
[12:04] <wgrant> Hm?
[12:04] <bigjools> those Build attributes get reset in the webapp when you retry the build
[12:04] <bigjools> which explains why you need lp.edit
[12:05] <bigjools> so I am still confused as to wehy SPRB needs it :/
[12:05] <wgrant> But shouldn't they be set from within retry()?
[12:06] <wgrant> Once you're inside the object, security is irrelevant.
[12:06] <bigjools> I didn't think it was but now you have me thinking
[12:07] <bigjools> since IBuild is exported, lp.edit still makes sense anyway
[12:08] <wgrant> For a dangerous value of sense that has caused security issues in the past!
[12:09] <bigjools> yeah, we have a bad record there :(
[12:09] <wgrant> I mean that particular line of ZCML has been problematic.
[12:17] <wgrant> bigjools: That conflict's resolved.
[12:17] <wgrant> Argh, wrong push location though.
[12:17] <bigjools> heh
[12:25] <wgrant> bigjools: That looks a bit healthier.
[12:32] <bigjools> wgrant: approved
[12:32] <bigjools> I can land it, it's db-devel right?
[12:32] <wgrant> bigjools: It's db-devel.
[12:33] <wgrant> bigjools: But watch out: thumper tried to land the prereq earlier, and the instance disappeared silently.
[12:33] <bigjools> :/
[12:33] <bigjools> what happened to the pre-req?
[12:33] <wgrant> Hm?
[12:34] <bigjools> it landed, or is it still in limbo?
[12:35] <wgrant> bigjools: It's not landed. The instance died, and we're not sure why.
[12:35] <bigjools> ok I'll try merging it and having another go
[12:35] <wgrant> So you might not want to land this headlessly.
[12:36] <bigjools> I'll run tests on my box
[12:36] <wgrant> Ah, good point.
[12:36] <bigjools> I don't need no steenkin ec2
[12:36] <bigjools> I have a fork whore
[13:10] <wgrant> bigjools: It hasn't exploded yet?
[13:10] <bigjools> wgrant: there's a test failure
[13:11] <wgrant> Hrmph.
[13:11] <bigjools> ProgrammingError: relation "sourcepackagerecipebuildupload" does not exist
[13:11] <bigjools> for a few tests
[13:12] <bigjools> test_DeleteExpiredBlobs test_cronscript test_PersonPruner and others - non soyuz, which is odd
[13:12] <wgrant> Oh, damn.
[13:12] <wgrant> I know about and have fixed that.
[13:12] <bigjools> lib/canonical/librarian/tests/librarian-report.txt now
[13:13] <bigjools> if you have a fix I'll quit this test run
[13:13] <wgrant> I forgot to pump one of the DB patch changes through. Oops.
[13:13] <wgrant> Sorry.
[13:13] <bigjools> ok
[13:14] <wgrant> (we can't drop SPRBU entirely due to replication limitations, so it has been moved to another schema, which confuses things that look for foreign keys referencing Person)
[13:21] <wgrant> bigjools: r8934 has that DB change pumped through (it's already reviewed) and pushed.
[13:21] <wgrant> But I guess it'll take about 10 minutes to appear on the public branch.
[13:25] <bigjools> okay
[13:27] <bigjools> wgrant: on your lp:~wgrant/launchpad/sprb-new-model-columns branch?
[13:27] <wgrant> Stuart Metcalfe doesn't exist on Freenode, does he?
[13:28] <wgrant> bigjools: The missing piece started on https://code.edge.launchpad.net/~wgrant/launchpad/sprbu-columns-to-sprb, but is now in p-u-sprb-handling
[13:28] <bigjools> ok got it
[13:29] <bigjools> ok off with another test run
[13:29] <wgrant> Thanks.
[13:29] <bigjools> doubt you'll be up in 3h huh? :)
[13:29] <wgrant> I really hope not.
[13:30] <wgrant> 3am while sick is not advisable.
[13:32] <bigjools> hope you're feeling better tomorrow
[13:40] <bigjools> wgrant: still failing
[13:41] <wgrant> bigjools: Is this line in database/schema/patch-2207-32-0.sql?
[13:41] <wgrant> ALTER TABLE SourcePackageRecipeBuildUpload DROP CONSTRAINT sourcepackagerecipebuildupload_registrant_fkey;
[13:41] <bigjools> wgrant: yep
[13:42] <bigjools> I suspect that when I run "make check" it deletes the table when doing make schema
[13:43] <bigjools> anyway, I need food, back in a bit
[13:52] <stub> If dropping the table is too painful, comment out that line and open a bug.
[13:53] <wgrant> See, the tests pass here.
[13:54] <wgrant> Ah, no, there's one failure.
[13:54]  * wgrant pokes around.
[13:55]  * wgrant drops the rest of the foreign keys.
[13:56] <wgrant> stub: No objections to dropping the other three foreign keys?
[13:57] <stub> No - all the foreign key constraints on that table should die.
[14:00] <wgrant> bigjools: OK, r8935 pushed, with all the foreign keys dropped. All the failures you've mentioned are fixed by that.
[14:10] <bigjools> wgrant: ok trying again
[14:24] <deryck> adeuring, gmb, intellectronica, kfogel -- just a reminder, update the board before the standup.
[14:24] <kfogel> deryck: oh, thanks!
[14:24] <deryck> I did some QA and moved things there.
[14:25] <kfogel> deryck: I saw.  We don't have to hit "save" or anything, right?  Just move the post-it and it's done?
[14:26] <deryck> kfogel, right.  Just move the card.
[14:26] <kfogel> deryck: *nod*
[14:26] <maxb> ooi, why does the LaunchpadDatabaseRevision table contains multiple rows, instead of just the current revision?
[14:26] <kfogel> intellectronica: know a good example of a usage of a standard Zope form somewhere?  (I'm in bug #515584)
[14:26] <mup> Bug #515584: BugsPatchesView:batchedPatchTasks() should use a Zope form, instead of validating form values manually <story-patch-report> <Launchpad Bugs:Confirmed for kfogel> <https://launchpad.net/bugs/515584>
[14:27] <wgrant> maxb: I don't know for sure, but it's probably something to do with the fact that a DB patch can live in a branch for ages.
[14:27] <intellectronica> kfogel: it's probably worth fixing that together with fixing it for the search form
[14:27] <maxb> ah - so in theory they might not actually be sequential?
[14:27] <wgrant> maxb: Exactly.
[14:27] <intellectronica> kfogel: there's a bug for that. let me try and find that
[14:27] <wgrant> maxb: In practice, too.
[14:28] <intellectronica> kfogel: https://bugs.edge.launchpad.net/malone/+bug/322130
[14:28] <mup> Bug #322130: Convert IHasBugs.searchTask(order_by) to use a real enumeration <api> <tech-debt> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/322130>
[14:29] <kfogel> intellectronica: thank!
[14:29]  * kfogel opens it up
[14:29] <intellectronica> kfogel: it's quite a lot of work, i think
[14:30] <intellectronica> but it would be even more work if we end up doing it twice
[14:30] <kfogel> intellectronica: it's a lot of work?  Just because of all the callers?
[14:30] <wgrant> bigjools: If it's still looking good, I will head to bed.
[14:30] <kfogel> intellectronica: if it's just a bunch of caller updates, well, Emacs and I can do that together.  If you think it's a lot of work in terms of inherent complexity, then I'm not sure lumping the two bugs together is a good idea.
[14:30] <bigjools> wgrant: yes, no issues so far
[14:30] <bigjools> sleep well
[14:30] <intellectronica> kfogel: yes. also you need to arrange for backwards compatibility
[14:30] <wgrant> bigjools: Excellent. Thanks.
[14:31] <kfogel> intellectronica: backwards compatibility?  This is an API issue?
[14:31] <kfogel> mmmmm
[14:31] <intellectronica> kfogel: maybe the API, also the search form, since many users save URLs for later
[14:32] <kfogel> intellectronica: okay, then I think we should keep these two bugs separate.  I'm all for fixing 322130, but 515584 is its own separate piece of tech debt, and doesn't have any compat issues.
[14:32] <kfogel> intellectronica: *nod* I see.
[14:32] <intellectronica> kfogel: ok, maybe you're right and it's worth fixing this first, don't know
[14:33] <kfogel> intellectronica: This *is* a fair amount of work, then.  Not against it, but I don't think we should just randomly start on it vs some other thing -- it needs to be triaged, and we probably want team input, or at least deryck's.  There might be more presing stuff to do.
[14:33] <kfogel> intellectronica: which we can discuss on the call now :-)
[14:33] <intellectronica> kfogel: indeed :)
[14:34] <kfogel> intellectronica: in the meantime... know a good example of a zope form? :-)
[14:45] <al-maisan> are thunderbird 3 and enigmail conflicting packages these days
[14:45] <al-maisan> enigmail de-installs thunderbird 3 and vice versa
[14:45] <al-maisan> ECHAN
[14:45] <al-maisan> sorry
[14:45] <deryck> kfogel, looking at QA page, can you update bug 513608, to link branch, status, milestone, etc.  I think this landed?
[14:46] <mup> Bug #513608: community-contributions.py script should use Launchpad to determine who is not a Canonical employee <Launchpad Foundations:Confirmed for kfogel> <https://launchpad.net/bugs/513608>
[14:46] <kfogel> deryck: yup
[14:48] <kfogel> deryck: oh, no -- wrong bug number there.  513608 is still open, it's just mentioned in an XXX comment now.  the fix that landed is for another bug.  I'll fix it all up.
[14:48] <kfogel> (the qa page I mean)
[14:49] <deryck> kfogel, excellent.  Thanks, sir.  I think I marked something as OK, so sorry about that.
[14:49] <kfogel> deryck: well, the change is indeed OK, it just needs to be associated with the right bug number.  no worries.
[14:49] <deryck> ok, cool
[14:52] <kfogel> deryck: so, it kind of disturbs me that if I do a bugs search across all projects, and put "community-contributions.py" in the search box, it shows no matches -- even though I know of bugs where that exact string is in the *summary* of the bug.
[14:52] <kfogel> deryck: is this expected?
[14:53] <deryck> by "search across all projects" what exactly do you mean?
[14:53] <kfogel> deryck: https://bugs.launchpad.net/, put that string in the search box, make sure "All projects" is checked, hit the button.
[14:54] <kfogel> deryck: it also turns up nothing if I do "One project:" and put launchpad or launchpad-projects as the project name.
[14:56] <deryck> kfogel, seems like a bug.  This should work.  Maybe something with the way full text queries handle the ".py"
[14:57] <kfogel> deryck: urgk, sigh.  I'll push stack once more :-) and ensure there's a bug report for this.
[14:57] <kfogel> may already be one, we'll see
[14:59] <deryck> kfogel, note that search on "launchpad" shouldn't work but search on "launchpad-project" should, since that is the project group.  yes, this is confusing, I know.
[15:00] <kfogel> deryck: I knew the latter should work.  I can never remember what the former is supposed to represent.
[15:01] <deryck> kfogel, it's a thing to catch bugs that no one knows where to file, *I think*. :-)
[15:01] <kfogel> deryck: oic :-)
[15:04] <kfogel> deryck: so, it turns out that in addition to that change (the one that is not for 513608), I also need to land https://code.edge.launchpad.net/~kfogel/launchpad/cc-script-new-world, which is approved.  To land that, I need to find the bug number(s) relevant to it.  On the way to finding those, I may be filing a bug about how I can't find them.  There.  I think that's everything at the current stack level.
[15:04] <kfogel> :-)
[15:05] <deryck> heh
[15:05] <deryck> Not too bad for a monday, kfogel ;)
[15:05] <kfogel> deryck: oy
[15:14] <kfogel> deryck: okay!  that's in the queue (https://pqm.launchpad.net/).  No need to respond.  I'm just feeling the work-at-home-cabin-fever this morning and so I'm yammering what I do at you.
[15:15] <kfogel> :-)
[15:32] <kfogel> deryck: are bug searches supposed to be case-insensitive?
[15:34] <deryck> kfogel, I'm sure they are supposed to be, but I can't confirm for certain yet.  Never checked on that yet.
[15:35] <kfogel> deryck: I'm assuming they should be too.  Doesn't matter for the purposes of the bug consolidation I'm doing right now of some search failure bugs, but I was just curious.
[15:46] <adiroiban> gmb: hi. any news about the ever disappering branch ?
[15:50] <gmb> adiroiban: No, it's running on ec2 at the moment and hasn't died yet.
[15:50] <gmb> adiroiban: I'll let you know how it goes.
[15:50] <adiroiban> thanks
[15:56] <kfogel> deryck: okay, it's all in bug #29713 now, which I think maybe should be high priority (search is supposed to work reliably!)
[15:56] <mup> Bug #29713: bug search fails to find results despite exact search string being in bug titles <Launchpad Bugs:Triaged by stub> <https://launchpad.net/bugs/29713>
[15:56] <deryck> kfogel, yeah, jml is beating the search drum too. :-)
[15:57] <kfogel> deryck: oh, I wonder if he knows of any dup bugs, then.  jml?  ^^
[15:58] <jml> kfogel, I don't.
[15:59] <kfogel> jml: ok, thx
[16:19] <noodles775> I've got an ec2 instance that's hung during windmill tests... is this a known issue? http://pastebin.ubuntu.com/381681/
[16:19] <noodles775> BjornT: ^^ ?
[16:23] <sinzui> jtv: thanks for doing the triage
[16:23] <jtv> sinzui: chr
[16:23] <sinzui> jtv: I am thankful none-the-less
[16:23] <jtv> very gracious
[16:26] <jtv> sinzui: here, have a free desktop background made of 9th-century ceiling design: http://people.canonical.com/~jtv/DSCF0570.JPG
[16:26] <jtv> sinzui: took that in the Dome of Charles the Great at Aachen yesterday
[16:27] <noodles775> Wow...
[16:28] <jtv> it was pretty stunning, yes
[16:28] <jtv> also the bust of the big man himself
[16:29] <sinzui> jtv: thanks.
[16:42] <kfogel> adeuring: looking for an example of standard, best-practices Zope form usage (for bug #515584) in our bugs code.  Do you know a good place?
[16:42] <mup> Bug #515584: BugsPatchesView:batchedPatchTasks() should use a Zope form, instead of validating form values manually <story-patch-report> <Launchpad Bugs:Confirmed for kfogel> <https://launchpad.net/bugs/515584>
[16:42] <adeuring> kfogel: not out of the box...
[16:42] <kfogel> adeuring: np.  If you spot anything, or you know of some good docs on this, let me know.  I'll figure it out eventually.
[16:43] <kfogel> .oO (he said, optimistically)
[16:43] <mramirez> can help me configure my mail server launchpad
[16:43] <mramirez> help mail
[16:43]  * adeuring is somewhat confused today. I contenated mentally at first "standard, best"  to "bastard"...
[16:44] <adeuring> kfogel: the best approach is to search for a simple from, but, in our case, one that does not use POST but GET
[16:51] <kfogel> adeuring: I guess what I'm really asking is, how will I know a good example when I see one?
[16:51] <kfogel> I'm not sure how to recognize the standard/best practice.
[16:51] <adeuring> kfogel: when it is simple ;)
[16:52] <kfogel> adeuring: It's a zen afternoon for you, I see.
[16:52] <adeuring> kfogel: ;) let me try to find something
[16:53] <kfogel> adeuring: btw, how long are you on today?  (reason: bad cabin fever, really need to just go outside and walk to the store and get a muffin, get some sunshine)
[16:53] <kfogel> if you'll be around for a bit, I'll do that and come back
[16:54] <adeuring> kfogel: an hour or so, i guess, the I'll leave for one or two hour; after that (around 9pm my time) I'll be back
[16:56] <kfogel> adeuring: you're coming back at 9pm??
[16:56] <adeuring> kfogel: yes
[16:59] <kfogel> adeuring: ok; I'll be out for a few, then back here.  If you happen to dig up a great example using an enum and standard zope form stuff, paste it to me.  If not, no worries; I'm grepping around for method="get" etc, and I'm sure I'll find the right thing eventually.
[17:37] <maxb> mbarnett: If you happen to be around, what are your thoughts on the launchpad-dependencies Slony-I thread?
[18:38] <sinzui> bac: I updated bug 523891 with my findings. Do you think my proposal is sane?
[18:38] <mup> Bug #523891: +needs-packaging includes packages that has upstream links <Launchpad Registry:Triaged by sinzui> <https://launchpad.net/bugs/523891>
[18:45] <bac> sinzui: yes, what you propose does make sense...i think
[18:47] <sinzui> bac: My fix may also fix bug 512831. I have tried to fix the gtk+2.0 packaging link, but I cannot. Every time I try to edit Lucid's link, I get Karmic's, so I set the same object to the same state. It is not possible to correct the the data from the dsp/sp pages.
[18:47] <mup> Bug #512831: Packaging records not editable <package-link> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/512831>
[18:50] <sinzui> I just confirmed I can fix the lucid/+source/gtk+2.0 by creating the link from the upstream project. I think I will make my goal of week 3 to close the last of the packaging-link bugs
[19:13] <mwhudson> good morning
[19:32] <kfogel> mwhudson: good morning
[19:44] <thumper> morning
[19:51] <jpds> thumper: Morning.
[20:14] <kfogel> adeuring: I'm noticing a problem with +patches view, but it might just be an artifact of my local dev instance.  After patching database/sampledata/current-dev.sql with the db diff I've been using for weeks to test +patches view, and then running 'make schema', I visited https://bugs.launchpad.dev/patches-view-test/+patches.  There were no patch tasks listed, though!  There should be six or seven of them -- the ones in my custom samp
[20:14] <kfogel> ledata.  Puzzled, I created a new bug on the 'patches-view-test' product, attached a patch to it, and refreshed the view.  Now that bug alone shows up, but the old bugs in my sampledata still don't.  I tried adding a new comment on one of those old bugs, to see if maybe that would cause a refresh in the 'latest_patch_uploaded' column, but it didn't cause the bug to appear in the view.
[20:16] <adeuring> kfogel: that sounds really odd. Do you see the bugs missing on the +patches view on other bug pages for the test project?
[20:16] <kfogel> adeuring: yes, they are missing on other entities
[20:17] <kfogel> adeuring: assuming by "test project" you meant my test instance
[20:17] <adeuring> kfogel: I mean that thingy (IProduct, IIRC) that you created first, and where you then added the bugs for
[20:18] <kfogel> adeuring: btw, my db sampledata patch is here: http://paste.ubuntu.com/381809/
[20:19] <kfogel> adeuring: so when you say "+patches view on other bug pages for the test project", what does that mean?  The product ('patches-view-test') has only one bugs page....
[20:19] <adeuring> kfogel: OK, let me look. As a guess without lookng: if the test bugs are missing on the other bug related pages for the test project as well, I'd guess that the ID of the test project changed
[20:19] <adeuring> soryy...
[20:19] <adeuring> I mean: Do you see the bugs on the http://bugs.launchpad.dev/testproject , for example?
[20:19] <kfogel> adeuring: this isn't actually holding me up on bug #515584 work, since I can just create a bit of new data easily, but ... it's worrying, obviously :-).
[20:19] <mup> Bug #515584: BugsPatchesView:batchedPatchTasks() should use a Zope form, instead of validating form values manually <story-patch-report> <Launchpad Bugs:Confirmed for kfogel> <https://launchpad.net/bugs/515584>
[20:20] <kfogel> adeuring: oh, yes, the bugs are there on bugs.launchpad.dev/patches-view-test, sorry, I should have said that.
[20:20] <adeuring> odd... let me look at the sampledata
[20:20] <kfogel> But the bugfilters stats portlet on that page says "0 bugs with patches", and going to ".../+patches" shows no patches.
[20:24] <adeuring> kfogel: Trying to apply you patch to trunk r10326, I get the message "Hunk #1 FAILED at 1377", Did you get perhaps something similar?
[20:25] <kfogel> adeuring: no, I did not.  You're using db-devel, right?
[20:25] <kfogel> adeuring: I branched my branch from an up-to-date db-devel this morning, AFAIK
[20:25] <adeuring> kfogel: argh, no... let me try again
[20:25] <kfogel> adeuring: :-)
[20:27] <kfogel> adeuring: hey, hmm, how would I do a python "if ... else ..." in a tal:content tag using the "python" magic word?  I can't use any indentation, obviously...
[20:28] <adeuring> kfogel: use a browser class mehod?
[20:28] <adeuring> ...method...
[20:28] <kfogel> adeuring: oh, I see :-)
[20:28] <kfogel> adeuring: sigh.  ok.
[20:28] <adeuring> ;)
[20:28] <kfogel> adeuring: .oO (But why can't I just implement all of Launchpad in this .pt file?)
[20:28] <adeuring> kfogel: but... what is your use case? perhaops there are other options
[20:30] <kfogel> adeuring: in the menu that offers sort orders, the actual orders we offer sometimes begin with "-" and sometimes don't.  But what we show do the user should never show the "-".  E.g., although it might be "-importance" behind the scenes, it should display to the user as "importance" in the dropdown.  So I was going to test the first char and do "value[1:]" if it was "-" ...
[20:30] <kfogel> you see why it's tempting to  just take care of that in the .pt file
[20:32] <adeuring> kfogel: yes. But I think the "technical" values (with or without a leading '-') differ anyway from what we display to the user. the "technical" bvalues are all lower-case, while the displayed text might be capitalized
[20:33] <kfogel> adeuring: hmmmm, ok.  I'll run with that.  I think the patch I first show you (soon) will be very much in need of review.  but that's okay :-).
[20:40] <adeuring> kfogel: I think I know why your old attachments/patches don't show up: We have meanwhile a cached column "latest patch uploaded" or somesuch in the tabkle bugs. And this column is normally updated by DB triggers. But your test data is probably "too old" to be "aware" of the triggers...
[20:40] <adeuring> kfogel: but there is a simple way to fix this, let me looks
[20:40] <kfogel> adeuring: thanks
[20:41] <adeuring> kfogel: in the file database/schema/patch-2207-29-0.sql, there is an UPDATE command. Just run this command via psql.
[20:42] <kfogel> adeuring: wow!  thank you.
[20:42] <adeuring> kfogel: welcome :) But I am the one to blame to for all the mess with this column ;)
[20:43] <kfogel> adeuring: I think what I'll do after I run that is regenerate my db sampledata diff
[20:43] <kfogel> that old one's getting stale
[20:43] <adeuring> kfogel: rigth, makes sense. a classical case of bit rot?
[20:46] <thumper> jml: ping
[20:47] <kfogel> adeuring: ezzatly
[20:50] <jml> thumper, hi
[20:50] <thumper> jml: what was the state of your factory no-commit branch?
[20:50] <thumper> jml: landed, or work needed?
[20:51] <jml> thumper, huge chunks of work needed.
[20:51] <jml> thumper, it didn't even make it all the way through ec2 test -- it crashed it or hanged it or something
[20:51] <jml> thumper, all I did was go through factory and delete all of the calls to commit
[20:56] <kfogel> adeuring: ok, rtfm'ing but I think you know the answer quickly: what user and db do I invoke psql as?
[20:57] <kfogel> adeuring: (I've never had to do it locally before for Launchpad)
[20:57] <adeuring> kfogel: "psql -d launchpad_dev" .
[20:57] <adeuring> you don't need to specify a user
[20:58] <kfogel> adeuring: thanks
[21:01] <kfogel> adeuring: that update command worked, thank you
[21:02] <adeuring> kfogel: welcome. As I said, I am trhe one to blame for all this mess. background: the +patches view timed out for ubuntu, so I added this cached column bug.lastest_patch_uploaded .
[21:06] <kfogel> adeuring: well, you're not to blame -- ubuntu is!
[21:06] <poolie> hi there kfogel
[21:06] <adeuring> yeah, too many bugs ;)
[21:07] <poolie> how are the bugs?
[21:07] <kfogel> poolie: hey, there.
[21:07] <kfogel> poolie: we're down to the last couple of bugs in launchpad.  Pretty cool.  I guess we might all be able to go home after today.
[21:07] <poolie> good to hear :)
[21:07] <kfogel> poolie: Oh, wait -- we already are home.  And there are 2000 bugs, not 2.  My bad.
[21:08] <kfogel> adeuring: hunh, I just notice (now that I have all my old data back!) that the batch size for patch tasks is, like, 5, instead of 50.  While that's useful for development, I'm worried that we built it into the code somewhere (temporarily for testing) and forgot to take it out.  What controls the batch size again?
[21:09] <kfogel> oh
[21:09] <kfogel> adeuring: it's a personal pref, isn't it?
[21:09]  * kfogel sees
[21:09] <adeuring> kfogel: do you perhaps use a bookmarked URL?
[21:09] <kfogel> adeuring: nope
[21:11] <adeuring> kfogel: but the page https://staging.launchpad.net/ubuntu/+patches shows more than 5 bugs
[21:11] <kfogel> adeuring: not for me :-)
[21:11] <kfogel> adeuring: sorry, i mean not in my launchpad.dev instance
[21:11] <kfogel> adeuring: I wonder if we have a lower batch size in general for .dev instances, just for easier testing?
[21:11] <adeuring> kfogel: odd. are you sure that you don't use a parameter like batchsize=5 or so?
[21:12] <adeuring> kfogel: could be, I am not sure...
[21:12] <kfogel> adeuring: if I do, it's not in the URL
[21:23] <kfogel> adeuring: https://code.edge.launchpad.net/~kfogel/launchpad/515584-use-zope-form
[21:23] <kfogel> adeuring: would love early review from you on the route I'm taking
[21:23] <kfogel> adeuring: AFAICT, what I'm doing isn't more "Zope-y" than any other way, it just reduces some code duplication.
[21:30] <adeuring> kfogel: I'll look
[21:31] <kfogel> adeuring: thank you
[21:36] <adeuring> kfogel: you can create a vocabulary with the right options and display that as a drop-down list. Tha's done more or less automatically by LPFormView
[21:37] <adeuring> IOW, you don't need patchTaskOrderings()
[21:37] <adeuring> kfogel: and for the form view, you need and interface class which defines the values you want to display onn the form
[21:38] <kfogel> adeuring: aaaaah
[21:38] <kfogel> adeuring: much clearer now, thank you
[21:39] <kfogel> adeuring: (I don't think this work was wasted, though, as it still consolidated stuff outside the .pt file.  Now it's just  matter of moving code around.)
[21:41]  * maxb is unconvinced by mwhudson's docstring nargery
[21:41] <maxb> Does "Calculate the appropriate value for the BZR_PLUGIN_PATH environment." feel right to anyone?
[21:44] <mwhudson> oh oops
[21:44] <mwhudson> at least it follows the coding standard now :-)
[21:47] <kfogel> jml: hey, something's come up, can I move our tomorrow call to Wednesday?  (Or, hmm, it's not on cal for tomorrow anyway, so maybe it's cancelled this week anyway?)
[21:48] <jml> kfogel, it's cancelled this week, I'm away.
[21:49] <kfogel> jml: *nod*
[21:50] <thumper> jml: did you end up talking to james_w about multi-distroseries recipes?
[21:50] <kfogel> adeuring: when does trunk freeze?  Wednesday?
[21:51] <thumper> kfogel: Friday normally
[21:51] <kfogel> thumper: oh, that's not so bad, okay
[21:51] <james_w> thumper: not yet
[21:52] <jml> thumper, no.
[21:53] <thumper> james_w: so... what's the story with that then?
[21:53] <james_w> it's not clear yet
[21:54] <james_w> there will be some recipe format work needed to support it if that is the way we want to fix it
[21:55] <james_w> otherwise we could do it soyuz side
[21:55] <thumper> james_w: in which case, I'm going to say it is all go with what we have
[21:55] <thumper> james_w: so a recipe is going to have a base branch and an associated distroseries
[21:57] <james_w> thumper: I think you may be making a decision that makes it harder to provide the user experience that you want, but I can understand the desire to move forwards
[21:57] <thumper> james_w: well...
[21:57] <thumper> james_w: lets design for what we want then
[21:58] <thumper> james_w: if we really want multi distroseries recipes
[21:58] <thumper> james_w: then lets work out what we need to make that happen, and JFDI
[21:58] <james_w> yes
[21:58] <thumper> james_w: do you know what needs to happen?  I don't
[21:58] <james_w> it's not me that is driving that requirement
[21:58] <thumper> who is?
[21:59] <james_w> someone on the LP side
[21:59] <james_w> thumper: no, I haven't thought it through yet.
[21:59] <thumper> ok
[22:00] <james_w> I would like to do so, but the water is a little over my head right now
[22:00] <james_w> it would only be a few hours work to design something and implement it though
[22:01] <thumper> james_w: ok... can I do anything to help?
[22:02] <james_w> either schedule something to force the issue, or lighten the load elsewhere to give me the time to do it
[22:03] <thumper> james_w: who do I need to talk to about your schedule and load?
[22:04] <james_w> thumper: that's not particularly clear right now
[22:04] <poolie> hi james_w
[22:04] <james_w> hi poolie
[22:04] <poolie> i'd like to catch up sometime
[22:04] <poolie> realize it's late right now
[22:04] <james_w> well, I am here
[22:05] <thumper> james_w: :-) however that doesn't help me help you
[22:05] <james_w> thumper: I realise that :-)
[22:06]  * thumper reboots server
[22:08] <james_w> thumper: we don't really have a manager right now, in the conventional sense at least. I guess it is split between Hugh and Robbie.
[22:22]  * rockstar reboots
[22:41]  * mwhudson heads out for an early lunch -- unproductive morning
[22:45] <lifeless> mwhudson: when you get back
[22:45] <lifeless> mwhudson: lets talk
[23:12] <jelmer> wgrant, hi
[23:14] <wgrant> jelmer: Hi.
[23:15] <jelmer> wgrant: you have launchpad working on lucid right?
[23:15] <wgrant> jelmer: Yes.
[23:15] <jelmer> wgrant: what did you need to do to get it working?
[23:16] <wgrant> And I tried to run the test suite overnight, but it died early on for un-Lucid reasons.
[23:16] <wgrant> jelmer: Install an old launchpad-dependencies (since the new one needs slony for postgres 8.3 -- that's about to be reverted)
[23:17] <wgrant> You will also need to install python-egenix-mx{datetime,tools} from ppa:launchpad, or better still merge the versions in there so they're up to date.
[23:17] <wgrant> That's about it.
[23:19] <wgrant> Also, Canonical's non-Launchpad webapp teams are utter failures at security. Grrr.
[23:21] <lifeless> wgrant: heh
[23:22] <jelmer> wgrant, thanks
[23:22] <lifeless> I'm not entirely sure why the login.ubuntu.com became a different team
[23:22] <wgrant> lifeless: Not just that, but yes.
[23:22] <jelmer> wgrant, is that documented somewhere yet?
[23:22] <wgrant> jelmer: Which?
[23:23] <jelmer> how to use lp on lucid?
[23:23] <wgrant> No, since the two blockers are bugs that are easily fixed by anybody with upload privileges to ppa:launchpad.
[23:23] <wgrant> ie. anybody in ~launchpad or maxb.
[23:33] <jelmer> hmm
[23:33] <jelmer> wgrant: so I guess I should fix it rather than document it on the wiki?
[23:34] <wgrant> jelmer: Definitely.
[23:34] <wgrant> Don't fix lp-dependencies yourself for now, since that's a bit harder, but the two outdated packages are just trivial merges.
[23:36] <mwhudson> lifeless: hi
[23:36] <lifeless> mwhudson: hai
[23:37] <lifeless> mwhudson: IRC or voice. either is fine for me - but this did sound a little thorny.
[23:37] <mwhudson> lifeless: so plugin unloading/layers are bad etc
[23:37] <mwhudson> lifeless: i think irc will do, to start at least
[23:37] <lifeless> ok
[23:37] <lifeless> so plugin unloading is 'unregister + delete from sys.modules'
[23:38] <lifeless> what interests me is why you need it
[23:38] <lifeless> layers are just a poor implementation of testresources; we don't need to talk about that immediately :)
[23:38] <mwhudson> so there's a specific problem -- probably really a launchpad bug -- that some tests fail when bzr-git is loaded
[23:39] <lifeless> is there a bug showing the failure?
[23:39] <lifeless> or a pastebin or something I can see?
[23:39] <mwhudson> (it's because LaunchpadTransport rejects filenames at one level apart from '.bzr' and 'backup.bzr' and so on, and bzr-git probes for some files)
[23:40] <lifeless> mwhudson: this suggests to me that bzr-git on the smart server may cause explosions?
[23:40] <mwhudson> however, there is a more general issue that we don't want bzr-git to be loaded when we don't expect it to be, i guess mostly because bad things could happen in the branch puller
[23:40] <mwhudson> (mirrored branches and imported branches should be made more similar, yes, but not by accident)
[23:41] <mwhudson> lifeless: it's possible, yes
[23:41] <lifeless> mwhudson: so only loading a plugin when you want it is fairly easy: don't import it :>
[23:41] <mwhudson> lifeless: sure, that part works fine
[23:41] <lifeless> mwhudson: but that doesn't help with the test failures
[23:41]  * mwhudson rummages for the failure
[23:42] <mwhudson> lifeless: http://pastebin.ubuntu.com/381912/
[23:42] <mwhudson> there are many things one could do to make this failure go away
[23:43] <mwhudson> you could fix the codehosting vfs to not explode on attempts to _read_ disallowed filenames
[23:43] <mwhudson> (which we should probably do anyway)
[23:43] <mwhudson> or you could unregister the git formats
[23:43] <lifeless> oh looks; test tools :)
[23:44] <lifeless> so
[23:44] <mwhudson> or we could run all tests that use bzr-git in subprocesses i guess
[23:45] <lifeless> I think you shouldn't blow up internally on read attempts to unexpected files: NoSuchFile is more appropriate
[23:45] <lifeless> 'these are not the files you are looking for', I mean. That, or bzr-git should be catching the permission denied error (by making it subclass something it catches)
[23:45] <lifeless> mmm
[23:45] <lifeless> * change the vfs
[23:46] <lifeless> * catch the error in bzr-git
[23:46] <lifeless> * use subunit to run the git using tests
[23:46] <lifeless> * use a resource to load git and unload it for tests that need it
[23:46] <lifeless> the last one is pretty easy
[23:46] <mwhudson> if it is, that must be the better option
[23:47] <mwhudson> the first two are probably good ideas but only solve the specific problem
[23:47] <lifeless> It seems like a workaround to me - is there evidence for or against having othe specific problems?
[23:47] <mwhudson> we probably wouldn't need the resource, it's only one testcase class (i think)
[23:48] <lifeless> you'll probably need to reach around inside bzrlib guts in the first place, but its not hard.
[23:48] <lifeless> and we can dress it up later.
[23:48] <lifeless> I suggest encapsulating it as follows:
[23:48] <maxb> wgrant, jelmer: It's not even a merge, just a no-change rebuild. Also, it's not required
[23:49] <lifeless> change bzr-git's __init__.py to not register stuff directly, rather to have a 'register()' function, which is called at the end of the module.
[23:49] <mwhudson> lifeless: i guess the only other specific problem i can think of is the branch puller
[23:49] <wgrant> maxb: Not required?
[23:49] <lifeless> and a deregister() function, which undoes - however ugly it is - what register did.
[23:49] <mwhudson> lifeless: but we're into 'unknown unknowns' on the cheney scale here
[23:49] <lifeless> make them both idempotent
[23:49] <mwhudson> (or was it rumsfeld?)
[23:49] <lifeless> mwhudson: I can write this for you in an hour or so, ifyou need
[23:49] <maxb> wgrant: the egenix thing is only a build-dep, not a dep
[23:50] <wgrant> maxb: It causes me problems here if I don't have a 2.5-supporting one.
[23:50] <lifeless> mwhudson: your test case would then do 'import bzrlib.plugins.git; bzrlib.plugins.git.register()' in setUp, and deregister in tearDown
[23:50]  * wgrant finds the import.
[23:50] <mwhudson> lifeless: that would work
[23:50] <maxb> wgrant: oh! Well we should add it to lp-deps then
[23:50] <lifeless> put this conversation in a bug on bzr-git; assign to me
[23:50] <wgrant> maxb: psycopg2 needs it.
[23:50] <maxb> the only reason I've been lazy about updating it is that aptitude wasn't whining at me
[23:50] <wgrant> maxb: It depends on it, but not a specific version.
[23:51] <mwhudson> lifeless: to generalise slightly, you could say that the next level down of problem is that it's hard to be confident of what's going to happen when you call "Branch.open" on a URL you don't entirely trust
[23:51] <lifeless> I don't think this is the best option, but it has clear limits which making things work with bzr-git being loaded doesn't.
[23:51] <lifeless> mwhudson: uhm, I don't get what that means
[23:52]  * maxb runs 'lpnochange egenix-mx-base' ..... I should put that script somewhere :-)
[23:52] <mwhudson> lifeless: if you set up a branch reference at some url that points to http://bazaar.lp.internal/$id_of_private_branch and asked for a mirror of the branch
[23:53] <lifeless> mwhudson: thats what the open hooks are for, no ?
[23:53] <mwhudson> if the puller wasn't careful, it would suck the private branch into public area
[23:53] <mwhudson> in the bzr-git case it would just be a performance screw up
[23:53] <lifeless> mwhudson: and similarly for git, I guess.
[23:53] <mwhudson> mmm, maybe the open hooks are enough these days
[23:54] <lifeless> mwhudson: so, I think that 'check policy' and 'plugin installed' are orthogonal.
[23:54] <lifeless> mwhudson: we should make sure you can enforce whatever policy is needed, but that should be entirely different from 'is bzr-svn installed and loaded'.
[23:55] <maxb> wgrant: I can't find the import, where is it?
[23:55] <mwhudson> lifeless: that certainly sounds like a worthy goal
[23:55] <wgrant> maxb: Probably _psycopg.so
[23:57] <lifeless> mwhudson: so, with respect to bzr-git, opening a random url will 'try all the things that can open branches'
[23:58] <lifeless> mwhudson: if you want a policy of 'we only support X types when we open a url' - file a bug on bzr, explain why you want it, and we can figure out how to do it.
[23:58] <wgrant> maxb: That does have an mx.DateTime reference.
[23:58] <wgrant> maxb: I would upgrade and see what breaks, but I have a test run going at the moment.
[23:59] <mwhudson> lifeless: if you know what the formats are precisely, that's easy enough already
[23:59] <mwhudson> i guess having an open hook that rejected non BzrBranch subclasses would do well enough for us