[00:00] <yacoob> *tap*tap* is this thing on? :)
[00:03]  * fullermd notes that in his years of running theatre tech, there was a standing order that tapping microphones was cause for finger-breaking...
[00:04] <yacoob> luckily this doesn't work yet over tcp/ip 8)
[00:05] <fullermd> I know.  Insufficient future-proofing   :(
[00:05] <maxb> I've never had cause to use bzr over smb, but that error does sound like that might be the problem.
[00:06] <yacoob> there's bug 31006, but *somehow* it was working for me before (with bzr 1.6 or so)
[00:07] <yacoob> RRrright.
[00:07] <yacoob> my repo was pack-0.92
[00:08] <yacoob> it works with that format
[00:08] <yacoob> it very much doesn't with 2a
[00:08] <maxb> It's breaking in even more esoteric ways for me
[00:09] <yacoob> le sigh.
[00:09] <yacoob> no love for this bug since 2009/09/29
[00:11] <yacoob> and I've foolishly said 'bzr upgrade' on my shared repo. Yay.
[00:11] <yacoob> no way to downgrade, right?
[00:17] <yacoob> ok, 'bzr upgrade' performed on a shared repo did... weird things. Topmost .bzr is no longer there, and I can't run 'bzr info' in that directory anymore
[00:17] <yacoob> exactly *one* of the repos below got converted from pack-0.92 to 2a
[00:18] <yacoob> and that directory got 'backup.bzr' directory
[01:05] <lifeless> yacoob: the dirstate code doesn't change from pack-0.92 to 2a
[01:06] <lifeless> yacoob: something else has altered
[01:06] <lifeless> yacoob: it also doesn't impact repositories at all, only working trees
[01:07] <yacoob> lifeless, interesting. But I've just verified that 'bzr push' from my local machine to a directory mounted via smbfs will work when format is pack-0.92, and fail with 2a
[01:08] <yacoob> both locks and oplocks seem to be there
[01:08] <lifeless> file a bug then
[01:09] <yacoob> I'll do that tomorrow I think. Kind of sleepy now :)
[01:31] <fossrox> hi guys!
[01:31] <fossrox> I've noticed a problem in documentation: http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/introducing_bazaar.html
[01:32] <fossrox> link: Bazaar Quick Start Card - a one page summary of commonly used commands.
[01:32] <fossrox> Not found: http://doc.bazaar.canonical.com/bzr.dev/en/quick-reference/quick-start-summary.svg
[01:32] <fossrox> thanks in advance guys!
[02:20] <dOxxx> good evening
[02:21] <lifeless> hai
[02:21] <dOxxx> any mac users around that would be willing to try installing the bzr 2.0.4 package I just built?
[02:21] <dOxxx> I'd like to have some verification other than my machine before I upload it to the bzr release page
[02:28] <dOxxx> Anyway, if there is anybody here that's willing, try it here: http://launchpad.net/bzr-mac-installers/2.0/2.0.4/+download/Bazaar-2.0.4-1-desktop.pkg
[02:28] <dOxxx> I'll be doing the same for the 2.1.0rc1 installer
[02:33] <dOxxx> a clean build of the mac installer takes like 25 minutes :(
[02:34] <dOxxx> 90% of it is pyqt I'm sure
[02:59] <MTecknology> Any ideas what causes this to happen? No handlers could be found for logger "bzr"
[02:59] <dOxxx> MTecknology: context?
[02:59] <MTecknology> It's only happening when I try to do bzr pull from www-data user
[03:00] <MTecknology> dOxxx: I found out what'
[03:01] <MTecknology> s wrong... typo
[03:02] <MTecknology> maybe not...
[03:02] <MTecknology> Could be an environment thing :S
[03:04] <dOxxx> looks like it might be bug 503886
[03:05] <dOxxx> you may want to try the newly released bzr 2.1.0rc1 or 2.0.4 which have a fix for making it easier to see what the error on the server is
[03:05] <dOxxx> but I would hazard a guess that your ~/.bzr.log cannot be accessed as the www-data user
[03:06] <dOxxx> on the server
[03:19] <MTecknology> dOxxx: looks like that user can access that fiel
[03:19] <MTecknology> dOxxx: but deleting it removed the error - thanks
[04:03] <lifeless> oh hai, it is the internets
[04:03] <fullermd> I made you an internets, but I eatered it.
[04:04] <lifeless> I'm in your router eating your packetz?
[05:10] <dOxxx> good night all
[06:14] <micahg> hi, how do I merge in a branch with no common ancestor?
[06:17] <Peng> Um, IIRC "bzr merge -r 0..-1 /path/to/branch".
[06:17] <Peng> I don't remember if there are any caveats.
[06:17] <Peng> That may do a cherrypick and drop the actual revision information...
[06:17] <Peng> I know what you want is _possible_, I just don't remember exactly how. :P
[06:17] <micahg> Peng: worked, thanks
[06:18] <micahg> or maybe not...
[06:18] <micahg> it moved the directory :(
[06:18] <micahg> now I have debian and debian.moved
[06:22] <micahg> peng: ^^
[06:39] <Peng> micahg: Uh-huh. If both branches have directories named "debian", it's a conflict/.
[06:41] <micahg> Peng: what do I do?
[06:42] <RAOF> Resolve the conflicts?  IE: work out what's different in debian & debian.moved, work out what you want in debian/, and then delete debian.moved.
[06:42] <RAOF> meld is a good tool for the task of producing the debian/ you want from debian & debian.moved
[06:43] <micahg> k, so it'll still have the history from the new branch if I do that?
[06:43] <RAOF> Yes.
[06:43]  * micahg wishes winmerge was ported to linux
[06:44] <RAOF> It's called *meld* :)
[06:44] <micahg> RAOF: I've tried meld in the past unless 1.3 is a new version
[06:44]  * micahg will try it now
[06:44] <micahg> indeed
[06:45] <micahg> they seem to have made some improvements :)
[06:45] <RAOF> Looking at the screenshots I can find for winmerge, it looks almost exactly like the meld I know & love.
[07:15] <micahg> RAOF: so, I moved what I want into the debian dir, but the diff seems to show that everything's changed?
[07:15] <micahg> did I want to go the other way?
[07:30] <RAOF> micahg: I'm not 100% sure what you've done, so I'm not sure.
[07:30] <micahg> I added the files from debian.moved that I wanted to debian
[07:30] <micahg> but now bzr diff shows evrything different
[07:30] <micahg> was I supposed to merge into debian.moved instead>
[07:32] <RAOF> debian.moved will be the debian directory of the branch you tried to merge *into* the current branch (ie: if you ran bzr merge $TARGET then debian.moved will be the debian dir from $TARGET).
[07:32] <RAOF> You should end up with just a single debian directory by merging the changes you want from debian.moved into the files in debian.
[07:32] <micahg> debian.moved was the original dir
[07:34] <RAOF> I might have it the wrong way around, then.  From memory, it's the directory from the thing that you're trying to merge from that gets renamed in a conflict.
[07:34] <micahg> RAOF: bottom line though is I want to move the new stuff into the old dir?
[07:35] <RAOF> Yeah.  At the end, you want the debian/ directory to contain the stuff that you want.
[07:35] <micahg> RAOF: did that, but I still have issues
[07:35] <micahg> so I need to move the stuff from debian to debian.moved and then delete debian and rename debian.moved?
[07:36]  * micahg fires up meld again trying to get this right
[07:37] <RAOF> I'm not totally sure what your issues are.
[07:38] <RAOF> I'm pretty sure that it doesn't really matter how you end up with the debian/ directory, though.  Moving stuff from debian.moved => debian, or moving from debian=>debian.moved & then renaming debian should be equivalent.
[07:41]  * micahg is very lost
[07:41] <RAOF> Let's try and help me work out precisely what's happening :)
[07:42] <micahg> I'm running bzr merge -r 0..-1 TB3 into TB2
[07:42] <RAOF> In your current tree, you've got debian and debian.moved.  You've taken all the changes from debian.moved that you wanted & applied them to debian, so debian/ is now what you'd like in your final tree.
[07:42] <micahg> this creates a debian dir of tb3 contents and debian.moved of tb2 contents
[07:42] <micahg> I moved what I wanted into debian
[07:43] <micahg> bzr diff shows everything is diffferent
[07:43] <RAOF> By “everything”, what do you mean?  Can you pastebin the output of bzr diff?
[07:44] <micahg> it removes and adds the files
[07:46] <micahg> I can;t even do bzr diff on one file
[07:54] <RAOF> Can you pastebin the full diff?  I'm having difficulty visualising what's happening
[07:56] <micahg> no, it's 24k lines
[07:57] <micahg> RAOF: ^^
[08:03] <RAOF> Ow.
[08:03] <RAOF> I'm not really sure what's happening, sorry.
[08:05] <RAOF> I'll try to make a simple analogue of what you're doing locally; see if I can wangle it.
[08:07] <micahg> RAOF: you can reproduce, branch thunderbird-3.0.head and thunderbird.head from code.lp/thunderbird
[12:15] <abli> Hi! How can I 'join' different projects? I.e. merge all versions from one into the other, if they don't have a common ancestor? 'bzr merge' works only if there is a common ancestor, merge-into plugin ditto; fastimport plugin apparently wants to replace the full version history instead of tacking it at the end.
[12:22] <Peng> abli: "bzr merge -r 0..-1 foo" should work.
[12:24] <abli> Ok, I'll try that.
[12:25] <Peng> Possible side effects include unhappiness, maiming, and death. or not.
[12:33] <abli> It appears thats what I was looking for. Thanks!
[12:34] <Peng> \o/
[14:22] <goneri> Hi, I did a svn→bzr transition and now I've a broken branch that don't share revision with trunk. This branch starts when the svn branch had been created. So now Bzr can't merge this branch in trunk since there is no shared references. Is there a way to edit the initial revision of my branch?
[16:15] <mobodo> when I do 'bzr export --format="zip" - myDirectory', I got nothing, but if I do 'bzr export --format="tgz" - mDirectory', it works
[16:16] <mobodo> also, zip to a file instead of stdout works
[16:37] <Colonel-Rosa> morning, does anyone know of a bzr netbeans plugin?
[16:37] <Colonel-Rosa> If not, I'll head the advice found on the wiki and clone the hg plugin and see what I can do
[16:37] <Colonel-Rosa> heed*
[18:19] <keithy_> hi whats the statuse on nested tree support?
[18:28] <The_User> Hi! Is there anything like "svn (up|co) -N" in bazaar?
[18:34] <The_User> In svn you can do a checkout this way without downloading all the contained files and subdirectories, you use "svn up" without "-N" to download them completely.
[18:41] <jpds> The_User: bzr update|checkout ?
[18:42] <The_User> jpds: yes, but without downloading all sub directories
[18:52] <The_User> ??
[20:04] <mobodo> could somebody confirm something for me? I think "bzr export --format=zip - " is broken
[20:05] <mobodo> with tar/tgz/tbz2 it works fine (export to stdout), but not with zip
[20:05] <mobodo> just want to check if it's my installation that's broken or bzr
[20:05] <mobodo> (export to a file works, it's just to stdout that's broken)
[23:03] <fullermd> The_User: (hours later) No, the working tree (or revisions thereof) is always entire.
[23:03] <The_User> fullermd: okay :
[23:03] <The_User> D
[23:04] <fullermd> Now, that's no theoretical boundary to only _checking out_ parts of it.
[23:04] <fullermd> But certainly anything dealing with history has a revision's full tree as its smallest component.
[23:05] <fullermd> And there's no implementation of checking out part of a tree.  The 'view' support can sorta let you post-facto treat a full checkout as if it were partial, but that doesn't help you   :)


