[12:05] <kiko> bradb, well, it currently tracebacks, and that's pretty bad
[12:06] <bradb> kiko: right, i'll file a bug on that. thanks for pointing it out.
[12:06] <bradb> salgado: i'll file a bug on that too. i believe that param used to be used before the search page was deanorakified somewhat.
[12:07] <salgado> bradb, no need. I already fixed
[12:07] <bradb> salgado: awesome! thanks. :)
[12:07] <salgado> and I'm going to add code that uses it and is tested.
[12:08] <bradb> great, much appreciated
[12:10] <salgado> bradb, is there any page in malone which shows the bugs I reported?
[12:10] <bradb> salgado: just the one you created
[12:10] <bradb> i haven't really looked at that page though
[12:10] <bradb> (i say "you created" because it's a FOAF link, but maybe someone else created it, dunno)
[12:11] <salgado> yep, I understood it that way
[12:12] <daf> SteveA: pong again
[12:12] <daf> bradb: no, she doesn't grok the new bugmail format
[12:13] <daf> bradb<EMAIL_ADDRESS>[12:13] <bradb> heh
[12:13] <bradb> is that your way of saying she'll be broken for a while yet?
[12:14] <daf> well, maybe I can fix her tomorrow
[12:14] <daf> but don't count on it
[12:14] <kiko> bradb, tell me, where can I find out all the magical slots in an editform?
[12:14] <bradb> kiko: which editform?
[12:15] <bradb> kiko: in a nutshell, look in bugtask.zcml, for each of the "browser:editform" directives there are two attributes you'll probably be interested in:
[12:15] <bradb> 1. for="..." -- the iface for which this is an edit form
[12:16] <kiko> hmmm
[12:16] <kiko> okay, it's in zope
[12:16] <bradb> 2. fields="... ... ..." the fields of that iface that are available in the form.
[12:17] <bradb> lifeless: hi. might you have a moment to cherrypick an important patch into prod?
[12:19] <kiko> bradb, do you know if the label zcml attribute allows doing ${bug/id}?
[12:19] <bradb> kiko: i don't believe it does allow dynamic content.
[12:20] <bradb> kiko: fwiw, i tried changing the titles too. i've already nagged SteveA about that.
[12:20] <kiko> I've fixed that
[12:20] <kiko> just use the headings slow
[12:20] <kiko> it's not too hard
[12:20] <kiko> slot
[12:20] <bradb> kiko: how do you i18n that?
[12:20] <kiko> in the template?
[12:21] <bradb> kiko: and will maintainers expect that? i expect pagetitles.py.
[12:21] <kiko> oh
[12:21] <kiko> not titles, I'm talking headers
[12:21] <kiko> sorry
[12:21] <bradb> oh, ok, gotcha
[12:22] <sabdfl> mpt: how difficult is it to sort a table when clicking the table header?
[12:22] <kiko> sabdfl, what do you mean by "difficult"?
[12:23] <sabdfl> kiko: as in, is it something we can easily add to a table?
[12:23] <kiko> you need to submit a get variable, pick that up, reissue the query, display the results, store the last sort in a variable.
[12:23] <kiko> oh
[12:23] <sabdfl> no, it's possible to do it all in JS
[12:23] <kiko> you mean client-side sorting
[12:23] <sabdfl> yes
[12:23] <kiko> well, that won't take into account differences between display and storage
[12:23] <bradb> how does that work with paging?
[12:23] <kiko> I don't know if that is a showstopper or not
[12:24] <sabdfl> i'm thinking of places where we don't use paging
[12:24] <sabdfl> like the lists of languages with translation
[12:24] <sabdfl> https://launchpad.ubuntu.com/distros/ubuntu/hoary/+lang/ca
[12:25] <kiko> bradb<EMAIL_ADDRESS>is ready for you
[12:25] <kiko> it fixes about 10 bugs
[12:25] <kiko> and does some UI fixage with it
[12:25] <kiko> enjoy
[12:25] <kiko> add tests please
[12:25] <bradb> kiko: do all of them need tests?
[12:26] <kiko-afk> kthxbye
[12:26] <kiko-afk> ;)
[12:26] <kiko-afk> nah, just one or two
[12:26] <bradb> heh, ok
[12:26] <kiko-afk> you'll see the code changes
[12:26] <kiko-afk> they are the ones that need testing
[12:27] <bradb> kiko-afk: ok if i look at it tomorrow then?
[12:27] <kiko-afk> sabdfl, it's some tricky JS to sort, but there may be some ready-made stuff we can just plug it in
[12:27] <kiko-afk> bradb, of course
[12:27] <bradb> kiko-afk: thanks
[12:33] <bradb> lifeless: when will the day come that i'm going to be able to ask baz to tell me all of my branches which have patches missing from rf, and which patches those are? i'm currently actively working on six different branches, and have occassionally found myself simply losing track (before i was forced into tracking this info in a text file.)
[12:34] <bradb> (er, make that seven; i'm branching again to do a sampledata change on the sixth branch i'm working on)
[01:07] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Fix BugTaskSet.search() (just one argument that was not consistent with the column name it should be matched) and add code that uses the fixed part to make sure it's tested. (patch-2088<EMAIL_ADDRESS>[01:39] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  fix presentation details for coc pages, pagetest added. (patch-2089<EMAIL_ADDRESS>[01:44] <kiko-afk> sabdfl, http://www.kryogenix.org/code/browser/sorttable/
[01:46] <sabdfl> thanks!
[01:47] <kiko-afk> that's a quite nice implementation we could borrow
[01:48] <sabdfl> very
[01:52] <kiko-afk> hah
[01:52] <kiko-afk> sabdfl, it works already :-)
[01:52] <kiko-afk> man that was pretty easy
[01:52] <kiko-afk> @@ -5,6 +5,10 @@
[01:52] <kiko-afk>
[01:52] <kiko-afk>
[01:52] <kiko-afk>
[01:52] <kiko-afk> +<metal:head fill-slot="head_epilogue">
[01:53] <kiko-afk> +
[01:53] <kiko-afk> +</metal:head>
[01:53] <kiko-afk> +
[01:53] <kiko-afk>  <metal:leftportlets fill-slot="portlets_one">
[01:53] <kiko-afk>

[01:53] <kiko-afk>  </metal:leftportlets>
[01:53] <kiko-afk> @@ -22,7 +26,7 @@
[01:53] <kiko-afk>      Select a template name to begin translating immediately!
[01:53] <kiko-afk>

[01:53] <kiko-afk>
[01:53] <kiko-afk> -

[01:53] <kiko-afk> +

[01:53] <kiko-afk>

