[02:25] <spiv> Morning everyone.
[04:14] <purple_cow> Can I get some administrative help?  I need the no language deleted from https://launchpad.net/products/xchat-gnome/trunk/+pots/xchat-gnome
[05:59] <mpt> Goooooooooooooooooooood afternoon Launchpadders!
[06:15] <bluefoxicy> hi
[06:24] <lifeless> I want to make a spec on pqm
[06:25] <lifeless> but have it visible in the bzr project
[06:25] <lifeless> is that possible ??
[06:25] <lifeless> erm
[06:25] <lifeless> bzr product
[06:36] <lifeless> mpt: any suggestions for https://launchpad.net/products/bzr/+spec/0.10-release-process ?
[07:20] <mpt> lifeless, arrange the dependency levels horizontally instead of vertically
[07:21] <mpt> That way you know they're only ever going to be three ovals wide, so they're less likely to overflow
[07:22] <mpt> Also, the specification shouldn't link to itself
[07:22] <mpt> and "Remove Dependency" should have a "-" icon, not a "+" icon
[07:23] <bluefoxicy> mpt: https://launchpad.net/distros/ubuntu/+spec/automated-problem-reports
[07:24] <mpt> Oh, so it's unlimited depth?
[07:24] <mpt> Then there's no hope
[07:25] <mpt> But, rounded rectangles would be more compact than ovals
[07:25] <bluefoxicy> to be fair I think I'm the only one to cause that situation with my whoring of pitti's spec :)
[07:25] <bluefoxicy> mpt:  there's another spec that I haven't made that would have I think 6 horizontal dependencies
[07:26] <bluefoxicy> I haven't added it to +spec/ because, well, people would think I'm crazy.
[07:26] <mpt> And, the clickable items in the graph should look more clickable.
[07:26] <mpt> And, "Dependency tree:" shouldn't end in a colon.
[07:26] <bluefoxicy> invert colors when mouse passes over?  :P
[07:27] <bluefoxicy> oho it's a map
[07:32] <mpt> No, that wouldn't make them look more clickable until it was too late
[08:09] <mpt> lifeless / BjornT / spiv, where is the latest location of the zope tree?
[08:09] <mpt> bzr pull --remember sftp://sodium.ubuntu.com/home/warthogs/archives/rocketfuel/zope/3.2/ gives me "0 revision(s) pulled"
[08:10] <BjornT> mpt: what does bzr revno in your zope tree say?
[08:10] <mpt> BjornT, 36
[08:12] <BjornT> mpt: ok, then it should be up to date, i think. that's the revision containing stub's test setup changes.
[08:13] <BjornT> mpt_: ok, then it should be up to date, i think. that's the revision containing stub's test setup changes.
[08:17] <mpt_> ok, thanks BjornT 
[08:24] <sabdfl> BjornT: do you know how i use stub's mechanism to leave a message to be displayed on the next page load?
[08:25] <sabdfl> ah
[08:25] <sabdfl> BrowserNotificationMessages
[09:01] <sivang> morning
[09:17] <Sp4rKy> elmo ping ?
[09:24] <sabdfl> lifeless: not currently possible, would you like to write a spec on how that would look-and-feel?
[09:27] <sivang> hey sabdfl 
[09:29] <sabdfl> hi sivang
[09:29] <carlos> morning!
[09:30] <sivang> morning carlos 
[09:30] <carlos> sivang: hey dude!, how's going?
[09:30] <sivang> carlos: fine, fine, you?
[09:31] <carlos> well... I would prefer to have more vacations ;-)
[09:31] <lifeless> sabdfl: added that as a TODO
[09:32] <sivang> carlos: heh
[09:32] <carlos> but is time to start working again...
[10:13] <ddaa> Good morning.
[10:13] <sivang> morning ddaa 
[10:17] <ddaa> Hi sivang
[10:18] <Sp4rKy> please
[10:18] <Sp4rKy> i've an @ubuntu.com adress but doesn't appears to LP
[10:19] <lifeless> Seveas: do you run ubugtu ?
[10:19] <Seveas> lifeless, yes
[10:19] <lifeless> suggestion for you
[10:19] <lifeless> in a single channel, if a bug is mentioned twice in a short period, STFU about it :)
[10:20] <lifeless> (optionally check if its changed its summary or status I guess)
[10:20] <Seveas> that's a plan
[10:20] <lifeless> ubugtu can get quite disruptive otherwise
[10:21] <Seveas> I'm not near the code now, could you file it as a bug (product: ubuntu-bots)
[10:21] <lifeless> done
[10:23] <Seveas> ta
[10:24] <carlos> Sp4rKy: did you added and confirmed it ?
[10:25] <carlos> lifeless: hi
[10:25] <lifeless> carlos: hi
[10:25] <carlos> lifeless: should the 'launchpad' user have access to staging's database as the user 'postgres' ?
[10:25] <lifeless> no
[10:26] <carlos> hmmm... I think stuart suggested that in one email... perhaps he was talking about my user. Let me try..
[10:26] <lifeless> access as postgres will give you access to all the user passwords etc
[10:26] <lifeless> so its tightly constrained even on staging
[10:26] <carlos> lifeless: ok, it has, but if you select the right database
[10:26] <Sp4rKy> carlos i have to add it manualmly ?
[10:27] <carlos> Sp4rKy: I think so
[10:30] <Sp4rKy> but it is forwarded to my other adress :/
[10:31] <spiv> Sp4rKy: yeah, @ubuntu.com addresses aren't automatically added to launchpad at the moment.  So long as you can receive mail there, you should be able to add it to your existing launchpad account just fine, though.
[10:32] <Sp4rKy> k
[11:07] <sabdfl> malcc: morning. did kiko catch you on friday?
[11:09] <ddaa> lifeless: jamesh: mpool: spiv: bazaar meeting in 51 minutes, please put proposed agenda items on the wiki
[11:09] <ddaa> jamesh: is SteveA somewhere around?
[11:11] <carlos> lifeless: about our previous talk
[11:12] <malcc> sabdfl: Morning, I saw his email about a soyuz design session this week
[11:12] <carlos> lifeless: launchpad user on asuka has rights to connect as postgres user
[11:12] <carlos> I got an error because I was connecting to the wrong database
[11:12] <sabdfl> malcc: tomorrow ok?
[11:13] <malcc> sabdfl: Tomorrow is fine, but I'll have to be back in town for 6pm
[11:14] <sabdfl> i was thinking we would do it at Docklands, sound OK?
[11:14] <malcc> Yes, that's fine. Is that the novotel near the exhibition center where I was interviewed?
[11:18] <jamesh> ddaa: he is here, but talking
[11:20] <sabdfl> yes
[11:27] <carlos> danilos: I just handled XaraLX translations, if he confirms that everything is ok, I will request the removal on production
[11:28] <danilos> carlos: ok, can you also send me the queries, so I at least have them in case of a need
[11:28] <carlos> sure
[11:28] <danilos> carlos: also, I'd like to have your latest stuff for edgy opening if it's not in your branch (it isn't, right? ;)
[11:28] <carlos> it should be there...
[11:28] <danilos> carlos: ah, ok, sorry for assuming incorrectly then :)
[11:28] <carlos> the only changes I have on staging is to disable the statistics updates
[11:29] <sivang> do I need to talk to mpt about a change that adds something visually to a page? (that is, it's outside controls and such)
[11:29] <carlos> I need to push my changes to test them on staging ;-)
[11:29] <sivang> malone #3186
[11:29] <Ubugtu> Malone bug 3186 in blueprint "New spec form has undescribed no-capitals constraint" [Medium,Confirmed]  http://launchpad.net/bugs/3186
[11:29] <danilos> carlos: sure, go ahead :)
[11:30] <danilos> carlos: I've got another "critical" bug to work on, so I'll do that now
[11:30] <carlos> cool
[11:30] <sivang> ah oops, not a change actually, only a small addition. cool
[11:50] <jamesh> lifeless: have you had a chance to look at packaging the tickcount module yet?
[11:50] <sivang> labas SteveA 
[11:51] <lifeless> jamesh: meep meep meep.
[11:51] <lifeless> I got distracted by debian changing python policy
[11:51] <SteveA> h isivan
[11:51] <lifeless> jamesh: I'm packaging it for Ubuntu right ?
[11:51] <SteveA> lifeless: what's the python policy change?
[11:52] <lifeless> SteveA: rather than having python-FOO and python2.4-FOO for regular python packages, there is now a system that builds a symlink farm for all installed pythons
[11:52] <SteveA> I see
[11:52] <lifeless> and thus you have just one python-FOO package which supplies the module to all pythons
[11:52] <SteveA> does this work in all cases/
[11:52] <SteveA> ?
[11:53] <sivang> lifeless: What are you packaging ?
[11:53] <lifeless> sivang: tickcount
[11:53] <SteveA> I'd guess there are exceptions where there are different released versions for different pythons
[11:53] <sivang> lifeless: ah, cool
[11:53] <lifeless> sivang: a diagnostic extension SteveA wrote
[11:53] <sivang> lifeless: I know, I already looked at it :-)
[11:53] <lifeless> SteveA: right. its made the common case much simpler. The uncommon case still needs separate packages for each python
[11:53] <sabdfl> https://help.launchpad.net/ComingFeatures/EssentialSpecificationSubscribers
[11:53] <sabdfl> need a star that is less obviously from google :-)
[11:54] <lifeless> SteveA: i.e. binary modules, or incompatible python codebases for different pythons etc
[11:54] <sivang> sabdfl: oh, goody
[11:55] <jamesh> lifeless: I think that was the plan
[11:55] <lifeless> jamesh: 'we' have been involved with it
[11:55] <lifeless> I dont know if edgy is doing the transition yet... I'll ask
[11:56] <sabdfl> jamesh: will you update your scheduler to look at SpecificationSubscription.essential when that lands, please?
[11:56] <lifeless> ok, edgy has. cool
[11:57] <jamesh> sabdfl: sure.
[11:57] <sabdfl> jamesh: there is also a DISCUSSION state for specs
[11:57] <sabdfl> so drafting vs discussion can be explicit
[11:57] <sabdfl> i.e. if the state is discussion, then it needs a discussion session
[11:57] <sabdfl> if the state is drafting, then it needs drafting
[12:01] <danilos> carlos: ping
[12:01] <carlos> danilos: pong
[12:02] <sivang> sabdfl: this is result of the weekend hacking? :-)
[12:02] <danilos> carlos: on xaraxl issue: do you have a list of translators whose translations we should keep?
[12:02] <lifeless> ddaa: is it meeting time ?
[12:02] <danilos> carlos: perhaps it's better to do queries in the form of "person NOT IN ..."
[12:02] <ddaa> Yup
[12:02] <ddaa> Finishing preparing.
[12:03] <carlos> danilos: I prefer to remove only the ones that I was told to remove
[12:03] <carlos> danilos: and remove later anything else
[12:03] <carlos> than remove something by mistake
[12:03] <danilos> carlos: well, from the last email he sent I got the impression that he sent the list of translators who are allowed to translate it
[12:03] <carlos> just because someone forgot to gave me that name...
[12:03] <ddaa> jamesh: -> #launchpad-meeting
[12:03] <carlos> danilos: he sent the list of allowed, and the list we should remove
[12:04] <carlos> but we cannot undo removals
[12:04] <danilos> carlos: yeah, it makes sense, but it's a much more clear-cut 
[12:04] <carlos> so I prefer to take the less destructive operation ;-)
[12:04] <danilos> I agree, but how come there is a romainian single translated entry?
[12:05] <danilos> s/romainian/romanian/
[12:11] <carlos> danilos: URL?
[12:11] <danilos> carlos: well, read the Neil's response
[12:12] <carlos> I see...
[12:12] <carlos> let me check
[12:14] <danilos> carlos: https://staging.launchpad.net/products/xaralx/0.4/+pots/xaralx/ro/+translate?batch=10&show=translated, space is translated
[12:14] <carlos> yeah, I saw it
[12:14] <danilos> carlos: though, it's on production as well
[12:15] <danilos> how does one tell who did the translation?
[12:15] <carlos> yeah, seems like that guy did translations after we close it
[12:15] <carlos> danilos: well, that's one of our remaining UI bugs
[12:16] <danilos> carlos: ah, ok, I don't think I am assigned to that one :)
[12:16] <sivang> Can anyone please tell me, where I find the files/templates responsible for example, for what the +addspec page contains when access? (specifically stationary text on that page)
[12:18] <carlos> sivang: look inside zcml/ directory
[12:18] <matsubara> sivang: you should look on the zcml for the addspec 
[12:18] <carlos> there you have the link between the pagetemplates and the URLs
[12:19] <sivang> carlos, matsubara : gazil thanks.
[12:25] <sabdfl> stub: https://sodium.ubuntu.com/~andrew/paste/filexJOZb6.html
[12:25] <sabdfl> please review, and if ok let me have a number? thanks
[12:26] <sabdfl> sivang: it's the visible tip of the weekend, yes
[12:34] <danilos> stub, carlos: if I run a query, and later modify it slightly, how do I purge postgres' cache so I can time it again?
[12:35] <carlos> danilos: no idea
[12:35] <carlos> danilos: perhaps restarting postgres...
[12:35] <danilos> carlos: well, I guess I can't do that with staging ;)
[12:36] <carlos> right ;-)
[12:36] <mpt> grumph
[12:36] <carlos> danilos: anyway, timing things on staging in the morning is not a good idea
[12:37] <carlos> danilos: language packs are being generated atm
[12:37] <mpt> Who knows about KarmaContext? salgado I guess
[12:37] <sivang> matsubara, carlos : I've found specification-add.pt but I can't see where to change the text explaining about the rules for the .name attribute
[12:38] <sivang> hey mpt 
[12:38] <danilos> carlos: well, I am looking for really big differences (like a hundred times faster, so I don't care about the 10x slowdown) don't know if language-pack generation cares :)
[12:38] <mpt> hi sivang, how's hacking
[12:38] <danilos> mpt: carlos should know about karmacontext as well :)
[12:38] <sivang> mpt: good , good, started to get along with testbrowser, even converting 2 tests in specs/ to testbrowser, just to make my patch look cooler to kiko ;-)
[12:39] <sivang> mpt: part of a fix to malone #52038
[12:39] <Ubugtu> Malone bug 52038 in blueprint "Please rename "Braindump" state to "New"" [Wishlist,In progress]  http://launchpad.net/bugs/52038
[12:39] <carlos> danilos: no, language packs doesn't care about it
[12:40] <carlos> sivang: is an edit or add form ?
[12:40] <sivang> carlos: add form
[12:40] <sivang> carlos: "Register a feature specification.."
[12:40] <carlos> sivang: in that case, I guess the form is autogenerated and you can get those descriptions from the interface
[12:40] <carlos> inside the  interfaces/ directory
[12:41] <sivang> right, looking there then
[12:41] <carlos> we use the interfaces documentation to render those forms
[12:41] <sivang> cool, tanks
[12:41] <sivang> err, thanks that is
[12:41] <carlos> mpt, danilos: I know a bit of that, but just because I talked with salgado about the spec
[12:41] <carlos> mpt: what do you need?
[12:42] <mpt> carlos, two of my branches failed PQM in lib/canonical/launchpad/doc/karmacontext.txt
[12:42] <mpt> And I wasn't touching karma stuff in either of them
[12:42] <carlos> could I see the error?
[12:43] <mpt> one moment
[12:43] <danilos> carlos: sorry, I thought you were also the one to implement it
[12:43] <carlos> I don't know anything about those tests but perhaps I see something obvious that gives you a clue...
[12:43] <carlos> danilos: no ;-)
[12:43] <jamesh> mpt: I have a fix for the karmacontext bug, but couldn't land it due to 30-mergepeople.txt errors
[12:44] <mpt> heh
[12:44] <jamesh> the test in question is unreliable
[12:44] <mpt> jamesh, is that 30-mergepeople.txt problem the one that's been around for months?
[12:44] <danilos> guys, guys, can't you write bug-freeTM code? :P
[12:44] <spiv> jamesh: hah.
[12:44] <jamesh> mpt: I think so
[12:45] <mpt> ok, I'll queue up after you then jamesh
[12:45] <mpt> unless it's an easy fix that I can try landing as well
[12:45] <spiv> danilos: it's writing bug-free tests that's the tricky bit sometimes ;)
[12:46] <mpt> Writing test-free bugs, on the other hand, that's easy
[12:46] <lifeless> bug 51130
[12:46] <Ubugtu> Malone bug 51130 in launchpad-bazaar "cannot rename a branch I own" [Critical,Confirmed]  http://launchpad.net/bugs/51130
[12:46] <danilos> spiv: then lets skip that step \o/
[12:46] <danilos> mpt: yeah :)
[12:46] <jamesh> mpt: this is the fix I made: https://sodium.ubuntu.com/~andrew/paste/filerkk5v9.html
[12:49] <lifeless> jamesh: ok, so dyson
[12:49] <lifeless> jamesh: I think: 1/ eliminate recursion, 2/ leave the version constraints etc at the moment - see how it goes
[12:50] <lifeless> jamesh: we can add recursion if needed, or do globl matching for x dirs - i.e. location/*/*.tar.gz in the future
[12:50] <jamesh> lifeless: it sounds like eventually we want another field to say whether recursion is required
[12:50] <lifeless> right, but lets iterate
[12:50] <lifeless> how does that sound ?
[12:51] <lifeless> is it compatible with the feedback you got ?
[12:51] <jamesh> sounds good.
[12:52] <jamesh> turning off recursion should hopefully get it to do something
[12:52] <lifeless> ok, thats good. I realise it will be a bit before you get back to it, but I'm really keen to get this deployed - so please let me know if you get other things assigned to you that will delay this
[12:52] <lifeless> reviewer meeting in 8 minutes
[12:53] <mpt> thanks jamesh
[12:54] <jamesh> mpt: you could try putting that fix in and see if you can merge successfully
[12:54] <jamesh> mpt: perhaps that'll make the 30-mergepeople.txt test go away for me :)
[12:55] <mpt> Yes, I've stuck it in both branches (momentarily flummoxed by that test not yet existing in one of the branches:-)
[12:55] <mpt> ah, foo, with a repository I can't push multiple branches simultaneously
[12:56] <sivang> carlos, matsubara : yay, found it.
[12:56] <lifeless> reviewer meeting in 4 minutes
[12:57] <carlos> sivang: hint, use "grep -r 'the string you want to find'"
[12:57] <carlos> it's really helpful to learn where are those strings
[12:57] <spiv> I often type "grep -Irn ...", it's a handy combination of flags.
[12:58] <spiv> The -I is a really lazy way to filter out .pyc files :)
[12:58] <sivang> carlos: tried with -ril, which gave nothing when I searched for "mozilla-type-ahead-find, postgres-smart-serial." that appear is examples for spec names.
[12:58] <mpt> ahhhh, nifty
[12:58] <carlos> I see
[12:58] <sivang> carlos: was probably a bad search string...
[12:59] <sivang> spiv: oh cool!
[12:59] <lifeless> review meeting time
[01:00] <SteveA> lifeless: any plans to do the conversion of old branch data onto sodium?
[01:00] <lifeless> SteveA: after the meeting please
[01:00] <lifeless>  * Roll call
[01:00] <lifeless>  * Agenda
[01:00] <lifeless>  * Next meeting
[01:00] <lifeless>  * Queue status.
[01:00] <SteveA> i typed that before you said "meeting time" :-)
[01:00] <lifeless> 20:59 < lifeless> review meeting time
[01:00] <lifeless> 21:00 < SteveA> lifeless: any plans to do the conversion of old branch data onto sodium?
[01:00] <lifeless> not as far as my irc client knows :)
[01:01] <SteveA> I'd like to add to this agenda "reviewing Trivial branches"
[01:01] <SteveA> or "trivial commits"
[01:01] <lifeless> ok
[01:01] <lifeless> whose here ?
[01:01] <lifeless> spiv: ping
[01:01] <lifeless> jamesh: ping
[01:01] <spiv> me
[01:01] <lifeless> BjornT: ping
[01:01] <SteveA> my here
[01:01] <jamesh> here
[01:01] <lifeless> next meeting - monday coming, same time ?
[01:02] <SteveA> +1
[01:02] <BjornT> here
[01:02] <lifeless> 2006-08-15 at 1100 UTC. it is
[01:02] <spiv> sure
[01:02] <lifeless> ok
[01:02] <lifeless> queue status
[01:03] <lifeless> 11 branchs in the main queue
[01:03] <lifeless> oldest is 51 days which I believe to be bogus
[01:03] <lifeless> jamesh: any input on that rather large # ?
[01:04] <jamesh> lifeless: I think the branch was entered with a cut-n-pasted date originally and my code believes the dates for new branches
[01:04] <lifeless> this has happened before
[01:04] <jamesh> either that or it picked up the date from the last time cprov put the branch up
[01:04] <spiv> I'm curious about why after 9 days salgado still hasn't reviewed a one-line change of mine ;)
[01:04] <lifeless> it really screws up the process. Can you make analysing and fixing this a high priority please? (If SteveA agrees)
[01:05] <jamesh> since he's used "cprov/launchpad/queue-ui" as a long running branch
[01:05] <spiv> jamesh: can you perhaps 
[01:05] <lifeless> other than that : Oldest (non-bogus date) is 16 days with steve, then 12 with kiko and 10 with jamesh. Our sevice level is slipping
[01:05] <spiv> extract the date of the earliest unmerged revision in the relevant branch?
[01:05] <lifeless> I mailed the reviews list last week with a nag.
[01:06] <lifeless> spiv: jamesh: I've no opinion about the best way to implement - can you discuss post-meeting ?
[01:06] <SteveA> the 16 day thing is blocked on some production changes
[01:06] <lifeless> SteveA: doing the review is blocked ?
[01:06] <SteveA> yes.  I don't want to look at it before I know what it needs to fit with.
[01:07] <lifeless> ok. This should be work-in-progress then surely ?
[01:07] <SteveA> I'm -0 on jamesh analysing and fixing a problem caused by people not using [@DATE@]  correctly
[01:07] <SteveA> I think we should tell people just to use [@DATE@]  by email and in the next launchpad dev meeting
[01:07] <lifeless> (if what its fitting with is not done yet, how can it be ready to review ?)
[01:07] <SteveA> and only if that fails to address the problem
[01:07] <SteveA> to look for a technological solution
[01:08] <SteveA> lifeless: that branch can be moved to w-i-p
[01:08] <SteveA> it can be WIPed from my queue
[01:08] <lifeless> SteveA: in this sort of situation, please do that rather than sitting on the branch. 
[01:08] <SteveA> ok
[01:08] <lifeless> I'm moving it now
[01:09] <SteveA> ok
[01:09] <lifeless> is there a similar issue with flacoste/launchpad/tt-search ?
[01:09] <lifeless> which is in kiko's queue 
[01:10] <SteveA> no idea
[01:10] <lifeless> jamesh: david/launchpad/importd-bzr-native is in your queue. You've been overseas for an extended duration right ?
[01:10] <spiv> (Thinking of [@DATE@] , it appears salgado forgot it entirely for a branch of his in my queue, so I'm +1 on a reminder about it by email/at the lp meeting)
[01:11] <lifeless> ok, lets do an email reminder - SteveA can you do the agenda thing for lp, I'll send an email to launchpad@ after this meeting
[01:11] <jamesh> lifeless: yeah.  I'll try and get to my two oldest ones early this week, but the other two would probably be better to reallocate
[01:11] <SteveA> ok
[01:11] <lifeless> jamesh: ok. BjornT is back, BjornT - are you willing to take flacoste/launchpad/tt-bug-fixes and cprov/launchpad/small-fixes ?
[01:12] <BjornT> lifeless: sure
[01:12] <lifeless> thanks - can you update PendingReviews ?
[01:12] <lifeless> ok, that should reduce it from crisis situation
[01:12] <BjornT> ok
[01:12] <jamesh> updated
[01:12] <lifeless> I'll send another nag email tomorrow, directly rather than just noted in the message header for everyone
[01:13] <lifeless> thats to grab kiko and salgados attention
[01:13] <lifeless> SteveA: you will be around when kiko and salgado show up right? can you draw their attention to reviews for me please ?
[01:13] <SteveA> I'll be in meetings here
[01:13] <SteveA> so probably not
[01:13] <lifeless> oh.
[01:13] <lifeless> ok
[01:13] <lifeless> BjornT: could you ?
[01:14] <SteveA> lp infrastructure sprint in progress
[01:14] <SteveA> I'm just taking time out for the bzr and review meetings
[01:14] <BjornT> lifeless: sure, i'll do that
[01:14] <lifeless> thanks!
[01:14] <lifeless> ok.
[01:14] <lifeless> trivial branch reviews (stevea)
[01:14] <SteveA> ok
[01:15] <SteveA> we've talked in the past about adding links to the emails from PQM
[01:15] <SteveA> so that reviewers can, with a single click, see the code changes that have been committed
[01:15] <SteveA> this will plug a gap in our reviews, in checking that [trivial]  commits really are trivial
[01:15] <SteveA> often someone thinks something is trivial, but it really is not
[01:16] <SteveA> even though it is just a few lines of code, it has other issues
[01:16] <SteveA> today, lifeless set up a branch browser on devpad.c.c
[01:16] <SteveA> I've asked the admins to make the browser available to the outside world via apache + certificate
[01:16] <SteveA> I'd like someone to make PQM emails contain links to appropriate places in the branch browser
[01:17] <SteveA> lifeless: what needs changing in our PQM setup to make this so?
[01:17] <lifeless> the email sending plugin needs code changes to add the link
[01:18] <lifeless> the exact structure I dont have mapped in my head, but it will require changes
[01:18] <SteveA> where is the code that needs hacking on?
[01:18] <SteveA> i'd like to give this to jamesh to hack on
[01:18] <lifeless> https://launchpad.net/products/bzr-email
[01:18] <lifeless> is the current email sending facility
[01:19] <lifeless> we mirror the structure from balleny to sodium
[01:19] <lifeless> so some local path algebra should be enough to setup the correct browser url, without needing PQM's magic URL knowledge.
[01:20] <lifeless> jamesh: while you are at it, if you could review matthieu moys improvements which are in malone, that would be great - and it may well help what you are doing
[01:20] <SteveA> there is a spec on what we want from PQM emails
[01:20] <jamesh> lifeless: okay.  For the browser URL, I think we just need a URL base and the PQM commit revision ID
[01:21] <lifeless> yes, that requires signficantly more effort and a complete change in how the emails are generated and sent
[01:21] <lifeless> jamesh: thats what I'm thinking too - just a new parameter to the plugin to add this link, turned on by the present of the URL base
[01:22] <lifeless> ok, anything more on this ?
[01:22] <SteveA> any idea where that spec is?
[01:23] <SteveA> https://launchpad.canonical.com/PQMCommitMessages
[01:23] <jamesh> lifeless: I guess letting the user provide a format string would be a good way to do it genericly (substituting in public branch URL, revision number and revision ID as needed)
[01:23] <lifeless> jamesh: start with the simplest approach IMO
[01:23] <lifeless> jamesh: which I'll happily let you define
[01:23] <SteveA> that's all from me
[01:24] <lifeless> ok, any other business ?
[01:24] <lifeless> 5
[01:24] <lifeless> 3
[01:24] <lifeless> 2
[01:24] <lifeless> 1
[01:25] <lifeless> thanks for coming, meeting is done
[01:28] <carlos> later!
[01:31] <SteveA> mpt: still around?
[01:32] <SteveA> lifeless: and after the review meeting...
[01:32] <SteveA> lifeless: any plans to do the conversion of old branch data onto sodium?
[01:33] <lifeless> yes, plans, but currently I have no time allocated to that
[01:33] <lifeless> nor any expected for another 7 weeks
[01:34] <SteveA> lifeless: does it have to be you who does this, or could someone else?
[01:34] <lifeless> someone else can ensure that all the data is converted and prepare a branch with the ghosts filled
[01:34] <lifeless> stub or I have to do the actual merge of data into rocketfuel itself
[01:35] <lifeless> plus I'll need to write a bzr script to refresh all the annotation data in rocketfuel itself, which is needed to get the right answers to bzr annotate
[01:35] <lifeless> btw, right now you should get useful answers to annotate, just not complete ones - it will show the merged revision in the mainline
[01:35] <lifeless> which you can see who it came from easily
[01:35] <SteveA> wasn't so useful
[01:36] <SteveA> I got lots of "pqm@.... " and only a few actual names
[01:36] <SteveA> quite a few blank lines too
[01:36] <lifeless> can I ask you chat with spiv / jamesh / me next time you try to do this
[01:36] <lifeless> as it may be a UI issue
[01:36] <SteveA> ok
[01:36] <SteveA> I was chatting with mpool last time, btw
[01:37] <SteveA> and I think he identified a UI issue from it
[01:37] <sivang> Is it gramtically correct to say something like "May contain lowered case letters, numbers, and dashes only..."
[01:37] <SteveA> but I don't recall the details
[01:37] <sivang> ?
[01:37] <SteveA> no
[01:37] <SteveA> "lower"
[01:37] <SteveA> not "lowered"
[01:37] <SteveA> and "lower-case"
[01:37] <sivang> SteveA: cool, thanks
[01:37] <SteveA> not "lower case" I think
[01:37] <SteveA> in this specific case
[01:37] <lifeless> SteveA: ok. gotta run, brain melting from multiplexing too mcuh
[01:37] <SteveA> ok
[01:37] <SteveA> thanks for the update about these things
[01:38] <sivang> so only "lower letters" ?
[01:38] <SteveA> sivang: no
[01:38] <SteveA> "lower-case letters"
[01:38] <sivang> SteveA: thanks.
[01:40] <danilos> ha, the neighbour pulled carlos' cable out :)
[01:41] <sivang> heh
[01:44] <sivang> can I put a test that validates an interface's attribute description in pagetests/specs or should it be put in another place, testing not "real" functionality, but rather and interface's documentation?
[01:44] <sivang> note that this attribute description is used all over, not just in specificaiton
[01:44] <sivang> (s)
[01:45] <sabdfl> SteveA: en route shortly. start lunch without me i'll eat before leaving
[01:45] <SteveA> sabdfl: ok
[01:45] <lifeless> night all, going v soon
[01:46] <danilos> stub: ping
[01:47] <sivang> ah no, my bad, this is only for specifications.
[01:50] <sivang> ah, doc/specification.txt seems to be the right place.
[01:55] <sabdfl> cheers lifeless, good work on the bzr 0.10 release management front
[01:56] <sabdfl> BjornT: what's the email address to subscribe wiki pages to?
[01:57] <sabdfl> in order that wiki changes be communicated to spec subscribers
[01:57] <BjornT> sabdfl: notifications at specs.launchpad.net
[02:00] <sabdfl> BjornT: thanks muchly. and the wiki just has to put the changed url in there, right?
[02:01] <BjornT> sabdfl: exactly
[02:55] <sivang> kiko dude!
[02:55] <kiko> hey sivang 
[02:56] <kiko> how goes it
[02:56] <sivang> kiko: can I send you a trivial that seems to me like it will fix #3186 , a proper error message is already there.
[02:56] <kiko> sure
[02:56] <sivang> kiko: cool, I suspect you haven't had time to review my patch ?
[02:56] <sivang> kiko: (the big one..)
[02:57] <kiko> sivang, will have time this week
[02:57] <kiko> it's not very big though
[02:57] <sivang> right, I shoudl have said "big"
[02:57] <sivang> :-)
[02:58] <danilos> kiko: review 44860, only test changes (this message tagged with "nag" :)
[02:59] <kiko> gool
[03:06] <Yannig> Hello everybody :)
[03:06] <Yannig> Litle dumb question (it's been a long time since the last one :p)
[03:07] <sabdfl> malcc: erk. i have a customer meeting tomorrow
[03:07] <Yannig> On https://launchpad.net/distros/ubuntu/dapper/+lang/oc, why is almost all showing as "new" whereas i've been translating for several months
[03:07] <Yannig> ?
[03:07] <malcc> sabdfl: Ok, I can fit around it if it's not all day, or we can go for Wednesday?
[03:09] <sabdfl> wednesday 1pm sharp, my house ok?
[03:09] <sabdfl> we have till 5pm
[03:09] <malcc> sabdfl: Sure, send a map or suchlike, I've not been to your place before
[03:09] <sabdfl> if we need to look at again we have some gaps thu, fri
[03:09] <sabdfl> round the corner from the office in south ken
[03:10] <sabdfl> clan can point you in the right direction
[03:10] <malcc> Ok thanks
[03:33] <sivang> kiko: sent.
[03:36] <kiko> replied, thanks.
[03:37] <sivang> kiko: yay!
[03:39] <kiko> matsubara! happy to see you safe and sound
[03:39] <SteveA> kikokik
[03:40] <stub> danilos: pong
[03:41] <danilos> stub: hi
[03:41] <danilos> stub: I am trying to time a couple of queries, but after a first run, they are all very fast; how do I clean up postgres cache or whatever?
[03:43] <stub> danilos: PostgreSQL caches in its shared buffers, which can be cleared by 'sudo -u postgres pg_ctlcluster restart', and using your filesystem cache, which can be replaced by reading lots of other files.
[03:43] <danilos> stub: there is nothing I can do for staging? (I need to test with real world data, because I am fixing some requesttimeouts)
[03:45] <kiko> matsubara, did you have a good trip?
[03:45] <matsubara> kiko: it was ok. 
[03:46] <kiko> not good, just ok? lemme guess -- crying baby?
[03:47] <sivang> heh
[03:51] <BjornT> kiko, salgado: lifeless asked me to remind you that you have pending reviews that are rather old in your queue.
[03:51] <kiko> BjornT, I know. thanks.
[03:53] <kiko> stub, ping?
[03:56] <kiko> ddaa, ping?
[03:56] <ddaa> kiko: hello
[03:56] <kiko> ddaa, https://launchpad.net/products/bugzilla/main
[03:57] <kiko> ddaa, if there was a bzr branch import for this, where would I be able to see it?
[03:57] <kiko> (it says auto tested)
[03:57] <ddaa> I'll herd the imports when I come back from workrave
[03:57] <ddaa> you should have branch by the end of the day
[03:58] <ddaa> you would be able to see it on the productseries page
[03:59] <kiko> ddaa, thanks. we should probably move that information to the main product page.
[04:01] <kiko> matsubara, at what time did you arrive at heathrow, btw?
[04:03] <kiko> ddaa, do we have non-trunk imports?
[04:09] <ddaa> kiko: for cvs, no
[04:09] <kiko> ddaa, all right.
[04:10] <ddaa> for svn, since trunk is not special, we cannot really prevent them
[04:10] <ddaa> esp. since imports will eventually become fully automatic
[04:10] <ddaa> but they will not be attached to the trunk history
[04:11] <ddaa> as a rule, we do not support non-trunk
[04:11] <kiko> ah, right.
[04:11] <ddaa> the +source page needs fixing btw
[04:11] <sivang> how do I know when my patches have landed so I can close bugs and dance happily btw?
[04:11] <ddaa> It's on of the medium importance things plan to do at the end of this month, or early next month
[04:12] <kiko> great.
[04:13] <kiko> sivang, matsubara will land them and update your bugs when he has the momemt.
[04:13] <sivang> kiko: cool, gazil thanks.
[04:15] <ddaa> importd is a fussy wore
[04:15] <ddaa> whore
[04:15] <ddaa> it only gives head :)
[04:16] <sivang> heh
[04:22] <danilos> kiko: will you have a spare moment to help me with bug 30602, or should I pester someone else? ;)
[04:22] <Ubugtu> Malone bug 30602 in rosetta "ERROR IN: https://launchpad.net/distros/ubuntu/dapper/+source/vlc/+pots/vlc/tl/+translate" [Critical,Confirmed]  http://launchpad.net/bugs/30602
[04:22] <kiko> danilos, I will have a moment, yes
[04:22] <kiko> I'll ping you in a bit
[04:22] <danilos> kiko: sure
[04:40] <flacoste> BjornT: ping
[04:41] <BjornT> hi flacoste 
[04:41] <flacoste> hi bojrn!
[04:41] <flacoste> sorry, hi Bjorn!
[04:42] <kiko> danilos, ping
[04:42] <flacoste> BjornT: you have been reassigned as my reviewer for my bug fixes branch, do you know when you'll have time to do the review?
[04:43] <danilos> kiko: pong
[04:43] <BjornT> flacoste: i'm reviewing it now
[04:43] <flacoste> BjornT: great, thanks!
[04:58] <BjornT> flacoste: what's the rationale for showing all menu options when a ticket is closed? (i.e, what's the use case for editing a resolved ticket)
[04:59] <flacoste> well, the bug was about the bug linking for which I see a use case (way to document a bug)
[05:00] <flacoste> and I asked kiko about the 'description' and he returned the question as 'why not allow it'
[05:00] <matsubara> kiko: at 7:00, 7:30 IIRC. I was at the baggage retrievel at 8:00
[05:00] <SteveA> malcc: ping
[05:00] <flacoste> so I enable it, but honestly, I don't have any use case in mind
[05:00] <malcc> SteveA: Hi
[05:00] <kiko> thanks matsubara 
[05:01] <flacoste> BjornT: also, at the sprint, we discussed removing the possibility of editing the description of a ticket entirely
[05:01] <matsubara> kiko: I'll land sivang's patch as soon as I have some time here.
[05:01] <kiko> sure. as I said, when you have time
[05:01] <flacoste> since a ticket is more like a conversation than a bug report
[05:01] <ddaa> kiko: import herding done, there was a bunch of autotested imports (mostly stuff that got downgraded to testing after bzr-native), so it may take a little while before everything is processed
[05:02] <SteveA> malcc: could you come to docklands for 1/2 a day tomorrow, to look at some of our webapp stuff -- giving out some of your apple webobjects experience?
[05:02] <SteveA> kiko: would you be okay with this?
[05:02] <malcc> SteveA: Sure
[05:02] <ddaa> kiko: have a look at bugzilla tomorrow, it should be there
[05:02] <Nafallo> ddaa: btw, why aren't the imported branches up-to-date. backuppc for example?
[05:02] <matsubara> sivang: please send me the patch with the last modifications
[05:03] <ddaa> Because the backuppc import is broken
[05:03] <ddaa> interesting
[05:04] <Nafallo> banshee is also behind ;-)
[05:04] <sivang> matsubara: will do. 
[05:04] <BjornT> flacoste: ok, sounds reasonable, it was mostly the description as was concerned about, and i agree that it shouldn't be editable at all. let's keep what you have for now, then. i have one small thing to comment on, though, i'll send an email.
[05:05] <ddaa> Mh, banshee has one of those obscure cscvs failures, cannot help
[05:05] <ddaa> backuppc problem appears obvious
[05:05] <ddaa> if you are lucky, I may be able to fix it with minimal problem
[05:06] <kiko> ddaa, you rock
[05:06] <kiko> SteveA, I think not.
[05:07] <kiko> SteveA, malcc has planning of Soyuz work to do before meeting with mark
[05:07] <Nafallo> ddaa: nice, thanks :-)
[05:21] <flacoste> BjornT: do you want me to also get rid of the **kwargs in the mock object __init__ or only in the setup_menu function?
[05:22] <flacoste> BjornT: otherwise, the setup_menu() can validates the arguments but I can still use the facility of __dict__.update(**kwargs) in the mock object constructor
[05:30] <BjornT> flacoste: i was mainly thinking of setup_menu(). i'm not so concerned about ticket(), since it's not used directly in the tests. 
[05:30] <flacoste> BjornT: fine
[05:37] <ddaa> Some well meaning individual is changing the value of CVS modules of imports that are syncing.
[05:37] <ddaa> I do not know who that is
[05:38] <ddaa> so I broadcast it
[05:38] <ddaa> DO NOT DO THAT
[05:38] <ddaa> there's an explicit assertion so import fails if you do that
[05:38] <ddaa> if the module changes, it's a different import
[05:39] <ddaa> module renaming does not exist in the cvs model, it's changing history
[05:39] <ddaa> and if the module was not renamed there is no valid reason to change the cvsmodule of an existing import
[05:46] <kiko> ddaa, who could that be? only admins or source admins, right?
[05:47] <ddaa> unless there's a bug in the permissions, yes
[05:47] <kiko> I suspect a bug in the permissions.
[05:48] <ddaa> kiko: can you investigate and have it fixed?
[05:48] <kiko> ddaa, you're probably better equipped to do so
[05:49] <ddaa> in short, only admin and source admin are allowed to change source details if importstatus is PROCESSING, SYNCING, or STOPPED
[05:49] <ddaa> kiko: please, I have my plate full
[05:49] <kiko> ddaa, best if you file a bug -- I'm also very busy
[05:49] <ddaa> bah, let them burn
[05:50] <ddaa> I need to fix that stuff eventually, but it's a bit down the todo
[05:55] <ddaa> oh
[05:55] <ddaa> actually that's not it
[05:55] <ddaa> sorry
[05:55] <ddaa> it's a bug in the cvs module alias handling!
[05:56] <Nafallo> yay
[05:59] <ddaa> cvs -d :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome co -c
[05:59] <ddaa> procman      -a gnome-system-monitor
[05:59] <kiko> stub, ping?
[05:59] <ddaa> What You Get Is Not What You Asked For
[05:59] <stub> kiko: pong
[05:59] <kiko> stub, do you have time for us to do the bug cleanup in production today?
[06:00] <ddaa> weeginwhyaff!
[06:00] <stub> kiko: IF you are happy with the existing queries, sure.
[06:00] <kiko> stub, IF you give me a list of the bugs being modified, I'm happy with the first one, and I'll be happy to manually clean up the remaining set.
[06:00] <kiko> stub, once that's done you can run a final delete of the bogus SPNs.
[06:01] <kiko> stub, meaning workflow would be: a) list affected bug IDs b) drop source package name on bugtasks where that can be done c) delete all bogus SPNs we currently can d) tell me what IDs still need fixing e) I fix them f) drop the remaining bogus SPNs.
[06:06] <ddaa> CVS = Confuses Virtue and Sinfulness
[06:08] <stub> That will need to wait for quiet time then
[06:08] <LarstiQ> ddaa: sounds like one for the bzr quote page? ;)
[06:08] <ddaa> Feel free
[06:08] <ddaa> That's the point of quote pages :)
[06:09] <ddaa> Though I find weeginwhyaff a bit more catchy :)
[06:09] <ddaa> and it also applies to hotel restaurants...
[06:10] <LarstiQ> I'm not sure about the ee and one of the fs
[06:11] <Nafallo> lol
[06:11] <kiko> stub, quiet time?
[06:11] <ddaa> ?
[06:15] <kiko> stub, when would be a good time for that?
[07:03] <stub> kiko: So we only wanted to do the update rather than both the update and the delete?
[07:10] <stub> kiko: Bugs that will be affected by the update are at https://sodium.ubuntu.com/~andrew/paste/file9Nffg9.html
[07:11] <stub> kiko: I've run the update. About to trash spns (will take maybe 20 mins)
[07:28] <sivang> matsubara: sending now
[07:32] <bradb> kiko: if you have time this afternoon, maybe we can walk through the nominate/approve/decline UI.
[07:33] <LarstiQ> bradb: https://launchpad.net/products/bzr/bzr.dev/+bugs currently oopses, (bugs of a series), is that intended to work?
[07:48] <sivang> matsubara: sent
[08:01] <kiko> bradb, okay.
[08:01] <kiko> stub, thanks.
[08:04] <kiko> stub, ping me when that's finished and I'll start the bug cleanup procedure.
[08:22] <jamesh> LarstiQ: bugs attached to product series has not been implemented/rolled out yet
[08:22] <LarstiQ> jamesh: is it being worked on?
[08:22] <jamesh> yeah
[08:23] <LarstiQ> any idea when it will be rolled out?
[08:23] <ddaa> yay, importd-bzr-upgrade up for review
[08:23] <ddaa> almost
[08:27] <ddaa> up for review
[08:27] <ddaa> Please tell lifeless when he wakes up.
[08:28] <jamesh> LarstiQ: no idea
[08:29] <LarstiQ> jamesh: it would be useful functionality, we'll see
[08:29] <jamesh> ddaa: there was a guy on #gnome asking about importd imports that were out of date and who to ask about it
[08:29] <jamesh> ddaa: he left before I could talk to him, but I assume he was referring to the rhythmbox import
[08:29] <ddaa> Rythmbox is borked
[08:30] <ddaa> I just looked at the errors and fixed a few easy ones
[08:30] <ddaa> Rythmbox is not one of those
[08:31] <ddaa> CVS.Error: File checkout did not give file data and did not indicate file was removed.
[08:31] <ddaa> i remember I wrote that sanity check
[08:31] <ddaa> it's a condition that should never ever happen
[08:32] <kiko> a file is missing
[08:32] <ddaa> that means that their cvs server is crap, or they've done bad things with their repository
[08:32] <LarstiQ> the latter shouldn't be uncommon
[08:32] <ddaa> Yeah, something like a file is missing that we still know about through the log
[08:33] <jamesh> if I see him again, I'll ask if he did any CVS surgery around the time the imports stopped working
[08:33] <ddaa> oh, i have extra logging
[08:33] <ddaa> CRITICAL: 'E cvs server: warning: new-born rhythmbox/shell/rb-audioscrobbler.c has disappeared\n' CRITICAL: 'Remove-entry rhythmbox/shell/\n' CRITICAL: '/cvs/gnome/rhythmbox/shell/rb-audioscrobbler.c\n' CRITICAL: 'ok\n'
[08:34] <jamesh> sounds like surgery
[08:36] <ddaa> the CRITICAL are cscvs'
[08:38] <ddaa> I guess I could teach cscvs to handle Remove-entry
[08:38] <ddaa> with some extra context, for anal-retention
[08:40] <ddaa> Nafallo: backuppc is fixed
[08:40] <ddaa> enjoy
[08:40] <Nafallo> ddaa: nice, thanks :-)
[08:40] <bradb> LarstiQ: targeting bugs to series' is what i'm working on right now, as part of the release management era of Malone
[08:42] <LarstiQ> bradb: my use case is looking up if a bug was present in a version a user is using. I usually forget when exactly it is closed a while after it is fixed in bzr.dev
[08:43] <bradb> LarstiQ: ISWYM. bug 424
[08:43] <Ubugtu> Malone bug 424 in malone "No distribution or version field" [Medium,Confirmed]  http://launchpad.net/bugs/424
[08:44] <bradb> unfortunately, it hasn't yet been made a priority
[08:44] <Nafallo> ddaa: oh. fixed didn't mean synced :-)
[08:45] <ddaa> well, importd has synced it, now we need to wait for the update to be published
[08:45] <ddaa> mh
[08:45] <ddaa> Will be there tomorrow.
[08:45] <Nafallo> oki, thanks :-)
[08:45] <kiko> LarstiQ, how would you propose fixing that problem?
[08:45] <kiko> LarstiQ, ISTM that you're going to have to ask the end-user what version he was using
[08:46] <kiko> and then you're going to have to record what version the bug was fixed in
[08:46] <ddaa> jamesh: if you feel idle, it would be great to have a "Branch.pull_now" flag for those cases
[08:46] <ddaa> so importd could tell the branch puller when it has new stuff
[08:46] <kiko> which could be obtained from the release information tied to a productseries
[08:46] <kiko> hmmm
[08:46] <LarstiQ> kiko: asking the user for the version is less important for me to be done by launchpad, I can handle that otherwise
[08:46] <ddaa> so we can get low latency w/o having to scan the 500+ importd branches every time
[08:46] <kiko> LarstiQ, then.. what's the issue?
[08:46] <jamesh> ddaa: yeah.  That along with making the branch pull intervals a bit smarter
[08:47] <LarstiQ> kiko: but trawling through closed bugs, noting the date fixed, finding out if that was before or after a release, that is the issue
[08:47] <jamesh> (backoff on errors, etc)
[08:47] <kiko> LarstiQ, oh, you want something more advanced
[08:47] <LarstiQ> kiko: infestations indeed
[08:47] <kiko> LarstiQ, so what we could do pretty easily is match release dates with bug status change dates
[08:47] <LarstiQ> kiko: I was led to believe the series attached to bugs would go a way to supporting that
[08:47] <ddaa> jamesh: if we have that, we also need a knob for pull_now, usable by branch owner or admin, on the web ui
[08:48] <LarstiQ> kiko: that would help
[08:48] <kiko> LarstiQ, no, the series attached to bugs is actually an important distinction (how do you differentiate bugs fixed on head from bugs fixed on a branch)?
[08:48] <jamesh> ddaa: sure.
[08:48] <kiko> LarstiQ, but that would require you to be precise in entering releases. hmmm.
[08:48] <kiko> LarstiQ, maybe I should contact freshmeat again... using a feed from them would be cool
[08:49] <ddaa> I'm at 9+ hours, time to piss off
[08:49] <jamesh> ddaa: are there any other knobs that would need to be pulled?
[08:49] <ddaa> what do you mean?
[08:49] <LarstiQ> kiko: are you familiar with the debian bts?
[08:49] <jamesh> ddaa: never mind :)
[08:49] <kiko> LarstiQ, somewhat
[08:50] <LarstiQ> kiko: there is a 'found' command to keep track of versions that suffer from a bug
[08:50] <kiko> LarstiQ, ah, like infestations. I always found that approach Too Much Work<tm>
[08:51] <LarstiQ> kiko: which is rather of use for keeping track of security bugs across stable/testing/unstable
[08:53] <LarstiQ> kiko: well, the current situation where a bug disappears after it is closed on the trunk is Too Much Work too
[08:55] <kiko> LarstiQ, having multiple series handles that use case without the nitty-gritty of handling the individual versions.
[08:55] <kiko> they are separate things, versions from series, though.
[09:06] <kiko> jamesh, email sent -- looked at about 100 bugs today so the python people should be happy now :)
[09:06] <kiko> stub, how's that run going? can you get me the other bug IDs I need to clean up?
[09:07] <kiko> bradb, ping?
[09:07] <stub> kiko: Still running
[09:08] <bradb> kiko: pong
[09:08] <jamesh> kiko: in answer to the user names issue, we don't get the display name for users in all situations (e.g. commenters), so I wasn't including it.
[09:08] <bradb> kiko: i'm just writing a few more tests
[09:08] <jamesh> kiko: I did run a script to set up the person records for all Python developers beforehand, which did add displaynames
[09:09] <bradb> kiko: I'll be ready for a demo in about 20 mins, if you have time.
[09:09] <kiko> stub, wow. ok, thanks.
[09:09] <kiko> bradb, sure. I have some issues with the advanced search that I'd like you to take a look at afterwards
[09:09] <kiko> jamesh, the dump doesn't contain them?
[09:09] <bradb> kiko: sure
[09:13] <jamesh> kiko: the SF web pages only include display names for assignee and reporter -- take a look
[09:13] <kiko> jamesh, ah right. but in the cases I showed you there /was/ a display name for the reporter and he was still imported as...
[09:14] <kiko> jamesh, oh, maybe the problem is ordering?
[09:14] <jamesh> kiko: yeah.  The code currently ignores the displayname given for the reporter
[09:14] <jamesh> kiko: but even if it didn't, it would have problems if it first sees a user as a commenter rather than a reporter
[09:14] <kiko> right
[09:15] <jamesh> kiko: could possibly fix this with some preprocessing of the dump files and create all the users up front
[09:15] <kiko> jamesh, yeah, as we could do for bug numbers as well <wink>
[09:15] <kiko> okay, bbiab
[09:15] <jamesh> kiko: fixing bug numbers is postprocessing
[09:15] <matsubara> sivang, kiko: http://pqm.launchpad.net
[09:16] <matsubara> enjoy!
[09:24] <sivang> matsubara-dinner: yay! thank you.
[09:25] <sivang> my first landing, albeit very trivial :-)
[09:58] <sivang> can I remove or change this branch's content ? I want to wipe it out and start fresh in the same place.
[09:58] <sivang> https://launchpad.net/people/ubuntu-dev/+branch/hubackup/ubuntu
[10:00] <LarstiQ> this is so becoming a faq
[10:00] <LarstiQ> sivang: in your situation, a bzr push --overwrite should do the trick, if used with a 'correct' branch
[10:01] <sivang> LarstiQ: how do I know if the branch is 'correct' ?
[10:01] <LarstiQ> sivang: you said you wanted to start fresh
[10:03] <sivang> LarstiQ: start fresh on the supermirror, the branch I want to push has 446 revisions :-)
[10:04] <LarstiQ> sivang: well, just push that with --overwrite then?
[10:04] <sivang> LarstiQ: okay, just wanted to make sure I know what you meant by 'correct', sorry if I bugged.
[10:05] <LarstiQ> no problem bugging me
[10:05] <LarstiQ> sivang: the issue is that removing a branch is hard, replacing all its content with --overwrite is much easier
[10:06] <LarstiQ> sivang: for some reason, I'm not aware of stfp clients that allow an easy rm -rf
[10:06] <sivang> LarstiQ: I see, thanks for the insight then.
[10:16] <bradb> kiko: ping
[10:16] <kiko> bradb, pong
[10:25] <SteveA> hi sivang.  congratulations for getting a patch into RF.
[10:30] <sivang> SteveA: thanks, looking forward to see the bigger one land as well.
[10:31] <kiko> ('Invalid value', token u' ' not found in vocabulary)
[10:31] <kiko> sivang, you could fix that one, eh?
[10:31] <kiko> sivang, it happens when you type a single space in the sourcepackagename field when editing a bugtask
[10:32] <sivang> kiko: /me goes to check
[10:33] <sivang> kiko: do we have a bug report about it ?
[10:33] <kiko> not sure, sivang 
[10:33] <sivang> kiko: will check, and report one if not.
[10:33] <kiko> cool
[10:38] <sivang> staging's data is free for play right? (e.g. it refreshes periodically)
[10:39] <matsubara> sivang: yes
[10:39] <sivang> matsubara: cool, thanks
[10:39] <matsubara> sivang: and congrats about the first patch :)
[10:40] <sivang> matsubara: thanks :)
[11:38] <kiko> BjornT, did we land the linkify-tags patch I gave you a starter on?
[11:52] <boim> newbie Q:  Seems too good to be true.  I just ask for free CDs?
[11:52] <sivang> hrm, seems 'Choice()' ignores 'constraint=name_validator'
[11:52] <boim> how long does it take?  should I jsut ask for them instead of a long download?
[11:53] <kiko> boim, you're in the wrong channel, but see shipit.ubuntu.com.
[11:53] <flacoste> sivang: a vocabulary is a form of constraint, what exactly do you want to do?
[11:54] <sivang> flacoste: so, I want to pass the value before checking it's in the range of the constraint, through the name_validator
[11:58] <flacoste> sivang: I don't have enough context to be of much help
[11:58] <sivang> flacoste: sorry, I will provide more:
[11:59] <sivang> flacoste: As kiko noted above, when editing a bug task, and adding a whitespace somewhere in the name of the sourcepackage, an ugly error is shown
[11:59] <sivang> flacoste: malone #55553
[11:59] <Ubugtu> Malone bug 55553 in malone "sourcepackage name should have a proper error message when reciving bad input." [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55553
[12:07] <sivang> flacoste: so, realizing name_validator can do the job to validate a sourecpackagename, if I could pass the value recived in the IBugTask's sourcepackagename , before being checked in the vocabulary, through name_validator, I would be able to present a meaningful error message to a user . then if it passes through name_validator, what's left is to change the default error message when the value was not found in the vocabulary. Am I going in the right
[12:07] <flacoste> sivang: ok, i see the problem, what is the form in question?
[12:08] <flacoste> sivang: i don't think adding a name_validator to the schema would be of any help
[12:09] <sivang> flacoste: okay, the form name is bugtask.py
[12:09] <flacoste> sivang: either validate that in the view or add a view for the error type that is raised (that's the regular zope.app.form machinery)
[12:10] <flacoste> sivang: it's BugTaskEditView?
[12:11] <sivang> flacoste: not sure we're talking the same terms, where are forms stored in the source tree? :)
[12:12] <sabdfl> sivang: easy mistake to make, since Z3 conflates the two in evil and mysterious ways
[12:12] <kiko> ahem