[00:07] <wgrant> How is the discussion about community committers/reviewers going?
[00:09] <mwhudson> it's petered out
[01:22] <thumper> mwhudson: had lunch yet?
[01:22] <mwhudson> thumper: no
[01:23] <thumper> you should grab something to eat, then we can talk about reviews :)
[01:38] <mwhudson> thumper: just finished with kiko
[01:39] <thumper> :)
[01:39] <thumper> ok
[01:51] <mwhudson> thumper: so yeah, i need to eat, and then we should talk
[01:55]  * mwhudson lunches
[02:20] <mwhudson> huh, x has gone odd and i need to restart anyway so...
[02:35] <mwhudson> argh
[02:35] <mwhudson> i've managed to uninstall gnome-panel somehow :/
[02:50] <thumper> :(
[03:15] <thumper> mwhudson: ping
[03:17] <mwhudson> thumper: pong
[03:17] <mwhudson> (sorry, no notifications with no panel!)
[03:17] <thumper> heh
[03:17] <thumper> mwhudson: when do you want to do a call?
[03:18] <mwhudson> thumper: now is good
[05:16] <wgrant> I pushed a couple of new revs to a branch 12 minutes ago... still awaiting scanning.
[05:23] <spm> looking....
[05:24] <wgrant> It's scanned now.
[05:24] <wgrant> Just took ages.
[05:24] <wgrant> Not quite 2006-ages, but getting close.
[05:24] <spm> hrm...
[05:24] <spm> :-)
[05:24] <wgrant> Part of that could be slave lag too, I guess.
[05:25] <spm> slave lag? as in DB? shouldn't be that bad!
[05:25] <wgrant> I'd hope not.
[06:00] <lifeless> thumper: mwhudson: have you guys seen beanstalkd ?
[06:04] <mwhudson> lifeless: no
[06:44] <StevenK> Bah, registering an MP just gave me a timeout error
[06:45] <mwhudson> StevenK: the branch was probably still being scanned
[06:45] <lifeless> mwhudson: apparently designed 'to make websites faster by doing slow tasks asynchronously'
[06:46] <lifeless> http://flapjack-project.com/ references it
[06:46] <mwhudson> StevenK: wait a minute or so and resubmit
[06:46] <mwhudson> lifeless: on the face of it, that sentence doesn't make sense :)
[06:46] <mwhudson> but i guess i know what they're driving at
[06:46] <StevenK> mwhudson: Aye, will do
[06:46] <lifeless> i paraphrased an equally not-quite-sane quote
[06:47] <lifeless> anyhow, might be worth a gander
[06:47] <mwhudson> lifeless: it seems a bit like gearman, maybe?
[06:47] <lifeless> maybe, more lightweight and message bussy I think
[06:47] <StevenK> mwhudson: Worked, thanks
[06:48] <mwhudson> StevenK: np, it's just another reason to kill the branchrevision table...
[06:50] <mwhudson> lifeless: it does have a "simple enough to possibly work" sort of feel to it
[06:51] <lifeless> auxesis told me about it a year or so back
[06:51] <lifeless> and I blanked on it when the whole reinvent wheels was going on
[06:51] <lifeless> just got reminded, so - saying;)
[08:01] <adeuring> good morning
[09:10] <mrevell> Morning
[09:17] <thumper> lifeless: I don't understand what beanstalked is
[09:18] <wgrant> noodles775: So, apart from the state thing, how does the proposal look?
[09:25] <noodles775> wgrant: It looks great so far... I usually find some things come out in the wash, hence putting together the schema change. But it allows everything we discussed earlier (common shared data, shared data for package builds etc.)
[09:26] <noodles775> wgrant: I'll create a WIP mp when it's ready and add you to it to get your feedback/thoughts.
[09:26] <wgrant> noodles775: Great, thanks.
[10:27] <wgrant> noodles775: http://people.ubuntu.com/~wgrant/launchpad/buildfarm/new-build-model-again.png <- now with fewer missing attributes, more compliant names, and proper lp.* division
[10:27] <noodles775> wgrant: thanks.
[10:28] <wgrant> The layout seems quite a bit busier, but it is hopefully more accurate.
[10:29] <wgrant> Hm, early release?
[10:36] <noodles775> wgrant: how do you feel about s/job/build_farm_job so we don't have confusion over the job table?
[10:36] <wgrant> noodles775: Good point.
[10:42] <noodles775> wgrant: also, am I right that there's a bunch of stuff missing atm? (like IBuild.package_upload -> PackageBuild?, IBuild.can_be_retried/rescored -> BuildFarmJob?)
[10:42] <noodles775> I'll do an initial change, and then check for missing fields in the new schema, probably easier.
[10:43] <noodles775> erm, forget the last two... properties.
[10:44] <noodles775> actually, forget I spoke at all :)
[10:44] <wgrant> Yeah, all properties.
[10:44] <wgrant> They should probably be included, but that would get very big.
[10:44] <noodles775> Yeah, we can include them when updating the iface/model code.
[11:09] <wgrant> Yay, Sphinx.
[11:09]  * wgrant loves Sphinx.
[11:23] <wgrant> Evening jtv!
[11:23] <jtv> hi wgrant!  Sorry to have been ignoring you... half a world of travel plus tonsilitis.
[11:23] <jtv> But I suggest you visit Thailand someday and we'll fix that.  I'll personally guarantee that you have a good time.  :)
[11:23] <wgrant> Ew, tonsilitis.
[11:24] <jtv> (I'm gushing a bit because of the "oh btw I fixed the bugs" thing :-)
[11:24]  * wgrant is still not quite over the Wellington whooping cough.
[11:24] <jtv> whoa
[11:24] <wgrant> Yeah, it likes to stick around for a couple of months.
[11:24] <jtv> yes, it sort of contradicted for me the whole theory that January is midsummer on that hemisphere...
[11:24] <wgrant> Heh.
[11:25] <jtv> So, what were the remaining bugs?
[11:25] <wgrant> So, yeah, template builds and uploads work with a couple of my branches. 'tis encouraging.
[11:25]  * wgrant digs up the branches.
[11:26] <wgrant> https://code.edge.launchpad.net/~wgrant/launchpad/bug-549340-fix-buildqueue-destruction <- this one has been rejected, but should be resolved by noodles' model redesign.
[11:26] <wgrant> And the last three revs on https://code.edge.launchpad.net/~wgrant/launchpad/get-translations-jobs-working
[11:27]  * jtv looks
[11:28] <jtv1> BTW thanks for unifying the slaveStatus... for our use case it was painfully obvious that something like that was needed, but I just didn't have enough overview to be sure about the other use-cases.
[11:28] <jtv1> okay I shouldn't have touched that cable...
[11:29] <jtv> bit awkward here with a main machine that won't boot and a router that throws up packet storms... means I had to plug the iffy wall cable straight into my laptop.
[11:30] <wgrant> Hah.
[11:30] <wgrant> Yeah, that slaveStatus branch should be landed right after PQM opens.
[11:32] <wgrant> Then I'll get the others in soon after, although things won't work completely until the modle rework.
[11:32] <wgrant> So we might actually have three working build farm jobs in 10.04... maybe.
[11:33] <jtv> We're certainly hoping we can manage that.
[11:33] <jtv> By the model rework you mean the simplification with build attempts etc. that you sketched out two weeks or so ago?
[11:34] <wgrant> No attempts any more. I believe noodles is currently attempting to realise something like http://people.ubuntu.com/~wgrant/launchpad/buildfarm/new-build-model-again.png
[11:35] <noodles775> jtv: yep, I'll have a WIP MP with a very early schema change in a few mins.
[11:35] <jtv> cool!
[11:35] <jtv> noodles775: meanwhile, we've been talking about replacing getName/verifySlaveBuildID with a single generateSlaveCookie method that produces a hashed cookie.  Verification consists of re-generating it and seeing that it matches what the slave says.
[11:36] <wgrant> jtv: I've another branch which rips the slave build ID out of everywhere except rescueBuilderIfLost, so you will be able to completely replace it without breaking anything else.
[11:36] <noodles775> jtv: yeah I saw. Is that related to wgrant's branch that removes the builder dependency on ...
[11:36] <jtv> it gets better and better :)
[11:48] <noodles775> wgrant, jtv, bigjools: If you want to take an early look, grab the branch from https://code.edge.launchpad.net/~michael.nelson/launchpad/db-build-generalisation-db-changes/+merge/22527 before LP goes down in 10mins :)
[11:48] <bigjools> good call :)
[11:48]  * wgrant grabs.
[11:48] <jtv> noodles775: thanks
[11:49] <noodles775> There are a lot of notes/todos in there, but it'll give you a chance to let me know if it's heading in the right direction.
[11:49] <wgrant> I think they might've turned off the cron jobs off already.
[11:49] <noodles775> OK, I'll paste a diff.
[11:49] <jtv> that'd make sense, let things quiet down.
[11:49] <wgrant> There's no mirrored copy of the branch, nor diff. :(
[11:49] <bigjools> gah
[11:50] <bigjools> branching failed
[11:50] <noodles775> wgrant, jtv, bigjools: http://pastebin.ubuntu.com/406980/
[11:50] <wgrant> noodles775: Thanks.
[11:51] <bigjools> ta
[11:53] <wgrant> I was thinking that it was rather simple. But of course there's no non-binary job data, so it can be...
[11:53] <wgrant> Convenient.
[11:54] <noodles775> wgrant: Yeah, if we don't have to populate with any future SPRBuild data, it will be convenient.
[11:57] <wgrant> noodles775: I'd like to make BFJ.virtualized NOT NULL while we're at it.
[11:57] <noodles775> Noted.
[11:58] <jtv> noodles775: what's the stuff with the sequence for?
[11:58] <wgrant> Virtualisation is very much something that you can't care about here.
[11:58] <wgrant> Er, can't *not* care about.
[11:59] <noodles775> jtv: It's just because I created the tables using CREATE TABLE blah AS (as I think it's a bit more readable, enabling the table creation based on existing data/types etc.)
[11:59] <noodles775> But the only way I could see to have a primary key as the first column using this method was to explicitly create the sequence.
[11:59] <jtv> noodles775: that's true... the other way to do it would be a conventional CREATE TABLE followed by INSERT INTO
[12:00] <noodles775> (adding a primary key afterwards works fine, but it ends at the end of the table).
[12:00] <noodles775> jtv: Yeah, I guess I thought the advantage of inheriting all the column defs from the existing tables was nice... but maybe it's not worth it?
[12:01] <noodles775> It's really just the value+type.
[12:02] <jtv> noodles775: it's not going to be all that important (barring mistakes), but personally I prefer to have all the constraints and indexes in there from the start.  Also makes it easier to catch little things like fixed-size columns following text columns.
[12:03] <noodles775> jtv: yep. OK, I'll switch it over.
[12:03] <noodles775> jtv1: yep. OK, I'll switch it over.
[12:05] <jtv1> cool, thanks for accommodating my OCD.  :)
[12:10] <jtv> Can anyone (esp. Registry I guess) shed some light on this shortlist exception?  OOPS-1550O2497
[12:19] <wgrant> noodles775: I wondered about build_warnings. I guess we should just drop it.
[13:12] <noodles775> wgrant: yeah, i can only see it in the schema.
[13:19] <wgrant> noodles775: Are you going to leave buildduration in the model as an abstraction? We'll hopefully be able to fill it in properly soon.
[13:23] <noodles775> wgrant: as a property on the model, sure, but I'm not sure why we'd want to fill it in (ie. for it to be a db column?).
[13:24] <noodles775> Or that's what you meant?
[13:24] <wgrant> noodles775: It has been thought for a while that we should eventually retrieve the real duration from the slave.
[13:25] <noodles775> wgrant: ah I see. Well, I'm guessing rather than "We'll be using it real soon", we'll just have to add it later then ;)
[13:26] <wgrant> noodles775: Yep, just leave it as a property for now.
[13:46] <sinzui> I just saw an interesting test failure in ec2. object-milestones failed because the test data used 2010-04-01 and 2010-04-02 and the test is verifying those dates...but the UI shows the dates as "in 22 hours" as the moment counts down.
[13:46] <sinzui> jpds: you can ignore the error in the test, there is nothing for you to do.
[13:47] <jpds> sinzui: I figured so. :)
[13:47] <wgrant> Hah.
[13:47] <wgrant> We are in the future now.
[13:50] <sinzui> We were promised jet packs in the future, where is mine?
[14:05] <deryck> another hour on release time, for those who missed the channel change or the chatter on #launchpad
[14:11] <kfogel> adeuring: did you have a chance to review my bug #538219 branch before LP went read-only?  (I'm having trouble reaching the branch right now, or I'd just look.)
[14:12] <adeuring> kfogel: sorry -- I missed completely your review request (
[14:13] <kfogel> adeuring: np, just when you have a chance (and lp is back) take a look
[14:13] <adeuring> kfogel: to avoid such a mess in the future, please ping me on IRC and I'll do the review ASP
[14:13] <kfogel> adeuring: I think it's a pretty small change.  I didn't refactor some duplicated in the tests because it didn't seem worth it yet.
[14:13] <kfogel> adeuring: oh, you were definitely asleep when I made the MP :-)
[14:14] <adeuring> kfogel: well, oh, right, that was around midnight my time... But anyway, somehow I do not notice the review requests in my inbox properly...
[14:15] <kfogel> adeuring: it's really no mess, don't worry.  Considering that the next release is a month away, it's okay if there's a day delay in reviewing this change!  (I just wish I'd finished it sooner.)
[14:25] <noodles775> wgrant: around? I keep finding my self saying, BuildFarmJob, PackageJob, BinaryPackageJob, insteada of PackageBuild, BinaryPackageBuild.
[14:25] <noodles775> I'm keen for the Build ending, but wondering if we shoud update BuildFarmJob to SomethingFarmBuild?
[14:43] <leonardr> flacoste, before we can put launchpadlib 1.5.8 into lucid (that's the one that uses web service 1.0 by default)
[14:43] <leonardr> we need to port all the packages that use launchpadlib to api version 1.0
[14:43] <leonardr> jamesw identified 9 such packages
[14:43] <leonardr> apport
[14:43] <leonardr> bughugger
[14:43] <leonardr> bzr-builddeb
[14:43] <leonardr> bzr-pqm
[14:43] <leonardr> groundcontrol
[14:43] <leonardr> lptools
[14:43] <leonardr> quickly
[14:43] <leonardr> ubuntu-dev-tools
[14:44] <leonardr> ubuntu-qa-tools
[14:44] <leonardr> pitti ported apport yesterday
[14:44] <leonardr> some of these probably don't need to be ported, but we need to at least check
[14:44] <flacoste> oh shit
[14:44] <flacoste> that's a lot of work :-/
[14:44] <flacoste> when the beta2 is coming out in a week
[14:44] <leonardr> yeah
[14:44] <leonardr> i'm happy to help but we need to coordinate with the owners of those packages
[14:45] <leonardr> the porting is easy (assuming these apps have unit tests)
[14:45] <leonardr> the coordination is a time sink
[14:47] <james_w> we don't really have owners of packages in Ubuntu
[14:47] <james_w> I can help you make the changes easily
[14:48] <leonardr> ok, that makes things look better
[14:49] <leonardr> flacoste, gary, should i go for it? (gary: this would mean putting off the launchpadlib pagetest thing)
[14:49] <leonardr> gary: or i can finish the pagetest branch first
[14:49] <flacoste> leonardr, gary_poster: since that item has a Due date, i think it makes sense to push that forward first
[14:50] <gary_poster> leonardr: Yeah, I'm +1 on working on that
[14:50] <flacoste> gary_poster, leonardr: especially if it means we don't need to support the /beta webservice for 5 years!
[14:50] <leonardr> all right
[14:50] <gary_poster> right :-)
[14:50] <leonardr> james_w, do you have time?
[14:50] <leonardr> if not i can send you recommendations via email
[14:50] <james_w> right now?
[14:51] <leonardr> james_w: i'm going to start right now, but like i said, if you're not free, you can come in late
[14:51] <james_w> I'll be with you in 20
[14:52] <leonardr> all right
[15:00] <james_w> leonardr: ok, I'll take bzr-builddeb obviously, and ubuntu-qa-tools
[15:00] <leonardr> james_w: there don't seem to be any changes necessary to ubuntu-qa-tools, but look it over to double check
[15:00] <james_w> oh, ok
[15:01] <james_w> should we make it explicit anyway?
[15:21] <james_w> leonardr: are we changing the constructor call to make it explicit, or just allowing them to pick up the default?
[15:21] <leonardr> james_w: allowing them to pick up the default
[15:21] <james_w> ok
[15:21] <leonardr> i'm concerned about 1) uses of named operations not present in 1.0
[15:21] <leonardr> 2) explicit references to "beta"
[15:21] <james_w> I agree that ubuntu-qa-tools is fine, bughugger is done
[15:22] <leonardr> because of 2) i just realized that ubuntu-qa-tools is not fine
[15:22] <james_w> ok
[15:22] <james_w> bzr-builddeb is fine
[15:22] <leonardr> all right
[15:22] <james_w> bzr-pqm is broken
[15:22] <leonardr> there are several calls to launchpad.load() which include a "beta" url
[15:24] <james_w> yeah
[15:25] <james_w> what should they use there?
[15:25] <james_w> lp.load(SERVICE_ROOT + "bugs/" ...
[15:25] <james_w> or does it need the version in there too?
[15:28] <leonardr> the version does need to be in there
[15:28] <leonardr> let me try to find a better solution
[15:29] <james_w> urg, we would have to use lp._root_uri
[15:30] <leonardr> yeah
[15:30] <leonardr> but, that's better than having a hard-coded version
[15:30] <james_w> yeah
[15:30] <james_w> would be great if lp.load could interpret a relative URL as being relative to the service root
[15:32] <gary_poster> deryck, did you decide on a "consider opening up PQM" time?
[15:32] <leonardr> james_w: yeah, that's bug 524775
[15:32] <mup> Bug #524775: Launchpad.load doesn't like relative urls <launchpadlib :New> <https://launchpad.net/bugs/524775>
[15:32] <deryck> gary_poster, thinking about that now actually.
[15:32] <gary_poster> cool
[15:32] <leonardr> james_w: i could fix that easily, but releasing a <IP_ADDRESS> launchpadlib would be a bit of a pain. do you think it's worth it?
[15:33] <james_w> we can just use lp._root_uri +
[15:34] <leonardr> yeah
[15:34] <gary_poster> how much of a pain leonardr?  and is this the only app that does this?
[15:34] <leonardr> gary: no, it's all over
[15:34] <gary_poster> ...
[15:34] <leonardr> lifeless even put a special hack into lptools/launchpad.py to fix bug 524775
[15:34] <mup> Bug #524775: Launchpad.load doesn't like relative urls <Launchpad Foundations:Triaged> <launchpadlib :Triaged> <https://launchpad.net/bugs/524775>
[15:35] <gary_poster> james_w, leonardr, how tight is time?
[15:35] <gary_poster> and how long will this take?
[15:35] <leonardr> gary: james_w and i agree it's not worth it right now
[15:35] <leonardr> we'll just use _root_uri
[15:36] <gary_poster> ...don't like it, but ok.
[15:36] <james_w> we can take a list of the ones we do it to and followup with a correct fix once it is fixed in lplib
[15:36] <leonardr> yeah
[15:37] <gary_poster> ok
[15:37] <gary_poster> might as well dump that info in the bug report, once you have it
[15:42] <leonardr> james_w: my proposed changes to ubuntu-qa-tools
[15:42] <leonardr> http://paste.ubuntu.com/407091/
[15:42] <leonardr> gary: so far all the changes are "now it has to support multiple versions" changes, not 1.0-specific changes
[15:43] <james_w> my bughugger change: https://code.edge.launchpad.net/~james-w/bughugger/fix-api-usage/+merge/22536
[15:43] <gary_poster> leonardr: good, and not surprising
[15:43] <james_w> leonardr: looks good to me
[15:43] <leonardr> apport was the only app that actually used those features
[15:43] <leonardr> james_w: i'm pushing a branch
[15:44] <james_w> bzr-pqm: https://code.edge.launchpad.net/~james-w/bzr-pqm/fix-service-roots/+merge/22540
[15:46] <leonardr> https://code.edge.launchpad.net/~leonardr/ubuntu-qa-tools/fix-api-usage
[15:46] <leonardr> james_w, taking a look at yours
[16:06] <leonardr> james_w: i have a bad feeling about the get_bazaar_host calls in bzr-pqm
[16:06] <leonardr> investigating
[16:07] <leonardr> eh, i guess theres' tests for it, they'l'l fail if something's wrong
[16:09] <leonardr> james_w: i'm pretty sure quickly doesn't need any changes
[16:10] <james_w> good
[16:10] <leonardr> lptools does need changes, working on them now
[16:20] <leonardr> https://code.edge.launchpad.net/~leonardr/lptools/multiversion-support/+merge/22544
[16:27]  * leonardr does not look forward to searching for "1.0" in 5 years when we're trying to deprecate 1.0
[16:28] <leonardr> perhaps we should give the api versions ubuntu release-like names that do not conflict with ubuntu release names
[16:31] <james_w> lptools looks good to me
[16:31] <leonardr> i don't see any problems with groundcontrol, i'm confirming with doctormo
[16:33] <leonardr> james_w: the only one i don't have information for is bzr_builddeb. what does that look like?
[16:33] <james_w> I'll fix it
[16:33] <james_w> it's got an lp.load
[16:33] <leonardr> all right
[16:35] <leonardr> confirmed that the lp.load is the only problem
[16:45] <abentley> bigjools, re: http://pastebin.ubuntu.com/407124/ can self.can_copy_to_context_ppa ever evaluate false in this loop?
[16:45] <bigjools> looking
[16:47] <abentley> bigjools, (and if so, would you really want to present it as a potential copy target to the user?)
[16:47] <bigjools> abentley: it could do in some weird situations
[16:48] <abentley> bigjools, so in those situations, it would make sense as a copy target?
[16:48] <bigjools> no, it doesn't
[16:48] <bigjools> that's what the loop's doing isn't it?
[16:48] <abentley> bigjools, the loop says it will be included as a possible target if the user can't upload to it.
[16:49] <abentley> If it evaluates false, the and expression is false, and so it will be included in the list of terms.
[16:49] <jtv1> sinzui: thanks for the help with the shortlist issue.  I now remember it was adeuring who came across before, and I reviewed the branch myself.  Is anyone fixing it or shall I?
[16:50] <bigjools> abentley: ah no it's excluding the context  PPA
[16:50] <jtv1> abentley: hi!  Did you claim a review for me and not get around to finishing it?
[16:50] <abentley> jtv, oh, maybe.
[16:50] <bigjools> abentley: it's just doing it in a very odd way
[16:51] <jtv> abentley: hope "maybe" is not your vote on the MP.  ;-)
[16:52] <abentley> jtv, yes, I forgot about that.  Sorry.  I'll do it next.
[16:52] <jtv> abentley: cool, thanks.  I wasn't going to force you, but would be grateful.
[16:53] <abentley> bigjools, if the context ppa is included in self.ppas_for_user, and self.can_copy_to_context_ppa evaluates False, the context PPA will be included in the list of target PPAs.
[16:55] <bigjools> abentley: yeah that's what I mean by that code being weird!
[16:55] <abentley> bigjools, because the "and" expression will evaluate False, which means we won't continue.
[16:56] <bigjools> indeed
[16:56] <bigjools> abentley: I've no idea why the first condition is there
[16:57] <abentley> bigjools, my guess is that the context PPA should be excluded all the time.  But "required" should only be set False if both conditions are true.
[16:57] <bigjools> abentley: the archive in question is not always a PPA
[16:57] <bigjools> it can be a copy archive
[16:58] <bigjools> which uses the PPA views/templates
[16:58] <bigjools> I think that's why it's there
[16:58] <abentley> bigjools, The context may not be a PPA or the "ppa" variable may not be a PPA?
[16:59] <bigjools> abentley: potentially both but the context usually
[17:00] <bigjools> the ppa variable is 99% a ppa
[17:00] <bigjools> unless there's a bug somewhere
[17:07] <abentley> bigjools, that suggests that 1% of the time, getPPAsForUser will return archives that are not PPAs.  Is that what you mean?
[17:07] <abentley> bigjools, and if so, how to I force it to give me only ppas?
[17:08] <bigjools> abentley: it can happen if the user owns a non-PPA archive.    I said "bigjools, my guess is that the context PPA should be excluded all the time.  But "required" should only be set False if both conditions are true."
[17:11] <abentley> bigjools, do you agree with that now?
[17:15]  * jml afk
[17:17] <bigjools> abentley: I agree
[17:18] <abentley> bigjools, cool.  I'll tweak that as I refactor it, then.
[17:19] <bigjools> abentley: thanks - are you making a vocabulary out of it?
[17:20] <abentley> bigjools, I'll at least extract a function that turns a list of archives into a SimpleVocabulary.
[17:20] <bigjools> cool
[17:21] <abentley> bigjools, haven't made vocabularies before, so it's a bit new.
[17:22] <abentley> Because my context won't be an archive, I don't think the copy packages page can share an archive with the request-a-build page.
[17:23] <abentley> Because my context won't be an archive, I don't think the copy packages page can share *a vocabulary* with the request-a-build page.
[17:23] <bigjools> the vocab is dependent on the user
[17:24] <abentley> bigjools, but the vocab on the copy packages page is also dependent on the context ppa, and this won't be true for my case.
[17:25] <bigjools> that is true
[17:25] <bigjools> but it's a bit of a hack
[17:27] <abentley> bigjools, I haven't seen the UI, but it seems like another option would be to include the context PPA in the vocabulary, and select it using the "initial_values".
[17:40] <sinzui_> join #launchpad
[18:42] <jml> g'night all
[18:48] <james_w> leonardr: oops _root_uri isn't going to work: https://code.edge.launchpad.net/~leonardr/ubuntu-qa-tools/fix-api-usage/+merge/22541
[18:56] <leonardr> james_w: we can convert that uri to a string easily enough
[18:56] <james_w> yep
[19:36] <sinzui> gary_poster, ping
[19:36] <gary_poster> sinzui: on call pong you later?
[19:36] <sinzui> gary_poster, sure. barry and I want to know if there is a python 2.6 list of issues
[19:39] <gary_poster> no; that's my next task tho
[19:41] <barry> gary_poster, sinzui that's the #1 thing holding up my work on integrating lp w/ mm3 (which requires py2.6)
[19:42] <gary_poster> barry: it will be tackled this cycle
[19:42] <barry> gary_poster: fab
[20:02] <leonardr> james_w: any progress on bzr-builddeb? that's the only one i don't know about
[20:03] <james_w> leonardr: nope, I've been working on other things.
[20:03] <james_w> it's an easy job though
[20:03] <leonardr> james_w: i'll take a look if you want
[20:03] <james_w> no, it's fine
[20:03] <leonardr> all right, just let me know when you've got something so i can send another email
[20:46] <kfogel> sinzui: not sure if this is something you can answer, but the definition of lib/lp/bugs/browser/bugcomment.py:BugComment.can_be_shown() puzzles me and I'd like to ask someone about it.  I expected it to contain code determining if getUtility(ILaunchBag).user can view this comment or not -- but instead, it's just about bugwatches.
[20:47] <kfogel> sinzui: Is there some other method that does what I expected can_be_shown() to do?  I don't see any... (this is all for bug #546943, by the way).
[20:47] <mup> Bug #546943: Hidden bug comments still have a direct link/page that is visible <easy> <spam> <Launchpad Bugs:In Progress by kfogel> <https://launchpad.net/bugs/546943>
[20:48] <sinzui> kfogel, the rule may be vestigial. we hid imported bug comments for many months
[20:49] <kfogel> sinzui: I guess I'm looking for the condition that says "this comment is hidden", in the way meant by bug #546943.  I thought this method was it, but it looks like not.
[20:49] <mup> Bug #546943: Hidden bug comments still have a direct link/page that is visible <easy> <spam> <Launchpad Bugs:In Progress by kfogel> <https://launchpad.net/bugs/546943>
[20:49] <kfogel> oh, maybe self.visible
[20:49] <sinzui> ah
[20:50] <sinzui> kfogel, .hidden means private. that is how we remove spam
[20:50] <kfogel> sinzui: i.e., it's nothing to do with authn perms that might differ by user -- "hidden" in this context means "hidden from everyone"
[20:50] <sinzui> kfogel, admins need to see them, maybe chr too
[20:50] <kfogel> ?
[20:51] <kfogel> sinzui: hmm, this prop might be on IMessage instead
[20:51]  * kfogel pokes around more
[20:52] <sinzui> can_be_shown is from comment imports. .visible is from spam control. In this case losas need to see them so that they can find what needs to be reenabled
[20:53] <sinzui> kfogel, is the comment view guarded by a security checker? one that asks of the comment is .hidden and decides if the user can see it?
[20:53] <kfogel> sinzui: yes -- that was how I got to can_be_shown() in the first place
[20:53]  * sinzui thinks the comment and the link to it should have the same security rule.
[20:53] <kfogel> sinzui: i.e., lib/lp/bugs/templates/bugtask-index.pt
[20:53] <sinzui> okay. I think I see
[20:54] <kfogel> sinzui: although bugcomment-index.pt also has that rule, ...
[20:54] <kfogel> but I think that may be a red herring
[20:55] <sinzui> We need up update the security rule on the view to do something like return user.is_admin or context.hidden
[20:55] <sinzui> we want the link to reuse the rule
[20:56] <kfogel> sinzui: thaht would be the clean fix, absolutely
[20:56] <kfogel> sinzui: I started my journey by trying to find out what the rule ought to be :-)
[20:56] <kfogel> sinzui:  which is how I ended up here in the Emerald City
[20:59] <mwhudson> morning
[21:02] <kfogel> mwhudson: morning
[21:03] <kfogel> sinzui: I think I've got it now; thanks for the help.
[21:03] <sinzui> fab
[21:08] <kfogel> sinzui: hmm.  I'm trying to test this on launchpad.dev now.  Do you have any idea *how* the admins set a comment as hidden?
[21:08] <kfogel> I don't see any UI for it.
[21:10] <sinzui> kfogel, there is no ui :(
[21:10] <kfogel> sinzui: db tweak?
[21:10] <sinzui> they use an api script
[21:10] <kfogel> aaaah
[21:10] <kfogel> sinzui: ok, on it, thx
[21:11] <sinzui> I was thinking that we could provide an form for anything that provides IMessage that allows the admin to edit or hide the message.
[21:12] <sinzui> one day we will support this: /bugs/1/message/2/+edit
[21:12] <mup> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Invalid> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <OpenOffice:Invalid by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Ubuntu:In Progress by sabdfl> <ubuntu-express (Ubuntu):Invalid by jahyire2006> <Ubuntu Jaunty:In Progress> <ubuntu-expre
[21:12] <kfogel> sinzui: mup bit you :-)
[21:12] <sinzui> mup is a luser
[21:12] <kfogel> mthaddon: ping
[21:13] <kfogel> mthaddon: Do you have the script that admins use to set a bug comment as "not visible"?  I'd like to see that script, if you do.
[21:13] <sinzui> I want re re-enable bug expiration and expire it
[21:14] <kfogel> losas, see above question I addressed to mthaddon
[21:20] <kfogel> sinzui: Victory!  I think: I used psql to set the 'visible' boolean column to False for a comment I just added; now when I'm logged in as Foo Bar (i.e., launchpad.dev admin user), I still see that comment on the bug's page, but it's highlighted yellow now.  Do you know if this is the expected behavior?
[21:21] <kfogel> ah, yes, and as anon user, I cannot see the comment.
[21:23] <sinzui> I do not know about a highlight rule
[21:23] <sinzui> I think gmb implemented the hid bug feature
[21:28] <kfogel> sinzui: that helps.  I'm pretty sure what I'm seeing is the intended behavior, though (I mean, modulo the bug I'm trying to fix)
[21:30] <wgrant> Hmm. Does anyone know if the PPA download counts script is running yet?
[21:50] <thumper> I've started getting: /usr/lib/pymodules/python2.6/lazr/uri/__init__.py:19: UserWarning: Module launchpadlib was already imported from /usr/lib/pymodules/python2.6/launchpadlib/__init__.py, but /usr/lib/pymodules/python2.6 is being added to sys.path
[21:50] <thumper> when I use bzr
[21:51] <thumper> anyone seen this?
[21:51] <thumper> or know how to fix it?
[21:54] <mwhudson> i see it
[22:01] <james_w> leonardr: lptools, ubuntu-qa-tools, bughugger and bzr-pqm all fixed in Ubuntu, bzr-builddeb will uploaded tomorrow
[22:07] <leonardr> great, i'll send an update
[22:48] <kfogel> sinzui: wouldn't mind a little Captain Obvious, if you have a sec: http://paste.ubuntu.com/407277/
[22:48] <kfogel> I'm pretty sure I've got some kind of wrong-type-of-object issue going on, but so far haven't been able to determine how to get to the object I need.
[22:51] <wgrant> kfogel: That's a fake BugComment.
[22:51] <wgrant> The real object is BugMessage. BugComment is a browser-specific wrapper.
[22:51] <wgrant> And it probably doesn't expose .visible yet.
[22:53] <wgrant> Hm, but it looks like it is. Odd.
[22:53] <kfogel> wgrant: looks like it is what?
[22:53] <wgrant> Oh, it's just not in IBugComment.
[22:53] <wgrant> kfogel: .visible is on BugComment, but not IBugComment.
[22:54] <kfogel> wgrant: you'd think I'd have all these laysers straight by now, but noooooooo.
[22:54] <wgrant> So it's accessible internally, but not externally.
[22:54] <kfogel> ah
[22:54] <kfogel> hmmm
[22:54] <kfogel> I wonder if exposing it is the right approach.
[22:54] <kfogel> What I really want is for the comment to 404 if visited via direct URL (e.g., bugs/54/comments/37)
[22:54] <wgrant> Right, I was about to ask why you were doing it this way.
[22:55] <kfogel> right now, the effect that code would have (if it were working) would be to show a bug comment page, but with an empty space where the comment text should be
[22:55] <kfogel> wgrant: I'm not persuaded I should be doing it this way.
[22:55] <kfogel> wgrant: do you know a better way, a way to make the page pretend not to exist at all?
[22:55] <wgrant> kfogel: Change BugTaskNavigation.traverse_comments
[22:56] <kfogel> wgrant: ?  hmrm.  Let me look, bbiab
[22:56] <wgrant> Although you should probably 403 it instead.
[22:56] <wgrant> Rather than denying its existence.
[22:56] <wgrant> But I wonder how much other stuff that would break.
[22:56] <kfogel> wgrant:     def traverse_comments(self, name):
[22:56] <kfogel>         """Traverse to a comment by id."""
[22:56] <kfogel> wgrant: I have to admit, that's a mismatch between method name and documentation :-)
[22:57] <wgrant> kfogel: 'name' is a universal idiom.
[22:57] <kfogel> wgrant: it's the "traverse_comments" plural part that bugs me.  The method is named for its implementation strategy rather than its effect.  What it's really doing is taking you to a comment; how it gets there is its own business, IMHO.
[22:58] <wgrant> kfogel: Ah, right.
[22:59] <kfogel> wgrant: anyway, I'm going to try a patch based on your idea.
[22:59] <wgrant> kfogel: For an example of a similar 404 thing, check LaunchpadRootNavigation.traverse's person privacy handling.
[22:59] <kfogel> wgrant: thanks!
[23:00] <wgrant> But I really think it would be better to just revoke launchpad.View for hidden comments and deal with fallout. That would be the proper solution.
[23:00] <kfogel> wgrant: how does one "revoke launchpad.View" ?
[23:02] <wgrant> kfogel: Alter the ViewBugMessage security adapter to return True only if the comment is visible or the user is an admin.
[23:03] <kfogel> wgrant: ooooh, btw, so far this patch has exactly the effect I wanted: http://paste.ubuntu.com/407283/
[23:03] <kfogel> wgrant: trying your view-revokation method now
[23:03] <wgrant> kfogel: Except that patch makes it impossible to show again without DB access.
[23:03] <kfogel> wgrant: ??
[23:04] <kfogel> wgrant: (I mean, I still have to add the user == admin condition in there, but that's not related to your comment just now I think)
[23:04] <wgrant> kfogel: Ah, right, once you add the user == admin thing it will be fine.
[23:04] <kfogel> wgrant: toggling visibility of comments is done through DB at the moment, true, but the lack of UI for it is not related to this change.
[23:04] <wgrant> kfogel: Isn't there an API to do it?
[23:04] <kfogel> wgrant: that is, even if the admin could still see the comment, they'd still need to use the DB to change the visibility
[23:05] <kfogel> wgrant: nope, no UI yet
[23:05] <kfogel> wgrant: now, it's true that an admin will *see* the comment (it'll have a yellow background, too, to highlight that it's not visible to the rest of the world)
[23:05] <wgrant> kfogel: Admins may set visibility through the API with bug.setCommentVisibility.
[23:06] <kfogel> wgrant: sorry, I confused API with UI, yes.
[23:06] <wgrant> Though since it's on bug, not bug_message, it doesn't require the comment to be traversable.
[23:06] <kfogel> wgrant: yes they can do it via API -- but that would be true either way
[23:06] <kfogel> right
[23:09] <kfogel> wgrant: http://paste.ubuntu.com/407285/  seems to have all the desired effects; care to have a look?
[23:10] <kfogel> (I guess there's a style question of whether those parens are really needed, but whatevs.)
[23:10] <wgrant> kfogel: That looks about right.
[23:10] <kfogel> wgrant: ok, now I'm going to learn about "bzr shelve" and try your other proposed way :-)
[23:10] <wgrant> Except that this whole visibility thing is implemented by working around the Zope security machinery.
[23:10]  * wgrant cannot live without shelve.
[23:11] <kfogel> wgrant: yeah... I have the feeling that if I had a wider/deeper picture of how Launchpad fits into Zope, I'd be more dissatisfied with this solution.  Ignorance truly is bliss sometimes.
[23:25] <wgrant> kfogel: Do you know what the status of checkwatches is? see #launchpad
[23:33] <kfogel> wgrant: btw, I don't think the LaunchpadRootNavigation.traverse() solution is actually better here.  It does 301 redirects, not 404s, and I think we actually want a 404 here (which my patch gets by simply returning None).  I guess I could do the "raise NotFound(self.context, name)" trick, but what's the advantage?
[23:34] <wgrant> kfogel: Right, the NotFound case is what I was thinking of. But it's not really comparable, since you can just return None from a normal traversal method and get the same effect.
[23:34] <kfogel> exactly
[23:35] <maxb> For some reason launchpadlib 1.5.6 is missing its bzr tag. Please could someone who is a member of ~lazr-developers add it:
[23:35] <maxb> bzr tag -d lp:launchpadlib -r<EMAIL_ADDRESS>1.5.6
[23:35] <wgrant> (I didn't actually look at the method first, sorry)
[23:35] <maxb> I've checked the branch against the tarball to verify the revision
[23:46] <wgrant> spm: How do I get the PPA log parser script set up?
[23:47] <spm> this'd be similar ot the Q&D checks we did the other week?
[23:48] <wgrant> I don't think I know about those checks.
[23:48] <spm> wild stab in the dark guess that...
[23:48] <wgrant> I guess I'm not even sure if the prod config has been fixed yet. And Julian won't be around for several days.
[23:49] <spm> wgrant: in any event it's a two step. 1. it's in the code tree cronscripts/<file>.py 2. a request is made - RT is preferred cc'ing team lead/whome ever to get the nod that this is sane etc
[23:49] <spm> some are part of a release cycle - code* are the most notable here - so they get added to the Production Status page as a special rollout request.
[23:50] <spm> some are an *integral* part of ....
[23:50] <wgrant> spm: Do you know if there's an RT about it already?
[23:51] <spm> I don't - I'll check....
[23:54] <wgrant> Julian suggested that he would organise it last week, but I can't see LPS or RT or anything at all to check its status.
[23:59] <thumper> woo.. just slammed my big branch into ec2 test