[12:25] <jbailey> https://launchpad.net/distros/ubuntu/+source/evolution is telling me I don't have access to this page.
[12:26] <jbailey> https://launchpad.net/distros/ubuntu/+source/evolution-data-server works fine, however.
[12:36] <raphink> jbailey: confirmed here
[12:36] <jbailey> raphink: Thanks, I'm filing it now.
[12:36] <raphink> :)
[12:36] <jbailey> raphink: Will you confirm bug 31573 please?
[12:36] <Ubugtu> malone bug 31573 in launchpad "Evolution source package in Ubuntu page tells me I don't have access" [Normal,Unconfirmed]  http://launchpad.net/bugs/31573
[12:37] <jbailey> Ubugtu: Thanks.
[12:37] <raphink> jbailey: done
[12:38] <jbailey> raphink: Thanks.
[01:00] <mpt> Goooooooooooooooooooooood afternoon Launchpadders!
[01:02] <raphink> hmm hello mpt 
[01:02] <ajmitch_> hi
[01:03] <dholbach> good night
[01:31] <ddaa> Little game for you
[01:32] <ddaa> Who can guess what this small icon represents?
[01:32] <ddaa> http://ddaa.net/bazaar/emblem6.png
[01:32] <lifeless> dog doing its business
[01:33] <ddaa> lifeless: I cannot imagine how you manage to see that...
[01:33] <lifeless> head in the top left, fire hydrant in bottom right, body between
[01:34] <ddaa> mh... maybe an outline would help...
[01:34] <spaescowboy> there's some sort of note, and a brick
[01:34] <spaescowboy> represents? hmm
[01:34] <spaescowboy> heh
[01:38] <ddaa> It's meant to say "source code buttress"...
[01:38] <ddaa> anybody would half a brain would see it's a flying buttress...
[01:42] <ddaa> I do not mean to insult anybody...
[01:48] <jamesh> lifeless: by the way, does the launchpad importd stuff handle time going backwards in CVS branch history?
[01:49] <ddaa> I think that one is slightly better defined. http://ddaa.net/bazaar/emblem7.png
[01:50] <ddaa> spaescowboy: btw, congrats for noticing the carefully tuned brick pattern
[01:50] <mpt> The requested URL /bazaar/emblem7.png was not found on this server.
[01:50] <ddaa> fixed
[01:52] <ddaa> buttress on source
[01:52] <ddaa> tell me, how'm supposed to represent that?
[01:53] <mpt> A dog kissing a document?
[01:53] <mpt> buttress on source
[01:53] <mpt> ok, this is where I admit I don't know what buttress is
[01:53] <lifeless> jamesh: FSVO backwards, yes.
[01:53] <lifeless> jamesh: date stamp skew we should be quite robust on
[01:54] <ddaa> oh, yeah, I actually see the dog, cute...
[01:54] <lifeless> jamesh: popping revisions of the end we are not.
[01:54] <lifeless> ddaa: see!
[01:54] <ddaa> lifeless: but he does not see an hydrant, he sees a dog
[01:55] <ddaa> I've not yet completely lost faith in my graphic abilities, I'm going to inflict a few more of those on you.
[01:55] <jamesh> lifeless: okay.  I found that the CVS -> Subversion conversion script they're using for gnome doesn't seem to be so robust: http://mail.gnome.org/archives/gnome-hackers/2006-February/msg00078.html
[01:56] <lifeless> jamesh: that sort of historical thing we should be pretty much immune to
[01:56] <lifeless> jamesh: I spent ages on it, and though I've thought of an even better way now, its still seriously robust
[01:56] <jamesh> nice
[01:56] <lifeless> jamesh: it even handles revision-date loops
[01:56] <lifeless> i.e. file A: rev 1.1 Time 1 message A, rev 1.2 Time 2 message B
[01:57] <jamesh> I found that Tailor seems to have problems with date skew too
[01:57] <lifeless> file B: rev 1.1 Time 2 message B, rev 1.2 Time 1 message A
[01:57] <lifeless> we will handle that correctly.
[01:57] <lifeless> by generating 3 revisions
[01:57] <lifeless> rev 1: File A 1.1, file B not present
[01:58] <lifeless> rev 2: File A 1.2, File B 1.1
[01:58] <lifeless> rev 3: File A 1.2 File B 1.2
[01:58] <lifeless> (yes thats an impossible corner case, but it represents a class of loops I've seen in the wild)
[01:59] <lifeless> yes, I have no faith in Tailor or cvs2svn
[01:59] <lifeless> As a one-shot system they are both fixable but AFAIK they are not fixed.
[02:00] <lifeless> If you guys can wait for the bzr versions of importd I think you'll get much better results.
[02:01] <jamesh> They seem set on doing the conversion middle of march :(
[02:01] <lifeless> fork jhbuild to bzr :)
[02:01] <jamesh> I'm planning to
[02:02] <lifeless> I'm going nose-down for a while, back at a convenient break
[02:02] <jamesh> I did a Tailor conversion after fixing the RCS files with vi :)
[02:03] <spiv> The python cvs -> svn conversion has some annoying problem with dates from its conversion: http://mail.python.org/pipermail/python-dev/2005-November/058269.html
[02:04] <ddaa> pathological but good example why repository-wide revno is a booooooorken idea...
[02:06] <ddaa> spiv: unless the operator did something really stupid, cscvs should be able not to care, since we will only convert chunks where the timestamps should be monotonically increasing.
[02:06] <spiv> ddaa: I just assumed that cscvs would do a better job :)
[02:06] <ddaa> Well, I do not have to.
[02:07] <ddaa> The breakage is linked to svn broken model.
[02:07] <ddaa> Since cscvs does not convert _to_ svn it cannot have this problem.
[02:07] <mpt> ddaa, since you're awake now (why?), should we discuss RCS imports?
[02:08] <ddaa> I'm awake because I spent a couple of hours drawing a buttsource emblem
[02:08] <ddaa> mpt: let's talk about it
[02:08] <mpt> So, I'm perhaps in a good position here, because I know almost nothing about this subject
[02:09] <ddaa> you might have noticed that for a few days I've been ranting/bitching/pleading for various changes to the productseries model in the mailing list and the bugtracker.
[02:09] <mpt> yes
[02:09] <mpt> Is this the sort of thing where a spec would be useful to tie all the design details together and ensure they work as a whole?
[02:10] <mpt> or would that be a net waste of time?
[02:10] <ddaa> basically, I want to convince you because I think a few important UI model changes are needed, so it's going to go through you in the end anyway.
[02:10] <ddaa> Mh... maybe a spec would be useful...
[02:11] <ddaa> there's at least two idea in the air so far.
[02:11] <ddaa> (at first there was only one, but Keybuk generously suggested another one)
[02:12] <mpt> ok. Why does Launchpad care about RCS stuff at all?
[02:12] <ddaa> mpt: because a large part of my job is converting upstream RCS repositories (CVS an SVN currently) into Bazaar branches.
[02:13] <mpt> why?
[02:13] <mpt> what are the resulting Bazaar branches useful for?
[02:13] <ddaa> at least two things
[02:13] <mpt> (btw we seem to have <https://wiki.launchpad.canonical.com/BranchImports> on this already)
[02:14] <ddaa> this spec is just a minor bit
[02:14] <ddaa> One of the important pages is https://wiki.launchpad.canonical.com/TheBazaar
[02:15] <ddaa> So, the grand plan is that in the end
[02:15] <ddaa> the source code for most major open source projects will have its history in bzr branches
[02:15] <ddaa> that will be used by HCT
[02:16] <ddaa> to allow packagers to easily share patches across distribution boundaries
[02:16] <mpt> ok
[02:16] <ddaa> There's a dizzying number in moving parts involved in getting there, so I'm not going to get in the detail.
[02:17] <ddaa> One aspect of that grand plan is importing a fine-grained revision history of upstream projects into bzr.
[02:18] <ddaa> Automatic RCS imports are also instrumental in delivering GrumpyGroundhog.
[02:18] <mpt> ok
[02:19] <ddaa> A more immediate use case for normal people is using bzr to hack on projects that care nothing about bzr.
[02:19] <ddaa> That's also a good thing to "subvert" the projects into using bzr progressively.
[02:19] <mpt> (wow, this is a whole world of specs I've never seen before)
[02:21] <ddaa> One scenario would be that a few devs start hacking on bzr for their own convenience, publish their branch, and slowly all members of the project gain awareness of bzr benefits.
[02:21] <mpt> right
[02:22] <ddaa> eventually, the core devels say "okay now that branch is mainline" and the RCS import becomes history.
[02:23] <mpt> nifty
[02:23] <ddaa> Or not, but a subset of the hackers can still use bzr to collaborate and prepare patches to send to core devs.
[02:24] <ddaa> So, that's a big big projects which has been in the works ever since the company exists. And has suffered delays for many many reasons.
[02:24] <ddaa> Mostly reasons like "it's a really complex and hard problem"
[02:24] <ddaa> mpt: so are the use cases clear to you, now?
[02:25] <mpt> yep
[02:26] <ddaa> Since the project has been in the work for so long, it has accreted a stupendous amount of cruft.
[02:26] <ddaa> To set up a RCS import, at the moment
[02:26] <ddaa> one has to create a ProductSeries.
[02:27] <ddaa> The main purpose of a ProductSeries is to model how big projects maintain parallel lines of development, like apache1 and apache2, or the major versions of postgres, or the various branches of automake. 
[02:28] <ddaa> For the most part, these "series" have a life of their own, their are projects inside the project.
[02:29] <mpt> ok
[02:29] <ddaa> mpt: that's the point where you can start to smell an attempt to "model the open-source world".
[02:29] <mpt> So do some products not have product series in the real world?
[02:29] <ddaa> most of them don't
[02:30] <ddaa> projects only develop series when they grow big enough to spare resources on maintaining stable branches
[02:31] <ddaa> most projects just work on a main branch, make a release (though many do not even do that) and move on
[02:31] <mpt> so at the moment you're creating fake product series for these products?
[02:32] <ddaa> Yeah that's one of the issues. Many project have only one series, called various names like "main", "trunk", "head", "1.0", etc.
[02:33] <ddaa> For such projects, the series is just an extra layer of indirection.
[02:33] <ddaa> The project has a whole has releases, has packages, translations, etc. but it needs a series just to access those features.
[02:34] <mpt> This seems a bit analagous to translations, where a bunch of things have only one template
[02:34] <mpt> requiring an extra click
[02:34] <ddaa> I know nothing about translations...
[02:36] <ddaa> So one of the ideas would be giving Products an implicit ProductSeries
[02:36] <ddaa> which could have a NULL name, or some reserved name like "main".
[02:37] <ddaa> That would allow presenting the features for that ProductSeries as if they were features of the Product itself.
[02:37] <mpt> ok
[02:38] <ddaa> Another issue, one that's more important to me because I think it's not just a UI issue, but really a model bug
[02:38] <ddaa> is the way RCS imports are coupled to ProductSeries
[02:38] <ddaa> ATM, a ProductSeries has 0 or 1 RCS import defined within it.
[02:38] <ddaa> The only way to set up a RCS import is to create a ProductSeries.
[02:39] <ddaa> Can you see the hidden assumption?
[02:40] <mpt> apart from that all products must have product series?
[02:41] <ddaa> The hidden assumption is that: RCS imports are only used for foreign repositories which are used to cut releases.
[02:42] <mpt> and not for ...?
[02:42] <ddaa> and not for branch that developpers use to collaborate
[02:43] <ddaa> or for branch that they use for any godforsaken reason the devels came up with...
[02:44] <ddaa> I have a couple of practical use cases, and a plausible future use case.
[02:44] <ddaa> Practical use case: gnome-app-install
[02:44] <ddaa> mvo used to work on gnome-app-install on the GNOME CVS
[02:44] <ddaa> now he switched to bzr
[02:44] <mpt> and now uses bzr instead
[02:45] <ddaa> yet he still keeps the CVS around and wants it updated
[02:45] <ddaa> because that the communication channel with the GNOME translation team.
[02:45] <ddaa> Nothing to do with releases.
[02:45] <mpt> so he wants a bzr export, rather than an import?
[02:46] <ddaa> mpt: syncing the CVS with bzr is his problem.
[02:46] <ddaa> it's not possible to do it in the general case anyway
[02:47] <ddaa> It's just an example of why a RCS import can be something else than a branch used to make releases.
[02:47] <mpt> ok.
[02:47] <ddaa> Another real world use case:
[02:47] <ddaa> Some projects, I do not remember which ones, create one branch for each release.
[02:48] <ddaa> They supposedly use that branch to do the stabilisation work.
[02:48] <ddaa> Here the branch are used to do releases, but they are not release series.
[02:48] <mpt> Mozilla does that, aiui
[02:49] <ddaa> Actually, the branch for the release series should probably be something like a branch maintained by Dyson, the tarball importer, merging from the RCS import branches for each release.
[02:50] <ddaa> Another real world use case:
[02:50] <ddaa> some projects are unconscious enough to actually use CVS for feature branches.
[02:51] <ddaa> Again, nothing to do with releases.
[02:51] <mpt> unconscious? :-)
[02:51] <ddaa> out of their mind, immune to pain, whatever
[02:52] <ddaa> mpt: are those use case clear to you?
[02:53] <ddaa> * those use cases
[02:54] <mpt> the one about a branch for each release isn't entirely clear
[02:54] <mpt> Are you saying we might want to import one release, but not the other releases in that series?
[02:54] <ddaa> BTW, I'm not sure that mozilla is a good example. Their minor releases are probably treated as release series by packages.
[02:55] <ddaa> mpt: I'm saying that for some project, a release series would actually be associated to a collection of RCS imports.
[02:56] <ddaa> The actually branch representing the series would be merging from those rcs import branches. There's actually a tool out there that's supposedly able to find out which imported revision is closest to a tarball.
[02:56] <ddaa> It's called Dyson, coded by Keybuk.
[02:56] <ddaa> now the responsibility of niemeyer
[02:57] <mpt> ok.
[02:57] <ddaa> Now my pet use case:
[02:58] <ddaa> when we implement imports from other DVCS
[02:58] <ddaa> (because it's "when", not "if")
[02:58] <ddaa> there will actually be a need for RCS imports for any random hacker's branch.
[02:59] <ddaa> even people who are not owners of the product
[02:59] <ddaa> Currently, the fact that RCS import is couple to a ProductSeries couples the ownership of the import to the ownership of the product.
[03:00] <ddaa> That has not been a problem so far to be honest. But I think mainly because RCS imports did not have a lot of public adoption for a variety of reasons.
[03:01] <mpt> ahh
[03:01] <mpt> so this is for when we're trying to get people to switch from other DVCSes, rather than other CVCSes :-)
[03:01] <ddaa> Also, examination of the Branch.url specified by the users show interesting things.
[03:02] <ddaa> I noticed at least one branch whose URL was set to a SVN repository.
[03:03] <mpt> That's supposed to be an URL of a page that describes the branch, correct?
[03:03] <ddaa> No, that's supposed to be the URL of a bzr branch out there, that can be checked out using "bzr get".
[03:03] <ddaa> The user got the checkout bit right.
[03:04] <ddaa> So back to mvo's use case.
[03:05] <ddaa> In an ideal world, he would detach the CVS import from the productseries, and attach his bzr branch to the productseries.
[03:06] <ddaa> He does not need or want a productseries for the CVS import. That would be just confusing to people. He's just interested in the RCS import service.
[03:06] <mpt> Is his bzr branch really managing a product series, or is it just the product in general too?
[03:06] <ddaa> In my understanding, it's the product in general.
[03:07] <ddaa> The gist of my argument is: "RCS import is a useful service by its own".
[03:07] <ddaa> coupling it artificially to some other concept only reduces the ability of the system to answer the answer the user needs accurately.
[03:08] <mpt> Are you saying it shouldn't need attaching to a product series *or* a product?
[03:08] <ddaa> Mh
[03:08] <ddaa> I think it would be good to require that a RCS import is always attached to a product.
[03:09] <ddaa> If only to help people find them.
[03:09] <ddaa> Also because I expect they are only needed for projects large enough to need a product.
[03:10] <ddaa> But actually, I'd like to see the RCS import to be "just another kind of branch".
[03:10] <ddaa> It's just a branch in another VCS than bzr. That we make available in bzr format.
[03:11] <mpt> ok.
[03:11] <ddaa> I think I've finished my diatribe.
[03:11] <mpt> So how does all of this involve me? :-)
[03:12] <ddaa> This is all about users and use cases.
[03:12] <ddaa> You are the UI nazi.
[03:13] <ddaa> I would not involve you in deeply technical issues of RCS import publishing for example.
[03:13] <ddaa> But this is an issues with important consequences on the user experience.
[03:14] <mpt> all right
[03:14] <ddaa> So I believe that if take position in that discussion, that would have a large impact.
[03:14] <ddaa> * if you take position
[03:14] <mpt> so this needs a spec with a name like RcsImportsWithoutSeries?
[03:15] <ddaa> Sounds right to me.
[03:15] <mpt> ok
[03:16] <ddaa> Thanks for your attention.
[03:16] <mpt> thanks for your explanation
[03:16] <mpt> I understand more about Launchpad now
[03:17] <stub> I believe we need to keep ProductSeries in the datamodel, because there are a number of large high profile projects that need it. However I'm all for hiding it in the UI for the bulk of our small projects.
[03:17] <ddaa> you're welcome, on my last performance evaluation lifeless said I was not asking for help often enough
[03:17] <ddaa> now I feel like I spending most of time giving work to other people :)
[03:17] <ddaa> oops
[03:17] <ddaa> now I feel like I am spending most of my time giving work to other people :)
[03:17] <stub> ddaa: Keep that up and you will become a manager :)
[03:18] <ddaa> stub: ack++ ProductSeries is really useful in some cases.
[03:19] <ddaa> it just has some sort of over-inflated sense of its self-importance at the moment
[03:20] <ddaa> so I'd like to beat it back in the rank
[03:39] <lifeless> ddaa: before you go
[03:39] <lifeless> mpt too
[03:39] <lifeless> we are doing the RCS imports to aid collaboration of developers on Ubuntu
[03:39] <ddaa> zzzzzz pong zzzzzzz
[03:40] <lifeless> non-ubuntu included projects, and unrelated projects are really not very interesting from that perspective.
[03:40] <lifeless> yes, we are not turning people down, and I'm not suggesting we should start doing that
[03:41] <lifeless> but I do want to ensure we don't forget *why* we are doing this: its not to get people to migrate to bzr (one-shot converters are _MUCH_ easier) - its to allow hct, and grumpy to be effective.
[03:41] <lifeless> that is all
[03:41] <mpt> ok
[03:41] <ddaa> that was not really the perspective I had
[03:41] <ddaa> I realize that ubuntu is the main client of rcs imports at the moment
[03:42] <lifeless> ubuntu is the reason we are doing rcs imports at all
[03:43] <lifeless> go sleep now, sorry for disturbing just as you disappeared.
[03:43] <ddaa> I thought they were doing ubuntu to bootstrap rcs imports and hct ;)
[03:44] <ddaa> (well, actually the plan did sound like that to me, back then)
[03:46] <ddaa> which is also consistent with who where the two first hires
[03:46] <lifeless> first hire was dave miller
[03:47] <ddaa> oh really, I thought it was you
[03:47] <lifeless> for bugtracking for the distro
[03:47] <lifeless> second was me, for VCS for the distro
[03:47] <ddaa> third?
[03:47] <lifeless> jdub or scott, I can't remember which. it was about then Mark went critical mass on hiring
[03:48] <ddaa> yeah, he did that two or three times :) that was fun
[03:51] <mpt> The sooner someone reviews my trivial/ branch, the fewer duplicate bug reports we'll get...
[03:51] <mpt> especially from Dino Solon A. Agcambot
[03:52] <jamesh> did he strike again?
[03:53] <mpt> yeah
[03:54] <mpt> Should we track the London Launchpad workshop as a sprint in Launchpad?
[03:54] <jamesh> I don't think we're doing spec work there
[03:55] <jamesh> and linking specs to sprints is about the only thing you can do with sprints in LP
[03:56] <mpt> yyyyeah
[03:57] <OgMaciel> hi... I'm trying to register a new team but don't really undertand the contact email field... is that an existing email address?  I assumed that was the answer but it won't let me re-use my own email
[03:58] <jamesh> OgMaciel: if you don't set a contact email for a team, then correspondence to the team will be mailed to each member individually
[03:58] <OgMaciel> jamesh, I'd like to have the emails sent to me... how can I do this?
[03:58] <jamesh> OgMaciel: if there is a mailing list you'd like correspondence for the team sent to, set it as the team's contact email address
[03:58] <jamesh> OgMaciel: and no one else on the team?
[03:59] <jamesh> why?
[03:59] <OgMaciel> jamesh, don't have one yet...
[03:59] <OgMaciel> jamesh, I figured I'd get emails about administrative stuff
[03:59] <OgMaciel> jamesh, just don't want to bother the other members
[03:59] <jamesh> OgMaciel: the common use case is to set the team as a bug subscriber
[03:59] <OgMaciel> jamesh, cool...  thanks
[04:00] <jamesh> in which case you'd want all team members to get the mail
[04:00] <mpt> hmm, that could be a bit more obvious
[04:00] <OgMaciel> mpt, agreed
[04:02] <jamesh> dsaa: reporting the same bug multiple times does not get it fixed quicker
[04:03] <mpt> Why is "a new message ... sent to this address with instructions on how to finish its registration" anyway?
[04:03] <mpt> That looks like residue from registering a person. It doesn't make sense for registering a team.
[04:05] <OgMaciel> mpt, actually, I just registered a team but didn't get an email
[04:12] <mpt> OgMaciel, reported bug 31590
[04:12] <Ubugtu> malone bug 31590 in launchpad "Contact e-mail address entry for new team should be more obvious" [Normal,Unconfirmed]  http://launchpad.net/bugs/31590
[04:14] <OgMaciel> mpt, can you link me please?
[04:17] <mpt> "link you"?
[04:18] <mpt> You mean give the bug report URL? That's what Ubugtu's for ^^
[04:18] <OgMaciel> mpt, link to the bug... but it's ok
[04:19] <OgMaciel> mpt, never used Ubugtu 
[04:19] <mpt> read up
[04:19] <OgMaciel> mpt, thanx
[04:20] <OgMaciel> mpt, I can read (I bet it is something like !ubugtu bug#) but am going to Malone anyhow
[04:20] <lifeless> Ubugtu: 31590
[04:20] <lifeless> nah
[04:20] <lifeless> its bug #31590
[04:20] <Ubugtu> malone bug 31590 in launchpad "Contact e-mail address entry for new team should be more obvious" [Normal,Unconfirmed]  http://launchpad.net/bugs/31590
[04:21] <lifeless> OgMaciel: the URL is on the right hand side
[04:21] <OgMaciel> lifeless, am there already... thanks  ;)
[05:35] <mpt> Both before and after updating sqlobject, I get     *  Module canonical.lp.z3batching, line 41, in __init__
[05:35] <mpt>       listlength = list.count()
[05:35] <mpt> ForbiddenAttribute: ('count', <sqlobject.main.SelectResults object at 0xb2a5696c>)
[05:35] <mpt> (that's after make clean and make schema, too)
[05:39] <jamesh> mpt: is your sqlos up to date?
[05:39] <mpt> I hadn't updated that specifically
[05:42] <mpt> That worked, thanks jamesh 
[06:34] <mruiz> hi! someone can help me?  I made a project by error. Can I erase it?
[06:35] <dilys> Merge to devel/launchpad/: [trivial]  Restore logtail to builder page (r3150: Matthew Paul Thomas)
[06:36] <spiv> mruiz: stub can.
[06:36] <stub> Whats the project name?
[06:36] <mruiz> spiv: thanks 
[06:36] <mruiz> stub: ubuntu-cl
[06:38] <stub> Gone
[06:38] <mruiz> stub: thanks!
[06:41] <stub> mpt: Is there any reason we might want to prefer /++resource++foo.png URLs to /@@/foo.png URLs ? I was just about to land a search and replace making things consistant but thought I'd better check.
[06:44] <mpt> stub, no reason that I know of
[06:44] <mpt> I've just been shortening them as I find them
[06:45] <stub> ok. as long as I'm not breaking your syntax highlighting or triggering a Netscape 4alpha2 bug
[06:46] <jamesh> stub: did that sqlobject fragment help with the person_sort_key stuff?
[06:47] <stub> jamesh: Haven't tried it yet but it looks perfect
[06:48] <jamesh> stub: seems that sqlobject only does those colunm name checks if orderBy is a string (or list of strings)
[06:48] <jamesh> other sqlbuilder expressions get passed through as is
[07:21] <SteveA> hi
[07:26] <dilys> Merge to devel/launchpad/: [trivial]  Consistently use preferred /@@/ syntax instead of ++resource++ in resource URLs (r3151: Stuart Bishop)
[07:32] <SteveA> stub: we could call /@@/ anything -- such as "resources" or "images" if we want
[07:34] <stub> ack
[07:37] <LaserJock_away> does anybody know what "Users can spoil their votes?" mean for a LP poll?
[07:53] <Link9618> Where is the Passwd when I sign up
[08:23] <stub> So how does this @ubuntu/member/foo IRC thing work?
[08:35] <carlos> morning
[08:38] <ulinskie> hello
[08:47] <SteveA> hey, carlos
[08:47] <carlos> SteveA: hi
[08:48] <SteveA> stub: one way is that you give freenode money, and they give you a fancy pseudo-domain
[08:48] <SteveA> stub: the other is that you can somehow register your affiliation with some group that is registered with freenode
[08:48] <SteveA> carlos: have you seen the spreadsheet i sent to the list, about rosetta queries?
[08:49] <carlos> SteveA: I have the ajax branch working but not finished and without tests. Kiko asked me to stop it for a while and ask for a review of what I have atm.  Do you want to do that review? (not now, when you have some time)
[08:50] <carlos> SteveA: I saw the email, yes, I'm going to work on that now after some DB changes I need to request to stub
[08:50] <SteveA> sure, i'll do the review.  let's look next week
[08:50] <SteveA> i'm very excited that we may be able to get +translate pages working twice as fast TODAY
[09:21] <mpt_> SteveA, call?
[09:22] <stub> SteveA: I was wondering if there was an official Ubuntu freenode group given the ubuntu/member bit. Perhaps for all Ubunteros or something.
[09:23] <SteveA> nah, i think for anyone who claims to be interested in ubuntu
[09:24] <SteveA> mpt_: sure, 5 mins?
[09:25] <mpt_> ok
[09:32] <nitishp> You guys rock!
[09:34] <SteveA> hi nitishp.  thanks for the feedback.  although, i want to say that we only rock some of the time, we actually suck some of the time too.
[10:15] <daf> morning
[10:36] <dilys> Merge to devel/launchpad/: [trivial]  Added Akan plural forms (r3152: Carlos Perell Marn)
[10:38] <carlos> daf: morning
[10:45] <SteveA> carlos: about the optimisation...
[10:45] <carlos> SteveA: any problem?
[10:45] <SteveA> what i'd like to do first is to just optimize that one query that would provide the most savings
[10:45] <SteveA> and nothing else
[10:45] <SteveA> do you think you can do that?
[10:46] <SteveA> then i can review it
[10:46] <SteveA> and i can also help, if there are any things you need help with doing it
[10:46] <carlos> yes, I wil do it, don't worry
[10:47] <SteveA> and then we can see about what we should do next
[10:47] <carlos> s/wil/will/
[10:47] <SteveA> the point is, i don't want us to rush in and optimise more than that one thing to start with
[10:48] <SteveA> daf: on the bug report email
[10:49] <SteveA> what i'm most concerned about for today's meeting is having the OOPS bugs listed, and ensuring that an appropriate person is assigned to each
[10:50] <SteveA> there are just 17 oops bugs
[10:50] <SteveA> do you think we can go through them all in the meeting?
[10:51] <daf> yes
[10:55] <carlos> SteveA: I think the COUNT query you are talking about in your email is related to statistics updates
[10:56] <SteveA> even so...
[10:56] <carlos> Instead of caching, I could try to improve that code so we don't do a select COUNT every time, just a field update
[10:56] <SteveA> can you point me at the code in question?
[10:56] <carlos> sure, just a second
[10:58] <carlos> SteveA: database/pofile.py#updateStatistics (line 467)
[11:00] <carlos> SteveA: we execute it with every message on the submit
[11:02] <carlos> SteveA: the first optimization I can think on is execute it once per submit instead of once per entry changed
[11:03] <carlos> in the worst case (all entries changed), instead of executing it ten times we will execute it just once
[11:03] <carlos> in the best case (none is changed), we will execute it once instead of none but I suppose I should be able to figure a way to reduce this to zero too
[11:03] <daf> this COUNT query is the longest one?
[11:05] <carlos> daf: that method is not raising just one query but three or four
[11:05] <carlos> daf: count queries
[11:06] <daf> ah, got the spreadsheet now
[11:07] <daf> you think it's possible to replace these three SELECT COUNT with one?
[11:08] <carlos> no, those are different counts
[11:08] <carlos> I think it's possible to reduce the number of calls to that method
[11:09] <daf> ok, so 3 queries instead of 210
[11:09] <daf> do it!
[11:10] <carlos> well, I need to check how is that we did 70 queries instead of 10
[11:10] <carlos> it should be done only once per entry
[11:11] <daf> ah
[11:11] <carlos> and 10 entries per page is 10 calls to updateStatistics == 30 queries not 210...
[11:11] <daf> maybe call traceback.print_stack() in updateStatistics()?
[11:12] <daf> I thought you said "once per submit"
[11:12] <daf> but I support you meant "once per message submitted"
[11:12] <daf> suppose
[11:12] <daf> jamesh: ping
[11:14] <daf> carlos: looking at those queries, I don't understand why we can't execute them once for every POST
[11:14] <SteveA> indeed
[11:14] <carlos> daf: atm is once per message submitted. I want to change it once per submit
[11:15] <SteveA> cool
[11:15] <carlos> daf: we can, that's what I'm suggesting ;-)
[11:15] <daf> ok
[11:15] <daf> that's great
[11:15] <SteveA> so, what i think you're saying carlos is there is no need to cache this
[11:15] <SteveA> because it should be just one query anyway
[11:15] <daf> I thought you were saying we needed to execute them once for every entry in the form
[11:16] <carlos> SteveA: well, that's already caching things, but the cache update is done too often
[11:16] <carlos> that's the problem
[11:18] <carlos> SteveA: btw, your spreadsheet is really helpful here. Thank you
[11:18] <SteveA> carlos: I want to get this added to timeout and soft timeout oops reports
[11:19] <carlos> SteveA++
[11:19] <SteveA> actually, we can do an even better report, using a combination of this, and jamesh's query-genericness code
[11:29] <jamesh> daf: pong
[11:29] <SteveA> carlos: i have an idea about the librarian problem
[11:30] <SteveA> the idea is to get spiv to extend the librarian clent and server with an optional "client request ID"
[11:30] <SteveA> so that the librarian server can log this
[11:30] <SteveA> then, in the rosetta code, provide such an ID, that is unique to that particular request.
[11:30] <SteveA> then, we examine the librarian logs of server and of client interactions, to see what is going on
[11:31] <carlos> that will help us to debug the problem
[11:31] <carlos> spiv: what do you think?
[11:31] <SteveA> jamesh: i'd like to talk about doing some oops report additions.  i can code it, or you can, depending on how much time you have spare from the buildbot errors work.
[11:32] <SteveA> jamesh: can we have a brief phone call about that?
[11:32] <SteveA> as, i'll be after some pointers on how to do it, if i'm going to do it
[11:32] <SteveA> carlos: i think this will be better than using the workaround right away, because it gives us a reasonable chance to get at the root of the problem.
[11:33] <daf> jamesh: can you confirm/reject #30376/#30277?
[11:33] <carlos> SteveA: well, the workaround wil still raise this error
[11:33] <SteveA> oh, really?
[11:33] <SteveA> that's good
[11:33] <carlos> SteveA: but the idea is to catch the exception and do a full export without using the librarian
[11:33] <SteveA> ok
[11:34] <cprov> morning guys
[11:34] <carlos> cprov: morning
[11:34] <cprov> carlos: hi carlos
[11:34] <carlos> cprov: and congratulations! I didn't know you are going to get married!
[11:35] <cprov> carlos: yes, just after next conf, thank you
[11:35] <jamesh> SteveA: sure.  I'll fire up skype
[11:36] <jamesh> daf: bug 30277: depends on what we want to use PGP keys for -- currently we are only verifying that the key belongs to the account
[11:36] <Ubugtu> malone bug 30277 in launchpad "launchpad recommends generating a new key but shouldn't" [Normal,Unconfirmed]  http://launchpad.net/bugs/30277
[11:37] <jamesh> daf: did you mean 30276 rather than bug 30376?
[11:37] <Ubugtu> malone bug 30376 in launchpad "autogen addforms add button is not in tab index" [Normal,Unconfirmed]  http://launchpad.net/bugs/30376
[11:37] <daf> cprov: congratulations!
[11:38] <daf> jamesh: yes, I did
[11:38] <cprov> daf: thx
[11:38] <daf> jamesh: all I'm looking for at the moment is to get thse bugs out of Unconfirmed
[11:39] <jamesh> daf: I've marked 30276 as needs info - need further input from elmo before further investigation
[11:39] <daf> thanks
[11:40] <SteveA> jamesh: i'm running skype
[11:42] <jamesh> SteveA: I can't seem to connect
[11:42] <SteveA> how strange
[11:42] <SteveA> has skype worked for you before?
[11:42] <jamesh> yes.  We used it before
[11:43] <SteveA> darn proprietory software
[11:43] <jamesh> says "Reason unknown"
[11:43] <jamesh> are you able to call me?
[11:43] <SteveA> can you even connect to echo123 ?
[11:44] <SteveA> no, i could not call you
[11:44] <SteveA> but echo123 worked for me
[11:44] <jamesh> same error
[11:45] <cprov> stub: ping
[11:45] <stub> cprov: pong
[11:45] <stub> Whitespac handling in the z3.2 doctest stuff appears to have changed :-(
[11:45] <cprov> stub: how is the current mawson state ?
[11:46] <stub> cprov: I havn't touched it since last night when I finished setting up the db for you. What still needs doing?
[11:47] <cprov> stub: not users neither production DB in pgsql
[11:47] <stub> I can't parse that sentence
[11:47] <cprov> stub: sorry .. there is no allowed users to access the DB
[11:48] <cprov> stub: I agreed in cprov & launchpad
[11:48] <cprov> stub: also could not found the production dump 
[11:48] <stub> I can connect just fine from the launchpad account
[11:49] <stub> psql -d launchpad_dogfood -U statistician
[11:50] <cprov> stub: ok, you must log in as launchpad yet, as it was before, works, thanks
[11:50] <stub> :q!
[11:58] <BjornT> stub: what's different with the whitespace handling in the zope 3.2 doctest stuff?
[11:58] <stub> BjornT: Page tests that used to pass now failing for what looks like whitespace only differences.
[12:09] <BjornT> stub: strange, i don't recall any such changes. you sure that it's not the actual output from the page tests that has changed?
[12:10] <SteveA> stub: maybe it is as easy to convert such tests to use the new testing stuff?
[12:10] <stub> Possibly - could just be fragile tests. I hate debugging these things :-)
[12:11] <stub> SteveA: I haven't looked at that yet. I expect it is faster for me to debug what is happening with the existing page tests, and I'd rather land this sooner rather than later.
[12:12] <stub> Oops... better grab some food before the meeting
[12:13] <jamesh> BjornT: I did up a quick hack to add a project bugs listing page: https://chinstrap.ubuntu.com/~dsilvers/paste/fileAZSiJ1.html
[12:13] <jamesh> BjornT: it would allow people to go to https://launchpad.net/projects/launchpad/+bugs and see bugs on launchpad, malone, rosetta, etc
[12:14] <jamesh> it feels a little unclean, since it makes projects into IBugTargets when they don't actually have bugs directly assigned to them.
[12:19] <BjornT> jamesh: yeah, i don't like having something claiming to be an IBugTarget, when it's not. it might be better to create a new interface, like is done for tickets, IHasBugs or something like that.
[12:20] <daf> BjornT++
[12:20] <BjornT> jamesh: anyway, probably better to talk to bradb about it, since he has plans to add project bug reports later.
[12:21] <SteveA> IBugAggregator, then IButTarget extends IBugAggregator ?
[12:22] <BjornT> SteveA: yes, something like that
[12:23] <SteveA> darn, I said ButT
[12:24] <matsubara> good morning.
[12:24] <jamesh> BjornT: I also ran into a problem today where the email interface can create bugs whose titles include newlines
[12:24] <jamesh> BjornT: which makes it impossible to add followup comments through the web interface unless you remove the newline from the comment subject
[12:26] <daf> jamesh: file a bug!
[12:26] <jamesh> daf: like bug 31618?
[12:26] <daf> hi matsubara 
[12:26] <Ubugtu> malone bug 31618 in malone "Email interface can create bug titles containing newlines" [Normal,Unconfirmed]  http://launchpad.net/bugs/31618
[12:26] <daf> jamesh: yes, exactly like that :)
[12:28] <BjornT> jamesh: yeah i saw that one. probably IMessageSet.fromEmail should unfold the headers. i thought that python's email library did that automatically, but apparently it doesn't
[12:44] <kiko> ahoy there
[12:45] <kiko> BjornT, jamesh, new interface++
[12:56] <jblack> I had to use launchpad for a few things in the last week. Its looking really good these days.
[12:57] <SteveA> meeting in 2
[12:57] <Kinnison> time enough for me grab a drink, brb
[12:58] <kiko> stub, tell me about this merge of r3151 -- does it help us with random 404s or not really?
[12:58] <SteveA> spiv: ping
[12:59] <SteveA> kiko: i was talking with carlos about a way to trace this librarian issue
[12:59] <pitti> hi
[12:59] <SteveA> hi pitti 
[12:59] <kiko> SteveA, ah, finally, traction!
[12:59] <SteveA> MEETING STARTS
[01:00] <SteveA> Welcome to the weekly launchpad developers' meeting
[01:00] <carlos> kiko: I'm going to implement the workaround anyway as it does not affects that debug solution
[01:00] <SteveA> who is here today?  please say "here" in the langauge of your choice
[01:00] <kiko> cool carlos 
[01:00] <salgado> here
[01:00] <kiko> aqui
[01:00] <SteveA> ia
[01:00] <carlos> aqu
[01:00] <matsubara> here
[01:00] <jamesh> here
[01:00] <mpt> here
[01:00] <Kinnison> aqu
[01:00] <daf> yma
[01:00] <cprov> here
[01:00] <jblack> here
[01:00] <bradb> here
[01:01] <spiv> Here.
[01:01] <SteveA> bjorn sends apologies.  it is a holiday in lithuania.
[01:01] <pitti> I'm here (lurking)
[01:01] <SteveA> stub: ?
[01:02] <SteveA> lifeless: ?
[01:02] <monzie> hi all
[01:02] <SteveA> hi monzie 
[01:02] <SteveA> have you come to the launchpad developers' meeting?
[01:02] <lifeless> SteveA: yes ?
[01:02] <monzie> i am trying to register a new pgp key for my page https://launchpad.net/people/manishchakravarty
[01:02] <SteveA> lifeless: you're here at the meeting.
[01:03] <monzie> I am entering the correct finger print and it keeps on giving errors
[01:03] <SteveA> == Agenda ==
[01:03] <SteveA>  * Roll call
[01:03] <SteveA>  * Agenda
[01:03] <SteveA>  * Next meeting
[01:03] <monzie> can you please help?
[01:03] <SteveA>  * Activity reports
[01:03] <SteveA>  * Items from last meeting
[01:03] <SteveA>  * Asterisk project status report (robert)
[01:03] <SteveA>  * Launchpad oops milestone report (daf)
[01:03] <SteveA>  * Production / staging (stub)
[01:03] <SteveA>  * Triage of pitti's six points (steve)
[01:03] <SteveA>  * Keep, Bag, Change
[01:03] <SteveA>  * Three sentences
[01:03] <SteveA> 
[01:03] <SteveA> matsubara: maybe you can help monzie on #launchpad-help ?
[01:03] <niemeyer> mim
[01:03] <lifeless> SteveA: apparently :)
[01:03] <matsubara> SteveA: sure.
[01:03] <SteveA> monzie: please /join #launchpad-help
[01:04] <SteveA> thanks matsubara 
[01:04] <monzie> ok SteveA 
[01:04] <kiko> somebody needs to call stub...
[01:04] <SteveA> next meeting, i may be traveling
[01:04] <SteveA> kiko: would you chair the next meeting, same time same place?
[01:04] <kiko> of course
[01:04] <kiko> it would be a pleasure
[01:05] <SteveA>  * Activity reports
[01:05] <kiko> up to date
[01:05] <SteveA> i suck.  i didn't send any for a while.
[01:05] <mpt> up to yesterday
[01:05] <jblack> up to date
[01:05] <cprov> up to date
[01:05] <matsubara> up to date
[01:05] <bradb> up to date
[01:05] <daf> up to date
[01:05] <salgado> up to date
[01:05] <Kinnison> I missed the last two of last week, summary will follow in three-sentences time, otherwise I'm up-to-date for distro
[01:06] <carlos> SteveA: I have a meeting about my university studies at the time of next meeting so I don't think I will be able to attend launchpad's one (it's really important and I cannot miss it)
[01:06] <carlos> up to date
[01:06] <SteveA> carlos: that's okay.  be sure to send kiko your three sentences.
[01:06] <carlos> ok
[01:06] <spiv> I'm behind (but have some notes so I should send a catch up)
[01:06] <SteveA> can someone phone ddaa please
[01:06] <jblack> calling
[01:06] <lifeless> up to datish
[01:06] <SteveA> thanks jblack 
[01:07] <lifeless> I had a few dropped packets and reset on tuesday
[01:07] <lifeless> so tuesday and wed are in
[01:07] <SteveA> so, jamesh, just you and me missing the activity reports
[01:07] <SteveA> moving on...
[01:07] <SteveA>  * Items from last meeting
[01:08] <SteveA>  * Kiko to try and put his explanations of debugging errors and timeouts on the wiki
[01:08] <jblack> ddaa is on the way
[01:08] <lifeless> salgado: you have duplicated your branch.
[01:08] <stub> up to date
[01:08] <SteveA>  * Steve to find someone to maintain the launchpad-dependences packages
[01:08] <SteveA> jblack: will this be you, or will it be jbailey?
[01:08] <jblack> This will be me
[01:08] <SteveA>  * Steve to set up wiki page for march meeting
[01:08] <kiko> SteveA, hmm. didn't do that. I could probably wait for the debugging traceback code to land 
[01:08] <SteveA> done, mailed launchpad list
[01:08] <SteveA> kiko: can you formulate that as a MeetingAction ?
[01:09] <SteveA>  * Andrew to document --stop-on-first-failure on the wiki, talk with daf
[01:09] <SteveA> spiv?
[01:09] <SteveA> daf?
[01:09] <SteveA>  * Steve or Kiko to mail lifeless about review queue and Bjrn's branch
[01:09] <spiv> No action... daf, let's talk straight after this meeting?
[01:09] <kiko> that we did, talk to lifeless about it
[01:09] <daf> spiv: yes, let's
[01:09] <SteveA>  * Steve to mail lifeless about getting pqm to stop accepting empty merges
[01:09] <SteveA> i didn't do that
[01:09] <kiko> I filed a bug, SteveA 
[01:09] <SteveA> cool
[01:09] <kiko> so he's been mailed
[01:09] <lifeless> kiko has filed a bug
[01:09] <SteveA>  * Andrew to mail lifeless, cc list, about making progress on buildbot patch
[01:10] <SteveA>  * Andrew to work with ddaa on librarian issue in importd2bzr
[01:10] <ddaa> hello, sorry being late
[01:10] <SteveA>  * Jordi to send spreadsheet to Steve
[01:10] <lifeless> I need a priority indication from you and steve  - can it wait for me to get past the 0.8 sprint ?
[01:10] <SteveA> i have the spreadsheet
[01:10] <SteveA> lifeless: yes, it can wait
[01:10] <lifeless> thanks
[01:11] <spiv> The buildbot patch is closer to landing, I've been exchanging email with lifeless about it, CCing the list.
[01:11] <kiko> we have the spreadsheet! thanks jordi 
[01:11] <lifeless> buildbot patch has moved on a step, now at a bzr/bzrtools mismatch I hope to correct tomorrow.
[01:11] <SteveA> congratulations to salgado and carlos for catching up with their activity reports, from last week
[01:11] <ddaa> librarian issue in importd2bzr: did not forward that to spiv, did not actually manage to get a successful "check_merge" on a clean rocketfuel tree...
[01:11] <lifeless> its a simple thing, only complication is ensuring I don't break launchpad.
[01:11] <spiv> I asked ddaa about his librarian issue; he said he'd ask me if he needed my help.
[01:12] <SteveA> okay
[01:12] <SteveA> i think we're done with things from last week's meeting
[01:12] <SteveA>  * Asterisk project status report (robert)
[01:13] <lifeless> waiting on a quote in the UK
[01:13] <SteveA> ETA?
[01:13] <lifeless> I have prodded RT about it
[01:13] <lifeless> one sec, can we come back to this
[01:13] <jbailey> lifeless: "Obelix is a lovely cat"
[01:14] <SteveA> yes, we can come back to this
[01:14] <SteveA>  * Launchpad oops milestone report (daf)
[01:14] <kiko> (nice report format daf, I like it!)
[01:14] <daf> thakns kiko
[01:14] <SteveA> daf: take the floor
[01:14] <kiko> you're weclome
[01:14] <daf> https://chinstrap.ubuntu.com/~daf/bugs/oops.py
[01:14] <SteveA> thanks
[01:14] <daf> more bugs filed than last week
[01:15] <daf> but more of them fixed too
[01:15] <kiko> daf, can you <strike> the fix committed and released ones?
[01:15] <SteveA> bug 2496
[01:15] <Ubugtu> malone bug 2496 in launchpad "Launchpad blows up if you try to use non-ascii characters in your password" [Normal,In progress]  http://launchpad.net/bugs/2496
[01:15] <daf> kiko: sure -- file a bug so I don't forget
[01:15] <kiko> on what?
[01:15] <kiko> daf, how about I just privmsg you until you do it? :)
[01:15] <daf> fine
[01:15] <SteveA> there are various oops bugs that don't have an assignee
[01:16] <carlos> daf: hmmm, it's still showing duplicates?
[01:16] <daf> https://chinstrap.ubuntu.com/~daf/bugs/scrape.py?q=milestone%3Aoops+-status%3Afix_released+-status%3Afix_committed&s=assignee
[01:17] <SteveA>     * #31042 RequestExpired Timeout on +translate page
[01:17] <SteveA>     * #31198 update-pkgcache raising TypeError exception
[01:17] <SteveA>     * #31367 Specifying a non-published binary package when filing a bug causes an oops
[01:17] <SteveA>     * #31410 OOPS-45A501 Timeout opening translation page
[01:17] <SteveA>     * #31589 Attempting to set redirection_url to a tuple instead of a string in login machinery
[01:17] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/45A501
[01:17] <SteveA>     * #30109 Timeout error when setting a target release
[01:17] <SteveA>     * #30184 OOPS-31A502 in https://launchpad.net/distros/ubuntu/+allpackages
[01:17] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/31A502
[01:17] <SteveA>     * #30605 Timeout at +translate page
[01:17] <SteveA>     * #30831 timeout searching for package in distro
[01:17] <SteveA>     * #30913 Oops while updating bug 30467
[01:17] <Ubugtu> malone bug 30467 in gnome-screensaver "Electricsheep screensaver does not show up in screensaver dialog" [Normal,Confirmed]  http://launchpad.net/bugs/30467
[01:17] <SteveA>     * #30957 searching for bugs by milestone cases an OOPS
[01:17] <SteveA>     * #31380 source package sort by version doesn't cope with invalid version numbers
[01:17] <SteveA>     * #31381 POMsgSet.active_texts assumes POFile.pluralforms is an int
[01:17] <SteveA>     * #28476 Request expired when trying to merge user accounts
[01:17] <SteveA> each of these bugs needs someone working on them
[01:17] <SteveA> they are all related to OOPSes we're seeing in production
[01:17] <kiko> SteveA, I can work with daf on that after the meeting.
[01:17] <stub> So can we consider that URL a prototype for a Project bug view?
[01:17] <SteveA> okay, great
[01:18] <kiko> stub, jamesh wrote email to the list about that today
[01:18] <mpt> stub, it's a project milestone bug view
[01:18] <jamesh> kiko: you mean mentioned on IRC?
[01:18] <mpt> (all those products happen to have an "oops" milestone)
[01:18] <daf> (it's the same code which generates the bug reports reports)
[01:19] <kiko> jamesh, hmmm. perhaps :)
[01:19] <kiko> jamesh, it should become email, at any rate
[01:19] <jamesh> yeah
[01:19] <kiko> in australia you are never allowed to rely on IRC
[01:19] <kiko> it's a national law
[01:19] <SteveA> anything else on the "oops" milestone report?
[01:20] <kiko> punishable by 10 years fixing symlink races in universe packages with no maintainer
[01:20] <daf> MeetingAction: kiko and daf to assign oops bugs to people
[01:20] <SteveA> thanks daf
[01:20] <SteveA>  * Production / staging (stub)
[01:20] <stub> Once we are happy with the report, it should definitely be moved into Launchpad. I can understand keeping it external for tweaking to make rollouts more agile.
[01:20] <stub> Anyway...
[01:20] <kiko> yeah, it's lovely
[01:20] <stub> Staging will be having daily database syncs as of tomorrow.
[01:20] <stub> Nothing thrilling happening on production except I feel the performance analysis tools people have thrown together seem to be working at we are making good headway into the timeout pages.
[01:20] <stub> mawson is now running breezy. Currently only being used by celso for testing.
[01:20] <stub> We have approval for a bigger'n'better emperor to be purchased along with an identical twin. No ETA on that.
[01:20] <stub> I want to get us onto PostgreSQL 8.1, which I will be testing after I've got us on Zope 3.2.
[01:21] <jamesh> are there PG 8.1 packages available for breezy?
[01:21] <pitti> yes, there's a backport
[01:21] <jamesh> cool.
[01:21] <pitti> however, it's slightly out of date
[01:21] <pitti> I uploaded 8.1.3 yesterday, breezy should get that 
[01:21] <pitti> breezy-backports, that is
[01:21] <kiko> pitti, you are the rock and roll man
[01:21] <SteveA> i'm modifying jamesh's oops.cgi code today to give a table that shows where to optimize in the request's statements, similar to the spreadsheet i mailed ot the list.
[01:22] <daf> reducing the number of DB queries seems to be a common theme in our performance work
[01:22] <SteveA> stub: next production run?
[01:22] <bradb> stub: Maybe we can bump batch size up to 50? It seems fine on staging.
[01:22] <daf> SteveA's work should allow us to easily see which queries to try and eliminate
[01:23] <stub> Next production update Tuesday. No firm opinions on what patch level to rollout. It will be as of now unless anyone lets me know otherwise (or I change my mind tomorrow :) )
[01:23] <SteveA> stub: carlos is working on an important optimisation of +translate pages
[01:24] <stub> Excellent. If I understood your analysis we should be able to get those pages down to < 8 seconds
[01:24] <carlos> It should be ready to review today 
[01:24] <SteveA> MeetingAction: carlos to tell stub (and the list) the patch level when he gets optimisation code reviewed and landed
[01:24] <SteveA> stub: yes, easily.  And down to 4.5s in the mid term
[01:25] <SteveA> moving onwards...
[01:25] <SteveA>  * Triage of pitti's six points (steve)
[01:25] <SteveA> pitti wrote a message about issues with soyuz
[01:25] <cprov> here we go
[01:25] <SteveA> i'd like us to make sure that each point is being addressed by someone
[01:26] <SteveA> with a concrete plan of how to proceed, whether it is actual things that are underway, or meetings / phonecalls needed
[01:26] <SteveA>  * no builds for *-updates (this blocks some important bug fixes in
[01:26] <SteveA>    breezy and security bug fixes in -updates versions)
[01:26] <SteveA>  * buildd give-back requires a lot of unnecessary manual work
[01:26] <SteveA>  * no reverse dep checking for package demotions
[01:26] <SteveA>  * no anastacia tool
[01:26] <SteveA>  * no syncs or package removals happen ATM and there is a backlog.
[01:26] <SteveA>    we should allow more people to do syncs; with the freezes approaching,
[01:26] <SteveA>    it will get harder to get syncs approved, which will just create
[01:26] <SteveA>    even more manual work (or reduce the quality of dapper)
[01:26] <SteveA>  * security uploads still need manual intervention 
[01:26] <SteveA> 
[01:26] <SteveA> 1. no builds for *-updates
[01:26] <SteveA> Kinnison: i think you wrote a followup email about this
[01:26] <Kinnison> I did
[01:26] <pitti> last point is settled now
[01:27] <kiko> it's getting there. cprov has the patch he needed in production
[01:27] <cprov> we have code to do it, it requires real world tests before release
[01:27] <kiko> now it's a matter of testing it and rolling out the code
[01:27] <SteveA> ETA?
[01:27] <kiko> was blocked on mawson
[01:27] <lifeless> FYI I'm chatting with admins, you may need to sms me to get my eyeballs back here for a few minutes
[01:27] <SteveA> lifeless: ok
[01:27] <kiko> if stub has mawson in good shape
[01:27] <SteveA> lifeless: /msg me your 3 sentences
[01:27] <kiko> then we can start testing it today and get it out by next week
[01:27] <cprov> I'm planning to release it today evening after run over a set of packages built by Kinnison
[01:27] <SteveA> ok, thanks
[01:27] <stub> kiko: if it isn't I don't know about it
[01:27] <cprov> kiko: he has 
[01:28] <kiko> stub, you didn't email, so I can't know about it either.
[01:28] <kiko> you can't assume we guess these things
[01:28] <SteveA>  * buildd give-back requires a lot of unnecessary manual work
[01:29] <SteveA> what will happen about this?
[01:29] <stub> kiko: eh? I'm just saying if there is anything left to do I'm now aware of it, because I think it is all sorted.
[01:29] <kiko> does anyone know any details about that one?
[01:29] <cprov> SteveA: I've commented a bug from infinity about that, I think we can sort it very quickly
[01:29] <Kinnison> cprov: I'll be making those packages once I've been to the distro team meeting
[01:29] <SteveA> cprov: okay, talk with infinity, and report back to the mailing list please
[01:29] <kiko> stub, and I'm saying I'd like you to use email to notify us of progress, because if you don't I need to start poking around to find out
[01:29] <cprov> SteveA:  fine, I'll
[01:29] <SteveA>  * no reverse dep checking for package demotions
[01:29] <pitti> kiko: infinity's bug list
[01:30] <kiko> pitti, gotcha
[01:30] <stub> kiko: But there is no progress - it is done!
[01:30] <SteveA> kiko, stub, please continue elsewhere, if necessary
[01:30] <SteveA>  * no reverse dep checking for package demotions
[01:31] <pitti> about that: dak's tools had some reverse dependencies/build-dep checks whether it is safe to demote a package
[01:31] <pitti> right
[01:31] <pitti> so, e. g. we don't know right now whether we break anything by demoting mozilla to universe
[01:31] <pitti> and we could just cross fingers with the mysql 4.1 demotion
[01:31] <SteveA> Kinnison; can you write a braindump about a tool for this, as part of your distro team duties?
[01:31] <kiko> pitti, is that a dak script?
[01:31] <cprov> pitti: uhm, I'm affraid it requires some doc 
[01:32] <pitti> kiko: I mainly used melanie -R -n
[01:32] <pitti> kiko: I'm sure that the actual demotion tool had a similar check
[01:32] <cprov> pitti: aha melanie 
[01:32] <kiko> pitti, because if it is, it might be something that elmo might entertain doing after the datacenter is more afloat
[01:32] <Kinnison> SteveA: Mostly this point is "port melanie, port anastacia, port <foo>, port <bar>"
[01:32] <kiko> right.
[01:32] <kiko> Kinnison is right
[01:32] <SteveA> Kinnison: so, either elmo needs to do it, or we need specs to get launchpad people to do it
[01:32] <pitti> what it should do, is: if I want to demote package foo to universe, it should check whether there are any packages in main that b-d/depend on it
[01:33] <pitti> likewise for total removals
[01:33] <cprov> Kinnison: I see and we are blocked on elmo, I mean elmo is also blocked in DC
[01:33] <SteveA> okay, this one appears to be blocked at present.
[01:33] <SteveA>   * no anastacia tool
[01:33] <cprov> SteveA: human resource for soyuz is very wanted ;)
[01:33] <SteveA> no idea wha tthat is
[01:33] <SteveA> but i imagine it is the same deal
[01:33] <cprov> SteveA: another tool
[01:33] <kiko> SteveA, same deal, yes
[01:33] <Kinnison> SteveA: It needs someone to pick apart the tools, write down what the distro team actually use, before a spec can be written
[01:34] <SteveA>   * no syncs or package removals happen ATM and there is a backlog.
[01:34] <Kinnison> pitti: could you do that, I.E. actually write down what you want in a more detailed way wrt. the modes of melanie you use etc
[01:34] <kiko> Kinnison, porting them is actually not so  much work if you sit down to reverse-engineer them
[01:34] <kiko> SteveA, that is something that just requires elmo running them. 
[01:34] <Kinnison> kiko: I guess not
[01:34] <pitti> Kinnison: yes, I can
[01:34] <kiko> the tools exist to do them and they have been production-tested-and-deployed
[01:34] <SteveA> kiko: we all know that elmo is super-busy
[01:34] <pitti> Kinnison: I'll talk with Kamion (who actually does demotions, I can't)
[01:34] <Kinnison> pitti: right
[01:34] <pitti> Kinnison: and come up with a list of things we need
[01:35] <kiko> SteveA, or to have elmo or cprov pass on the knowledge to kamion
[01:35] <cprov> kiko: it concerns me because the current scripts we have done it are totally outside the LP code standards
[01:35] <kiko> so he can do it
[01:35] <Kinnison> pitti: cool. make sure you communicate with cprov about all that
[01:35] <SteveA> so... did we address this one:
[01:35] <SteveA>   * no syncs or package removals happen ATM and there is a backlog.
[01:35] <pitti> yes
[01:35] <kiko> cprov, that's something we need to deal with
[01:35] <SteveA>  * security uploads still need manual intervention 
[01:35] <pitti> ideally, all ubunto-core-devs could trigger a sync on the websites
[01:35] <pitti> maybe something finer-grained, though
[01:36] <kiko> pitti, I'm fine with that being the plan, but short-term the right person with drescher access can do it today 
[01:36] <pitti> but assinging all those syncs to just elmo is neither good for him nor for us
[01:36] <dholbach> (respecting freeze situations)
[01:36] <pitti> kiko: right
[01:36] <cprov> kiko: hope you don't mean "stand with", they don't use LPCONFIG, neither common log options, it's a mess 
[01:36] <kiko> I /think/ it's a matter of getting Kamion or someone else drescher access
[01:36] <pitti> he has already
[01:36] <kiko> cprov, we can stick them in contrib/ for now and rewrite them later
[01:36] <Kinnison> SteveA: the manual intervention on security uploads I believe has been fixed
[01:36] <pitti> right
[01:36] <SteveA> okay
[01:36] <kiko> pitti, so then nag him to run the removals and syncs!
[01:37] <pitti> kiko: Kamion can't do that
[01:37] <SteveA> then we just have the "need some of the dak kinda tools" issues, which we'll get some docs for
[01:37] <cprov> kiko: okay, it's a plan
[01:37] <kiko> pitti, why not?
[01:37] <Kinnison> if elmo would train someone else (E.g. Kamion) to do the removals and syncs then we'd be slightly better off
[01:37] <Kinnison> kiko: there are social processes involved also
[01:38] <SteveA> pitti: can i consider this agenda item finished for today?
[01:38] <pitti> SteveA: yes
[01:38] <SteveA> thanks
[01:38] <SteveA>  * Keep, Bag, Change
[01:38] <pitti> thank you all for the heads-up
[01:38] <SteveA> with a countdown
[01:38] <SteveA> 10
[01:38] <SteveA> 8
[01:38] <SteveA> 6
[01:38] <SteveA> 5
[01:38] <SteveA> 4
[01:38] <SteveA> 3
[01:38] <SteveA> 2
[01:38] <SteveA> 1
[01:39] <SteveA> done
[01:39] <SteveA>  * Three sentences
[01:39] <SteveA> throw them out there!
[01:39] <salgado> DONE: Random bug fixes, some code review, finished MirrorManagement
[01:39] <salgado> TODO: ShipIt for dapper, code review and other random fixes
[01:39] <salgado> BLOCKED: No
[01:39] <mpt> DONE: Bug fixing, page headings, landed build page fixes, spec updates
[01:39] <mpt> TODO: finish page headings, more bug fixing, MaloneFrontPages spec
[01:39] <mpt> BLOCKED: SteveA's review of specs; BjornT's review of trivial/ branch
[01:39] <Kinnison> DONE: Assisted cprov wrt. getting the branch integrated with more tests. Various uploader tweaks and large amounts of test work done.
[01:39] <ddaa> DONE: planning importd bzr transition, syncher-logging
[01:39] <ddaa> TODO: importd bzr transition, merge outstanding branches, merge documentation
[01:39] <ddaa> BLOCKED: merge of buildbot patch
[01:39] <Kinnison> TODO: test packages for cprov as discussed, work on the distro for a while and be a user of soyuz
[01:39] <Kinnison> BLOCKED: not on you guys
[01:39] <SteveA> lifeless DONE: bzr-dir phases 2 and three (in review on phase 3), including shared repository support.
[01:39] <SteveA> lifeless TODO: PQM updates, production cherrypicking.
[01:39] <SteveA> lifeless BLOCKED: Z3 update [week ???] 
[01:39] <jblack> DONE: Bzr Advocacy, Bzr Support, Bzr documentation, Bzr wiki, light Bazaar Support
[01:39] <jblack> TODO: lp development/rollout debs, Advocacy, Documentation, Suppport
[01:39] <cprov> DONE: Soyuz UI, bug triage and fix 
[01:39] <jblack> BLOCKED: none
[01:39] <jamesh> DONE: code reviews, error report analysis improvements, pygpgme/launchpad integration (currently waiting on pygpgme branch into rocketfuel), branch status update XML-RPC interface, some performance analysis
[01:39] <jamesh> TODO: code reviews, branch status update XML-RPC interface, importd error reporting
[01:39] <jamesh> BLOCKED: no
[01:39] <bradb> DONE: Fixed bugs 29182, 29174, and a bug from the LaunchpadErrors report. Removed the search filter (for now). Converted all bug listings to new table format (diff cleanup pending.) Much user discussion.
[01:39] <cprov> TODO: SOyuz release of wanted feature (-updates, etc)
[01:39] <bradb> TODO: Cleanup buglist conversion diff, submit for review. Optional table/list view. Customizable batch size.
[01:40] <bradb> BLOCKED: No.
[01:40] <cprov> BLOCKED: none
[01:40] <kiko> DONE: looking into performance, keeping track of everybody, regular progress reports, heckling of problems in Rosetta and Malone
[01:40] <matsubara> DONE: bug triage, email support to a user on how to sign the ubuntu code of conduct, fixed some bugs on oops reports.
[01:40] <matsubara> TODO: finish fix on distrotask validation, fix bug non-ascii password, bug triage
[01:40] <matsubara> BLOCKED: No
[01:40] <SteveA> DONE: management, zope3.2 hacking, crowd control, oops analysis, management
[01:40] <SteveA> TODO: more of the same, except the zope3.2 hacking.
[01:40] <SteveA> BLOCKED: no
[01:40] <spiv> DONE: Fixed standalone page test running, closer to merging buildbot test fixes, misc sqlobject and librarian work.
[01:40] <stub> DONE: psycopgda work
[01:40] <stub> TODO: Zope 3.2, PostgreSQL 8.1
[01:40] <stub> BLOCKED: No
[01:40] <spiv> TODO: AuthServerCaching
[01:40] <spiv> BLOCKED: no
[01:40] <kiko> TODO: fix a few bugs I have started work on, more performance debugging, regular management
[01:40] <kiko> BLOCKED: no
[01:41] <daf> DONE: discuss people and users with mpt; advanced querying for bug triage tool; improve weekly bug report; #30912; #31333
[01:41] <daf> TODO: land optional-branch-title; assign oops bugs with kiko
[01:41] <daf> BLOCKED: no
[01:41] <kiko> carlos, daf, Kinnison: please don't batch your activity reports.
[01:42] <kiko> it makes it VERY hard for me to track progress
[01:42] <SteveA> ddaa BLOCKED: merge of buildbot patch
[01:42] <kiko> and there is no reason not to send them in daily
[01:42] <SteveA> ddaa: do you have this under control?
[01:42] <SteveA> mpt BLOCKED: SteveA's review of specs; BjornT's review of trivial/ branch
[01:42] <daf> kiko: sorry; I tend to forget until Thursday morning
[01:42] <ddaa> SteveA: I think spiv has that under control
[01:42] <SteveA> mpt: is the branch in the review queue?
[01:42] <daf> kiko: I'll try to do it more often this week
[01:42] <mpt> SteveA, yes
[01:42] <kiko> daf, do it daily, no forgetting allowed
[01:42] <Kinnison> kiko: Ditto, I'll try to remember
[01:43] <ddaa> need that to merge cscvs fixe to get clean check_merge to isolate importd2bzr merge problem...
[01:43] <SteveA> mpt: send a mail to the launchpad-reviews list, cc bjorn asking him to look at it, as a gentle reminder that you're blocked on it
[01:43] <jbailey> daf: My trick for a while was to send them mid day, so the reports were from midday to midday.
[01:43] <spiv> ddaa, SteveA: Yeah, the buildbot patch is under control... every day or so lifeless fixes another problem blocking the merge.
[01:43] <mpt> ok
[01:43] <niemeyer> kiko is the activity report batching fascist.
[01:44] <daf> niemeyer: clearly :)
[01:44] <SteveA> okay
[01:44] <jbailey> daf: That way it's not a pile of docs I have to write at the end of the day and hate. =)
[01:44] <SteveA> any other BLOCKED issues?
[01:44] <ddaa> spiv: I suppose that's good, assuming there's a finite number of those...
[01:44] <jbailey> SteveA: fv 09 07:35:13 <SteveA>        item for next meeting: check progress of issue tracker readyness next meeting
[01:44] <jbailey> SteveA: I don't think that made it to the agenda.
[01:44] <spiv> ddaa: We think we're running out, yeah :)
[01:44] <daf> jbailey: well, writing the reports is not the problem; sending them is :)
[01:44] <SteveA> daf: any idea why that didn't make it as a proposed agenda item?
[01:45] <daf> no
[01:45] <ddaa> SteveA: oh BTW, I'm uptodate with activity reports
[01:45] <daf> I didn't see it for some reason
[01:45] <SteveA> jbailey: bjorn is away today anyway, but we'll get it on there next week
[01:45] <carlos> sorry, I someone knocked my door.
[01:45] <SteveA> ItemForNextMeeting: check progress of issue tracker readyness
[01:45] <jbailey> SteveA: Thanks.
[01:46] <SteveA> carlos: you're holding the meeting up.  prepare your three sentences before the meeting next time.
[01:46] <kiko> yawn
[01:46] <jamesh> jbailey: I think BjornT's branches went in (email support, etc).  So that part will be rolled out next week
[01:46] <jbailey> jamesh: Nice, thanks.
[01:46] <ddaa> coooooooffeeeeeee
[01:46] <mpt> sleeeeeeeeeeeeeeeep
[01:46] <jamesh> jbailey: there is an RT request to get the actual incoming email directed to Launchpad's POP account though
[01:47] <carlos> DONE: Ubuntu Translation imports testing with soyuz, translation suggestions improvements with AJAX, bug #31333
[01:47] <stub> I believe there is still an rt issue about a POP mailbox for the issue tracker?
[01:47] <Ubugtu> malone bug 31333 in rosetta "Separate update in POST from rendering of form via redirect()" [Normal,Fix released]  http://launchpad.net/bugs/31333
[01:47] <kiko> jamesh, can you get me the RT id? 
[01:47] <SteveA> (note that the AJAX is an experiement, not going into production yet)
[01:47] <carlos> TODO: Finish POMsgSetPage, +translate form performance improvements, bug #1681
[01:47] <jamesh> kiko: I think BjornT included it in an lp-devel post.  Let me check
[01:47] <Ubugtu> malone bug 1681 in rosetta "Viewing a translation page fails in unix2newlines" [Major,In progress]  http://launchpad.net/bugs/1681
[01:47] <kiko> thanks
[01:47] <carlos> BLOCKED: no
[01:47] <SteveA> thanks carlos
[01:47] <SteveA> MEETING ENDS
[01:47] <kiko> EOM
[01:47] <carlos> SteveA: Will do, sorry
[01:47] <daf> carlos: what's holding up #1681?
[01:48] <jamesh> kiko: 1522
[01:48] <SteveA> spiv: can i get a brief phone call with you?
[01:48] <daf> lifeless: yo
[01:48] <carlos> daf: my lack of time
[01:48] <carlos> daf: but now it's high priority
[01:48] <kiko> thanks
[01:48] <carlos> kiko: I will try to send them daily, sorry
[01:48] <spiv> SteveA: Sure, but in a few minutes?
[01:48] <SteveA> spiv: yes, can we set a time?
[01:49] <daf> carlos: I think, in order of priority: (1) performance improvements (2) #1681 (3) POMsgSetPage
[01:49] <spiv> SteveA: Say 20 min from now?
[01:49] <daf> kiko: what do you think?
[01:49] <SteveA> spiv: 15 past the next hour?
[01:49] <carlos> daf: yeah
[01:49] <kiko> daf, I  want ALL of it done
[01:49] <spiv> SteveA: That'd be 25, but sure.
[01:49] <kiko> PMSP is so old I can SMELL it
[01:49] <carlos> kiko: but I will work on that order
[01:49] <SteveA> spiv: great.  talk with you then.
[01:49] <kiko> as long as it lands by next week
[01:49] <spiv> Ok.
[01:49] <carlos> kiko: unless you want it in other way
[01:49] <kiko> carlos, make that your deadline -- rollout + 1
[01:50] <kiko> no, the order is fine as long as you remember that you can't spend the week on performance, because it's easy to do that.
[01:50] <kiko> carlos, noted?
[01:50] <carlos> kiko: noted
[01:50] <kiko> wonderful
[01:50] <carlos> kiko: the performance thing will be done today
[01:50] <kiko> cool
[01:50] <carlos> at least what I talked with SteveA and daf
[01:51] <carlos> this morning
[01:51] <kiko> cool++
[01:51] <daf> carlos: keep us posted on how it's going
[01:51] <daf> carlos: especially if it turns out to be more complicated than you thought
[01:51] <carlos> daf: sur
[01:51] <carlos> dure
[01:51] <carlos> grrr
[01:51] <carlos> sure
[01:52] <lifeless> daf: what ?
[01:52] <lifeless> kiko: SteveA: re asterix Znarl tells me that we can move much more now the DC has space.
[01:52] <lifeless> so I will hopefully have etas for stuff on Monday
[01:53] <daf> lifeless: I'm trying to import a baz branch into bzr on chinstrap
[01:53] <SteveA> okay, cool
[01:53] <daf> lifeless: I can't get the reuse path right
[01:53] <SteveA> daf: item for next meeting please: asterix ETA
[01:53] <kiko> great
[01:53] <pitti> thanks guys
[01:53] <daf> SteveA: noted
[01:54] <carlos> see you later
[01:57] <lifeless> daf: its the root of the output
[01:57] <lifeless> daf: i.e. if you convert foo@bar.com into a dir 'FOO'
[01:58] <salgado> lifeless, my branch has a db patch, that's why I added it to stub's queue
[01:58] <lifeless> to reuse the history from that archive, you sepcify 'FOO' as the reuse path
[01:58] <lifeless> salgado: ah, ok.
[01:58] <lifeless> salgado: np then :)
[01:58] <daf> lifeless: nice -10 /home/warthogs/source/bzr.integration/bzr baz-import-branch portlet-refactor daniel.debonzi@canonical.com/launchpad--portlet-refactor--0 ../../rocketfuel/launchpad/devel/.bzr/
[01:58] <daf> er
[01:58] <daf> without the .bzr on the end
[01:58] <lifeless> definately wrong
[01:59] <lifeless> we are not in the arch namespace anymore
[01:59] <daf> what are you telling me?
[01:59] <lifeless> one sec
[02:00] <lifeless> daf: two things.
[02:00] <lifeless> daf: one is that that is the path to a BRANCH, not to an ARCHIVE
[02:01] <kiko> I like the caps
[02:01] <lifeless> daf: two, we have rearranged launchpad since converting, so you may not get complete history reuse, but thats ok. 
[02:01] <daf> right, I'm trying to use baz-import-branch
[02:01] <daf> I don't want the whole archive
[02:01] <lifeless> daf: please try nice -10 /home/warthogs/source/bzr.integration/bzr baz-import-branch portlet-refactor daniel.debonzi@canonical.com/launchpad--portlet-refactor--0 ../../rocketfuel/launchpad
[02:02] <lifeless> daf: its reuse, think of it as a cache of what it can find history in
[02:02] <stub> bradb: Any opinions on what the production bug batch size should be?
[02:02] <lifeless> erm, bugger.
[02:02] <lifeless> daf: I meant
[02:02] <lifeless> daf: nice -10 /home/warthogs/source/bzr.integration/bzr baz-import-branch portlet-refactor daniel.debonzi@canonical.com/launchpad--portlet-refactor--0 ../../rocketfuel
[02:04] <ddaa> lifeless: can you give me you thoughts on the open issues for the bzr transition plan?
[02:05] <lifeless> ddaa: not right now sorry, its midnight and after 17 hours I turn into a blasthering idiot
[02:05] <ddaa> that's a "blocked" but I did not mention it because I was waiting for mail to finish fetching
[02:05] <lifeless> ddaa: in other news, repositories are working.
[02:06] <ddaa> lifeless: please do that tomorrow first thing, it woud be great to have those nailed for monday's meeting
[02:06] <lifeless> ddaa: cross my heart and hope to emai
[02:06] <lifeless> l
[02:06] <ddaa> so we can actually start DOING that transition...
[02:08] <lifeless> ddaa: well, today can you pick a almost-inevitable bit and start on some tests ?
[02:08] <lifeless> ddaa: that seems to be a safe approach and will give your analytical side a break for a day
[02:08] <daf> lifeless: sorry, trying to do too many things at once -- trying it now
[02:09] <ddaa> lifeless: had my break yesterday with syncher-logging, I'm not sure what can be done at first without clearing the open issues, I'll try to see.
[02:10] <lifeless> ddaa: I mailed you yesterday about the ones open then
[02:11] <ddaa> lifeless: last I received was about the "new imports" on tuesday
[02:11] <daf> lifeless: yay, that works
[02:11] <daf> lifeless: 31 revisions rather than 1851
[02:11] <ddaa> lifeless: then I replied and sent "draft of implementation section"
[02:11] <lifeless> ddaa: it will be my first thing tomorrow
[02:12] <ddaa> thank you
[02:12] <lifeless> ddaa: though my hours will be shifted to accomodate bedtime being > 2400
[02:12] <daf> lifeless: thank you
[02:12] <lifeless> daf: np
[02:12] <ddaa> Thanks for telling, I wont wait for you to wake up. My sleep hours are utterly screwed too.
[02:14] <lifeless> night
[02:14] <SteveA> stub: ping
[02:14] <stub> SteveA: pong
[02:14] <SteveA> stub: i'm looking into bug 3052.  can you bounce the launchpad app servers?  i'm getting a failure now, and i want to see if i get another failure after an app server restart
[02:14] <Ubugtu> malone bug 3052 in launchpad "GPG upload of newly-changed key fails because we cache the old key" [Normal,Confirmed]  http://launchpad.net/bugs/3052
[02:15] <SteveA> or just nuke the GPG caches...
[02:15] <stub> One and two bounced....
[02:16] <spiv> SteveA: call?
[02:17] <stub> three and four bounced
[02:17] <SteveA> ta
[02:17] <daf> stub: just got a 500 on launchpad.net
[02:17] <daf> oh you bounced the server
[02:17] <daf> never mind
[02:18] <stub> You shouldn't have gotten a 500 though. Maybe I didn't wait enough between boucing the second set of instances.
[02:18] <SteveA> stub: okay.  no change on bug 3052
[02:18] <Ubugtu> malone bug 3052 in launchpad "GPG upload of newly-changed key fails because we cache the old key" [Normal,Confirmed]  http://launchpad.net/bugs/3052
[02:18] <stub> Does the cache get nuked on server startup?
[02:19] <daf> stub: reckon you'll have tim to hunt down #31589 or shall I hand it to someone else?
[02:19] <SteveA> i was trying to upload keys where i know the fingerprint is in the keyserver.  the upload of keys fails silently
[02:19] <SteveA> spiv: yes, skype or phone?
[02:19] <stub> Bug 31589
[02:19] <SteveA> stub: no idea.
[02:19] <spiv> SteveA: phone, landline
[02:19] <SteveA> stub: the "fails silently" part concerns me a lot
[02:20] <daf> bug 31589
[02:20] <Ubugtu> malone bug 31589 in launchpad "Attempting to set redirection_url to a tuple instead of a string in login machinery" [Normal,Confirmed]  http://launchpad.net/bugs/31589
[02:21] <daf> Seveas: are you sure Ubugtu isn't case sensitive?
[02:21] <stub> daf: probably not this week.
[02:21] <daf> stub: ok, thanks
[02:21] <Seveas> Bug 31589
[02:22] <kiko> daf, it will have to wait
[02:22] <daf> kiko: I just assigned to salgado
[02:22] <Seveas> INFO 2006-02-16T14:21:53 Bugtracker.bugSnarfer called by
[02:22] <Seveas>      Seveas!n=seveas@ubuntu/member/seveas.
[02:22] <kiko> he probably won't do it...
[02:23] <daf> who will?
[02:23] <kiko> nobody this week, let's leave it
[02:23] <Seveas> @reload Bugtracker
[02:23] <kiko> not a big deal.
[02:23] <Seveas> Bug 31589
[02:23] <Ubugtu> malone bug 31589 in launchpad "Attempting to set redirection_url to a tuple instead of a string in login machinery" [Normal,Confirmed]  http://launchpad.net/bugs/31589
[02:23] <daf> ok
[02:23] <Seveas> of course there are other parts in the code where strings are compared...
[02:24] <Seveas> but nothing a map(lambda x: x.lower) can't fix 
[02:24] <daf> whoa
[02:24] <daf> unicode smiley
[02:24] <Seveas> yes, evil isn't it 
[02:25] <daf> it is, even though I  unicode
[02:26] <Seveas> In a momentary lapse of reason I filled x-chats auto-replace functioin with unicode
[02:26] <Seveas> (*) (l) 
[02:26] <Seveas> hmm, it seems to be failing
[02:26] <Seveas>  
[02:26] <Seveas> ah, there it is 
[02:26] <kiko> that sounds like a lot of time on your hands
[02:27] <Seveas> not really, but momentary laps of reason don't take time into account
[02:27] <Seveas> lapses
[02:27] <Seveas> not laps
[02:28] <daf> SteveA: how's CrowdControl doing?
[02:33] <dilys> Merge to devel/launchpad/: [trivial]  Attempt to revert band-aid in bug 28900 now that spiv says we are safe, thanks to the story test runner/isolation work (r3153: kiko)
[02:34] <kiko> cool
[02:38] <kiko> BjornT, bradb, can you check out bug 30913, and check the OOPS report there to ensure that the bug is what we actually fixed (I did notice some INSERTs there)
[02:38] <Ubugtu> malone bug 30913 in malone "Oops while updating bug 30467" [Normal,Fix released]  http://launchpad.net/bugs/30913
[02:38] <SteveA> stub: do you know if restarting servers clears the GPG cache?
[02:38] <stub> Nope. 
[02:38] <stub> if I could remember where the cache was I could nuke it manually...
[02:39] <SteveA> cprov: do you know?
[02:40] <SteveA> lots of gpg- tmp dirs on gangotri
[02:40] <SteveA> in /tmp/
[02:41] <cprov> SteveA: yes, it does you can also invoke a method in IGPGHandler to clear the cache
[02:41] <cprov> stub: could you create the session_dogfood DB on mawson 
[02:41] <stub> cprov: ok
[02:42] <cprov> stub: or even better, give permission to launchpad become postgres ?
[02:42] <stub> cprov: I think it can (?)
[02:42] <SteveA> cprov: i'm seeing a weird thing in the gpg add keys interface
[02:42] <cprov> stub: launchpad@mawson:/srv/launchpad.net$ psql -U postgres -l
[02:42] <cprov> psql: FATAL:  Ident authentication failed for user "postgres"
[02:42] <SteveA> cprov: i upload a key's fingerprint, and then it doesn't apper anywhere, and there is no error
[02:42] <stub> (not sudo, but connect as user postgres)
[02:42] <stub> hmm
[02:43] <cprov> SteveA: weird, no UI error or email ?
[02:43] <stub> cprov: Can just connect as postgres to the launchpad_dogfood database
[02:44] <cprov> stub: yes, it can
[02:44] <SteveA> cprov: nothing i can see.  i was using admin powers to upload it to someone else.
[02:45] <stub> cprov: session database created
[02:45] <cprov> stub: it'd be nice if can create new DB too, can you grant this permission ?  less expensive to you and me ;)
[02:45] <SteveA> cprov: is it supposed to get the key immediately, or to send you an email ro what?
[02:45] <stub> cprov: The postgresql user 'cprov' can now do that
[02:45] <stub> (and now exists)
[02:45] <cprov> SteveA: it imports the key immediately from the keyserver
[02:45] <cprov> stub: very good
[02:46] <cprov> stub: thank you
[02:46] <SteveA> cprov: does the email address of the key have to match a launchpad address for the person?
[02:47] <cprov> SteveA: at least one of them should be your preferred, I think 
[02:47] <SteveA> cprov: okay
[02:47] <SteveA> so the problem may well be that launchpad is rejecting the key
[02:47] <cprov> SteveA: let me check it for you 
[02:47] <SteveA> but is not giving an error message in the UI
[02:47] <SteveA> to say this
[02:48] <kiko> stub, ping?
[02:49] <stub> kiko: pong
[02:49] <daf> stub: we have an OOPS which timed out on an INSERT
[02:49] <kiko> right -- https://chinstrap.ubuntu.com/~jamesh/oops.cgi/31A8
[02:49] <kiko> can you give us a reason on why that might time out?
[02:49] <kiko> I mean, contention, but contention against what?
[02:50] <SteveA> goddamn statistician
[02:50] <stub> Most likely because another query had locked the table (by doing an insert or delete) and not committed
[02:50] <kiko> stub, why would it block an insert into bugtask? does anyone delete from bugtask?
[02:50] <stub> Oops... I should really disable statastician for a while...
[02:50] <kiko> stub, I'm asking more in the line of "what other query"...
[02:52] <stub> kiko: Another insert would do it too - the constraint can't be checked until other pending inserts are committed.
[02:52] <SteveA> stub, jamesh: can we instrument the database adapter to detect a statement on transaction containing an INSERT or DELETE or UPDATE where the statement in question (not necessarily an INSERT or DELETE or UPDATE) occurs a long time since the start of the transaction?
[02:52] <kiko> ah, a constraint.
[02:52] <stub> (and there are lots of constraints on that table)
[02:53] <stub> SteveA: I don't follow. That sounds like how the statement timeout stuff works right now.
[02:54] <daf> stub: 
[02:54] <cprov> stub: session ident still failing in mawson
[02:55] <stub> cprov: ahh... yes.
[02:55] <daf> Proxy Error
[02:55] <daf> The proxy server received an invalid response from an upstream server.
[02:55] <daf> The proxy server could not handle the request GET /products/malone/+bug/30109/+duplicate.
[02:55] <daf> Reason: Error reading from remote server
[02:56] <stub> cprov: should be fixed now
[02:58] <cprov> stub: good, thanks
[02:58] <stub> One of the app servers might have been having trouble. Bounced. Not 100% sure though and too late to confirm :-/
[03:01] <kiko> stub, here's another one for you:
[03:01] <kiko> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-08/C391
[03:01] <kiko> stub, contention?
[03:02] <stub> kiko: That table was having issues a few days ago. I needed to rebuild the indexes.
[03:02] <cprov> stub: can you help me with this error -> https://chinstrap.ubuntu.com/~dsilvers/paste/fileOPwMki.html
[03:02] <cprov> stub: what does it exactly means ?
[03:02] <kiko> stub, should I assign it to you, or just close it?
[03:03] <cprov> stub: it doesn't happen in lp upstream tree only in mine
[03:03] <stub> kiko: Close it. It is fixed now.
[03:03] <kiko> ok.
[03:03] <stub> cprov: Your sqlos branch is out of date
[03:04] <stub> Hmm... maybe not. saw registerTypes and assumed.
[03:04] <cprov> stub: strange because it works locally
[03:04] <stub> Are you running breezy?
[03:05] <daf> stub: yay
[03:05] <cprov> stub: yes, I've got it and updated my tree
[03:05] <cprov> stub: anyway, I'll work it out
[03:05] <stub> cprov: That traceback can't be right
[03:05] <kiko> cprov, I have seen the same problem, actually
[03:06] <kiko> I think it happened when I had an updated sourcecode but and old tree
[03:06] <kiko> hm, PIL?
[03:06] <stub> Indeed. The traceback says that PIL is calling canonical code, which is just wrong
[03:06] <cprov> kiko: could be ...
[03:07] <kiko> PYTHONPATH perhaps is the culprit?
[03:08] <spiv> PIL uses .pth file evil, from memory.
[03:08] <kiko> that file is empty in breezy
[03:08] <spiv> I can't remember why it is that PIL has a tendency to infect unrelated tracebacks, though.
[03:11] <spiv> Oh, I remember why.
[03:11] <spiv> $ python -c "import __init__; print __init__"
[03:11] <spiv> <module '__init__' from '/usr/lib/python2.4/site-packages/PIL/__init__.pyc'>
[03:11] <kiko> ugh
[03:11] <kiko> gross
[03:12] <spiv> PIL really shouldn't have a __init__.py if it also uses a .pth
[03:13] <kiko> daf, oh, bug 31589 is probably trivial!
[03:13] <Ubugtu> malone bug 31589 in launchpad "Attempting to set redirection_url to a tuple instead of a string in login machinery" [Normal,Confirmed]  http://launchpad.net/bugs/31589
[03:13] <kiko> matsubara, are you interested in that one? jamesh gave us a good analysis
[03:14] <spiv> SteveA, stub: I have a branch for https://launchpad.net/products/launchpad/+bug/4613 if you're interested (it's on the review page)
[03:15] <matsubara> kiko: is it high priority? i'm kind of busy...
[03:15] <kiko> matsubara, yeah, it would be nice
[03:15] <kiko> no need to resort priorities but take it as it comes
[03:15] <kiko> matsubara, what are you working on right now?
[03:15] <kiko> btw, jamesh?
[03:16] <daf> kiko: where's the analysis?
[03:16] <cprov> spiv: can you any solution ? I have no clue for this PIL error
[03:16] <kiko> daf, in the bug report
[03:16] <matsubara> kiko: distrotask hell validator. actually answering BjornT comments on it. And the next thing on my todo list is fix the non-ascii password one. 
[03:17] <kiko> matsubara, leave the non-ascii password thing for now.
[03:17] <kiko> I think you should focus on easier bugs
[03:17] <kiko> you'll be more productive
[03:17] <kiko> that bug is hard to fix
[03:17] <daf> if matsubara's busy, I'll take it
[03:17] <kiko> great
[03:18] <kiko>    1 UnboundLocalError: local variable 'results' referenced before assignment
[03:18] <kiko>     0% from search bots, 0% referred from local sites
[03:18] <kiko>        1 https://launchpad.net/people/+index
[03:18] <kiko>         OOPS-46A156
[03:18] <matsubara> kiko: ok, but that one is halfway reviewed.
[03:18] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/46A156
[03:18] <kiko> that is horrible
[03:18] <kiko> matsubara, yes, but the review tells you to redesign the solution :)
[03:19] <kiko> matsubara, btw, nice work on +build and friends, looks nice!
[03:19] <bradb> kiko: I'll find the revno for the fix to bug 30913...
[03:19] <Ubugtu> malone bug 30913 in malone "Oops while updating bug 30467" [Normal,Fix released]  http://launchpad.net/bugs/30913
[03:20] <kiko> bradb, I have it -- just wanted you to confirm the fix
[03:20] <kiko> is fixing what you thought it did :)
[03:20] <spiv> cprov: hmm, I'm not sure, except that PIL is a red-herring.
[03:20] <bradb> kiko: Yeah, it should be fixed.
[03:20] <kiko> great
[03:20] <spiv> cprov: PIL's just showing up due to a bug in traceback generation, I think.
[03:21] <cprov> spiv: I'm resyncing the tree with --delete and will build it again, maybe it fix
[03:22] <spiv> cprov: good idea.
[03:24] <kiko> bradb, BjornT: I'd like bug 29176 to be a priority.. what's your opinion?
[03:24] <Ubugtu> malone bug 29176 in malone "Changing source package doesn't notify the new bug contact about the change" [Normal,Confirmed]  http://launchpad.net/bugs/29176
[03:24] <bradb> kiko: I think it's high priority too.
[03:25] <SteveA> cprov: when launchpad can't import a gpg key, where does the error message go?
[03:25] <SteveA> i mean, where are errors logged?
[03:25] <cprov> SteveA: one min, phone
[03:25] <SteveA> ok
[03:29] <cprov> SteveA: to the UI, always
[03:29] <cprov> SteveA: if not we have a bug
[03:29] <SteveA> there is an error shown in the UI
[03:30] <SteveA> i didn't notice it because the box was so tall it didn't look like an error box
[03:30] <SteveA> and it had an (i) symbol
[03:30] <SteveA> for information, not error
[03:30] <SteveA> but, what i mean is, where do the details go?
[03:30] <SteveA> all i know is "launchpad cannot import this key"
[03:30] <SteveA> no diagnositc info
[03:30] <SteveA> no oops
[03:30] <SteveA> we should get an OOPS from this, or something like that
[03:31] <cprov> SteveA: makes sense, could you file a bug with this info ?
[03:31] <jbailey> What's the best way to ask for a couple bulk tasks to be run against launchpad?  mdz sent me here.
[03:32] <SteveA> cprov: but... how do i look into a problem importing a GPG key today?
[03:32] <SteveA> where are problems logged?
[03:33] <cprov> SteveA: it's possible not logged, since they was no exception
[03:33] <SteveA> ok
[03:33] <cprov> there was
[03:34] <cprov> SteveA: odd of pyME, I think
[03:34] <SteveA> is there another way of getting someone's gpg key into launchpad?
[03:37] <mdz> jbailey: I think stub is the person to talk to
[03:37] <jbailey> mdz: Thanks!
[03:37] <jbailey> stub: Gratuitous nickhighlight.
[03:41] <cprov> SteveA: no, you can add it by hand in the DB
[03:41] <cprov> SteveA: but, it may result in future errors since we can't really import the key from DB
[03:54] <stub> jbailey: Yo
[03:55] <jbailey> stub: Can you handle a mass reassign and mass unsubscription for me?
[03:55] <stub> yup
[03:56] <jbailey> stub: All grub bugs that involve user 'jbailey' should involved 'tfheen' (subscription, assigned)
[03:56] <jbailey> stub: all evolution-exchange bugs that involve user 'jbailey' should involve 'desktop-bugs', which I suspect is a team (subscription, assigned)
[03:58] <stub> Should I be adding new subscribers, or replacing your subscription?
[03:58] <jbailey> replacing mine, if that's possible.
[03:58] <stub> Yup
[03:58] <jbailey> Lovely, thanks.
[03:58] <stub> Is this urgent or can I do it tomorrow?
[03:58] <jbailey> tomorrow is fine.
[03:59] <jbailey> Knowing that you can do it mean I don't have to go through them by hand. =)
[03:59] <jbailey> means, rather.
[04:00] <stub> Ok. Do you think this will be a common request or a one off? It makes a difference on how reusable any scripts i knock up should be.
[04:02] <jbailey> Hmm.
[04:02] <salgado> daf, did you file a bug for OOPS-46A156?
[04:02] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/46A156
[04:03] <jbailey> I suspect reasonably common - in my case it's because I'm doing more support stuff, but it'll be anytime someone leaves Ubuntu or whatever and someone else needs to take on the packages.
[04:03] <stub> ok. I'll sort it out tomorrow morning and email you when done.
[04:04] <jbailey> stub: Thanks!
[04:09] <daf> salgado: no, I didn't
[04:09] <daf> salgado: I was triaging a different bug at the time
[04:10] <daf> salgado: and this OOPS happened after I fiddled the query string by hand
[04:10] <salgado> daf, you did that search manually?
[04:10] <salgado> right
[04:10] <salgado> but it's still a bug. I'll file one
[04:10] <daf> ok
[04:12] <carlos> cprov: hi, how are going your soyuz tests?
[04:13] <cprov> carlos: bad bad my tree isn't running in mawson 
[04:13] <carlos> cprov: is there anything I can do to help you?
[04:15] <cprov> carlos: not yet, I'm about to go lunch
[04:15] <cprov> carlos: do you remember how did it got fixed ->   File "/srv/launchpad.net/codelines/uploader-tests/utilities/../lib/canonical/lp/__init__.py", line 69, in registerTypes
[04:15] <cprov>     psycopgda.adapter.registerTypes(psycopgda.adapter.PG_ENCODING)
[04:15] <cprov> TypeError: registerTypes() takes no arguments (1 given)
[04:17] <carlos> cprov: no idea, it's the first time I see that error...
[04:17] <carlos> cprov: I know stub said we need to get an updated psycopgda version, did you update it?
[04:18] <carlos> perhaps it's related to that
[04:18] <cprov> carlos: also psycogda ? ok will try
[04:18] <carlos> I think so
[04:18] <salgado> stub, I have a question for you on my reply to jamesh's error report. might you have some time to look at it? (I forgot to CC you, but it goes to launchpad@ anyway)
[04:21] <cprov> carlos: yes, we need, thanks dude
[04:21] <carlos> cprov: you are welcome
[04:25] <cprov> carlos: so, https://dogfood.ubuntu.com/ is up, it needs some tweaks in the old configuration file, but you can help me collecting some tests to run when I come back from lunch
[04:25] <carlos> cprov: ok
[04:25] <cprov> carlos: do you have anything in mind ?
[04:26] <carlos> cprov: well, first of all we will need pitti's pkgstriptranslations update to test Rosetta integration
[04:26] <carlos> cprov: are you able to install it?
[04:26] <cprov> carlos: let me check
[04:29] <cprov> carlos: I can, we have 2 i386 builders, they also need launchpad-buildd upgrade
[04:29] <cprov> carlos: grab the package from pitti and store somewhere in mawson
[04:29] <carlos> ok
[04:29] <cprov> carlos: back in 1 hour tops
[04:29] <carlos> cprov: will have it ready before you are back
[04:29] <carlos> ok
[04:29] <carlos> ping me when you are ready, please
[04:29] <cprov-lunch> ok
[04:36] <Dimka^> nice channel
[04:41] <ddaa> people are weird sometimes...
[04:48] <daf> carlos: how's that performance work going?
[04:48] <carlos> daf: running test
[04:48] <daf> carlos: excellent
[04:49] <carlos> it's a matter of moving one line from one part of the code to other part
[04:49] <daf> carlos: big diff?
[04:49] <daf> ah, sweet
[04:49] <carlos> yeah
[04:50] <carlos> I'm going to add a couple of extra tests to be sure that the cache values are being updated. I think we don't have such tests
[04:50] <daf> how are you thinking of doing the tests?
[04:50] <daf> doctest or pagetest?
[04:51] <carlos> doctest
[04:51] <daf> ok
[04:51] <carlos> I'm going to expand the import tests
[04:52] <daf> do you think you can get it done today with the tests?
[04:52] <carlos> daf: yes
[04:52] <carlos> that's the plan
[04:52] <daf> great
[04:53] <daf> matsubara-lunch: please ping me when you get back
[04:54] <stub> salgado-lunch: Is this the encoding query?
[05:24] <cprov> carlos: ping
[05:26] <carlos> cprov: pong
[05:26] <carlos> cprov: waiting for pitti
[05:26] <cprov> carlos: ok, ping me back when you have news from him
[05:26] <carlos> cprov: he had an emergency and will take sometime to get it
[05:26] <carlos> cprov: sure, I will ping as soon as I get it
[05:27] <cprov> carlos: ok
[05:31] <kiko> hey hey
[05:35] <carlos> cprov: in the mean time, could you merge from my branch?
[05:35] <cprov> carlos: yup
[05:36] <carlos> cprov: I added the small code change I told you yesterday. It filters any translation import that is not for 'main' component
[05:36] <carlos> to ignore universe uploads
[05:37] <cprov> carlos: makes sense, we do not automaticaly process them.
[05:38] <carlos> you don't automaticaly process universe uploads?
[05:38] <matsubara> daf: ping
[05:39] <daf> matsubara: hey
[05:39] <daf> matsubara: QA meeting?
[05:40] <matsubara> daf: sure
[05:41] <cprov> carlos: we (soyuz) do, you (rosetta) don't ...
[05:41] <carlos> right
[05:49] <carlos> cprov: I suppose you can start your tests without waiting for me or pitti
[05:49] <carlos> cprov: just in case you are blocked by pitti
[05:49] <cprov> carlos: yes, I can, no problem
[05:49] <carlos> we can test Rosetta later
[05:49] <carlos> as it's not going to be used until dapper gets the new version of the pkgstriptranslations
[05:52] <cprov> carlos: not really. Are you sure we won't have troubles related to your changes, I need to release soyuz ASAP
[05:52] <carlos> cprov: no, my changes are not going to be executed until pkgstriptranslations is not updated
[05:53] <carlos> so they will not cause any problem to you
[05:53] <cprov> carlos: I suppose it won't do anything if we don't have the extra translation file in the changesfile, isn't it right ?
[05:53] <carlos> anyway, I want to test them today
[05:53] <carlos> cprov: right
[05:53] <cprov> carlos: ok, let's hope the best ;)
[05:53] <carlos> but I don't want to block you on this if pitti is not able to provide me the package today
[05:54] <daf> carlos: don't try to do too many things at once
[05:55] <daf> carlos: get this performance stuff done, then work on the Dapper stuff
[05:55] <lucas> hi
[05:55] <lucas> I'd like to list the opened bugs for a list of packages
[05:55] <lucas> is there something clever to do than :
[05:55] <carlos> daf: while the tests are being executed, I need to do something. Anyway, is just testing it
[05:55] <lucas> fetch https://launchpad.net/distros/ubuntu/+source/flashplugin-nonfree/+bugs-text
[05:56] <lucas> for each bug listed, fetch https://launchpad.net/bugs/<bug>/+text
[05:56] <bradb> lucas: Not possible for a list of packages yet, sorry.
[05:56] <daf> lucas: is there some connection between these packages?
[05:56] <daf> carlos: your new tests are done?
[05:56] <lucas> daf: no
[05:56] <daf> ok
[05:57] <daf> if it was "packages I maintain" or something, then I can see us getting a page for that in future
[05:57] <carlos> daf: yes, but failed due dapper issues
[05:57] <daf> carlos: I don't understand
[05:58] <carlos> daf: dapper gives me errors sometime unrelated to our code
[05:58] <daf> ah
[05:58] <carlos> for instance, this time, /var/lock permissions are broken
[05:58] <lucas> would it be possible to get search filters for https://launchpad.net/distros/ubuntu/+source/flashplugin-nonfree/+bugs-text ?
[05:59] <daf> lucas: that's a good idea
[05:59] <daf> lucas: please file a bug about it
[05:59] <lucas> ok
[06:00] <daf> lucas: maybe write a page on the wiki about what sort of filtering you would like
[06:00] <daf> lucas: what the API would look like
[06:00] <daf> lucas: at the moment, though, I can't see this being implemented very soon
[06:01] <lucas> well, the same as the html search page would be a good start
[06:01] <daf> true
[06:02] <daf> bradb: how difficult is it to turn a form into a BugTaskSearchParams
[06:02] <daf> bradb: i.e. is there code that could be reused
[06:03] <bradb> daf: BugTaskSearchListingView is it. But I'd wait until I land the new bug listings across Malone, because I've done huge refactoring on that, and related, code. It'll be in review queue in about half an hour.
[06:03] <bradb> I've removed about a dozen view classes for one thing. This code was a silly maze of "elegance".
[06:04] <lucas> ok, bug filed
[06:05] <daf> bradb: sounds great
[06:05] <daf> bradb: I noticed recently that most IBugTarget views aren't in bugtarget.py
[06:06] <daf> bradb: perhaps a trivial merge fixing that is in order
[06:06] <daf> bradb: (assuming you haven't already)
[06:07] <bradb> I won't do it this time around, because this patch is ready and needs to land, but can you please file a bug on that so we don't forget to come back to it?
[06:09] <daf> sure -- I was thinking of doing it myself
[06:09] <daf> bradb: by the way, matsubara and I that Malone's untriaged bug count is up recently -- ok if we give that some atention?
[06:10] <bradb> daf: I'm way behind on bugmail, sadly. WAY behind.
[06:11] <daf> I know you and Bjorn are usually very good on giving Malone bugs love
[06:11] <daf> but I also know you're both really busy right now :)
[06:11] <carlos> daf: poimport.txt test pass. Running all tests to be sure
[06:11] <bradb> daf I had the impression that you and matsubara are meant to triage bugs, but maybe I misunderstood.
[06:11] <daf> carlos: find a reviewer while the tests are running
[06:12] <daf> bradb: we've been focusing on LP bugs up to now
[06:12] <bradb> ah
[06:12] <daf> things are shaping up there, so we're expanding our horizons
[06:12] <bradb> If you guys could so some Malone triaging, that'd be great. :)
[06:12] <daf> cool
[06:14] <daf> lucas: oh, you're *that* lucas!
[06:15] <lucas> *that* ? ;)
[06:16] <bradb> daf: Can I expect, from your triaging efforts, that I'll get poked about high priority Malone bugs? In an ideal world, it'd be nice to semi-ignore bugmail during some periods, but know that 1. users are still getting timely responses to their reports and 2. I'm not ignoring anything critical.
[06:16] <daf> lucas: yeah, I sponsored you for a while
[06:16] <lucas> ah yes :)
[06:17] <daf> bradb: are you saying you'd like to get poked about high priority stuff?
[06:17] <daf> lucas: how are you?
[06:17] <lucas> fine. I got quite heavily involved in debian's pkg-ruby-extras team and am now working on ruby packages in ubuntu
[06:18] <bradb> daf: yeah, particularly from the bug reports, since I'm aware of high priority stuff that doesn't necessarily come directly from a bug that was filed.
[06:18] <daf> lucas: cool
[06:18] <kiko> daf, I understand what bradb is talking about
[06:18] <kiko> he wants /us/ to bug him about bugmail
[06:19] <kiko> that he needs to attend to
[06:19] <kiko> I think that's okay
[06:19] <daf> ok, just confirming that
[06:19] <bradb> kiko often does that (like the bug mentioned earlier about changing bug contacts on changing a task's package) which is very useful to be poked about
[06:20] <daf> in that case, I'd like to poke you about bug 31641
[06:20] <Ubugtu> malone bug 31641 in malone "+editstatus page should not render page on post" [Normal,Unconfirmed]  http://launchpad.net/bugs/31641
[06:20] <daf> I think it could potentially reduce the number of +editstatus oopses significantly
[06:21] <bradb> kiko: BTW, I'm submitting the newly-formatted bug listings (across Malone) for review right now. Do you want me to fix bug 29176 this afternoon?
[06:21] <Ubugtu> malone bug 29176 in malone "Changing source package doesn't notify the new bug contact about the change" [Normal,Confirmed]  http://launchpad.net/bugs/29176
[06:22] <kiko> bradb, that'd rock!
[06:22] <bradb> ok, cool
[06:24] <bradb> daf: Is this critical? E.g. does it cause exceptions that appear in our errors report?
[06:25] <bradb> I define "Critical" as "prevents Ubuntu devs from doing their job", more or less
[06:25] <daf> bradb: +editstatus timeouts do appear in our errors report, yes
[06:25] <daf> bradb: Seb got hit by this a lot yesterday
[06:25] <daf> bradb: I'm not saying it's more important than other Malone OOPSes
[06:25] <daf> hmm, that's odd
[06:26] <daf> hitting Reply on a bug mail prompts me to reply to the person who made the change, not the bug
[06:26] <daf> despite the fact that the Reply-To header is there
[06:26] <daf> kiko: does this also happen to you in mutt?
[06:26] <bradb> daf: How does it behave with other mail that uses Reply-To?
[06:27] <daf> ah, it works for bugmail that's not from myself
[06:27] <daf> weird
[06:34] <carlos> cprov: ping
[06:34] <cprov> carlos: pong
[06:34] <carlos> cprov: I have the package from Martin
[06:34] <carlos> but, are you blocked by the postgresql problem ?
[06:35] <cprov> carlos: nop, have the DBs already
[06:35] <carlos> ok
[06:35] <daf> carlos: do you have a reviewer for your performange changes?
[06:35] <carlos> http://people.ubuntu.com/~pitti/packages/
[06:36] <carlos> daf: I'm adding a new test, to test the website changes. My previous ones were only testing the poimports
[06:36] <daf> I see
[06:36] <daf> how are you testing that?
[06:37] <carlos> daf: we already have a doctest for the POFileView class
[06:37] <carlos> so I'm extending it
[06:37] <carlos> I'm simulating a post with a new translation and check that the statistics are updated
[06:38] <daf> kiko: do you think you can insta-review this later today?
[06:38] <kiko> where is the patch?
[06:38] <daf> carlos says it isn't ready yet
[06:38] <daf> but he's promised to finish it today
[06:38] <kiko> I am here
[06:38] <kiko> daf, can you dupe bug 29279?
[06:38] <Ubugtu> malone bug 29279 in rosetta "Rythmbox translation template for croatian" [Normal,Unconfirmed]  http://launchpad.net/bugs/29279
[06:39] <carlos> kiko: it should be ready in less than 30 minutes
[06:39] <daf> kiko: sure
[06:39] <kiko> thanks
[07:00] <Kinnison> ciau all
[07:02] <mdz> ddaa: what is the best practice for registering other people's branches in launchpad?
[07:03] <jblack> mdz: You can just go ahead and do it. We can change the owner later.
[07:03] <mdz> ah, author can be null
[07:08] <carlos> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/filey0I0CF.html
[07:09] <carlos> wow, it's the first time I do a guess of the time that something will take and I use exactly that time...
[07:10] <kiko> carlos, tell me all about this patch
[07:10] <carlos> kiko: this patch uses the information from Steve's email
[07:11] <carlos> kiko: and reduce the number of SELECT COUNTs executed with every translation form submission
[07:11] <kiko> why?
[07:11] <carlos> kiko: also, it adds test to the statistics code that we were lacking and that I added to be sure that I didn't break anything
[07:12] <kiko> when was it executed before, when is it executed now
[07:12] <carlos> kiko: instead of execute it once per entry submitted, we do it once per submit as it's just an update of cached values
[07:12] <kiko> that is a nice thing
[07:12] <kiko> how many queries will it reduce?
[07:12] <carlos> kiko: In theory, in the worst case, from 10 to 1
[07:13] <kiko> and from 2500? :)
[07:13] <carlos> kiko: but I need to debug it a bit more now because Steve's data had 70 executions instead of 10
[07:13] <kiko> mmmm
[07:14] <carlos> kiko: the number of queries executed depend on the number of messages on hte translation form
[07:14] <carlos> by default we have 10 entries
[07:14] <carlos> and only the changed ones executed the count queries
[07:15] <carlos> kiko: hmm well, the right numbers would be 30 to 3 as every call to updateStatistics() has three SELECT COUNT sentences
[07:15] <kiko> that sounds very good
[07:16] <kiko> carlos, and the interface change?
[07:16] <carlos> cprov: I will need to leave in 15 minutes so I think I need to leave the Rosetta integration testing for tomorrow 
[07:16] <carlos> kiko: the lack of tests for that API
[07:16] <carlos> kiko: the interface was not in sync with the implementation
[07:16] <kiko> that makes sense.
[07:16] <kiko> r=kiko
[07:17] <carlos> kiko: btw, didn't we have a way to test that the objects follow the interfaces automatically?
[07:17] <cprov> carlos: just figure out I'm blocked on lack of plpython in mawson's postgres
[07:17] <cprov> carlos: what hell day !
[07:17] <carlos> cprov: oh! so the testing is blocked... ok
[07:18] <carlos> cprov: Could you ping me tomorrow when that's fixed?
[07:18] <cprov> carlos: yes, postgres scream when I run the uploader script
[07:18] <carlos> kiko: ok, thanks
[07:18] <cprov> carlos: of course
[07:18] <cprov> kiko: can you help me ?
[07:18] <kiko> cprov, I need to find znarl or elmo
[07:19] <carlos> cprov: I don't have special powers on mawson...
[07:19] <cprov> kiko: nice, will find what is precisely missing meanwhile
[07:20] <cprov> carlos: ehe, me neither
[07:21] <cprov> kiko: that's the main error -> http://librarian.dogfood.ubuntu.com/1566410/qPRj2bOPXSZz9SYoVy5sPnBskT8.txt. Any clue ?
[07:22] <kiko> cprov, this looks like a bad database restore, to me
[07:23] <cprov> kiko: uhm .. let's talk personally
[07:24] <SteveA> kiko: stage one of oops analysis is done: https://chinstrap.ubuntu.com/~stevea/oops.cgi/2006-02-09/A547
[07:25] <SteveA> next stage is about combining queries that have the same pattern, to tell you the gain from a particular code optimisation
[07:25] <SteveA> but, this will do for now
[07:26] <kiko> wow! that is great!
[07:28] <carlos> SteveA, kiko: btw, Tomorrow morning, I need to start working later than usual (a couple of hours or so), will send an email later
[07:28] <kiko> sure
[07:32] <carlos> SteveA, daf: Merge request sent for the SELECT COUNT changes. I will request a cherry pick of it when I'm back, later today
[07:32] <carlos> see you later
[07:32] <daf> carlos: good job!
[07:34] <daf> yikes, 2813 queries
[07:34] <daf> SteveA: that looks great
[07:34] <kiko> amazing!
[07:35] <daf> SteveA: "same pattern" == "after stripping out constants"?
[07:35] <SteveA> yes
[07:35] <kiko> ah, that makes sense
[07:35] <SteveA> because one optimisation will likely fix them all
[07:35] <daf> yes
[07:35] <daf> when are we expecting CrowdControl, by the way?
[07:35] <SteveA> when it is done
[07:35] <daf> I think that's going to do amazing things for contention
[07:36] <SteveA> i don't think so
[07:37] <kiko> yeah, tbh I don't think so either
[07:38] <kiko> but it will reduce the length and number of queries
[07:38] <SteveA> yes
[07:38] <SteveA> it will have a reasonable effect on all requests
[07:38] <kiko> SteveA, why not order the SQL statements by reps?
[07:39] <daf> rather than by potential time saving?
[07:39] <SteveA> kiko: it is ordered by the projected time saving
[07:39] <SteveA> so you decide how long you want the request to take
[07:39] <kiko> oh. that's not evident
[07:39] <SteveA> work your way down
[07:39] <kiko> make it the first column?
[07:39] <SteveA> and then see how many queries you need to optimize
[07:41] <SteveA> try now
[07:44] <SteveA> what is the password for foo.bar@canonical.com in sampledata?
[07:44] <kiko> test
[07:44] <kiko> it's nice
[07:45] <SteveA> hmm...
[07:45] <SteveA> not working
[07:45] <SteveA> oh, i know why
[07:53] <kiko> cprov, let me look into it
[07:54] <cprov> kiko: on to what ? the error message or in mawson itself ?
[07:55] <kiko> cprov, okay, I think I know what this is
[07:55] <cprov> kiko: tell me
[07:55] <SteveA> kiko: any idea what's up with keyserver.ubuntu.com
[07:55] <SteveA> ?
[07:56] <SteveA> it is not responding for me
 We have a power outage in the DC.  