[01:53] <kiko-afk>        Source
[01:53] <kiko-afk>        Template Name
[01:53] <kiko-afk> sabdfl, r=sabdfl? :-)
[01:53] <mpt> wait
[01:54] <mpt> Did you hack sorttable.js to look for translationstatuses?
[01:54] <kiko-afk> ;)
[01:54] <kiko-afk> nope
[01:54] <kiko-afk> no hacking involved
[01:54] <mpt> It looks for any table with an id?
[01:54] <kiko-afk> I'll post the diff and file to launchpad-list
[01:54] <kiko-afk> I think so
[01:54] <kiko-afk> you be the judge in 2m
[01:54] <mpt> What's the license?
[01:54] <mpt> MIT
[01:55] <kiko-afk> right
[01:55] <mpt> ah, cool, we can use it while still being non-Free, and relicense it however
[01:56] <cprov> night guys
[01:56] <mpt> kiko-afk: So you should have class="listing sortable", right?
[01:57] <kiko-afk> mail sent
[01:57] <kiko-afk> oh, I didn't change the class -- it still works :)
[01:59] <kiko-afk> wow
[01:59] <kiko-afk> it actually /does/ support dates
[02:02] <kiko-afk> mpt, send me your passport number
[02:02] <kiko-afk> NOW
[02:23] <mpt> muwahahaha
[02:28] <mpt> that sorting won't work for any list of more than 20 bugs
[03:30] <jamesh> mpt: were you working on Facet code for any of the other LP objects than IProduct?
[03:30] <mpt> jamesh: no
[03:30] <jamesh> okay.
[03:46] <mpt> oh, the sorting doesn't need to work for bugs, duh
[03:50] <jamesh> stub: ping?
[03:52] <stub> jamesh: pong
[03:54] <jamesh> stub: with one of the branches I've got in review at the moment, the issue of the Person.timezone default value came up
[03:54] <jamesh> stub: would setting the default for that column to the string 'UTC' be a problem, or would you prefer to have it NULL when it hasn't been explicitly set?
[03:55] <stub> I have no preference one way or the other. Do whatever makes the code most readable.
[03:55] <jamesh> okay.  That'd be to set the column to 'UTC' then.
[04:54] <jamesh> so "baz build-config" has a --update flag now
[04:54] <jamesh> should make using configs less painful
[06:19] <dilys> Merge to<EMAIL_ADDRESS>Remove obsolete code from the librarian, expand zopeless transaction tests a little, remove redundant begin from Librarian test tearDown.  r=SteveA. (patch-2090<EMAIL_ADDRESS>[06:45] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  fix product links in portal when used on product page (patch-2091<EMAIL_ADDRESS>[07:10] <dilys> Merge to<EMAIL_ADDRESS>Cherry pick patch-2074 into production (patch-2<EMAIL_ADDRESS><EMAIL_ADDRESS>[08:35] <stub> lifeless: pqm has hung
[08:53] <BjornT> hi stub
[08:54] <BjornT> what's the ETA for turning on the email interface?
[08:58] <stub> Launchpad needs an update before we can do that, hopefully I can get onto it today after I finished this review.
[08:58] <BjornT> cool, thanks
[08:58] <stub> BjornT: There is no way to configure it at the moment without manually hacking script.zcml, because scripts don't process .zcml overrides
[09:03] <jamesh> mpt: I was working on some facet menus for people and projects, and had a question.
[09:04] <jamesh> mpt: there currently isn't a URL for "bugs associated with this project", so do you think the link should be disabled, or point at "/malone", or not appear?
[09:05] <BjornT> stub: well, can't you put it in package-includes? it's nothing that gets overridden
[09:05] <mpt> jamesh: Ideally disabled, but I don't think the menus system supports that at the moment
[09:05] <mpt> jamesh: So point it to /malone, and report a bug that /projects/whatever/+bugs should exist
[09:05] <jamesh> mpt: it was about 5 lines to add support for disabled facet menu links
[09:05] <mpt> cool
[09:05] <jamesh> mpt: I've got it disabled in my branch currently.
[09:06] <mpt> So it appears as plain text, not linked, right?
[09:06] <jamesh> yeah
[09:07] <jamesh> same colour as the other non-highlighted links but no underline
[09:07] <jamesh> it'd be trivial to set the colour different, of course.
[09:07] <mpt> ok, I might twiddle that style later
[09:07] <stub> BjornT: I guess, but it will be blown away each rollout.
[09:07] <BjornT> stub: oh, ok
[09:10] <BjornT> spiv: ping
[09:11] <spiv> BjornT: pong
[09:11] <SteveA> hi
[09:11] <sabdfl> hi all
[09:12] <SteveA> jamesh: how did you add disabled facet menu links?  i'm doing some work on that at the moment.
[09:12] <BjornT> spiv: i have some problems with sqlobject. i'd like to select distinct bugtasks, while ordering them on some external table column like Bug.id. but it doesn't work since Bug.id isn't in the SELECT list.
[09:13] <jamesh> SteveA: just added a "linked" argument to the Link() constructor, and edited the page template to not generate an  tage for items with linked=False
[09:13] <SteveA> jamesh: i am introducing an explicit default state for the linked and selected properties, so that the menus system can know if a link is explicitly linked or unlinked, or just not yet set up
[09:13] <SteveA> jamesh: setting linked to False in the link constructor works kind of by accident :-)
[09:13] <spiv> BjornT: Hmm.
[09:14] <SteveA> i want to make it work on purpose
[09:14] <BjornT> spiv: it works if i don't set distinct=True
[09:14] <SteveA> i have an addition to facet menus that makes it easy to include menus from higher-up facet menus
[09:14] <SteveA> jamesh, mpt: do you think we need a 'disabled' property in links?
[09:15] <SteveA> at the moment, with james' addition, the linked property is used in two cases
[09:15] <mpt> SteveA: Since most things won't have their own calendars, yes.
[09:15] <SteveA>  1. when you're on the same page as a menu link would link to
[09:15] <SteveA>  2. when the thing the link points to is unavailable
[09:15] <SteveA> would you want to visually distinguish between these?
[09:16] <jamesh> SteveA: my code is at<EMAIL_ADDRESS>[09:16] <SteveA> thanks james
[09:16] <jamesh> SteveA: it also adds a calendar facet
[09:16] <SteveA> cool
[09:16] <spiv> BjornT: I think I know how to fix this.
[09:16] <mpt> SteveA: Definitely. Otherwise on a few pages it would appear as if there were two active facets.
[09:16] <jamesh> do you want me to put it up for review, or do you want to handle this?
[09:17] <BjornT> spiv: cool. how? :)
[09:17] <SteveA> jamesh: add it to my review queue.  i'll either merge it as is, or merge it into my menus branch.
[09:17] <jamesh> okay
[09:17] <spiv> BjornT: by explicitly distincting on only columns from the relevant table.
[09:18] <SteveA> spiv: did you make sqlobject make transactions obsolete on commit now?
[09:18] <spiv> BjornT: Or rather, by explicitly doing DISTINCT ON (Foo.id) rather than just DISTINCT.
[09:18] <spiv> SteveA: It's just been submitted to pqm.
[09:19] <SteveA> mpt: not so... one would be selected and unlinked, the other would be unselected and unlinked.
[09:19] <SteveA> mpt: but, maybe you want to make it more specific
[09:19] <SteveA> um, explicit
[09:19] <mpt> o i c
[09:19] <SteveA> spiv: cool.  once that's in, i'll try removing some of my sqlos hacks.
[09:20] <mpt> SteveA: All other things being equal, I'd prefer whatever approach didn't produce ambiguous combinations of properties
[09:21] <SteveA> mpt: fair enough.  i'll think about this a bit.
[09:21] <SteveA> mpt: can you give names to the different kinds of links we have?
[09:22] <SteveA> then, i could make an API specifically for displaying them
[09:22] <SteveA> for example
[09:22] <SteveA>  - disabled links
[09:22] <SteveA>  - current link (which might be linked or unlinked, depending on the current page)
[09:22] <SteveA>  - available non-current link
[09:23] <SteveA> in fact, those may be the only three you care about
[09:23] <mpt> that's pretty much it
[09:23] <jamesh> on my branch those are represented as (1) selected=False, linked=False, (2) selected=True and linked=True or False, (3) selected=False, linked=True
[09:24] <SteveA> right
[09:24] <spiv> BjornT: Hmm, actually, I think I need to fix it differently.  Anyway, I'll work on it :)
[09:24] <SteveA> so, we can just add a wrapper around an ILink before it gets to the page template
[09:25] <SteveA> that processes these combinations of properties into something convenient for the template to use
[09:25] <SteveA> for example:  tal:condition="link/type-is/disabled"
[09:25] <SteveA>  tal:condition="link/type/is-disabled" maybe
[09:26] <SteveA> something like this would make the page template sections to display links very easy to read and write
[09:26] <BjornT> spiv: really? it seemed to work with having all order-by columns and all select columns in a distint on(...).
[09:26] <BjornT> spiv: thanks for doing it, let me know how it goes :)
[09:27] <spiv> BjornT: Oh, good.  I'm still fiddling with making a proper sqlobject test case for it, once I have that I can stop guessing ;)
[09:48] <BjornT> SteveA: i've removed the database imports, that you told me to fix yesterday. do you want to take a quick look at it?
[09:48] <SteveA> sure, be glad to
[09:52] <spiv> BjornT: Actually, I'm confused.
[09:52] <spiv> BjornT: If you want to order bugtasks by Bug.id, isn't that the same as ordering them by BugTask.bug?
[09:53] <BjornT> spiv: ok, bad example :) let's say that i want to order by SourcePackageName.name instead
[09:54] <spiv> Ok, that's less crazy ;)
[09:55] <BjornT> SteveA: ok, sent you the diff by mail
[09:57] <SteveA> BjornT: I wonder about the bugtaskdelta
[09:57] <SteveA> what if it worked like this:
[09:57] <SteveA>  delta = IDelta(some_bug_task)
[09:57] <SteveA>  delta.setDifference(... various kw args)
[09:57] <SteveA> just an idea, don't know if it is better or not
[09:59] <SteveA> is there any test for BugDelta and BugTaskDelta?
[09:59] <SteveA> it would be good to have a test that just imports the classes, and instantiates them, as a minimum
[09:59] <SteveA> other than these comments, it looks good
[10:03] <BjornT> SteveA: there are some tests in bugnotification-email.txt. your suggestion is an improvment, but it's not something i want to spend time on doing right now.
[10:04] <SteveA> okay.  will you file a bug for doing it?
[10:17] <BjornT> SteveA: ok, i'll file a bug about it
[10:48] <spiv> BjornT<EMAIL_ADDRESS>should fix distinct for your case.  Want to try it out?
[10:49] <BjornT> spiv: thanks. sure, i'll try it out
[10:53] <rob^> hi, I have forgoten my password for the Ubuntu wiki, attempting to recover it asks me to use Launchpad to do so, however it doesn't change the wiki password only Launchpads
[10:53] <rob^> any ideas on what I'm doing wrong?
[10:55] <spiv> rob^: The ubuntu wiki uses the launchpad user database.
[10:55] <rob^> yes thats what I thought
[10:56] <spiv> rob^: So you should be able to use your launchpad login and password.
[10:57] <rob^> ok that works, but why did I sign up with a different username initially?
[10:58] <rob^> and its linked the accounts?
[11:02] <spiv> When the Ubuntu wiki was originally using Moin, it had its own user database and wasn't linked to anything.  We moved the content over to zwiki on www.ubuntu.com, which used launchpad logins, and more recently we moved the content back to moin, but still using the launchpad user database... so unless you signed up to edit the wiki before the original move to zwiki, the username shouldn't have changed.
[11:04] <rob^> maybe
[11:04] <spiv> Well, bugs do happen :)
[11:04] <rob^> yeah :)
[11:08] <rob^> thanks
[11:09] <mpt> SteveA/sabdfl: To what sort of places will the Rosetta 1.0 announcement be distributed?
[11:10] <sabdfl> mpt: as widely as possible
[11:10] <sabdfl> hopefully /.
[11:10] <mpt> ok
[11:10] <SteveA> various blogs, i expect
[11:10] <mpt> I'll put in a paragraph about what Rosetta actually is, then ;-)
[11:11] <sabdfl> mpt: guuuuurd thinkin'!
[11:13] <mpt> When is the launchpad.ubuntu.com --> launchpad.net switchover scheduled?
[11:32] <BjornT> spiv: your fix almost work. please add a test where you're ordering descending, and make it pass as well
[11:32] <spiv> Ah, good point :)
[11:36] <stub> mpt: As soon as I can get some elmo time.
[11:36] <mpt> ok
[11:37] <mpt> because if Rosetta 1.0 is released and everything's still pointing at launchpad.ubuntu.com, that could be a lot of Googlejuice down the drain
[11:39] <stub> Indeed - we should not make announcements until it is sorted
[11:47] <Burgundavia> mpt, you going to fix that cert issue as well?
[11:50] <stub> Which one? I don't think there is a single valid certificate on *any* of our systems ;)
[11:51] <stub> Its been on the todo list for ages - hopefully we get a real one now we have a final domain.
[11:52] <Burgundavia> yes, that one
[11:55] <jamesh> could file a bug in malone to get an Ubuntu CA cert added to the mozilla-firefox package
[11:55] <jamesh> that'd fix it
[11:55] <Burgundavia> that is a hack
[11:56] <Burgundavia> and non-ubuntu people are going to be using rosetta
[11:56] <jamesh> as opposed to all the other CA certs preloaded in Firefox?
[11:58] <Burgundavia> hmm
[11:58] <Burgundavia> but the 2nd point still stands
[12:08] <SteveA> jamesh: and then, you'd mark it as a security vulnerability so that it gets to existing browsers as a security update ;-)
[12:08] <SteveA> i don't think that'll fly with the distro folks
[12:09] <Kinnison> It's not like it's that expensive for a certificate
[12:10] <Kinnison> Pepperfish buy theirs in 2 year chunks for 89 US$
[12:10] <stub> Before anyone submits a bug, clear it with Mark. He might be restricted from reentering the certificate market (and this might be considered just that)
[12:11] <stub> We already are supposed to have real certificates - approved and everything. Just it never actually happened.
[12:23] <mpt> Burgundavia: A couple of years ago I reported a bug that Mozilla should be shipped with no CA certs by default :-)
[12:24] <SteveA> what was the answer to that?
[12:24] <mpt> I was wrong
[12:24] <mpt> As long as SSL works the way it does, you have to trust your browser vendor to trust CAs to trust organizations
[12:25] <mpt> It's very awkward and not very trust-*worthy*, but nuking the list wouldn't fix anything
[12:26] <mpt> (or rather, you have to (1) trust your browser vendor to (2) trust CAs to (3) trust organizations to (4) trust the competence+honesty of their Webmasters)
[12:37] <JanC> if verisign is still giving certs like they did 4-5 years ago, anybody can get a cert for about every domain name...
[12:38] <JanC> so I don't trust certs except for self-signed certs that I can check with the site author  :-P
[12:38] <mpt> Right, and Verisign is in the default CA list for major browsers, which prompted my bug report
[01:15] <cprov> morning guys
[01:15] <Kinnison> Hi cprov
[01:16] <cprov> hi there
[01:19] <stub> spiv: http://librarian.ubuntu.com is supposed to be the librarian, isn't it?
[01:19] <spiv> iirc, yes.
[01:22] <cprov> stub: didn't you cherry pick the RF-2089, fix for CoC pages, into production ?
[01:22] <stub> cprov: I did
[01:23] <jamesh> cprov: it is second in the pqm queue
[01:23] <stub> I rolled out a branch instead of the rocketfuel one because pqm is blocked
[01:23] <cprov> stub: jamesh : ohh ok ... thank you for instance
[01:24] <jamesh> cprov: ssh into chinstrap and run "lynx http://localhost:8000"
[01:26] <stub> spiv: Don't worry. User error.
[01:27] <cprov> jamesh: absolutely cool ... also including some missed "-----BEGIN PGP SIGNED MESSAGE-----", which produce fun anyway ;) external access restricted to pass or certificates ETA ?
[01:28] <jamesh> cprov: I think that's just the head of the message sent to PQM (which is a just a PGP blob).  lifeless would know.
[01:29] <stub> BjornT: email gateway is cronned up and running. It produced no output when I ran it, which I suspect means it is either working correctly or very broken.
[01:29] <lifeless> cprov: thanks :)
[01:29] <Kinnison> Do we not get dilys reporting baz bugs here any more?
[01:30] <lifeless> cprov: yes, thats the first line of the saved message, I have not (yet) made the lines() method determine gpg wrapping vs commands.
[01:30] <lifeless> stub: pqm is unblocked
[01:30] <stub> lifeless: You can kill that current pqm job to speed things up - a later merge will take it
[01:30] <lifeless> stub: ok
[01:30] <cprov> jamesh: yeah, it doesn't hurt and it is the only effort I can see to have RT PQM feedback
[01:31] <lifeless> if anyone wants to hack on the twisted ui, its just arch_pqm/ui/twisted.py
[01:31] <lifeless> still in the review queue IIRC ;0
[01:31] <BjornT> stub: it should mean that it works. i'll try it out
[01:33] <cprov> lifeless: I'll look but I can't garantee any it'll be fast, If you don't mind ...
[01:33] <stub> BjornT: It is running every three minutes
[01:34] <lifeless> cprov: ;)
[01:34] <lifeless> cprov: it was a quick hack I could do that wasn't reinventing the wheel nor spamming everyone.
[01:35] <lifeless> cprov: I'm going to put it up on pqm.ubuntu.com when I finally track elmo down.
[01:36] <cprov> lifeless: fantastic, It has been my dream since the very begining, pqm will rock  soon.
[01:37] <lifeless> yay
[01:37] <lifeless> probably the biggest thing would be a patch to the main script to timeout and reap all its children with increasing severity after X minutes with no output
[01:40] <Kinnison> stub: Can you see what's up with the pg backups on mawson, it's all stuck solid right now
[01:40] <cprov> lifeless: althrough it's not as selective as we expected, but I suspect it solves most of pqm human interation needs
[01:42] <Kinnison> Anyone here know what I need to put in my .vimrc to make it break hardlinks by default?
[01:45] <spiv> set backupcopy=breakhardlink,auto
[01:45] <Kinnison> and 'vi foo.c' will use .vimrc, it's not mad or anything?
[01:47] <stub> Kinnison: Bounced it all
[01:48] <Kinnison> stub: thanks
[01:48] <Kinnison> cprov: did that fix it?
[01:48] <spiv> Kinnison: I believe so, but my fingers are trained to always type "vim" :)
[01:49] <Kinnison> spiv: *grin*
[01:50] <cprov> Kinnison: stub: mawson pg* are fixed ? what did go wrong ?
[01:51] <lifeless> Kinnison: fl-cow
[01:51] <lifeless> Kinnison: please.
[01:51] <stub> Dunno. I just bounced it. mawson has locked before with no logs or hints, but I havn't seen it happen elsewhere and am not particularly bothered.
[01:51] <lifeless> Kinnison: as various $tools are NOT LINKSAFE
[01:51] <lifeless> Kinnison: link, for instance, AUTOCONF.
[01:52] <spiv> lifeless: like bicyclerepair? ;)
[01:52] <lifeless> spiv: dunno, probably not.
[01:52] <lifeless> spiv: file a bug ;-0
[01:52] <spiv> :)
[01:54] <Kinnison> lifeless: fl-cow?
[01:54] <lifeless> Kinnison: yes
[01:54] <Kinnison> what's that?
[01:54] <lifeless> LD_PRELOAD library to break links in a subtree automatically.
[01:55] <Kinnison> cute
[01:55] <lifeless> its in debian. should be in breezy
[01:55] <Kinnison> lunch for now... my adventures with 'baz diff --link' will be suspended until I have time to investigate that
[01:55] <BjornT> stub: it doesn't seem to work. do you see some error messages somewhere? if not, i'll make it more noisy, so it's easier to see what's going on.
[01:57] <lifeless> Kinnison: its easy ;0
[01:58] <stub> BjornT: No output. Subscribe to the topic I've just set up in launchpad-error-reports@, or monitor the list archive. But it needs noise ;) I suggest using canonical.launchpad.scripts.logger_options and canonical.launchpad.scripts.logger so it is easy to switch on or off
[01:59] <stub> (actually - I think I already changed that in my cronscripts branch up for review....
[02:00] <stub> BjornT: So feel free to review<EMAIL_ADDRESS>and merge it into your branch, which might make both our lives easier ;)
[02:01] <BjornT> stub: ok, i'll take a look at it :)
[02:04] <BjornT> although, first it's time for some lunch...
[02:09] <cprov> stub: btw, was the permission to create DB for the user launchpad in DF removed ?
[02:10] <stub> I don't remember
[02:12] <cprov> stub: could repair it to me ?
[02:13] <stub> cprov: I've granted access to create databases to the 'cprov' PostgreSQL user.
[02:13] <cprov> stub: better, thanks
[02:15] <cprov> stub: oops -> permission denied to copy database "launchpad_dogfood", ehe only create isn't enough I want real data for tests, could you arrange it too ?
[02:16] <stub> cprov: You can't copy that database because it is inuse anyway...
[02:17] <stub> I'm creating a dupe
[02:18] <cprov> stub: err, fine ;)
[02:22] <sabdfl> SteveA: is it possible to define a view on a request?
[02:22] <sabdfl> carlos: any excitement or response to the announcement?
[02:23] <SteveA> sabdfl: basically, yes.  it is a little bit odd though.  what do you want it for?
[02:23] <sabdfl> the portlets for the browser languages, and country languages
[02:24] <sabdfl> currently, each place that wants those needs some crappy View class bits
[02:24] <sabdfl> minor
[02:24] <SteveA> so you want to say request/@@some_portlet
[02:24] <sabdfl> be cleaner to go

[02:24] <sabdfl> yes
[02:25] <SteveA> so, the information for them comes only from the request?
[02:25] <sabdfl> with a little help, yes
[02:25] <SteveA> technically speaking, these are "resources" not "pages"
[02:25] <SteveA> just like an image or a style sheet
[02:25] <sabdfl> ok
[02:25] <SteveA> but, i think it would be as easy to define a view
[02:25] <sabdfl> but, it's a view on a context object, just the context is the request :-)
[02:25] <SteveA> because that's what people maintaining the portlets would expect
[02:26] <SteveA> views depend on two things:
[02:26] <SteveA>   the context
[02:26] <SteveA>   the request
[02:26] <SteveA> so, registering this as a view on the request, you're making it depend on
[02:26] <SteveA>   the request
[02:26] <SteveA>   the request
[02:26] <SteveA> workable, but a bit odd
[02:26] <SteveA> you could register them for Interface
[02:26] <SteveA> and then ignore the context
[02:26] <sabdfl> i suppose it could be registered for any context
[02:26] <sabdfl> snap
[02:26] <SteveA> right
[02:27] <sabdfl> and then i could still have a view class?
[02:27] <sabdfl> of course
[02:27] <SteveA> yes
[02:27] <sabdfl> i'll try that
[02:27] <stub> cprov: There is now a launchpad_dogfood_dupe database, and you should be able to duplicate it for your tests
[02:27] <sabdfl> where would you want to see the zcml, view class?
[02:27] <SteveA> i think the most easy to understand is registering them for zope.interfaces.Interface
[02:27] <SteveA> they are to do with displaying countries / languages
[02:27] <SteveA> so with those
[02:28] <SteveA> mpt: ping
[02:29] <SteveA> mpt: i've just finished the initial linkification stuff.  i think one part of your linkification example has revealed a bug in the general DPoT code.
[02:29] <SteveA> but i need some help seeing if it is so.
[02:34] <lifeless> oh, the baz branch name is now missing from product series
[02:34] <lifeless> :[
[02:34] <lifeless> https://launchpad.ubuntu.com/products/evolution-data-server/+series/main
[02:36] <lifeless> SteveA: zope3 runs out of memory : https://macquarie.warthogs.hbd.com/roomba/status/zope-zope3/events/61/log
[02:37] <lifeless> SteveA: I'll need to track down why, but it takes several days to get there, so it will be  along sidereal time
[02:37] <SteveA> ah, you mean that importing zope3 runs out of memory
[02:38] <lifeless> SteveA: yes
[02:38] <kiko-zzz> SteveA, what do I need to do to make a js file accessible via /@@/foo.js?
[02:38] <SteveA> for a second i thought you meant that some zope3 process was running out of memory
[02:38] <SteveA> kiko-zzz: wake up
[02:38] <SteveA> kiko-zzz: you register it as a resource
[02:38] <kiko> where?
[02:38] <lifeless> ddaa: ping
[02:38] <SteveA> in some zcml.  i wonder where the rest are registered...
[02:38] <kiko> I can't find where launchpad.js is registered...
[02:39] <ddaa> lifeless: pouet
[02:39] <kiko> found it
[02:39] <lifeless> ddaa: could you look at https://macquarie.warthogs.hbd.com/hoover/status/evolution-evolution-data-server-main/events/84/log as you know the incremental chatter stuff
[02:39] <lifeless> ddaa: we have a request from upstream
[02:39] <SteveA> lifeless: does the importer handle the svn:externals stuff that zope3 users?
[02:39] <SteveA> um, uses
[02:40] <ddaa> Mh... looks like there's one more loop that lacks chatter...
[02:40] <ddaa> lifeless: Tomorrow is a national holiday
[02:40] <ddaa> lifeless: and friday I'll be mostly busy packing up for barzil
[02:41] <ddaa> (taking off on friday night)
[02:41] <lifeless> ddaa: right.
[02:41] <lifeless> ddaa: if you can, please. I'll set an expectation of not-immediately though.
[02:41] <ddaa> Since pybaz archivelocation is not yet quite complete, but could probably be completed before barzil if I can single-mindedly focus on it
[02:42] <ddaa> there's a choice to be made there
[02:42] <ddaa> Your choice.
[02:42] <lifeless> location first
[02:43] <ddaa> Okay. The chatter thing is probably not very complicated. Will probably be easy to figure out early next week.
[02:43] <ddaa> (maybe do it before if I need a diversion, but the expectations are set)
[02:43] <lifeless> k
[02:44] <ddaa> btw, what are the news out there?
[02:45] <ddaa> I have had my head dug into pybaz for a few days, so there might be something worth telling me about.
[02:46] <ddaa> apparently not :)
[02:46] <lifeless> uhm
[02:47] <carlos> sabdfl, only the request from Quim
[02:47] <lifeless> tom has released an arch 2.0 prototype
[02:47] <ddaa> lifeless: hu?
[02:47] <lifeless> I'm optimising the heck outta the baz 1.5 tree structure
[02:48] <ddaa> baz cool... I really can't wait for the new inventory stuff to shut off those launchpad whiners ;)
[02:49] <jamesh> then we'll just whine about the size of the metadata being carried around in the tree :)
[02:50] <ddaa> revc... bah... I think I lost all interest in tomlord's doings. And TBH I do not have much residual interest left in other RCS issue. Maybe it's just a phase, but they way things are evolving is a bit depressing.
[02:50] <lifeless> jamesh: if I patch branch to do good headers, do you want to find the regressions it triggers;0
[02:50] <lifeless> jamesh: it is on the queu.
[02:51] <jamesh> "do good headers"?
[02:51] <ddaa> stop the metadata bulk from growing insanely
[02:51] <lifeless> jamesh: the metadata problem is O(n^2) growth
[02:51] <jamesh> so it wouldn't list the entire patch history in base-0 revisions?
[02:52] <jamesh> what sort of trees would be good to test that sort of thing?
[02:52] <ddaa> the first candidate for regressions in log-for-merge
[02:52] <ddaa> last time I looked at that code it was amazingly brain-damaged
[02:53] <SteveA> kiko: what should "bug 12345" link to if there is no bug 12345 ?
[02:53] <ddaa> packing up a number of undocumented, and unenforced, expectations.
[02:54] <jamesh> ddaa: I was thinking more along the lines of interoperability -- e.g. if I used a baz that didn't create such large metadata, would other people be able to use my branches?
[02:54] <ddaa> reading tla source code was a bit like ready a holy book, clues scattered all around, contradictory clues, etc.
[02:55] <lifeless> is there a 'merge products' feature planned ?
[02:55] <lifeless> (sound-juicer and sj are the same thing)
[02:55] <lifeless> jamesh: launchpad ;0
[02:55] <ddaa> jamesh: that's certainly going to break compatibility with some third-party tools, and some ancillary tools like log-for-merge (which affects "commit -s" ouput), but that should have no effect on core compatibility.
[02:55] <lifeless> jamesh: it should list just the new patch being added. Which is a trivial change I can do tonight.
[02:56] <lifeless> jamesh: the problem is the tools that depend on it : 'merge', 'log-for-merge'. 'merges'.  Does it, lifeless?
[02:58] <lifeless> mesh merge depends on it
[02:58] <lifeless> in that it does magic to remove the extra headers.
[02:58] <ddaa> well, should be a easy fix: "remove evil workaround"
[02:59] <lifeless> ddaa: except where we still need it. New logs would have a magic flag, and you need to conditional on it in a bunch of places.
[02:59] <lifeless> Thats shotgun surgery so you probably want to add a nice clean interface to get what people want and conditionalise in there
[03:02] <kiko> salgado, jamesh, SteveA, BjornT, spiv, stub: #canonical-meeting!
[03:02] <ddaa> mh... there does not seem be a canned name for that transformation in the Refactoring book...
[03:04] <lifeless> ddaa: see page 80
[03:04] <lifeless> or the smells list at the back
[03:05] <lifeless> for libarch it would be extract class + move method
[03:07] <ddaa> yeah, I know Shotgun Surgery. I was talking about the transformation. Yeah, I guess extract class + move method is right. But at a glance it did look like that was covering the "remove duplication" aspect.
[03:10] <lifeless> right, thats how you fix shotgun surgery
[03:10] <lifeless> you remove duplication ;0
[03:20] <ddaa> random thought
[03:21] <ddaa> the current pattern i'm using for create_master and create_mirror looks like:
[03:21] <ddaa> params = arch.ArchiveLocationParams()
[03:21] <ddaa> master.create_master(archive, params)
[03:21] <ddaa> (that's for an unsigned archive w/o listings)
[03:22] <ddaa> okay, that's fine because the common case is that you want make it explicit that you _really_ do not mean to have any option.
[03:23] <ddaa> But there are other cases, for example mirror, which could use (in the future) something like this Parameter Object pattern for --no-cached and --cached-tags options (because they are mutually exclusive, they are a not a good fit for keyword arguments).
[03:23] <ddaa> So, one option is to expect an optional parameter object.
[03:23] <ddaa> But I just thought of an interesting idiom with Method Objects and properties
[03:23] <ddaa> one could do:
[03:24] <ploum> Hello
[03:24] <ddaa> method = master.mirror(target, limit) # in the no-option case
[03:24] <ddaa> or
[03:24] <ploum> I tried to merge two accounts
[03:24] <ddaa> Hu
[03:24] <ploum> but not it seems that my personnal page is broken :-(
[03:25] <ddaa> master.mirror(target, limit) # no options
[03:25] <ploum> https://launchpad.ubuntu.com/people/ploum
[03:25] <ddaa> or: method = master.mirror ; method.no_cached() ; method(target, limit)
[03:25] <lifeless> ploum: are you lionel ?
[03:26] <ddaa> where the "master.mirror" would be a property that creates a method object.
[03:26] <lifeless> ddaa: eww
[03:26] <ddaa> is than insane crack?
[03:26] <lifeless> ddaa: yes yes yes
[03:26] <ddaa> * is that
[03:26] <lifeless> ddaa: there is a much cleaner way if you want that sort of complexity - Builder.
[03:26] <lifeless> ddaa: or.
[03:27] <lifeless> mirrorer = master.getMirrorer(target)
[03:27] <ddaa> lifeless: okay, so you want on optional parameter object? "params = arch.MirrorParams() ; params.no_cached() ; master.mirror(target, params)"
[03:27] <lifeless> mirror.no_cached()
[03:27] <lifeless> bah
[03:27] <lifeless> mirrorer.no_cached()
[03:27] <lifeless> mirrorer.mirror()
[03:28] <ddaa> Yeah... close to what I was thinking, but I was thinking of providing a seamless syntax for the common case.
[03:28] <lifeless> don't confuse people
[03:28] <lifeless> choose a clean way of doing it and do that.
[03:28] <lifeless> common case:
[03:28] <lifeless> master.getMirrorer(target).mirror()
[03:28] <ploum> lifeless, I am
[03:28] <lifeless> ploum: ok, there are some errors I can see.
[03:29] <lifeless> cprov: are you the /person person ?
[03:29] <lifeless> ploum: I don't know if its a bug, or something to do with your account. Lets see if we can find someone to help ;0
[03:29] <salgado> ploum, this is a known problem (https://launchpad.ubuntu.com/malone/bugs/1356). sorry for the trouble
[03:30] <salgado> it's going to be fixed soon and your page will be back working.
[03:30] <ploum> salgado, lifeless : thank you a lot !
[03:30] <ploum> I don't mind for the trouble
[03:30] <salgado> btw, this failure proves that the merge succeeded, at least
[03:30] <ploum> I just want to report the bug :-)
[03:31] <ploum> indeed, it seems that it succeeded
[03:33] <ddaa> lifeless: thinking of it, I think the builder pattern is what we want here. Clean extension point for verbose iter_ variants, single point sanity checking for master and target (good for our mirror-each-revision loop).
[03:33] <lifeless> ddaa: do you see the difference I'm making - that its always the same, theres always a method object.
[03:33] <lifeless> ddaa: :)
[03:33] <lifeless> ddaa: builder is suprisingly common once grokked.
[03:33] <ddaa> one important practical difference is where the target argument goes...
[03:34] <lifeless> ddaa: true. Theres a smalltalk idiom that I think you would like. each parameterisation method on the MethodObject returns self.
[03:34] <ddaa> yeah, I noticed that in your code.
[03:34] <ddaa> But that's not the python way of doing things.
[03:34] <lifeless> ddaa: so you could do: master.getMirrorer().no_cached().verbose().mirror()
[03:35] <ddaa> I can imagine that could be the way in other language, but that just make pythonistas go "eeeeew!"
[03:35] <lifeless> ddaa: I don't think its unpythonic, but its certainly not in common use in the std lib.
[03:35] <spiv> The pstats module in the stdlib does that.
[03:35] <ddaa> well... that makes me go "eeeew!"
[03:35] <lifeless> spiv: :-)
[03:35] <SteveA> kinda fails the LoD too
[03:35] <lifeless> LoD ?
[03:35] <spiv> Deferreds in Twisted also do that for adding callbacks.
[03:35] <ddaa> I love the "side effect gives no value" rule. It's actually a common rule in Scheme.
[03:36] <kiko> carlos, daf: ping?
[03:36] <spiv> "deferred.addCallback(foo).addCallback(bar).addErrback(boom)"
[03:36] <ddaa> spiv: duh! What's the point of doing that to a deferred, most of the time you just want to addCallback, addErrback, addBoth, or addCallbacks, to add just one level.
[03:36] <SteveA> law of demeter
[03:37] <spiv> ddaa: That's quite often exactly what you want.
[03:37] <spiv> ddaa: In particular, d.addCallback(func).addErrback(log.err) is a pretty common thing to want.
[03:37] <lifeless> SteveA: doesn't fail LoD then.
[03:38] <carlos> kiko, pong
[03:38] <spiv> But yeah, it's easy to get confused about the subtle difference between "d.addCallback(foo).addErrback(bar)" and "d.addCallbacks(foo, bar)".
[03:38] <kiko> carlos, can you help me understand why pofile.*Count takes an optional argument which is unused?
[03:38] <ddaa> spiv: you twisted guys have an interesting notion of error handling
[03:38] <lifeless> spiv: thats more a deferred model issue ;0
[03:39] <carlos> kiko, let me read the code...
[03:39] <ddaa> spiv: read me, I think that's a bad way of doing error handling.
[03:39] <carlos> kiko, oh, ok, because it comes from RosettaStats that is also implemented by POTemplate.*Count
[03:39] <spiv> ddaa: In what particular way is that bad?
[03:40] <carlos> kiko, and it makes no sense to specify the language in a POFile as you already know it
[03:40] <ddaa> Does not play way well with subsequent addition of callabacks.
[03:40] <SteveA> carlos: an api like getStatsFor(country) that returns an IRosettaStats would be better in that case
[03:40] <spiv> ddaa: Oh, right.  Yeah, log.err is an "end-user" errback :)
[03:41] <kiko> carlos, sounds horrible
[03:41] <ddaa> spiv: end-user errback should be model feature.
[03:41] <ddaa> but I'm not sure how you can make that fit in the deferred model.
[03:41] <carlos> SteveA, hmm, yeah, it sounds better
[03:41] <carlos> kiko, do you agree with that other solution?
[03:41] <ddaa> Since unhandled failures are collected at GC :(
[03:42] <ddaa> and because you want to be able to delay failure collection for "defer.fail(reason)" idioms"
[03:42] <spiv> ddaa: Right.  Deferreds ideally wouldn't exist at all, but given the language limitations they're about the best you can do.
[03:42] <carlos> stub, did you merge your cronscripts changes? I don't see any change with latest merge from rocketfuel
[03:43] <SteveA> i saw some interesting presentations at EP about async programming using yield
[03:43] <stub> It hasn't been reviewed
[03:43] <lifeless> erm, eeeeeeeeeeeeeeeeeeeeeeeeeeeeeew.
[03:43] <ddaa> spiv: btw, it looks like Python is about to grow a ".throw()" method on generators, which could be useful to twisted.
[03:43] <SteveA> python 2.5 is going to have a new form of yield that looks like:  foo = yield
[03:43] <kiko> carlos, yeah
[03:44] <kiko> it's much nicer
[03:44] <kiko> SteveA?
[03:44] <carlos> ok
[03:44] <ddaa> spiv: pep342, I just read about that. I assume you guys are following it closely. Aren't you?
[03:44] <carlos> kiko, could you open a bug report about that issue?
[03:44] <spiv> ddaa: I try to.  python-dev is pretty hectic at times.
[03:44] <kiko> carlos, sure.
[03:44] <carlos> kiko, thanks
[03:44] <SteveA> kiko:  what?
 python 2.5 is going to have a new form of yield that looks like:  foo = yield
[03:45] <jamesh> I take it that is for feeding a value back into the generator
[03:46] <SteveA> yes.  basically telling it to resume, and giving it back some value
[03:46] <BjornT> kiko: what's currently blocking BBA from being approved?
[03:47] <kiko> BjornT, me looking at it, I guess
[03:48] <SteveA> jamesh: approved your pygettextpo merge
[03:48] <ddaa> Wow, that sounds like something that would allow actually making async code that does not requires turning ones brain inside out to read.
[03:48] <BjornT> kiko: can you take a look at it soon, then?
[03:48] <kiko> BjornT, yes.
[03:48] <salgado> spiv, is there any reason for not running the sqlobject tests inside "make check_merge"?
[03:48] <BjornT> kiko: thanks
[03:48] <SteveA> ddaa: the latest twisted stuff has a hack to allow this kind of thing today
[03:48] <SteveA> i saw it demoed at EP
[03:48] <spiv> salgado: Not at all, so long as they pass ;)
[03:49] <ddaa> SteveA: yes, I've been looking a lot at the twisted2 api recently. But it's still a hack, it's ugly, difficult to grok, verbose... well twisted...
[03:49] <jamesh> SteveA: thanks
[03:49] <kiko> carlos, can you pick up a patch I have that implements sorting, check it out and merge it? rs=sabdfl
[03:50] <ddaa> SteveA: language support would significantly raise the cost of this pattern so it could be useful even in simple cases.
[03:50] <ddaa> * significantly lower the cost
[03:50] <kiko> SteveA, mpt: https://launchpad.ubuntu.com/malone/bugs/1420 shows me that DPoT isn't playing nice with my source code :-(
[03:50] <SteveA> yeah, that's the idea
[03:50] <salgado> spiv, right now they won't pass. but I'm planning to make it. would you review it for me as soon as it's ready?
[03:50] <kiko> could we make it so that lines prefixed with spaces are
-formatted?
[03:50] <sabdfl> DPoT?
[03:50] <kiko> displaying paragraphs of text
[03:51] <sabdfl> kiko: variable with fonts will make code snippets hard
[03:51] <sabdfl> width, even
[03:51] <kiko> sabdfl, right
[03:51] <spiv> salgado: Sure.
[03:51] <SteveA> i thought that dpot was supposed to be rendered with a fixed-width font
[03:52] <SteveA> using styles etc.
[03:52] <kiko> that's not what I'm seeing
[03:52] <kiko> anyway we can sort it out in the week
[03:52] <jamesh> the return statements on that page don't seem to be inside a
 or