[07:56] <cprov> SteveA: probably dead 
[07:56] <SteveA> ah
[07:56] <SteveA> this will arse up gpg things in launchpad, of course
[07:59] <kiko> cprov, it appears you're missing the postgresql fti stuff
[07:59] <kiko> is that possible?
[07:59] <kiko> postgresql-contrib?
[07:59] <cprov> kiko: nop, it's installed 
[07:59] <kiko> I wonder if it was installed after your DB was created
[07:59] <kiko> or something in the installation went wrong
[08:01] <cprov> kiko: maybe, don't know
[08:01] <kiko> launchpad_dev=# \df to_tsvector
[08:01] <kiko>                        List of functions
[08:01] <kiko>  Schema |    Name     | Result data type | Argument data types 
[08:01] <kiko> --------+-------------+------------------+---------------------
[08:01] <kiko>  ts2    | to_tsvector | tsvector         | oid, text
[08:01] <kiko>  ts2    | to_tsvector | tsvector         | text
[08:01] <kiko>  ts2    | to_tsvector | tsvector         | text, text
[08:01] <kiko> cprov, try that on mawson.
[08:03] <dooglus> is it possible to submit bug reports to malone by email?  or is that only for comments to existing reports?
[08:04] <kiko> dooglus, yes, new@bugs.launchpad.net
[08:04] <dooglus> kiko: I guess there's some kind of format I need to use?
[08:05] <dooglus> like, how do I specify the package?
[08:05] <bradb> dooglus: https://wiki.launchpad.canonical.com/EmailInterfaceUserDoc
[08:05] <dooglus> thanks
[08:05] <kiko> dooglus, there's a document, but the wiki is down because the DC has been blown up
[08:05] <bradb> er, sorry https://wiki.launchpad.canonical.com/MaloneEmailInterfaceUserDoc, but it appears down, yeah
[08:05] <kiko> back?
[08:05] <bradb> and now up?
[08:06] <bradb> weird
[08:06] <kiko> yeah
[08:06] <dooglus> bradb: is it to be expected that that site has an invalid certificate?
[08:07] <bradb> dooglus: Yeah
[08:09] <dooglus> bradb: it tells me that I need to sign the bug report email with GPG.  I don't have a GPG key, so does that mean I can't report a bug using email?
[08:09] <kiko> correct!
[08:09] <kiko> you can create a gpg key easily
[08:09] <kiko> it is as easy as 1-2-3
[08:10] <kiko> bradb, stop wrapping URLs in your emails...
[08:10] <bradb> It's the magic of Mail.app dude.
[08:10] <kiko> it's the CRAPACITY of mail.app perhaps
[08:10] <bradb> format=flowed is mutt's best friend, I hear
[08:10] <dilys> Merge to devel/launchpad/: [r=kiko]  Reduced de number of times that we update the IPOFile statistics. This is related to the bug #5751 (r3154: Carlos Perell Marn)
[08:10] <dooglus> kiko: I can create a GPG key, but malone won't know it's mine, right?
[08:10] <kiko> cool
[08:11] <kiko> dooglus, just upload it to launchpad, very easy too.
[08:11] <dooglus> kiko: launchpad is a big "503 Service Unavailable".  hence my wanting to use email instead.
[08:12] <kiko> dooglus, we're having a small DC catastrophe, bear with us for a few moments
[08:12] <dooglus> kiko: run out of petrol too?
[08:12] <cprov> kiko: sorry, but i can't access mawson yet
[08:12] <kiko> dooglus, we use gerbils instead of petrol
[08:13] <kiko> yeah, cprov, that's a given
[08:13] <dooglus> kiko: I see.  And who is using the gerbils when you need them?
[08:13] <kiko> apparently Znarl has not fed them for a month and they have gone on strike
[08:14] <kiko> we are playing them a movie with naked gerbilesses to see if they reconsider
[08:14] <dooglus> have you tried electricying the wheels they run in?
[08:15] <kiko> unfortunately that becomes a chicken and egg problem
[08:16] <kiko> Znarl reports there is some progress
[08:50] <ddaa> mdz: if the other person has a launchpad person/account/profile (whatever mpt and SteveA decided was the right terminology), you use that as the branch author. Otherwise, you leave the other NULL.
[08:50] <ddaa> * leave the author NULL
[08:51] <ddaa> BTW, we should arguably set the default author to the registrant when registering on a product.
[08:52] <ddaa> mdz: a shortcut for setting the author is to add branch from the person's profile
[08:55] <Seveas> what's up with lp? The wiki is borking...
[08:55] <Seveas> The authentication database is temporarily unavailable. Anonymous access only.
[08:56] <Seveas> I just lost quite a bit of editwork...
[08:56] <ddaa> Seveas: use the "back" function of browser to get it back
[08:57] <Seveas> that won't work, because wiki uses evil cache headers
[08:57] <Seveas> and of course the authentication db is still offline so it will log you out...
[08:57] <kiko> the DC suffered a kaboom
[08:58] <Seveas> hmm, daf got mad? 
[08:58] <ddaa> what does this ideogram mean?
[08:59] <Seveas>  <-- that one?
[08:59] <ddaa> yes that one
[08:59] <Seveas> silly smiley
[09:00] <Seveas> "tsu"
[09:09] <daf> 
[09:09] <kiko> y tu mam tambien!
[09:09] <ddaa> daf: I think you have network problem...
[09:09] <daf> really?
[09:10] <ddaa> yeah, the last thing you said came out as a bunch of CJK chars ;)
[09:10] <daf> 
[09:10] <daf> that would be a pretty bad network problem
[09:11] <ddaa> kiko: I think his mama does _not_ speak japanese, actually ;)
[09:11] <LarstiQ> 
[09:11] <bradb> asdjlfjalsdasd
[09:11] <LarstiQ> that's probably wrong
[09:12] <daf> you did *what* with your formal coat?
[09:12] <LarstiQ> hehe :)
[09:13] <ddaa> 
[09:13] <bradb> LarstiQ: Apparently that means "My haori viewing hitting position is"
[09:13] <ddaa> at least that's what babelfish says...
[09:14] <bradb>  . <-- Can you file a bug on that please?
[09:15] <daf> "you delightedly file an insect"
[09:15] <ddaa> that does not seem to roundtrip well...
[09:16] <ddaa> "As for you the file doing that insect which you rejoice it may?"
[09:16] <bradb> haha
[09:16] <ddaa> I think that's probably a good test for user interface
[09:17] <ddaa> if the text can roundtrip to japanese in babelfish and still be understandable, it's simple enough...
[09:17] <ddaa> gotta ping mpt about that
[09:28] <Seveas> ddaa, rofl 
[09:31] <Seveas> awesome
[09:31] <Seveas> now that launchpad is back, the back button DOES work 
[09:31] <Seveas> didn't lose any of the edit 
[09:34] <kiko> whee
[09:34] <kiko> launchpad.net is not back however
[09:36] <Seveas> well, enough parts of it for the wiki to work
[09:41] <kiko> BjornT, bradb: has anyone looked at bug 31367?
[09:41] <Ubugtu> malone bug 31367 in malone "Specifying a non-published binary package when filing a bug causes an oops" [Normal,Confirmed]  http://launchpad.net/bugs/31367
[09:42] <kiko> daf, matsubara: is that bug on the radar?
[09:43] <kiko> okay, I see it is
[09:44] <Seveas> ah, launchpad.net must be back too now 
[09:44] <bradb> It's a bug in the Soyuz code, that I saw happening in our sample data too, but I didn't think it could happen in production.
[09:45] <SteveA> kiko: yeah... restarting the keyserver fixed the strange gpg problems
[09:48] <kiko> SteveA, until they happen again :-(
[09:48] <kiko> bradb, a bug in soyuz code? I thought the callsite was to blame
[09:49] <SteveA> cprov: ping
[09:49] <SteveA> kiko: i just added a gpg key for manish (user with the support issue earlier), and *I* got the email to confirm ownership of the gpg key
[09:50] <SteveA> there is something wrong with the gpg code -- it is using the prefered email address of the currently logged in user rather than the prefered email address of the Person we're adding the key to
[09:50] <cprov> SteveA: pong
[09:50] <kiko> SteveA, that bug already exists!
[09:50] <kiko> mdz reported it
[09:50] <SteveA> kiko: oh
[09:50] <SteveA> it should be an easy fix
[09:50] <kiko> yes indeed
[09:50] <SteveA> just a replacement of user for self.context
[09:50] <kiko> and a test!
[09:51] <SteveA> live on the edge!
[09:51] <SteveA> we don't need no stinkin' tests
[09:51] <kiko> jeesus
[09:51] <cprov> SteveA: would you do it or should I ?
[09:52] <SteveA> cprov: not me.  i have crowds to control and oopses to mangle!
[09:52] <cprov> SteveA:  I have the entire soyuz with 100 critical bugs, if it matters :(
[09:52] <kiko> yay, finally fixed bug 6697
[09:52] <Ubugtu> malone bug 6697 in malone "Source package bugs list is missing filter links" [Normal,In progress]  http://launchpad.net/bugs/6697
[09:53] <kiko> I have had that tree open forever!
[09:53] <bradb> kiko: Hm, maybe. When that code was written I'm pretty sure the error message wasn't a convenient NotFoundError like it is now
[09:53] <cprov> SteveA: ok I'll 
[09:53] <bradb> Looks like it got better lately, and even has a doctest now.
[09:54] <ddaa> niemeyer: you around?
[09:54] <kiko> bradb, care to do a drive-by for bug 6697?
[09:54] <Ubugtu> malone bug 6697 in malone "Source package bugs list is missing filter links" [Normal,In progress]  http://launchpad.net/bugs/6697
[09:54] <kiko> you are the best person to do it
[09:55] <ddaa> kiko: care to review by syncher-logging branch?
[09:55] <kiko> ddaa, how big?
[09:55] <ddaa> more than trivial, but not large
[09:55] <kiko> you can try me at least
[09:56] <ddaa> ha, it's actually on BjornT's queue
[09:56] <ddaa> nevermind
[09:56] <kiko> ok
[09:57] <bradb> kiko: Probably best for me to hack the fix for it into my bug listings branch, because otherwise it'll cause conflicts, and the portlet code for the filter links is somewhat different now.
[09:57] <bradb> kiko: Are you using those +bugs-open links and such? Those are gone now.
[09:57] <kiko> bradb, the patch is minimal, though
[09:58] <kiko> https://chinstrap.ubuntu.com/~dsilvers/paste/file0RqVRa.html
[09:58] <kiko> the risk of conflicts is zero
[09:58] <kiko> I don't use any links
[09:58] <kiko> I just make the setup work
[09:59] <kiko> I change no portlet code either
[09:59] <bradb> That patch is about 50% conflicts :)
[09:59] <kiko> really?
[09:59] <kiko> how?
[09:59] <kiko> well, unless you reorganized browser/bugtask.py
[09:59] <kiko> the rest seems pretty safe
[10:00] <kiko> and it should be easy to mimic my changes into your code
[10:00] <bradb> I renamed the portlet into another file and blew away more than half a dozen classes in browser/bugtask.py.
[10:00] <kiko> I don't access the portlet at all
[10:00] <kiko> as I said
[10:00] <kiko> can you read the diff?
[10:00] <bradb> sure, e.g. context/@@+portlet-bugtasklist-mybugs
[10:01] <kiko> oh, you don't mean the file only then
[10:01] <kiko> well
[10:01] <kiko> how about you review, and I commit, and you solve the conflicts making sure this thing still works?
[10:01] <bradb> kiko: sure
[10:01] <kiko> I can probably add a test for the specific portlet, that'd be good.
[10:01] <kiko> you just rename later
[10:02] <bradb> kiko: I also blew away that BugListing stuff, btw.
[10:02] <kiko> I love that
[10:02] <bradb> That code was all way too "elegant".
[10:04] <bradb> kiko: wording:
[10:04] <bradb> +    def _sourcePackageContext(self):
[10:04] <bradb> +        """Is this page being viewed in a distrorelease context?
[10:04] <kiko> okay
[10:04] <kiko> c-n-p job
[10:05] <bradb> Same with the _distroSourcePackageContext method
[10:05] <kiko> yes
[10:06] <kiko> fixed
[10:06] <mdz> SteveA: https://launchpad.net/products/launchpad/+bug/29937
[10:06] <Ubugtu> malone bug 29937 in launchpad "Lies about which email address is being used during GPG verification" [Normal,Confirmed]  
[10:07] <bradb> kiko: other than that, wow, this is most excellent, r=bradb :P
[10:07] <bradb> it's nice to have it consistent
[10:07] <kiko> yeah, the changes are pretty minimal to get it working
[10:41] <kiko> cprov, do you by any chance fix or remove database.SourcePackage.getVersion?
[10:41] <cprov> kiko: no
[10:42] <kiko> can I kill it, or do you use it? it's as broken as can be
[10:43] <kiko> cprov, if you say I can kill it it's gone
[10:43] <cprov> kiko: rely on tests ;) if it breaks UI the fix will write them properly
[10:44] <kiko> okay.
[10:44] <kiko> I like that
[10:44] <cprov> I meant fixer ... whatever
[10:45] <cprov> kiko: Soyuz UI needs it, I'm confident things used in backend have enough/minimal tests
[10:46] <cprov> kiko: oh .. confusing, Soyuz UI needs this process (unsure code stripping) 
[10:46] <kiko> the UI uses getVersion? Only on DSP not in SP
[10:46] <kiko> ah
[10:46] <kiko> okay
[10:46] <cprov> not that broken method 
[10:47] <kiko> mmm
[10:51] <kiko> daf, matsubara: I think bug 5751 is the main rosetta +translate performance tracker.
[10:52] <kiko> can we unprivatize it?
[10:55] <matsubara> Ubugtu: wake up!
[10:57] <matsubara> kiko: there are some code details on the comments, do you think it's a good idea?
[10:58] <kiko> matsubara, I don't really care
[11:00] <matsubara> kiko: should I re-target it to oops?
[11:00] <kiko> sure.
[11:00] <matsubara> done
[11:01] <kiko> I wonder if pqm is alive
[11:02] <kiko> it is
 Ubugtu: wake up! <-- Ubugtu won't show private bugs
[11:18] <Seveas> (He can't even, but that's just a technicality)
[11:19] <lifeless> can he say 'thats a private bug, f*ckoff?'
[11:19] <matsubara> Seveas: I noticed that after I said it.
[11:20] <Seveas> lifeless, he does so in a notice to the caller
[11:20] <lifeless> 'notice' ? whats that ?
[11:21] <Seveas> lifeless, I just sent you one 
[11:21] <Seveas> it's a sort-of private message
[11:22] <lifeless> ah
[11:22] <Seveas> with the difference that most irc clients don't open a new window for it but display it in the active window
[11:22] <Seveas> which is quite useful in this case
[11:22] <lifeless> well
[11:22] <lifeless> irssi puts it on the server window
[11:23] <lifeless> fyi
[11:23] <Seveas> hmm, weird irssi-ness 
[11:23] <lifeless> not weird at all
[11:23] <lifeless> I'd be really pissed off if the server notices about bounces etc came into an active channel
[11:23] <Seveas> it's the only irc client I know that does it that way by defualt 
[11:23] <Seveas> server notices are different
[11:41] <LaserJock> alsa-tools apparently built on 2/3 but the binary pacakges aren't on the repo. Is that a LP or Soyuz problem?