[03:52] <jamesh> or use  's at the beginning of the lines
[03:52] <SteveA> yeah, i've found a bug in dpot
[03:53] <SteveA> there's a test for linkification that has revealed a bug in the algorithm
[03:53] <SteveA> i'm looking into it
[03:53] <salgado> spiv, there's one thing I need to ask you. what's our policy for getting stuff from upstream into our branch? can I just apply part of the changes needed or do you want me to get the whole changeset? (in case I need only a small part of a changeset)
[03:53] <SteveA> spiv: note, i ripped the locking out of the cacheing in our sqlobject
[03:53] <salgado> s/part of the changes/the part of the changeset/
[03:54] <spiv> salgado: Well, we want to be able to follow upstream with minimal effort.
[03:54] <spiv> salgado: And any divergence has a small cost to that... but backports don't hurt too much, so it's probably ok.
[03:58] <carlos> kiko, your lock solution rock
[03:59] <kiko> carlos, wooo!
[03:59] <kiko> I didn't know it would work!
[03:59] <carlos> SteveA, I added a glock.py file that improves the cronscripts lock solution and use it as a module. It's LGPL, I suppose it's not a big issue, right?
[04:00] <spiv> SteveA: Because we don't need it for our one-connection-per-thread case, and it was causing weird deadlocks?
[04:00] <carlos> it's at lib/canonical/launchpad/scripts/glock.py and will deprecate lib/canonical/launchpad/scripts/lockfile.py
[04:00] <SteveA> spiv: yes
[04:01] <SteveA> carlos: put it in lib/contrib in its own module
[04:01] <carlos> ok
[04:12] <kiko> sabdfl, prepared to be surprised?
[04:13] <Kinnison> stub: ping?
[04:14] <stub> Kinnison: pong
[04:14] <Kinnison> stub: mawson's pgsql is still all grungy
[04:14] <Kinnison> stub: how do I stop the dogfood launchpad, librarian etc?
[04:15] <stub> sudo to the launchpad user and kill the processes. It is old code that is still just run under screen.
[04:16] <Kinnison> okay
[04:16] <Kinnison> whose screen is running it?
[04:17] <stub> Kinnison: Mine generally. If we update the code we can background it properly (well... nohuped...)
[04:17] <bradb> morning
[04:17] <Kinnison> stub: Right
[04:18] <Kinnison> Stub: We intend to take dogfood right to the head of the devel branch
[04:18] <salgado> bradb, have you received a bugmail with my comment on https://launchpad.ubuntu.com/malone/bugs/1375 ?
[04:18] <stub> Kinnison: You want to handle it, or do you want me to do the drop?
[04:19] <bradb> salgado: yes, got it no
[04:19] <bradb> s/no/now/
[04:19] <cprov> Kinnison: indeed
[04:19] <Kinnison> What I need to know is how to update the database correctly
[04:20] <salgado> bradb, with the comment or with the change I did (assigning it to myself)? I'm asking because I didn't got the bugmail with the comment
[04:20] <bradb> salgado: i got both
[04:20] <stub> Kinnison: Checkout the Makefile.staging in dists--devel--0. It has targets to do everything you want and more.
[04:20] <bradb> salgado: i just deleted it though, but it also went to the lp list, IIRC
[04:21] <Kinnison> stub: Hmm, okay ta
[04:22] <salgado> bradb, yes, I was expecting to see it in the lp list. but I haven't
[04:22] <Kinnison> stub: has makefile.dogfood been updated?
[04:22] <bradb> did anyone else get bugmail for 1375?
[04:23] <stub> Kinnison:Basically just upgrade.py -d launchpad_staging; fti.py -d launchpad_staging; securtity.py -d launchpad_staging.
[04:23] <Kinnison> stub: so if I get a fully updated code drop onto mawson in the right place and then do 'make -f Makefile.dogfood dbupgrade' then it should do the right thing?
[04:23] <stub> Kinnison: I think it was mostly done for automatic updates, but might not be finished.
[04:24] <stub> Kinnison: If it has problems, it will be because of permissions. Hang - I'll check.
[04:24] <Kinnison> okay
[04:25] <carlos> kiko, ping
[04:26] <stub> Kinnison: Permissions should be fine - the launchpad user has permission to connect as user PostgreSQL to the launchpad_dogfood database
[04:27] <stub> Kinnison: So python update.py -d launchpad_dogfood -U postgres; python fti.py -d launchpad_dogfood -U postgres; python security.py -d launchpad_dogfood -U postgres
[04:27] <Kinnison> gotcha
[04:28] <stub> Kinnison: Oh... I changed the baseline recently. There will be a number of database patches to run manually in the database/schema/archive directory
[04:29] <stub> Kinnison: So first you will need to copy database/schema/archive/patch-17-* to database/schema
[04:29] <stub> Kinnison: That should take care of it all, and normally this would not be needed except I've let it lag too far behind production/staging
[04:29] <Kinnison> right
[04:31] <stub> Its *easy* - staging does it by itself every day ;)
[04:32] <Kinnison> not from this far back it doesn't :-)
[04:32] <morgs> bradb: nope, nobody (well, I can only speak for myself but I didn't get it...)
[04:36] <stub> Kinnison: If you somehow manage to totally root it (should be difficult since upgrade.py is transactional), I made a snapshot of the database earlier for debonzi ;)
[04:37] <Kinnison> stub: okies
[04:39] <SteveA> jamesh: why does no diff appear for<EMAIL_ADDRESS>on the pending-reviews page?
[04:39] <kiko> SteveA, the branch name was broken
[04:39] <kiko> it is double-dashes
[04:39] <SteveA> ah
[04:39] <SteveA> so it is
[04:41] <Kinnison> stub: did you really type in your password each time you wanted to update dogfood's launchpad?
[04:41] <Kinnison> stub: or is there some trick I'm missing for forwarding my SSH agent through sudo?
[04:41] <stub> Kinnison: I use ssh-agent. Elmo is due to give us a final solution, but for the time being it is ssh-agent or setting up keys to your chinstrap account.
[04:42] <cprov> stub: ehe I guess the snapshop was for me ;)
[04:42] <stub> Kinnison: I add my ssh key to launchpad's authorized_keys
[04:42] <Kinnison> stub: aaaah
[04:42] <stub> Kinnison: It annoys elmo, but it has to be done ;)
[04:43] <Kinnison> aye
[04:43] <Kinnison> Is anyone else here having trouble landing simple changes to rocketfuel?
[04:44] <Kinnison> and I'm trying to land trivial changes to three files not touched by the test suite
[04:44] <sivang> stub: I saw some of my suggestion got a page on the launchpad wiki :-)
[04:45] <sivang> stub: recall our talks of the issue tracker that'll bridge between the "moy mouse don't work" and how devs see the issues reported?
[04:45] <sivang> stub: (the "trasnlation layer" from the user --> developer)
[04:46] <sivang> specifically referring, to https://wiki.launchpad.canonical.com/MaloneSupportIntegration
[04:46] <sivang> Kinnison: hi there! :-)
[04:46] <Kinnison> hi sivang
[04:46] <carlos> Kinnison, I'm getting a bunch of errors with code unrelated to my changes, does it counts?
[04:47] <stub> Heh.... don't blame me. That is Brad's page ;)
[04:48] <Kinnison> carlos: probably
[04:48] <sivang> stub: hehe, well nice to know I wasn't the only one to think of it, that way it means it has some sort of feasability
[04:50] <sivang> btw, does the existance of this wiki mean anybody can take a part in Launchpad's development now?
[04:50] <sivang> (the launchpad wiki)
[04:50] <carlos> Kinnison, hmm, seems like it's getting better here so it's unrealted with your problem...
[04:51] <Kinnison> stub: why did you go from 17 to 25 on the db numbering scheme?
[04:51] <stub> Kinnison: Because I can't count?
[04:52] <mdke> is anyone around who knows anything about the authentication for ubuntu.com, specifically the wiki?
[04:52] <stub> Kinnison: I sync up with the launchpad release, currently 1.25
[04:52] <carlos> mdke, spiv is who did it
[04:52] <Kinnison> stub: aah
[04:52] <Kinnison> stub: The upgrade fails
[04:53] <mdke> carlos, thanks
[04:53] <Kinnison> stub: https://chinstrap.ubuntu.com/~dsilvers/paste/fileLX7dBP.html
[04:55] <Kinnison> stub: know how to fix that?
[04:57] <mdke> carlos, what is spiv's timezone?
[04:58] <Nafallo> mdke: CTCP TIME reply from spiv: Thu Jul 14 00:58:03 2005
[04:58] <Nafallo> ;-)
[04:59] <mdke> damn
[04:59] <mdke> thanks :)
[04:59] <stub> Kinnison: ok - give it another run (might want to use the --partial flag too, so it commits after each successful patch which will speed things up if this happens again)
[04:59] <mdke> anyone else know anything about how the wiki authentication works?
[05:01] <stub> mdke: We are running a hacked moin that talks to our authentication server, so logins are shared between the wikis, the Plone sites and Launchpad.
[05:01] <mdke> stub, i am interested in finding out how to hack moin in this way...
[05:02] <SteveA> mdke: hacking moin to talk to launchpad, or hacking moin to talk to some other authentication system?
[05:02] <stub> mdke: I believe you start with a good, stiff drink. It isn't plugin friendly. More info than that you have to talk to spiv - nobody else wanted to touch it ;)
[05:02] <mdke> SteveA, another one
[05:02] <mdke> stub, hmm :-(
[05:02] <mdke> SteveA, specifically a forum database
[05:03] <Kinnison> stub: it is using --partial
[05:03] <stub> mdke: spiv might be able to release his work (make that a 'will' if moin is GPL)
[05:03] <SteveA> mdke: send a mail to spiv asking about it.  andrew at canonical.com
[05:03] <bradb> mpt: around?
[05:04] <mdke> stub, moin is gpl i think
[05:04] <mdke> SteveA, will do thanks :D
[05:04] <BjornT> stub: i've reviewed your branch now, and i think i know why the email script wasn't working. it's using the wrong lockfile...
[05:04] <stub> BjornT: I fixed that.
[05:04] <SteveA> yeah, it is gpl
[05:05] <SteveA> mdke: can you also cc me<EMAIL_ADDRESS>[05:05] <mdke> SteveA, certainly
[05:05] <Kinnison> aah no, simple, just touches posubmission
[05:09] <BjornT> stub: hmm, ok. it seems like it worked once at least, though. it processed a mail brad sent a while ago.
[05:09] <bradb> SteveA: any news on page titles? that be a subtle-but-sweet improvement for Malone usability
[05:09] <bradb> s/that/that'd/
[05:10] <bradb> mpt seems to have dropped a slight bombshell on the malone menus implementation by pointing out that the "Show Reports" menu option should show the, ahem, "Advanced Search" page. :)
[05:11] <bradb> though Advanced Search will be fairly critical for 1.0, i don't think sabdfl is sold on it yet
[05:14] <stub> Kinnison: Touches it a few million times though ;)
[05:14] <Kinnison> stub: aye
[05:26] <Kinnison> stub: *pout* it's _still_ running patch 23
[05:28] <stub> Kinnison: it will get there ;) I can make it chew up more memory, but it will involve cancelling that update. Probably better to just leave it (don't think the extra RAM allocation will help the writes much anyway)
[05:28] <Kinnison> okay
[05:28] <stub> Kinnison: Oh... actually, there is something I can tweak.
[05:30] <Kinnison> what?
[05:32] <Kinnison> debonzi, stub: Talk to me about gina on production
[05:35] <stub> Kinnison: If you are happy with the data on staging, we can switch it on as soon as someone reviews the branch and it gets merged to Rocketfuel
[05:36] <stub> Kinnison: Which I doubt will happen until I'm in Brazil
[05:37] <Kinnison> stub: blergh, right
[05:37] <Kinnison> we need to get it going on production ASAP
[05:37] <Kinnison> whose review queue is the branch in?
[05:37] <debonzi> Kinnison, I tried to get an rs=kiko.. but I didn't receive it yet :(
[05:38] <debonzi> Kinnison, will ping him about it again
[05:38] <Kinnison> Thanks
[05:38] <Kinnison> an r=<foo> will do
[05:38] <Kinnison> but get it reviewed and in ASAP
[05:39] <kiko> yeah, I'd rather it got reviewed
[05:40] <stub> It won't be running until I'm in Brazil then, and I have no idea what the schedule will be like there.
[05:40] <bradb> kiko: i just added sample data for a distro release task
[05:40] <bradb> kiko: 5 modified files...
[05:40] <bradb> but simple, straightforward, couple-line test fixes. are you willing to rs this?
[05:40] <Kinnison> stub: right, how do I start launchpad in a sane way now?
[05:41] <bradb> (the most significant non-triviality was adding three lines to bugtask.zcml to define canonical URLs for bug tasks.)
[05:41] <stub> Kinnison: make start LPCONFIG=dogfood (assuming there is a dogfood config...)
[05:41] <bradb> s/for bug tasks/for distrorelease bug tasks/
[05:42] <kiko> bradb, sure, mail me
[05:42] <Keybuk> Kinnison: how often is gina running breezy into dogfood now?
[05:43] <Kinnison> Keybuk: Not sure, if debonzi doesn't know either, I'd say "not at all currently"
[05:43] <Keybuk> Kinnison: debonzi said "lunch"
[05:44] <Keybuk> can we run that daily, or even more-than-daily ?
[05:44] <Keybuk> so it has the latest, shiniest, breezy information
[05:44] <Kinnison> Once dogfood is up and going yes
[05:44] <Kinnison> it's currently down and crying
[05:45] <debonzi> Kinnison, do you want me to set gina up when dogfood is ready?
[05:46] <Kinnison> debonzi: I'd appreciate that, yes
[05:46] <Kinnison> debonzi: I'll tell you once it's ready
[05:46] <debonzi> Kinnison, cool..
[05:50] <Kinnison> Keybuk: dogfood can't start
[05:51] <Kinnison> https://chinstrap.ubuntu.com/~dsilvers/paste/filegFuUoP.html
[05:52] <stub> Kinnison: The config file is missing the trebuchet section
[05:53] <Keybuk> stub: didn't you merge that in from default yet?
[05:53] <stub> Dogfood hasn't been updated for ages
[05:54] <Kinnison> Keybuk: is the default trebuchet config okay for dogfood?
[05:55] <Keybuk> yup
[05:55] <Keybuk> defaults are ok everywhere
[05:59] <bradb> fuck
[05:59] <bradb> bad paste == rm'd file in working tree
[05:59] <kiko> woo
[06:00] <bradb> i have it mirrored already, i'm just trying to think of how to cvs -q up it...
[06:00] <Kinnison> Keybuk: right, I think dogfood is up
[06:03] <Kinnison> debonzi: Please import breezy and then start regular updates
[06:05] <bradb> kiko: in the meantime, i mailed you the patch
[06:06] <kiko> great
[06:21] <bradb> kiko-fud: do you have a chance now to review that patch? it's virtually [trivial]
[06:27] <stub> Is it my imagination, or is PQM not merging anything or sending responses?
[06:29] <bradb> it seems unlikely that it's your imagination
[06:29] <salgado> stub, I guess the problem is with responses only
[06:41] <bradb> sabdfl: what if we called it IBugTask.reportedin?
[06:41] <sabdfl> bradb: super
[06:42] <bradb> right, ok, filing the bug now to be sure we get to it
[06:44] <sabdfl> BjornT: what branch are you currently mreging in?
[06:44] <sabdfl> anybody know what branch stub is merging in, too?
[06:45] <sabdfl> BjornT: you reviewed it
[06:45] <sabdfl> i'd like to merge and test so I know if my merge will be OK
[06:47] <Kinnison> more dogfood in the morning methinks
[06:53] <BjornT> sabdfl: i'm merging<EMAIL_ADDRESS>[06:54] <BjornT> sabdfl: stub's should be<EMAIL_ADDRESS>then. (even though it's in need-reply status...)
[06:55] <sabdfl> thanks bjornt
[07:04] <kiko-fud> lifeless, did the magic pqm-viewer go live?
[07:05] <ddaa> ssh chinstrap lynx --dump http://localhost:8000/
[07:05] <ddaa> kiko-fud: your patch is second on the queue
[07:05] <kiko-fud> thanks ddaa
[07:10] <BjornT> anyone else seen failures from pqm, where the librarian couldn't be set up?
[07:10] <BjornT> OSError: [Errno 17]  File exists: '/var/tmp/fatsam.test'
[07:11] <SteveA> yeah
[07:11] <SteveA> kill all librarians
[07:11] <SteveA> rm -r /var/tmp/fatsam.test
[07:13] <BjornT> who can do that on chinstrap?
[07:14] <SteveA> ah
[07:14] <SteveA> various people who aren't here
[07:15] <SteveA> you can submit a merge with some extra code that does the 'rm -r' ;-)
[07:15] <SteveA> thus, getting the pqm user to do it by proxy
[07:15] <SteveA> actually, it's a reasonable thing to rm before a test run
[07:15] <kiko-fud> you are such an evil man
[07:17] <BjornT> ok, i'll wait until tomorrow and hopes that someone has fixed it until then, this merge isn't that important
[07:18] <SteveA> there is a bug in the librarian setup
[07:18] <SteveA> if /var/tmp/fatsam.test is there, it all falls apart
[07:19] <SteveA> also, the test runner can leave that directory, and maybe a librarian, sitting around
[07:19] <SteveA> an atexit hook could clean these up
[07:20] <debonzi> Kinnison, yep.. how much time more will you be online?
[07:33] <bradb> kiko-fud: might you have a moment to take a quick look at that patch?
[07:33] <kiko-fud> bradb, I already replied and r+ed it
[07:33] <kiko-fud> about 4h ago
[07:34] <bradb> 4h ago? heh
[07:34] <bradb> i don't see the reply, but if you say it's r'ed well, hey, that's good enough for me
[07:35] <kiko-fud> you wrote to launchpad-reviews only unfortuantely
[07:35] <kiko-fud> next time write to me CC: launchpad-reviews
[07:35] <kiko-fud> and stop this reply-to-list thing
[07:35] <kiko-fud> you'll get direct replies
[07:35] <bradb> Date: Wed, 13 Jul 2005 12:04:29 -0400
[07:35] <bradb> From: Brad Bollenbach<EMAIL_ADDRESS>[07:35] <bradb> To: Christian Robottom Reis<EMAIL_ADDRESS>[07:35] <bradb> Cc<EMAIL_ADDRESS>[07:35] <bradb> Subject: REVIEW REQUEST: Canonical URLs for IDistroReleaseBugTask
[07:36] <kiko-fud> maybe it's that list-reply thing that's going on
[07:36] <bradb> i always reply-to-list, because it annoys the heck out of me when other people *don't* do that!
[07:37] <bradb> but, i don't see how that mattered here, because i didn't reply to anything. mais en tous cas...
[07:37] <kiko-fud> I think for some reason I'm getting this horrible reply-to-list header
[07:37] <kiko-fud> and I hate reply-to-list-only
[07:38] <carlos> kiko-fud, I have a pending review to be done that is a bit urgent
[07:38] <carlos> kiko-fud, any chance to get some priority there?
[07:38] <kiko-fud> but I suck at reviews!
[07:39] <kiko-fud> nag a reviewer, carlos -- yes
[07:39] <carlos> kiko-fud, I'm not asking that you review it
[07:39] <kiko-fud> oh
[07:39] <carlos> but if you can point to anyone ;-)
[07:39] <carlos> if you can do it, is ok
[07:39] <kiko-fud> BjornT, salgado or SteveA
[07:39] <carlos> I thought you coordinate them, that's all O:-)
[07:40] <kiko-fud> I actually do, but ...
[07:40] <carlos> BjornT, salgado, SteveA: Any chance to get a review from you? it should be easy as it's not a new feature but bug fixing + tests
[07:42] <carlos> kiko-fud, btw, I have a friend from Spain that moves to Sao Pablo to work there, I think he will be there a year or so
[07:42] <kiko-fud> that's cool
[07:42] <salgado> carlos, I think I can look at it. where's the branch/diff?
[07:43] <dilys> Merge to<EMAIL_ADDRESS>new build (patch-39)
[07:43] <bradb> gotta run out for about 30-45 mins. back in a bit and will look at your branch too kiko-fud while i'm bazzing.
[07:43] <dilys> Merge to<EMAIL_ADDRESS>Display revision information before uploading changeset for archive-mirror (patch-31<EMAIL_ADDRESS>[07:44] <carlos> salgado<EMAIL_ADDRESS>[07:44] <carlos> but give me some extra minutes, I'm finishing a bug fix I found while testing it with real data
[07:45] <salgado> carlos, what bug is that you found?
[07:46] <carlos> salgado, a string substitution that expects an integer and seems to get a non integer value
[07:46] <carlos> salgado, it should be trivial to fix, it's the test what will be bigger
[07:47] <salgado> carlos, hmmm. I hope you're adding some sampledata to test this case too. ;)
[07:47] <carlos> I'm trying to detect the sample data that raises the bug as I don't see anything looking at the code
[07:47] <carlos> salgado, when you look at the diff you will see that all bugs I'm fixing have sample data and tests
[07:48] <carlos> salgado, so yes, I'm trying to find the data that raises it to add it to our tests
[07:48] <salgado> carlos, great. :)
[07:51] <SteveA_> kiko-fud: remember what bjorn was talking about earlier?  fatsam directories and all that?
[07:51] <SteveA_> i think pqm might be stuffed for running launchpad testes
[07:51] <SteveA_> um, tests
[07:52] <kiko-fud> I'm getting local librarian failures when running them
[07:52] <kiko-fud> dunno if that's a known issue or no
[07:52] <kiko-fud> t
[07:52] <SteveA_> could well be a librarian process lying around
[07:53] <SteveA_> and its /var/tmp/fatsam.test directory still being there
[07:53] <carlos> kiko-fud, are you using twistd 2?
[07:53] <kiko-fud> how do I know? :)
[07:54] <carlos> I applied a fix from daf, although it still fails from time to time
[07:54] <carlos> kiko-fud, if it's hoary it's not 2.0
[07:54] <carlos> carlos@gollum:~$ twistd2.4 --version
[07:54] <carlos> twistd (the Twisted daemon) 2.0.1
[07:56] <kiko-fud> it's hoary
[07:59] <ddaa> mh... chicken and egg...
[07:59] <ddaa> I need bound namespace objects to test mirroring
[08:00] <ddaa> but I need mirroring to test bound namespace objects...
[08:01] <SteveA_> do you need all of both?
[08:02] <carlos> kiko-fud, then it's not the same problem
[08:14] <jblack> Hi. Would anybody happen to know what a kochi is, as pertains to ttf? (as in ttf-kochi)
[08:15] <carlos> salgado, go ahead with the review, the bug seems to be inside the mail template that the script sends so it should be fixed without changing python code
[08:15] <SteveA_> it's a standard style family of japanese fonts
[08:16] <jblack> Anything more than that? I need to make a paragraph worth of description.
[08:16] <SteveA_> i read an article on japanese font families once
[08:17] <jblack> "ttf-kochi is a true type font for japanese characters. As many people know, japenese is one of those weird languages where instead of doing from left to right it goes from up to down. I hear sushi is good, but I think it sux. kthx, bye"
[08:18] <jblack> btw, thanks stevea
[08:19] <ddaa> jblack: if you want my opinion, I think "Kochi is a standard style family of japanese fonts." is perfectly all right.
[08:19] <ddaa> There are quite a few boring products in launchpad that have similar one-line descriptions.
[08:20] <ddaa> The suggested summaries in the comments are, in my opinion, quite completely over the top of what can be reasonably expected from us.
[08:20] <SteveA_> jblack: checking my info...
[08:20] <jblack> SteveA_: Its ok. I'm just having fun.
[08:21] <SteveA_>  ttf-kochi-gothic is high quality, Japanese gothic TrueType font.
[08:21] <SteveA_>  It does not include naga10 font, so it's DFSG-free.
[08:21] <SteveA_>  .
[08:21] <SteveA_>  The family of ttf-kochi-* is very smooth and beautiful compared with
[08:21] <SteveA_>  current free Japanese TrueType fonts. It has bitmap hinting information,
[08:21] <SteveA_>  so it's beautiful and not jagged to display on the CRT.
[08:21] <SteveA_>  This font is suitable for both printing and displaying Japanese
[08:21] <SteveA_>  characters.
[08:21] <SteveA_> i suppose you asked apt already?
[08:22] <jblack> I normally check apt straight off, but coming from ubuntu-sounds, and my general familiarity with the usual ttf fonts, I kind of missed that step
[08:41] <bradb> anyone know when pqm is expected to start working again? (no point even /asking/ if it's broken right now.)
[08:44] <jblack> how long has it been broken that you know of? Does lifeless know?
[08:45] <bradb> jblack: for what percentage of today has it been broken? hm, i dunno, anyone else?
[08:46] <bradb> lifeless won't be able to know until he wakes up (or somebody wakes him up), I suppose
[08:46] <jblack> I can go grab a phone card and call him if you're blocked
[08:49] <bradb> when pqm's dead, we're all blocked ;)
[08:49] <bradb> SteveA_, kiko-fud: what's the status of pqm?
[08:52] <jblack> Ok. I"ll get ahold of him.
[08:52] <bradb> jblack: you might want to wait a sec
[08:52] <bradb> just to see if kiko-fud or SteveA_ have an update on the status
[08:53] <bradb> but i do appreciate your willingness to help us out
[08:55] <bradb> or salgado, do you know what pqm's status is?
[08:57] <salgado> bradb, SteveA_ said something about a stale file (that can also be removed by stuffing some extra commands in the merge-request mail)
[08:57] <bradb> salgado: that rm -r stuff? :)
[08:58] <salgado> I guess so
[08:58] <salgado> will pqm execute any command you send him by mail?
[08:59] <jblack> Not as a general rule.
[08:59] <jblack> It can be hacked up to do most anything with some effort though...
[09:03] <Kinnison> debonzi: I'll be here on and off for the next few hours, but I'm working on personal stuff so I'm not going to be desperately responsive
[09:04] <bradb> Kinnison, the consumate hacker
[09:05] <debonzi> Kinnison, yep.. no problem .... are you the launchpad_dogfood master at this time?
[09:05] <Kinnison> debonzi: essentially yes
[09:06] <debonzi> Kinnison, cool :)
[09:16] <bradb> hm, there seem to be a group of schoolchildren loudly applauding at all passers-by on bicycle
[09:26] <salgado> from baz diff -H
[09:26] <salgado> -q, --quiet            Suppress progress information
[09:27] <salgado> but then, if you pass in -q you'll see that it really will suppress the whole output
[09:27] <bradb> including the diff?
[09:27] <salgado> yes
[09:27] <bradb> heh!
[09:27] <bradb> salgado: are you sure you diffed against the right thing?
[09:27] <carlos> SteveA_, I suppose that it's ok if a migration script uses database objects directly, right?
[09:28] <bradb> salgado: i.e. do you see output doing the exact same command without the -q?
[09:28] <salgado> bradb, yes. I tested without -q
[09:28] <carlos> SteveA_, the code will be executed once
[09:28] <bradb> wild
[10:09] <bradb> SteveA_: would it be fair to say that 'raise FooError("bar")' is the preferred way to raise an exception?
[10:09] <bradb> instead of, say, raise FooError, "bar"
[10:27] <salgado> bradb, SteveA_ once said that the former is the only right way to do it, IIRC
[10:38] <jblack> I'd like to put it on record that whatever I did in the last lifetime to get imports in this lifetime... I've learned my lesson, I'm very sorry, and I'll never do it again. :)
[10:42] <SteveA_> carlos: yes, it is okay for a migration script to do whatever it needs to do
[10:42] <bradb> salgado: that's what i thought
[10:42] <SteveA_> bradb: preferred over   raise FooError, "bar"
[10:42] <bradb> right
[10:42] <bradb> salgado: is IPerson.browsername suitable for the title attribute of an ?
[10:44] <salgado> bradb, I can't see why it wouldn't be
[10:44] <SteveA_> to get pqm running, if the problem is what bjornt noted, there would need to be a merge that adds a 'rm -r /var/tmp/fatsam.test' or some equivalent.
[10:44] <SteveA_> i don't know the details of the librarian test set-up, so it is a better idea to send the significant parts of your pqm rejection messages to the list, so that stub or lifeless can fix it properly
[10:48] <SteveA_> kiko-fud: there's no blu-tak kind of stuff in lithuania either.
[10:53] <kiko> thanks SteveA_
[10:57] <carlos> SteveA_, ok
[11:01] <SteveA_> salgado: i just reviewed<EMAIL_ADDRESS>with debonzi
[11:02] <salgado> SteveA_, thanks for noticing. I was going to review it after carlos' branch
[11:03] <SteveA_> salgado: maybe you can do<EMAIL_ADDRESS>[11:03] <SteveA_> it is a DPoT fix, and linkifying too
[11:03] <SteveA_> i'm going to sleep.  see you tomorrow.
[11:03] <kiko> that would be beautiful
[11:04] <salgado> SteveA_, I'll try to get on it today. otherwise I'll review it tomorrow
[11:04] <SteveA_> gotta have it rolled out tomorrow
[11:05] <SteveA_> if you can't do it, i'll ask bjorn tomorrow am
[11:05] <SteveA_> it is a small patch
[11:08] <kiko> why is PQM always giving me pain
[11:10] <salgado> cause otherwise you won't have anything to complain. :P
[11:10] <kiko> I have LOTS to complain about
[11:14] <salgado> carlos, kiko, contrib/glock.py we want to merge with as few modifications as possible or should we make it consistent with the launchpad codebase?
[11:16] <kiko> zero-modifications if possible
[11:17] <ddaa> SteveA_: I have a Method Object pattern, which style seems more pythonic to you: "location.Mirrorer().mirror()" or "location.make_mirrorer().mirror()"?
[11:18] <ddaa> bah... zaway..
[11:19] <bradb> kiko: sent a review of your branch
[11:19] <kiko> the latter is pretty weird
[11:19] <kiko> bradb, how does it look?
[11:20] <kiko> I fixed a broken pagetest
[11:20] <bradb> kiko: overall really nice. i appreciate the precise detail you pay the UI elements, wording, linkification, etc.
[11:22] <bradb> pqm gives me pain too. i shudder to think about the number of manhours it swallows each and every day.
[11:23] <kiko> jesus h. christ
[11:23] <kiko> thanks for the review, well thought-out comments
[11:23] <kiko> man, sabdfl's code for that url method is hideous :-)
[11:23] <bradb> heh
[11:23] <kiko> he must have been half-asleep
[11:25] <kiko> bradb, it's probably pretty easy to fix bug 1365, isn't it?
[11:25] <carlos> salgado, It's an external module, so we should not touch it at all
[11:26] <carlos> unless it has a bug, of course
[11:26] <salgado> yes. I asked just to make sure
[11:26] <carlos> I forgot to warn you about that file, sorry
[11:27] <salgado> don't worry
[11:28] <bradb> kiko: probably pretty simple. i'd jump into it right now, but i've already got 7 different branches active atm. :/ i'd have merged a few in and gotten them out of my way already if pqm worked.
[11:29] <carlos> bradb, lifeless should appear soon
[11:30] <bradb> i'm willing to transition to a system that uses pigeons to deliver my patches to a secretary in the london office, who then manually types in my changes
[11:30] <carlos> X-)
[11:31] <bradb> so, launchpad@ traffic is lagging way behind too eh?
[11:31] <bradb> i haven't seen my HEADS UP mail hit the list yet
[11:34] <lifeless> pqm is up
[11:34] <lifeless> AFAIK
[11:34] <kiko> no
[11:34] <kiko> pqm is crapping out
[11:34] <lifeless> kiko: no, its not 'live' because I can't find elmo
[11:34] <lifeless> kiko: lock file is not held, theres no active pqm runner process
[11:35] <salgado> isn't the problem that twistd pqm is running?
[11:35] <lifeless> kiko: its running your job at the moment
[11:35] <lifeless> salgado: huh ? no.
[11:37] <lifeless> salgado: that twisted bot does not take out a lock.
[11:37] <lifeless> salgado: it neither hinders nor helps the pqm engine
[11:37] <kiko> something isn't running because it gives me 100 test failures
[11:37] <lifeless> kiko: postgresql ?
[11:38] <salgado> lifeless, well, I was told the problem was because something was trying to remove the /var/tmp/fatsam/ directory
[11:38] <lifeless> kiko: you gotta understand, PQM is _real_ simple at the heart of it. The _only_ thing that runs persistently is .. nothing.
[11:38] <lifeless> salgado: that sounds like something related to gina or a buildd.
[11:38] <salgado> OSError: [Errno 17]  File exists: '/var/tmp/fatsam.test'
[11:38] <kiko>     OSError: [Errno 17]  File exists: '/var/tmp/fatsam.test'
[11:38] <kiko>     IOError: [Errno socket error]  (111, 'Connection refused')
[11:38] <salgado> this fatsam directory is held by librarian, IIRC
[11:38] <lifeless> salgado: right, its a launchpad test bug, not the pqm status thing
[11:39] <lifeless> uhm
[11:39] <lifeless> ok, I've just rmrfed that dir.
[11:40] <lifeless> kiko: can you file a bug please on launchpad - 'existing /var/tmp/fatsam.test breaks the test suite'
[11:40] <lifeless> kiko: might want to point out the silliness of using a hardcoded directory at the same time
[11:42] <salgado> lifeless, is diff -q supressing everything, including the diff, intentional? (even if the docs don't say so)
[11:43] <lifeless> salgado: baz version ?
[11:43] <salgado> Bazaar version 1.5~200507091049 and Bazaar version 1.4.2
[11:44] <lifeless> hmm, it was somewhat of an issue, thought it was fixed :\
[11:45] <salgado> I filled a bug on it. https://launchpad.ubuntu.com/malone/bugs/1430
[11:46] <salgado> kiko, bradb, let's say I'm looking at a bug and one of its tasks was reported in bazaar. I think it would be handy to have a link to see all bugs in bazaar
[11:47] <salgado> not yet sure if it would be better in the bug or the bugtask page
[11:48] <kiko> it's not very difficult to actually do this
[11:48] <kiko> if you are looking at the task
[11:48] <kiko> click on the product name
[11:48] <kiko> then click on "more malone bugs"
[11:48] <salgado> yes, but if I'm looking at the bug, then I'm 3 clicks away
[11:48] <lifeless> kiko: do you want me to file that bug ?
[11:48] <kiko> how many clicks away would you like to be?
[11:48] <kiko> lifeless, I've done it already
[11:49] <salgado> I'd like to be one. :)
[11:49] <lifeless> kiko: oh, is dilys just slow ?
[11:49] <kiko> I seem slow but I get there
[11:49] <bradb> salgado: i agree. i was just thinking the same thing earlier today (no joke)
[11:49] <kiko> dilys ignores the new format
[11:49] <lifeless> kiko: ..AH..
[11:49] <kiko> salgado, one-click. hmm. would be tough. two-clicks we can manage.
[11:49] <lifeless> thanks
[11:49] <kiko> enjoy
[11:50] <bradb> kiko: maybe this is another hint that the context-sensitive page should be the first thing one sees when one clicks on a bug?
[11:50] <kiko> well
[11:50] <kiko> perhaps
[11:50] <kiko> it would still be 2 clicks away
[11:50] <kiko> I'm okay with putting the "latest bugs filed on product X" portlet on the task page
[11:51] <kiko> would that make you both happier?
[11:51] <kiko> (we have portlets, why not go crazy :-( )
[11:51] <bradb> heh!
[11:51] <bradb> i previously put the status portlet on that page, actually
[11:51] <bradb> er, *stats*
[11:51] <bradb> but yeah, recent bugs, hmm...
[11:52] <bradb> what about in an actions portlet?
[11:52] <kiko> I hate those
[11:52] <kiko> but more importantly
[11:52] <kiko> which actions portlet? they are shared between bug and task currently, no?
[11:52] <kiko> oh, worse
[11:52] <kiko> there is none :)
[11:53] <bradb> kiko: here's the thing: when you're viewing a task, you can't click to go to the edit screen.
[11:53] <bradb> which was the first hint that we probably need an actions portlet on the task page
[11:53] <bradb> to toggle between view and edit
[11:53] <kiko> if you're logged in you can't actually go to the view page
[11:53] <kiko> is that a problem?
[11:53] <bradb> if we had that, it may become an obvious place to put the link to the "More Foo Bugs"
[11:54] <bradb> kiko: in practice, i watched a user experience the problem by getting all the way to the task page before realizing "oh, crap, i'm not logged in"
[11:54] <bradb> even if they login to that page, they're still only viewing.
[11:55] <kiko> yeah, that's arguably a bug
[11:55] <kiko> I noticed it the other day while testing that page
[11:55] <bradb> btw, i *hate* actions portlets too, but i think sabdfl has declared that we're standardizing them, until we have a menu system sufficient enough for the actions to be migrated into real menus (the lp menu thing is a step in the right direction)
[11:56] <bradb> and, with that in mind, i've watched how users become quickly accustomed to looking in the top right corner when they want to do "something"
[11:57] <bradb> kiko: are you suggesting that the view page show always redirect a logged-in user to the +edit page?
[11:57] <bradb> (what if they can't edit the page?)
[11:57] <kiko> I'm not suggesting anything, just thinking
[11:57] <kiko> ;)
[11:59] <bradb> kiko: could such an actions portlet, if it existed, also be the entry point to the reassignment workflow?
[11:59] <sabdfl> hey guys
[12:00] <bradb> hey sabdfl
[12:00] <sabdfl> lifeless: odd failure to merge with 1.4, trying now with 1.5
[12:00] <lifeless> sabdfl: !!version_end ?
[12:00] <sabdfl> yes
[12:00] <kiko> bradb, you are trying to make me cry now
[12:00] <lifeless> sabdfl: use --star-merge. its a bug that I need to look at.,
[12:00] <lifeless> sabdfl: I don't know the cause yet :[
[12:00] <sabdfl> star merge seems to be failing too
[12:01] <sabdfl> i'm pretty sure there are new commits to rf
[12:01] <lifeless> sabdfl: oh, thats unpleasant, and unusual.
[12:01] <bradb> kiko: i prefer to call it "brainstorming" :)
[12:01] <sabdfl> and it's saying skipping empty delta
[12:01] <dilys> Merge to<EMAIL_ADDRESS>[rs=sabdfl]  Change the column sorting Javascript code in Launchpad, and activate column sorting for the distibution release language status summary. (patch-2092<EMAIL_ADDRESS>[12:01] <lifeless> sabdfl: 'baz missing -s<EMAIL_ADDRESS>[12:01] <kiko> Command was successful.
[12:01] <bradb> wow, that seems to indicate pqm is working again
[12:01] <kiko> PQM!
[12:01] <kiko> wow!
[12:02] <kiko> sabdfl, that one was for you
[12:02] <lifeless> bradb: yes, there is a bug in the librarian test suite.
[12:02] <lifeless> bradb: I had to delete its stale working dir :[
[12:02] <sabdfl> lifeless: trying to merge RF into<EMAIL_ADDRESS>[12:02] <lifeless> sabdfl: sure - what does the command I posted output ?
[12:02] <kiko> man that message was horrible
[12:04] <sabdfl> lifeless:
[12:04] <sabdfl> slinky% baz missing -s<EMAIL_ADDRESS>[12:04] <sabdfl><EMAIL_ADDRESS>[12:04] <sabdfl>     [rs=sabdfl]  Change the column sorting Javascript code in Launchpad, and activate column sorting for the distibution release language status summary.
[12:04] <lifeless> sabdfl: right, thats the only missing patch, and it just landed. star merge was working ok.
[12:04] <lifeless> but the message sucks.
[12:06] <sabdfl> ah
[12:06] <lifeless> https://launchpad.ubuntu.com/malone/bugs/1435
[12:07] <lifeless> sabdfl: star-merge will work fine for you now.
[12:08] <lifeless> sabdfl: there was a problem with merging overnight, the librarian had left behind a stale working dir, which broke the test suite for subsequent runs. We've filed a bug on it and removed the current working dir, so those planned merges are now good to go.
[12:08] <lifeless> sabdfl: got a second to talk PQM ?
[12:10] <lifeless> kiko: any chance of someone meeting me at the airport ?
[12:11] <lifeless> kiko: my portugeuse is non-existant :[
[12:12] <kiko> lifeless, everybody (but sabdfl) will be picked up at the airport, haven't you been reading the sprint page?
[12:13] <sabdfl> lifeless: ok, thanks
[12:13] <lifeless> kiko: semi regularly l)
[12:14] <lifeless> sabdfl: busy there ?