[02:17] <kbrooks> HOW do I remove a release?
[02:19] <kgoetz> i don't think you can, lp doesnt support remving stuff to the best of my knowlage
[02:19] <kbrooks> kgoetz: "stuff"?
[02:19] <kgoetz> kbrooks: almost anything thta you might what to remove
[03:09] <changlinn> hello everyone, gotta problem signing up, it never sends me the email.
[03:10] <kgoetz> ISP spam filters?
[03:10] <changlinn> nup, my own mail server, and I have yet to install any...
[03:11] <kgoetz> checked your server logs?.... hm. i don't know what you need then tbh. 
[03:12] <changlinn> I have blacklists.org setup and a couple other blacklists...
[03:33] <changlinn> what mail server should it come from?
[03:33] <kgoetz> um. i'll try and find mine
[03:34] <changlinn> thanx
[03:34] <kgoetz> my email validation email is from bounces@canonical.com. i'll check for my original email to be sure
[03:35] <kgoetz> it's from "the launchpad team" noreply@canonical.com
[04:12] <spiv> lifeless: would you mind reviewing https://chinstrap.ubuntu.com/~dsilvers/paste/file8ZkgAR.html?  I think it's sane, but double-checking would be appreciated.  This fixes test failures with current bzr.dev.
[04:16] <lifeless> bug 29884
[04:16] <Ubugtu> Malone bug 29884 in ept "[dapper]  Adept crashes when selecting "remove package" via right-click" [Unknown,Unknown]  http://launchpad.net/bugs/29884
[04:16] <lifeless> bug 39884
[04:16] <Ubugtu> Malone bug 39884 in launchpad "test_branchtomirror tests disabled." [Normal,Confirmed]  http://launchpad.net/bugs/39884
[04:18] <lifeless> yes, mailed you a review
[04:18] <spiv> Thanks
[04:19] <spiv> Btw, I generally expect to find work mail sent to my @canonical.com address :)
[04:19] <lifeless> uhm, I type andrew b in and let evo sort it out
[04:19] <lifeless> do they go to different places ?
[04:20] <spiv> Different folders, yeah.
[04:20] <spiv> Not a huge issue, but I don't tend to look at personal mail at much while working.
[05:31] <mpt> Gooooooooooooooood afternoon Launchpadders!
[05:33] <kgoetz> hi mpt
[05:37] <ajmitch> good afternoon mpt, how are you today?
[08:06] <spiv> lifeless: ping
[08:07] <lifeless> pong
[08:08] <spiv> lifeless: A couple of things... did you get my mail confirming that that Twisted merge is safe?
[08:08] <lifeless> spiv: nope, got salgados
[08:09] <spiv> Ah, I wonder where that went.  Anyway, I ran make check_merge locally, and it all passed.
[08:09] <lifeless> wheres the branch with it in ?
[08:11] <spiv> I think it's only in patch form atm.
[08:12] <lifeless> please fix kthnx
[08:12] <lifeless> its a nuisance in patch form
[08:12] <spiv> Sure.
[08:12] <lifeless> and the other ?
[08:12] <spiv> I also sent a mail with yet another odd failure from pqm, this time trying to merge into SQLObject.
[08:13] <spiv> (which I want to do so I can merge buildbot, so I can merge the re-enable sourcecode checks...)
[08:13] <lifeless> you did ?
[08:13] <stub> Can anyone recommend a decent python parser generator?
[08:14] <spiv> lifeless: "Subject: Merge to SQLObject fails [pqm@canonical.com: failure] "
[08:14] <lifeless> do you mean 'a parser generator written in python' or 'a generator of parsers whose implementation is in python'
[08:14] <lifeless> spiv: I have no mail from you
[08:14] <spiv> lifeless: In the wee hours of May 6th.
[08:14] <stub> lifeless: the latter
[08:14] <spiv> lifeless: How odd.
[08:16] <spiv> lifeless: my local mail queue is empty, and the one about the Twisted merge was CCed to the launchpad list and reached that ok.
[08:17] <spiv> lifeless: I mailed them to robert.collins@ canonical.
[08:17] <lifeless> found them
[08:17] <lifeless> to simulate the sqlobject failure locally
[08:18] <lifeless> make -C ../.. check_merge
[08:18] <lifeless> run that from the sqlobject dir
[08:18] <spiv> Ah, is that what it does?  Thanks.
[08:18] <lifeless> (thats in the email that is sent to you)
[08:18] <lifeless> All lines of log output:
[08:18] <lifeless> Executing pre-commit hook make -C ../.. check_merge at Fri May  5 12:57:36 2006
[08:18] <spiv> Ah, yes.
[08:18] <spiv> I somehow missed that bit :(
[08:19] <spiv> My eyes for some reason didn't expect to find a command line in the middle of that line.
[08:19] <spiv> Which is probably more a bug in my eyes than in PQM :)
[08:20] <spiv> Ok, I'll see if I can fix that.  Thanks.
[08:56] <SteveA> morning
[08:57] <SteveA> spiv: i used spark before
[08:57] <SteveA> i think it was called spark
[08:58] <SteveA> http://pages.cpsc.ucalgary.ca/~aycock/spark/
[08:58] <spiv> SteveA: I think you mean stub?
[08:58] <SteveA> was stub asking about CCs ?
[08:59] <stub> Shh.... I'm trying to sleep
[09:00] <stub> Would you trust software written by a cock?
[09:00] <stub> I'll have a look - might be suitable.
[09:01] <lifeless> what do you need to parse ?
[09:01] <lifeless> and is it performance critical ? 
[09:01] <lifeless> If its not, I usually use recursive descent with an interpreter as its much easier to understand and debug
[09:02] <SteveA> lifeless: compared to spark?
[09:02] <stub> lifeless: The text search query parser is currently a collection of regexps, which works fine but we keep tripping over edge cases.
[09:03] <lifeless> SteveA: parser generators typically generate shift-reduce table parsers
[09:03] <lifeless> SteveA: which are a pillock to debug
[09:03] <stub> A tokenizer would probably be good enough
[09:19] <carlos> morning
[09:24] <SteveA> mpt__: ping
[09:24] <SteveA> hello carlos 
[09:25] <SteveA> carlos: we should talk with kiko this afternoon
[09:25] <SteveA> jamesh: hi.  i'd like to have a voice call with you today.
[09:25] <carlos> yeah, I didn't talk with kiko last Friday so I didn't arrange the meeting....
[09:25] <carlos> SteveA: I will do as soon as he wakes up
[09:26] <SteveA> carlos: great
[09:27] <SteveA> stub, spiv: what did you agree between you about authserver cacheing?
[09:30] <spiv> SteveA: That it's low priority now that downtime for rollouts is generally much smaller.
[09:30] <SteveA> spiv: it is still "essential" in the spec tracker
[09:30] <spiv> The same idea will still be useful for redundancy, though.
[09:30] <SteveA> https://launchpad.net/products/launchpad/+spec/auth-server-caching
[09:31] <SteveA> please change the priority, and note why in the status whiteboard
[09:31] <spiv> Ok.
[09:31] <SteveA> hmm... looking at the spec tracker menu, it seems we have a new CEO
[09:31] <SteveA> it says "* Mark Superseded"
[09:42] <SteveA> jamesh: ping
[09:43] <jamesh> SteveA: pong.
[09:43] <SteveA> hi
[09:43] <SteveA> skype talk?
[09:43] <jamesh> okay
[09:44] <sivang> morning all
[09:44] <SteveA> hello sivan
[09:45] <sivang> Labas SteveA 
[09:59] <mpt> spiv, have five minutes spare for a review?
[09:59] <mpt> or jamesh?
[10:00] <spiv> mpt: Ok.
[10:00] <spiv> mpt: I hope it's not as controversial as the last one :)
[10:01] <mpt> Actually, it's fixing a boo-boo from the last one :-)
[10:01] <mpt> https://chinstrap.warthogs.hbd.com/~dsilvers/paste/fileJIxqtN.html
[10:02] <mpt> (It was rather disappointing to be having to defend the idea that something that fails a lot of the time is a bug...)
[10:04] <SteveA> labas sivanai
[10:07] <mpt> spiv, the intent here is to fix bug 39312 (if you scroll horizontally to the point where the lines diverge, you'll see see the ~20-character diff), fix bug 43261 (by making the advanced search form use standard Launchpad markup), and make Rosetta's "[tab] " translation a little more understandable
[10:07] <Ubugtu> Malone bug 39312 in launchpad "Launchpad pages grab focus when they finish loading" [Normal,In progress]  http://launchpad.net/bugs/39312
[10:07] <Ubugtu> Malone bug 43261 in launchpad "Advanced search page lacks style sheet." [Major,In progress]  http://launchpad.net/bugs/43261
[10:09] <carlos> mpt: oh, so #39312 behaviour is our fault?? I thought it was a firefox problem!
[10:09] <mpt> carlos, well arguably browsers should ignore that JavaScript function anyway
[10:10] <mpt> in Dapper Firefox it just causes the taskbar button to throb, which isn't as bad
[10:10] <mpt> but that might be an Ian Jackson Special
[10:10] <spiv> mpt: amusingly enough, highlighting the changed text in that line in epiphany reveals another browser bug ;)
[10:11] <mpt> spiv, and trying to edit that JavaScript with syntax highlighting on caused gedit to hang
[10:11] <mpt> the script is cursed, I tell ya
[10:12] <spiv> mpt: yeah, I'd argue that javascript functions should only be allowed to change the focus within the browser viewport, not outside that, and certainly not the window itself.
[10:12] <mpt> yep
[10:12] <spiv> But until all browser implementors think the way I do...
[10:12] <spiv> (oh what a happy day that would be!)
[10:13] <spiv> "/* if(config.setFocus || true)config.frames.popups.focus();*/"
[10:13] <mpt> in the Mozilla 0.8/0.9 days there was a very annoying and very persistent bug where sometimes the layout engine would cause a window to jump to the front
[10:13] <spiv> Why add the || true as well as commenting it out?
[10:13] <mpt> That was a carnival of fury -- some people thought it was intentional, some thought it should be configurable, some people said "there shouldn't be any code in Mozilla that layers windows AT ALL"
[10:14] <mpt> spiv, hmmm, I don't know -- that's what the volunteer contributor did
[10:14] <mpt> I'll remove the || true
[10:14] <spiv> Ah, presumably debugging cruft.
[10:15] <spiv> Is it safe for me to assume that's the only change on this line?
[10:15] <mpt> yes
[10:16] <spiv> So there's a bunch of changes to a search form here that seem for more complicated than a simple reinstatement of a stylesheet.
[10:16] <mpt> Yes, it is more complicated
[10:17] <mpt> because I'm changing it to use <fieldset> instead of custom-styled <table>s
[10:17] <mpt> Remember before how it was all grey? Nice grey, but inconsistent with the rest of LP
[10:18] <spiv> Yeah, I followed the links on the bug report :)
[10:19] <spiv> Ok, this looks fine to me.
[10:19] <mpt> I haven't gotten rid of all the cruft, just enough to get it looking good again
[10:19] <spiv> I don't know why that javascript ever had a focus() call in it, that's just silly for a menu.
[10:20] <mpt> yeah
[10:20] <spiv> Anyway, r=spiv.
[10:20] <mpt> thanks!
[10:20] <SteveA> spiv: hi.  jamesh and i were just talking about james' current work on the authserver code
[10:21] <SteveA> i proposed that he put his work-in-progress up for review by you, so you can take a quick look over it while you're still around this week
[10:21] <spiv> Sounds like a good idea.
[10:55] <lifeless> ah, its the jojo boss :0
[10:58] <mpt> jojo, or yoyo?
[10:59] <lifeless> mpt: yes
[10:59] <SteveA> i want to buy a printer.  any recommendations for a colour inkjet kinda thing, compact dimensions?
[11:00] <mpool> hp ones have good linux support
[11:00] <mpool> i don't think the particular model matters much
[11:00] <SteveA> cool, thanks
[11:00] <jamesh> if you don't need colour, spend a little extra on a laser
[11:01] <mpool> there's a web site - linuxprinting.org
[11:01] <jamesh> you'll save on ink in the long run (especially if you don't print very often)
[11:01] <mpool> but in general hp are a good deal
[11:01] <mpool> jamesh: "black gold" :-)
[11:01] <SteveA> jamesh: especially if i *don't* print very often?
[11:01] <lifeless> even if you do need colout
[11:02] <jamesh> SteveA: yeah.  the ink in the nozzles on inkjet cartridges can dry up if you don't print often enough
[11:02] <lifeless> spend a little more and get a laser
[11:02] <jamesh> so you end up having to replace the cartridge early
[11:02] <lifeless> the single pass lasers are -really- nice
[11:03] <mpool> "do not expose your hp LaserJet to flame" (actual quote from manual)
[11:03] <lifeless> oh man
[11:03] <lifeless> a laserjet II, that would survive a fire
[11:03] <mpt> mpool, is that a reference to the old error message in lp(1), "printer is on fire"?
[11:03] <mpool> it may well be
[11:03] <mpool> they do sometimes have a dry sense of humour
[11:04] <mpool> lifeless: actuall V Joshi, the VP of that group, made a point at a large meeting once by standing on a LaserJet that they are unnecessarily overengineered
[11:04] <mpt> http://www.eeggs.com/items/1037.html
[11:04] <mpool> most customers actually will not pay more for a printer that can bear someone's weight
[11:05] <lifeless> indeed
[11:08] <lifeless> spiv: got that branch for me ?
[11:08] <SteveA> most offices want a photocopier that an bear someone's weight 
[11:08] <SteveA> for office parties
[11:08] <lifeless> s/want/need/
[11:09] <SteveA> in case they decide to bare their weighty arse
[11:09] <mpool> heh, you know there's probably an engineering requirement spec item about that
[11:09] <mpool> and a calculation of the dynamic load of a 90th-percentile drunk mail climbing onto a copier...
[11:09] <SteveA> you mean an ISO standard arse?
[11:10] <SteveA> to go with the ISO standard finger
[11:10] <mpt> Must withstand a pressure of 0.05 dpi (derri?res per inch)
[11:11] <SteveA> and other ISO standard body parts
[11:11] <SteveA> the finger is used to check for electrical safety among other things
[11:11] <SteveA> far thinner and more manouverable than a real finger
[11:11] <mpool> my elec eng ex-housemate had a Test Finger
[11:12] <mpt> ugh
[11:30] <doko> is there a way to send an email to somebody registered in launchpad?
[11:31] <SteveA> mpt: stick it in a paste-bin and let me look at it, if you want.
[11:31] <SteveA> doko: not using launchpad.  if they have chosen so, you can log in, see their email, then mail them
[11:34] <dilys> Merge to devel/launchpad/: [r=lifeless]  Update tests to be compatible with bzr 0.8. (r3539: Andrew Bennetts)
[11:41] <mpt> 19 conflicts!
[11:57] <lucasvo> hi
[11:59] <lucasvo> is there any possibility to add a comment or suggest an improvement of a spec on launchpad?
[12:00] <sabdfl> lucasvo: sure, in the wiki
[12:00] <lucasvo> sabdfl: it says "Locked page"
[12:00] <sabdfl> lucasvo: not sure why that is
[12:00] <lucasvo> ah, yes, how about LP & commercial software?
[12:00] <lucasvo> https://wiki.edubuntu.org/EmbeddedUbuntu
[12:01] <lucasvo> is it possible to have private specs, private branches and so on?
[12:02] <sabdfl> lucasvo: yes for bugs, not yet specs or branches
[12:02] <lucasvo> ok
[12:02] <lucasvo> sabdfl: when will that come?
[12:02] <sabdfl> lucasvo: it's not a huge priority, we want to get the public aspects working well first
[12:02] <sabdfl> we needed private bugs to deal with security issues
[12:02] <sabdfl> so bradb did that early
[12:02] <lucasvo> ok
[12:03] <sabdfl> but private specs and branches are less important right now
[12:07] <kgoetz> hi sabdfl
[12:08] <sivang> hey kgoetz :)
[12:09] <kgoetz> hi sivang :)
[12:09] <sivang> kgoetz: thank_you^3 :-)
[12:16] <sabdfl> hiya kgoetz
[12:35] <carlos> jordi: hi, around?
[12:46] <zakame> hi all
[12:49] <kgoetz> hi
[01:02] <SteveA> lifeless: meeting time?
[01:04] <lifeless> yup
[01:05] <lifeless> reviewer meeting time
[01:05] <jamesh> lifeless: I'm doing a pending-reviews run now with the extra column
[01:05] <lifeless> jamesh: ping
[01:05] <lifeless> spiv: ping
[01:05] <jamesh> pong
[01:05] <spiv> pong
[01:05] <lifeless> BjornT: ping
[01:05] <lifeless> SteveA: ping
[01:05] <SteveA> hi
[01:05] <lifeless> hi guys
[01:05] <BjornT> lifeless: pong?
[01:05] <lifeless> gimme just a second to setup the file for the meeting
[01:08] <SteveA> hi BjornT.  holiday today?
[01:08] <lifeless> agenda today
[01:08] <lifeless>  * Roll call
[01:08] <lifeless>  * Agenda
[01:08] <lifeless>  * Next meeting
[01:08] <lifeless>  * Queue status.
[01:08] <lifeless>  * Ensuring reviews [and subsequent discussion]  are visible. (SteveA)
[01:08] <lifeless>  * Dealing with reviews that go off the tracks and sit unreviewed for ages. (SteveA)
[01:08] <lifeless> mpt: ping
[01:09] <lifeless> those I have just pung, if you are here for the meeting, please say aye or similar
[01:09] <BjornT> SteveA: yeah, it's a public holiday today
[01:09] <lifeless> if you are not here for the meeting, say nay.
[01:09] <SteveA> aye
[01:09] <spiv> aye
[01:09] <BjornT> aye
[01:09] <jamesh> aye
[01:10] <lifeless> cool
[01:10] <lifeless> next meeting : 2006-05-15 at 1100 UTC. ok ?
[01:10] <BjornT> sure
[01:11] <spiv> sure (depending on jury duty)
[01:11] <jamesh> okay
[01:11] <mpt> nay
[01:11] <lifeless> ok
[01:12] <lifeless> queue status
[01:12] <lifeless> oldest unaccounted for branch is 4 days
[01:12] <lifeless> with BjornT 
[01:12] <BjornT> i'll review it tomorrow
[01:13] <lifeless> oldest in needs-reply is salgado/launchpad/shipit-for-dapper
[01:13] <lifeless> spiv: any idea whats got that held up ? 
[01:13] <spiv> lifeless: I have email about that somewhere, I'll dig it up...
[01:13] <lifeless> SteveA: you made a typo on the wiki page : needs-relpy
[01:14] <SteveA> opos
[01:14] <lifeless> SteveA: I'm fixing that now
[01:14] <SteveA> ta
[01:14] <lifeless> [it breaks the status grouping on pending-reviews] 
[01:14] <SteveA> i was obviously thinking of the blonde french actress julie delpy
[01:14] <lifeless> :)
[01:15] <spiv> lifeless: "Right, this branch wasn't quite ready for review yet," ... "Please don't review this branch again, as there's some issues you pointed here, that aren't solved ..."
[01:15] <lifeless> Hmm, I think such branches should be taken out of the system
[01:15] <lifeless> and put back in fresh when they *are* ready.
[01:15] <spiv> lifeless: basically, it was a work-in-progress branch, salgado put it up for early review.
[01:15] <lifeless> what do you you reviewers think ?
[01:16] <spiv> I think that's a good policy, I don't think it's benefitting anyone having it cluttering up the review queue pages.
[01:16] <SteveA> well
[01:16] <SteveA> it can be nice to see works in progress.  but i have a different suggestion
[01:16] <SteveA> what if we have a "work in progress" page, as a separate page
[01:16] <SteveA> and people can put works in progress there
[01:17] <jamesh> have a "doesn't-need-review-yet" state?
[01:17] <SteveA> and an equivalent script to jamesh's one can produce diffs for it
[01:17] <SteveA> so pointy-haired bosses like me can see what's going on more easily
[01:17] <lifeless> SteveA: I'm wearing a wig right now :)
[01:17] <SteveA> that way, the reviews page stays clear, but we get a place for "this is in progress"
[01:18] <lifeless> So, we have several options
[01:18] <lifeless> a new page
[01:18] <lifeless> a different classifier, but on the same page
[01:18] <lifeless> stop tracking the branch altogether
[01:18] <qqqtas> Hemp Gru joint
[01:19] <lifeless> I think putting them on the same page, but as 'Under development' status would work
[01:19] <lifeless> That could be sorted down the bottom by pending-reviews
[01:19] <SteveA> for a "my branches" page, i'd want to edit it organized by person, not by reviewer
[01:19] <lifeless> would not need to be in any reviewers queue (just have the top most section of the wiki page list 'under development' branches
[01:20] <SteveA> only when it is pending review would i want it to be in a reviewers' queue
[01:20] <lifeless> SteveA: agreed.
[01:20] <lifeless> SteveA: it seems conceptually easier to me to have a single 'these are the branches' page, with branches moving around there, than to have two pages and be forever copy and pasting between them
[01:21] <SteveA> of course, all this should be in launchpad before *too* long
[01:21] <lifeless> of course
[01:21] <SteveA> sure, let's try adding to the same page
[01:21] <lifeless> so, the simplest action right now, is 'stop tracking the branch'
[01:21] <lifeless> on the basis that lp should be doing that
[01:22] <lifeless> alright, that sounds fine to me. jamesh - I guess we'll want a status like 'in-development' ?
[01:22] <jamesh> lifeless: yeah.  that or in-progress or work-in-progress
[01:22] <jamesh> whatever people prefer
[01:22] <lifeless> jamesh: pick one :)
[01:23] <spiv> I like "work-in-progress"
[01:23] <jamesh> work-in-progress it is
[01:23] <SteveA> lifeless: would you move the current branch that is in development to the place you think it should be in that page, then jamesh can make his script accommodate
[01:23] <lifeless> SteveA: yep
[01:24] <jamesh> lifeless: if you stick it in its own section, it won't get assigned to any reviewer in the summary page
[01:24] <lifeless> jamesh: yes, I'll be adding a new section at the top
[01:24] <lifeless> titles 'Works in progress'
[01:24] <lifeless>  * Ensuring reviews [and subsequent discussion]  are visible. (SteveA)
[01:24] <lifeless> SteveA: care to introduce this
[01:24] <SteveA> sure
[01:24] <jordi> carlos: hello
[01:24] <carlos> jordi: hi
[01:24] <SteveA> sometimes, someone has mailed or asked on irc privately to a reviewer for a review.
[01:25] <SteveA> i know i've done this
[01:25] <SteveA> asking privately for a review isn't a problem at all
[01:25] <carlos> jordi: what needs to be done to reject/import the templates at https://launchpad.net/rosetta/imports/+index?status=NEEDS_REVIEW&type=pot ?
[01:25] <SteveA> but, the review itself, if it is more than "great, r=me" or "write some goddamn tests and ask me again", needs to be on the reviews mailing list
[01:26] <SteveA> otherwise, what often happens is, the email goes back and forth, and the cc list grows
[01:26] <SteveA> and we end up with just some people knowing about what's going on
[01:26] <lifeless> this is like a water cooler discussion
[01:26] <lifeless> that ends up with 5 people rather than 2
[01:27] <SteveA> so, i ask reviewers to always reply to emails about reviews onto the reviews list
[01:27] <jordi> carlos: there's different stories involved. Some of them I can remove in the evening, as I haven't got any reply, others are new, still bogus (gaim; wordpress, again)
[01:27] <jordi> schooltool for example is pending me doing a merge of old branch po files with new pot file on the new series
[01:27] <spiv> SteveA: What about reviews that are conversations on IRC -- should they be copied&pasted/summarised to email, or perhaps go straight to email in the first place?
[01:28] <ddaa> lifeless: now that 0.8 is out, when is launchpad switching to knits?
[01:28] <jordi> carlos: I'll  clear the list entirely in the evening
[01:28] <qqqtas> ship it is 100% free and no spam ??
[01:28] <jamesh> maybe a small summary email?
[01:28] <ddaa> qqqtas: yes
[01:28] <lifeless> I'd like any review to be sent to the reviews list
[01:28] <carlos> jordi: please, give one week to answer you, if you don't get an answer, remove them and notify them about the removal, we will have 3 extra days to revert the removal
[01:28] <jordi> ok
[01:28] <ddaa> qqqtas: spamming folks would really really damge the company's reputation
[01:28] <carlos> jordi: thank you
[01:28] <SteveA> spiv: you should use your judgement.  if the review goes on the mailing list, then others can learn from it and see what's going on.
[01:29] <spiv> Ok.  When in doubt, mail the list.
[01:29] <SteveA> it also provides evidence of work done, which is helpful when kiko and i come to do performance reviews.
[01:29] <SteveA> we don't look through irc logs.
[01:29] <SteveA> we do often look through mailing list archives
[01:29] <carlos> jordi: could you add that procedure to our documentation?, that way people will know how are we going to handle the requests too and they cannot complain if we remove them without warning, as you are already mailing them and we have it well documented.
[01:30] <SteveA> qqqtas: some people have been asked to pay money by the customs or import tax people of their own country.
[01:30] <jordi> ok
[01:30] <SteveA> qqqtas: but Canonical doesn't charge money.
[01:30] <jordi> in the FAQ?
[01:31] <SteveA> lifeless: i've finished
[01:31] <carlos> jordi: yes
[01:31] <lifeless> ok
[01:31] <SteveA> although, if there is a wiki page that says how we do reviews
[01:31] <kbrooks> can i ask a question :P
[01:31] <lifeless> so, I think that if its something work commenting on in the review
[01:31] <SteveA> a note could go on theere
[01:31] <carlos> jordi: perhaps you should take that update as the best time to migrate it to help.launchpad.net...
[01:31] <lifeless> s/work/worth/ then its worth sending to the list
[01:31] <SteveA> kbrooks: you just did ;-)
[01:31] <kbrooks> SteveA: is this a meeting?
[01:32] <jamesh> lifeless: https://chinstrap.ubuntu.com/~jamesh/pending-reviews/ <- now with new data column
[01:32] <SteveA> kbrooks: yes.  a few of us are having a meeting.
[01:32] <lifeless> jamesh: pending-reviews page updated
[01:32] <lifeless> jamesh: thanks. Thats going to be really useful
[01:32] <kbrooks> SteveA: can i ask questions? :-)
[01:32] <SteveA> kbrooks: we are responsible for reviewing the code that goes into the Launchpad software.  so we're meeting about how we do those reviews.
[01:32] <qqqtas> aha thanks
[01:32] <jordi> carlos: nod
[01:32] <jamesh> lifeless: it'll be more accurate as branch states change
[01:32] <lifeless> kbrooks: sure think
[01:32] <jordi> I have to look at how that works
[01:32] <lifeless> s/think/thing/
[01:32] <kbrooks> um
[01:32] <kbrooks> whats help.lp.met
[01:32] <kbrooks> net*
[01:33] <carlos> jordi: it's just another wiki
[01:33] <jordi> hmm, wiki
[01:33] <jordi> ok
[01:33] <SteveA> kbrooks: it's a place where documentation about how to use launchpad will go
[01:33] <carlos> jordi: is a matter of moving there the content we have and leave in the old location a link to the new one
[01:33] <jordi> the frontpage is just great :)
[01:33] <jamesh> I'm open to UI/layout improvement suggestions
[01:33] <jordi> yes
[01:33] <jordi> ok, that should be easy.
[01:33] <lifeless> jamesh: it looks great. thank you
[01:33] <jordi> carlos: have we talked about a layout?
[01:33] <SteveA> kbrooks: currently, we have some documentation for the people who develop launchpad, but almost none for the people who want to use launchpad
[01:33] <jordi> ie, would we want RosettaFAQ or Rosetta/FAQ?
[01:33] <kbrooks> SteveA: why should there be documentation? it's "easy" enough for people to use
[01:34] <jordi> kbrooks: it's not
[01:34] <carlos> jordi: notify me when it's done and I will update launchpad code to point to the new location
[01:34] <carlos> jordi: don't know
[01:34] <kbrooks> jordi: ah, well
[01:34] <SteveA> kbrooks: yes, many features are easy to use.  but some things are more difficult.
[01:34] <jordi> yup.
[01:34] <carlos> SteveA: do we have any special layout to follow at help.launchpad.net?
[01:34] <lifeless> SteveA: there is TipsForReviewers and PreMergeReviews. I'll add some text there.
[01:34] <SteveA> kbrooks: sometimes it isn't just using a feature that is hard.  it is working out how to make the best use of launchpad given your own interests and situation.
[01:34] <jordi> SteveA: ie, Rosetta/blahblah or RosettaBlah
[01:34] <SteveA> lifeless: thanks
[01:35] <SteveA> carlos, jordi: please ask kiko when he arrives.
[01:35] <carlos> ok
[01:35] <jordi> ok
[01:35] <kbrooks> SteveA: ah. well, i sort of have a feature request
[01:35] <SteveA> lifeless: i'm back at this meeting now
[01:35] <lifeless> SteveA: I would prefer a stronger statement than if in doubt
[01:35] <SteveA> kbrooks: join the launchpad-users mailing list, perhaps?  then you can have a discussion with people who aren't on irc right now
[01:36] <carlos> BjornT: I have a question about the new testing infrastructure, are you available?
[01:36] <lifeless> SteveA: reviews are different to general discussions, because they are the final influence on what lands.
[01:36] <kbrooks> SteveA: URL to mailing list area?
[01:36] <lifeless> I would like 'unless there is a reason not to, reviews -> the list'
[01:36] <carlos> kbrooks: https://lists.ubuntu.com/mailman/listinfo/launchpad-users
[01:36] <SteveA> kbrooks: https://wiki.launchpad.canonical.com/MailingLists
[01:37] <SteveA> lifeless: i agree, except in the cases of "no, go write some tests" and "all good.  r=me"
[01:37] <lifeless> SteveA: thanks
[01:37] <SteveA> i don't want to weigh us down with bureaucracy
[01:37] <lifeless> sure
[01:37] <lifeless> neither do I
[01:37] <SteveA> but i do want us to communicate effectively about the code and processes
[01:38] <lifeless>  * Dealing with reviews that go off the tracks and sit unreviewed for ages. (SteveA)
[01:38] <lifeless> care to intro this one :)
[01:38] <SteveA> o
[01:38] <SteveA> k
[01:38] <lifeless> [ * Resolution: reviewers should copy the reviews list in on all reviews except where its clearly pointless to do so.] 
[01:38] <SteveA> so, i left a review of brad's for ages, even though brad was dilligently nagging me about it
[01:38] <lifeless> SteveA: and I
[01:39] <BjornT> carlos: if it's a small question, sure, after the meeting.
[01:39] <SteveA> there was a discussion on the list about it
[01:39] <SteveA> the outcome of the discussion was
[01:39] <carlos> BjornT: oh, sorry, didn't remember the reviewer meeting is running now...
[01:39] <SteveA>  - the buck stops at the owner of the branch.  so, it is brad's ultimate responsibility to get his code reviewed.
[01:40] <SteveA>  - if a reviewer is not being effective at getting your code reviewed, then you can reallocate your branch to someone else
[01:40] <SteveA>  - a reviewer should, if possible, realize they aren't getting the review done, and seek to reallocate it to someone else.
[01:40] <SteveA> any comments from the gathered review team?
[01:41] <lifeless> one possibility is for me to set a hard limit on review time
[01:41] <kbrooks> can I ask a question?
[01:41] <SteveA> kbrooks: you don't need to ask to ask a question.
[01:41] <lifeless> and say 'This branch has not been reviewed', transferring it to xyz.
[01:41] <kbrooks> it's a small one: what does reallocate mean?
[01:41] <SteveA> it means to give to someone else
[01:41] <kbrooks> ok
[01:41] <kbrooks> ty
[01:42] <lifeless> I think that a hard limit will actually make it easier to not review branches
[01:42] <lifeless> because you'll know someone else will get the slack :{
[01:42] <lifeless> So I'd rather not do that. But what do y'all think ?
[01:42] <SteveA> it wasn't a good choice of words for that sentence.  "give" would have been better.
[01:42] <lifeless> SteveA: 'seek to have someone else review it'
[01:43] <SteveA> sure
[01:43] <lifeless> or 'seek a different reviewer' :)
[01:43] <SteveA> i used "reallocate" twice in the points above
[01:43] <spiv> lifeless: I agree.  I don't think we need a hard limit.
[01:44] <lifeless> BjornT: ?
[01:44] <lifeless> jamesh: ?
[01:44] <jamesh> okay
[01:44] <SteveA> i don't see how a hard limit would work.
[01:44] <BjornT> i agree as well, no hard limit is needed.
[01:44] <SteveA> what happens when the limit is reached?
[01:44] <ddaa> I think a limit serves a purpose.
[01:45] <lifeless> SteveA: lets not worry, as the unanimous feeling is one isn't needed.
[01:45] <SteveA> ok
[01:45] <lifeless> ddaa: what purpose ?
[01:45] <ddaa> It helps seeing when a reviewer regularly drops packets. Maybe some action is not called for when that happens, but just asking for the submitter to take care of it loses some information for understanding what's going on.
[01:46] <lifeless> ddaa: I already track that
[01:46] <ddaa> cool
[01:46] <lifeless> for instance, recent offenders are jamesh and stevea :)
[01:46] <lifeless> which leads into my next question
[01:46] <lifeless> are you guys managing to fit the daily review into your schedule ?
[01:47] <lifeless> right now we seem to be less frenetic than we were a month back, so its more like one every couple of days
[01:47] <spiv> I feel like I've been doing less reviewing recently.
[01:47] <jamesh> I let it slide for a while, but I'll make sure I fit them in
[01:48] <lifeless> jamesh: thanks.
[01:48] <lifeless> SteveA: what led to the long delay of bradbs branch ?
[01:48] <kbrooks> why is "reviewing" (what is that?) important? What do we review?
[01:48] <BjornT> i usually review the branch within a day or two after it lands in my queue.
[01:49] <jamesh> kbrooks: before landing any code into the mainline of Launchpad, it goes through a code review
[01:49] <lifeless> kbrooks: https://wiki.launchpad.canonical.com/PreMergeReviews
[01:49] <lifeless> BjornT: so, we agreed two weeks ago to aim for a 72 hour turnaround
[01:50] <lifeless> BjornT: that means realistically, next-day should be the expected case, and same day ideally.
[01:50] <SteveA> lifeless: my ever expanding todo list.  i let my review duties fall to the end of the list, because they're easy to put off.
[01:50] <lifeless> SteveA: should I stop giving you reviews to do? Kiko routinely asks to not have reviews assigned 
[01:51] <SteveA> we could try having me take reviews from the queue when i have time.
[01:51] <SteveA> but i think not now
[01:51] <SteveA> because andrew may be absent for a while, i'll need to help with it
[01:51] <lifeless> there is no 'queue' anymore
[01:52] <SteveA> there's the older ones from other people
[01:52] <SteveA> or newer ones
[01:52] <lifeless> the general queue is flushed by me to individual reviewers, I perform a load balancing task
[01:52] <lifeless> as well as trying to ensure the reviewers each get to look at all bits of launchpad
[01:53] <SteveA> http://c2.com/cgi/wiki?CodeReviewPatterns
[01:53] <SteveA> lifeless: don't change anything for a while
[01:54] <lifeless> wasn't planning on it
[01:54] <jamesh> lifeless: I've got another pending-reviews run part way through.  If everything is working, the changed branches should have the "state age" reset to zero
[01:54] <lifeless> was asking about the problem we had to debug it
[01:54] <SteveA> ok
[01:54] <lifeless> my feeling on this is that the review team is in good shape
[01:54] <lifeless> maybe one branch in 10 falls through the cracks
[01:55] <lifeless> which is way down from when I started managing the group, when many branches would be up in the double-digits
[01:55] <SteveA> good stuff
[01:55] <SteveA> i have heard much fewer complaints about code review from developers recently
[01:55] <lifeless> So I don't think anything needs changing. But we should still consider things can be improved, and actively debug each failure
[01:56] <lifeless> jamesh: thanks
[01:56] <SteveA> i meant "don't change anything wrt me being allocated reviews"
[01:56] <lifeless> SteveA: ah, right.
[01:56] <lifeless> SteveA: i won't - there is a protocol for you to do so anyhow :)
[01:56] <lifeless> SteveA: https://wiki.launchpad.canonical.com/TipsForReviewers
[01:57] <lifeless> end of meeting in 10
[01:57] <lifeless> 9
[01:57] <lifeless> 8
[01:57] <lifeless> 111
[01:57] <lifeless> 110
[01:57] <lifeless> 101
[01:57] <lifeless> 100
[01:57] <lifeless> 011
[01:57] <lifeless> 010
[01:57] <lifeless> 001
[01:57] <lifeless> 00
[01:57] <lifeless> 0
[01:57] <lifeless> thanks for coming
[01:57] <lifeless> see you next week
[01:58] <SteveA> i think i'll do the launchpad meeting countdown in unary
[01:58] <lifeless> 111111111
[01:58] <lifeless> 111111111
[01:58] <lifeless> 11111111
[01:58] <lifeless> 1111111
[01:58] <lifeless> 111111
[01:58] <lifeless> 11111
[01:58] <lifeless> 1111
[01:58] <lifeless> 111
[01:58] <lifeless> 11
[01:58] <lifeless> 1
[01:58] <lifeless> you mean ?
[01:58] <SteveA> yes
[01:58] <kgoetz> o_0
[01:58] <jamesh> that's not unary
[01:58] <jamesh> unary is:
[01:58] <jamesh> 0
[01:58] <lifeless> SteveA: we could play guess the base
[01:59] <jamesh> 0
[01:59] <jamesh> 0
[01:59] <jamesh> 0
[01:59] <jamesh> 0
[01:59] <jamesh> 0
[01:59] <jamesh> 0
[01:59] <jamesh> 0
[01:59] <jamesh> 0
[01:59] <SteveA> oh?
[01:59] <jamesh> 0
[01:59] <spiv> I'm looking forward to the Roman numerals.
[01:59] <kgoetz> *blink*
[01:59] <SteveA> i think that's nunnery
[01:59] <lifeless> SteveA: thats a *shsrubbery*
[01:59] <jamesh> is that like a monastery?
[02:00] <SteveA> only if the nuns are monstrous
[02:01] <lifeless> BjornT: btw, thanks for being here on your holiday
[02:02] <BjornT> np. since i was here anyway, i could just as well attend
[02:09] <jamesh> lifeless: the age stuff appears to be working
[02:11] <spiv> lifeless: /home/warthogs/archives/spiv/twisted/twisted-pyunit-compat/
[02:13] <jamesh> lifeless: btw, I finally got Ekiga working with siproxd by using a CVS snapshot of ekiga
[02:13] <lifeless> on chinstrap ?
[02:13] <carlos> BjornT: do you have time now?
[02:13] <lifeless> spiv: ^^ ?
[02:13] <BjornT> carlos: sure
[02:14] <carlos> BjornT: this is the initial version of the pagetest you reviewed using the new infrastructure: https://chinstrap.ubuntu.com/~dsilvers/paste/fileDxtHjx.html
[02:14] <carlos> BjornT: but it fails with the second submit I execute: https://chinstrap.ubuntu.com/~dsilvers/paste/filebOlBHX.html
[02:15] <carlos> BjornT: look for the second "browser.getControl(name='submit_translations').click()"
[02:16] <spiv> lifeless: yes.
[02:18] <lifeless> done
[02:20] <BjornT> carlos: right, bradb ran into the same problem before. hold on, i'll get you a patch you can apply locally. i'll try to fix it properly tomorrow.
[02:20] <spiv> lifeless: great, thank you.
[02:20] <carlos> BjornT: ok, thanks
[02:23] <spiv> Would someone like to do a quick review of https://chinstrap.ubuntu.com/~dsilvers/paste/filepr6u2j.html for me?
[02:28] <lifeless> pystone
[02:28] <lifeless> ARGH
[02:28] <lifeless> r=lifeless
[02:32] <BjornT> carlos: actually, try inserting ">>> browser.open('http://localhost/')" at the top of the page test.
[02:34] <carlos> BjornT: before the authentication?
[02:35] <BjornT> carlos: yeah
[02:35] <carlos> BjornT: same error
[02:42] <BjornT> carlos: ok. for now, apply this patch in your local zope tree: https://chinstrap.ubuntu.com/~dsilvers/paste/fileYElUMf.html
[02:42] <BjornT> that will let you get on with your work until i've taken a closer look at the problem
[02:43] <carlos> ok, let me try it...
[02:48] <carlos> BjornT: yeah, it solves the problem
[02:48] <carlos> BjornT: thanks
[02:48] <BjornT> cool
[02:49] <spiv> lifeless: Thanks
[02:51] <carlos> see you later
[02:51] <lifeless> night al
[02:53] <cprov> good morning, hackers
[03:21] <mpt> BjornT, ping
[03:21] <BjornT> hi mpt 
[03:21] <mpt> BjornT, would you have time to fix one more pagetest for me today? :-)
[03:23] <kiko> hey there
[03:23] <mpt> hi kiko
[03:26] <BjornT> mpt: maybe if it's quick, i've already worked too much than is suitable for a public holiday :)
[03:26] <mpt> ah
[03:26] <mpt> well, if I knew whether it was quick, I'd know enough to do it myself :-)
[03:26] <mpt> In mpt/launchpad/2006-03-MaloneSimplifications, pagetests/bugattachments/40-search-bug-attachments.txt fails, and I don't know why
[03:27] <BjornT> what is the failure?
[03:28] <mpt> ohhhh, hang on a minute
[03:28] <mpt> I know why it's failing
[03:28] <mpt> I thought it was returning completely different bugs
[03:28] <mpt> but it's not, it's just returning them in my tweaked format
[03:31] <mpt> VICTORY
[03:31] <mpt> BjornT, thank you for that *excellent* question
[03:32] <dilys> Merge to devel/launchpad/: [trivial]  Fix Bug 43245 in full text query parser (r3540: Stuart Bishop)
[03:32] <Ubugtu> Malone bug 43245 in launchpad "Search string causes syntax error in full text engine" [Normal,In progress]  http://launchpad.net/bugs/43245
[03:37] <zakame> hi all
[03:38] <BjornT> SteveA: any objections against having canonical_url() always return str objects, instead of (like now) sometimes str, sometimes unicode?
[03:38] <kiko> sounds correct to me BjornT 
[03:39] <SteveA> BjornT: well...
[03:40] <SteveA> the data will always consist of safe ascii-only characters
[03:40] <BjornT> yes, i was thinking of adding a .encode('ascii')
[03:40] <SteveA> if it returns a unicode, the information that it is safe is preserved
[03:41] <SteveA> if it returns a str, once that gets into other parts of the system, we no longer know that it is to be considered in ascii encoding
[03:42] <BjornT> SteveA: that is true. the problem is that bad things start to happen if you pass a unicode string to urlparse, for example: https://chinstrap.ubuntu.com/~dsilvers/paste/filebOlBHX.html
[03:43] <BjornT> basically, urlunparse returns unicode objects, and then other strings get converted to unicode objects, causing stuff like SimpleCookie to break...
[03:45] <BjornT> or actually, urlparse returns unicode, it caches previous parses.
[03:45] <BjornT> >>> urlparse.urlparse(u'http://localhost/')
[03:45] <BjornT> (u'http', u'localhost', u'/', '', '', '')
[03:46] <BjornT> >>> urlparse.urlparse('http://localhost/')
[03:46] <BjornT> (u'http', u'localhost', u'/', '', '', '')
[03:46] <SteveA> how is canonical_url used in that rosetta test?
[03:48] <BjornT> SteveA: at least the menu uses canonical_url, and calls urlparse with the result.
[03:49] <SteveA> sounds like SimpleCookie is most at fault
[03:50] <SteveA> i don't see how a menu that uses canonical_url links to a use of SimpleCookie
[03:52] <Seveas> Who should I contact for details of a possible significant improvement in the sourceforge remote bugwatch thing?
[03:52] <kiko> me
[03:53] <kiko> Seveas, me? or add a bug, as my queue is kinda long
[03:53] <Seveas> I'll paste something in here, if you like it I'll turn it into a bug
 Seveas: Sf has short URLs you can use, too
 hmm
 tell me more 
 e.g., http://sourceforge.net/support/tracker.php?aid=1478771
 Title: SourceForge.net: Detail: 1478771 - url last throws tb (darcs) (at sourceforge.net)
[03:53] <BjornT> SteveA:  yeah, that could be true. SimpleCookie looks explictly for str object. actually it's the use of urlparse that causes the problem, not canonical_url.
[03:53] <Seveas> so in short: no need to register all sf projects separately (!)
[03:54] <SteveA> BjornT: i don't see what the problem is from your example above.
[03:54] <SteveA> i think canonical_url should return a consistent type, as you suggested.  but that type should be unicode.
[03:54] <SteveA> our main use for canonical_url is using it in page templates and in emails
[03:55] <SteveA> both these things are handled as unicode internally, and then encoded appropriately for transmission
[03:56] <spiv> lifeless: Once we get all sourcecode/ tests running all the time again, please yell at anyone that wants to break them even for just a little while ever again.  The chain of merges involved in getting it passing again is ridiculous...
[03:56] <kiko> spiv, why did we disable them in the first place anyway?
[03:57] <spiv> kiko: I have no idea.  But I'm now sure it was a bad idea, whatever the reason ;)
[03:57] <BjornT> SteveA: well, URLs in page templates and emails should be ascii only anyway. but back to the problem.
[03:58] <SteveA> BjornT: yes that's my point :-)
[03:58] <SteveA> if we're keeping them as non-unicode, we've actually lost the information that they're ascii only
[04:00] <BjornT> ok, i kind of get your point.
[04:01] <SteveA> pragmatically, if it's causing problems for them to be unicode, and we're using them in other situations
[04:02] <SteveA> we can consider changing them to always return str type objects
[04:02] <SteveA> but i'd rather fix the real brokenness or work around it in specific places
[04:03] <BjornT> SteveA: anyway. when testbrowser builds the request, it uses urlparse to parse for example 'http://localhost/foo'. since the menu already called urlparse with u'http://localhost/foo', urlparse returns unicode strings, instead of str, like it normally does. it then joins the result from urlparse with the rest of the request, causing the whole request being a unicode string.
[04:03] <SteveA> does urlparse have a cache?
[04:04] <BjornT> yes
[04:04] <SteveA> ah
[04:04] <SteveA> so it is broken
[04:04] <SteveA> it is considering str equivalent to unicode
[04:04] <SteveA> and that's not valid
[04:04] <SteveA> and will lead to unexpected interactions depending on the state of the cache
[04:05] <BjornT> exactly
[04:05] <SteveA> i think a fix in this case would be to ensure we always use urlparse with str
[04:05] <SteveA> so, make the menus explicitly convert to ascii
[04:05] <SteveA> with a comment that urlparse is broken
[04:05] <SteveA> or, add our own urlparse to webapp.__init__
[04:05] <SteveA> i favour the latter, because it is a useful webapp workaround in general
[04:06] <BjornT> yeah, i think adding our own urlparse sounds like a good idea.
[04:07] <SteveA> then, urlparse can be added to the importfascist
[04:07] <SteveA> so that we're assured we're always using our own version
[04:08] <BjornT> yeah. i'll fix that tomorrow then.
[04:08] <kiko> BjornT, how's the bugwatches work going? can I see it up somewhere?
[04:08] <BjornT> (and send a mail to the mailing list about it)
[04:11] <BjornT> kiko: i've almost finished what we discussed doing, there's only some widget work left to do. i don't have time to set up a demo instance right now, but the first part is up for review, so you could grab the branch if you want.
[04:12] <kiko> BjornT, set up a demo so I can take a look at it.
[04:17] <carlos> kiko: hi, we should schedule/have the meeting about Rosetta tasks today
[04:17] <carlos> kiko: when would you have time for it?
[04:18] <kiko> now's fine
[04:19] <BjornT> kiko: ok... try 84.32.240.183:123
[04:19] <carlos> SteveA: do you have time now?
[04:19] <kiko> BjornT, I didn't mean "now" I meant when you could, given I won't be able to :)
[04:19] <kiko> but thanks
[04:19] <SteveA> carlos: not immediately.  i have a phone call in a second.
[04:20] <siretart> is it okay to register random upstream products without actually notifying upstream? whats the procedure if upstream wants to have control over the product entry?
[04:21] <kiko> it's okay but nice if you contact them, and if they want to take over it we hand it off to them
[04:21] <carlos> SteveA, kiko: I will need to leave in 2 hours and a half, perhaps we should agree something for tomorrow?
[04:21] <kiko> will SteveA's phone call take 2.5h?
[04:23] <kiko> BjornT, This address uses a network port which is normally used for purposes other than Web browsing. Firefox has canceled the request for your protection.
[04:23] <kiko> :)
[04:23] <carlos> I don't think so ;-), I'm warning early just in case something else prevent us to have the meeting today, to agree a time tomorrow so we don't delay it again ;-)
[04:23] <carlos> kiko: really?
[04:23] <carlos> that sounds so stupid...
[04:23] <kiko> yeah, port 123 is verboten
[04:48] <jordi> hi
[04:48] <jordi> rosetta meeting
[04:48] <jordi> sounds fun
[04:50] <SteveA> carlos, kiko: i'll be ready in 10 mins
[04:50] <carlos> jordi: ;-)
[04:50] <carlos> SteveA: ok, I'm ready 
[04:50] <carlos> kiko: ?
[04:51] <jordi> kiko: did you see my question about how to organise docs in help.lp.net?
[04:51] <kiko> sure #cm
[04:51] <kiko> jordi, I didn't, but hold on for a bit
[04:53] <Kinnison> kiko: When a bug is duplicated a lot, if I close one, does it close all duplicates?
[04:54] <kiko> Kinnison, duplication and bugtask status are unrelated.
[04:55] <Kinnison> kiko: so I need to click on every duplicate and close each individual task? Okay
[04:55] <Kinnison> not a problem, just wanted to know
[04:56] <kiko> Kinnison, no, ignore status for duplicates.
[04:56] <kiko> they don't show up in bug listings by default anyway
[04:57] <Kinnison> kiko: does the reporter of the duplicate get to know when I close the bug?
[04:58] <kiko> Kinnison, there's a bug filed on that which I am not sure was fixed or not
[04:59] <Kinnison> kiko: also, how do I unmark duplicateness?
[05:00] <kiko> clear the text box
[05:02] <Kinnison> mmm, obvious
[05:02] <Kinnison> :-)
[05:02] <Kinnison> thanks dude
[05:02] <kiko> not very nice UI, but you're welcome
[05:08] <trappist> if I'm, say, a moron and I accidentally send an email to launchpad that was meant to go to an individual, and if that message contains sensitive information, is it possible to get the comment removed from the bug?
[05:09] <jordi> wow, this was an instant export request
[05:09] <kiko> trappist, it is possible with DBA intervention.
[05:09] <kiko> however
[05:09] <trappist> bleh
[05:09] <kiko> many bug reports are echoed to mailing lists
[05:09] <kiko> and subscribers
[05:09] <kiko> so...
[05:10] <trappist> kiko: thankfully this bug doesn't seem to be getting a lot of attention - it's out there, I'm sure, but the more I can limit exposure (like, immortality in google's cache) the happier I'll be
[05:10] <kiko> trappist, you can make the bug private if you like...
[05:10] <trappist> there's an idea
[05:11] <trappist> that helps some
[05:13] <trappist> I suppose there's a really good reason for the bug to be the reply-to address, which is how this happened (that plus my inattention)
[05:13] <kiko> well
[05:13] <kiko> that is a matter of some debate
[05:13] <kiko> it's hard to strike a balance between keeping the discussion in the bug
[05:14] <kiko> and allowing people to discuss privately without being burned as you have
[05:14] <trappist> if I had a vote I'd say users should use their mua's reply-to-list feature to make their messages public
[05:15] <trappist> and that could go to the bug if the subject stays intact, with a re:
[05:15] <kiko> well, if the bug is CC:d it's enough
[05:15] <kiko> but...
[05:15] <kiko> many people don't use reply-to-list
[05:15] <kiko> how do you work around that?
[05:15] <trappist> if I see the guy's name I mean to email in the from: line and I hit reply, I have an expectation that it's going to him
[05:16] <kiko> yeah, see what you mean, but there are other angles to consider.
[05:16] <trappist> oh I understand that
[05:16] <trappist> your last point is a tough one
[05:16] <trappist> "people should do what they should do" is hardly an answer to it
[05:16] <kiko> the only answer I see is "user preference!"
[05:17] <trappist> ooh!
[05:17] <kiko> yeah.
[05:17] <trappist> user preference is almost always the right answer :)
[05:17] <kiko> well, except it's not :)
[05:17] <kiko> and we don't even have a facility for prefs in malone yet ;)
[05:19] <trappist> is there room for contributors to malone?  it's an awesome bug tracking system that could use a few more features, and I'd be interested in contributing
[05:20] <trappist> how about this: since replies are going to the bug, why not make the from: address the same, and add the poster as a piece of meta-data in the body?
[05:20] <kiko> trappist, I don't quite see what you mean
[05:21] <trappist> I mean it wouldn't have happened if I'd seen the bug in the from: field rather than my intended recipient
[05:27] <bradb> The subscribers of the dupe bug will mail from the dupe target bug. I fixed that bug a week ago. No idea if it's in production.
[05:27] <bradb> I guess I'll email launchpad@ about a way to make it easier to figure out what the current prod revision is
[05:29] <sfllaw> bradb: The best thing to do is log the Subversion revision number in the HTML of a page.
[05:29] <sfllaw> Maybe a META or something.
[05:29] <sfllaw> That way, if anyone sends you an HTML snapshot, you'll know exactly what revision generated that code.
[05:30] <kiko> subversion?
[05:30] <bradb> heh
[05:30] <sfllaw> Sorry.
[05:30] <sfllaw> Brain fart.
[05:30] <sfllaw> I was staring at Subversion all of yesterday.
[05:37] <bradb> ddaa: Is there an easy, programmatic, non os.system way, to do the equivalent of "bzr revno"?
[05:37] <ddaa> your mean using bzrlib?
[05:37] <bradb> sure
[05:38] <ddaa> what does the implementation of bzr revno look like?
[05:38] <bradb> I dare not find out.
[05:38] <bradb> but i guess i could
[05:38] <SteveA> the way to do this is on "make" to build a lookup list in a .txt file
[05:38] <ddaa> bradb: bzrlib.builtins.cmd_revno
[05:38] <SteveA> in a place well known relative to the webapp software
[05:38] <SteveA> so that it can read these and include them as needed
[05:38] <ddaa> bradb: it appears that branch.revno() does it
[05:39] <trappist> kiko: is it possible to unsubscribe, say, ubuntu-bugs from the bug?
[05:39] <SteveA> although, i'm not sure exactly what problem this is intended to solve
[05:39] <bradb> SteveA: My email will explain.
[05:39] <kiko> trappist, heh. no, but commonly-filed bug
[05:40] <sfllaw> kiko: Is there some way to get only newly-filed bugs?
[05:40] <sfllaw> Other than using procmail?
[05:40] <kiko> even using procmail it is non-trivial, but no.
[05:41] <sfllaw> kiko: Is there already a bug with this functionality?
[05:41] <sfllaw> I looked...
[05:41] <kiko> well, I'm not sure what you are asking for. only getting notifications for new bugs, not replies?
[05:41] <sfllaw> Yup.
[05:42] <sfllaw> My job would be a lot easier if I could process a bunch of those each morning.
[05:42] <sfllaw> Clear out duplicates that I remember.
[05:42] <trappist> following up on my earlier question, I guess I chould check out the malone source with bzr, but I'm not finding any info on where the repo is - can somebody point me to instructions on checking out?
[05:43] <kiko> sfllaw, use procmail?
[05:43] <kiko> :)
[05:43] <kiko> trappist, it's not publically available. :)
[05:43] <trappist> !
[05:43] <trappist> I'm a lil bit shocked
[05:43] <sfllaw> kiko: I could...  But it would be nice to not have LP continually hammer on my mail server.
[05:43] <kiko> yeah.
[05:43] <kiko> sfllaw, uhh I think you are prioritizing poorly there
[05:43] <kiko> mail server load -- trivial fix
[05:44] <kiko> malone preference -- large amount of work
[05:44] <sfllaw> I suppose.  But I'm paying for bandwidth.  :)
[05:44] <trappist> sfllaw: I'd +1 a feature like that
[05:45] <kiko> can't be that much in .ca
[05:46] <trappist> kiko: what's the motivation for not publishing the source?  it sounds like there's a lot of work to be done, and a lot of potential contributors...
[05:46] <kiko> trappist, it's a rather involved question to answer via IRC, but a) it will be public at some point in the future b) the concerns are more of fragmentation than of keeping the source secret
[05:49] <sfllaw> kiko: You need some sort of peer-to-peer protocol for LP.  :)
[05:50] <kiko> heh
[05:51] <SteveA> sfllaw: this was discussed a couple of years ago.
[05:51] <SteveA> sfllaw: we figured it would take a *lot* longer to develop launchpad that way
[05:51] <trappist> I see.  In the mean time, how does the project get contributors?
[05:52] <kiko> trappist, by assisting with triaging of the bugs themselves, and by providing useful feedback and criticism and QA on launchpad.
[05:54] <sfllaw> kiko: Well, I'll file a bug, because I think it would be of utility to people doing bug triaging.  It will be wishlist, of course.
[05:54] <bradb> BjornT: Ever figure out that testbrowser exception weirdness?
[05:56] <bradb> BjornT: Here's another observation: if I added a browser.open(".../+bugs") to workaround the bug, I still got the exception, but if I changed that to a browser.open($bug_page) I no longer got the exception.
[05:58] <SteveA> bradb: were you in the launchpad meeting on thursday?
[05:59] <SteveA> did you see the note about https:..
[05:59] <BjornT> bradb: yes, it's a weirdness in urlparse, i'll fix it tomorrow.
[05:59] <SteveA> did you see the note about https://wiki.launchpad.canonical.com/LaunchpadProductionStatus ?
[05:59] <bradb> oh, nice, didn't see that
[06:00] <SteveA> it was in the meeting
[06:01] <SteveA> stu added it for the kind of reason you point out in the email
[06:01] <SteveA> having something automated would be nice, although it wouldn't have the succinct reason for each cherrypick
[06:02] <SteveA> so, good suggestion brad.
[06:02] <SteveA> see if LaunchpadProductionStatus meets your needs
[06:02] <SteveA> and if not, we'll look at what to do
[06:03] <jordi> carlos: so I deleted one POT file
[06:03] <jordi> and it said "two items deleted"
[06:03] <jordi> and I freaked out :)
[06:03] <jordi> but it was one, really
[06:04] <carlos> jordi: two items deleted? or two items changed?
[06:04] <jordi> changed, sorry
[06:08] <carlos> jordi: there is a 'race' condition on that form
[06:08] <carlos> jordi: you get that page
[06:08] <carlos> the system approves one of your entries automatically
[06:08] <carlos> and you submit it
[06:08] <carlos> you submit it as Needs review, the system has it now as 'Approved'
[06:08] <carlos> so you change it
[06:09] <carlos> jordi: is not a big issue, it will be approved later 
[06:09] <jordi> aha
[06:09] <jordi> it just scared me twice already ;)
[06:33] <jordi> carlos: re: this thousand KDE po files
[06:33] <jordi> carlos: can I do soemthing about it?
[06:33] <carlos> jordi: no, I'm waiting for Riddell to know if we can ignore them or we are missing some .pot files
[06:33] <carlos> jordi: https://wiki.ubuntu.com/MissingPotFiles
[06:34] <jordi> makes searching for series po files quite impossible
[06:35] <carlos> yeah, I know...
[06:37] <sivang> matsubara: I see you checked the malone bug I filed, do you have any idea what might be causing this?
[06:38] <sivang> matsubara: if the package doesn't exist in the requested distro, the note does not get duplicated for some reason.
[06:40] <matsubara> sivang: I couldn't reproduce it. 
[06:42] <matsubara> sivang: wasn't it the case I commented on the bug? 
[06:46] <sivang> matsubara: I did not add the binary hint myself
[06:46] <sivang> matsubara: it was aded automatically
[06:49] <matsubara> sivang: ok, when you mentioned the note is duplicated, you mean duplicated in the description and the first comment? 
[06:50] <sivang> matsubara: correct. So this is working as desined?
[06:54] <matsubara> sivang: hmm, AFAIK when you edit a bug and it has no comments, the original description is appended as the first comment. I suppose the bug hint thing triggered that. That's a recently added feature, I think. I wasn't aware of it.
[06:54] <matsubara> sivang: I need to get some lunch, can we talk about this later? In 1 hour maybe?
[06:56] <jordi> carlos: https://launchpad.net/rosetta/imports/+index?status=NEEDS_REVIEW&type=po&start=1125&batch=75
[06:56] <jordi> there's some gcompris stuff in there
[06:56] <sivang> matsubara-lunch: ofcourse
[06:56] <sivang> matsubara-lunch: ping me when you're back.
[06:56] <jordi> hmm, and ooo
[06:57] <carlos> jordi: gcompris lacks a .pot file
[06:57] <jordi> nod
[06:59] <carlos> jordi: an dthe ooo entries need manual approval and contact those language teams and suggest that they should not use the country code information
[07:00] <carlos> talking about upstream language packs 
[07:01] <neutrinomass> I've tried signing the coc but I get two errors: The signed text does not match the Code of Conduct. Make sure that you signed the correct text (white space differences are acceptable). and "an error" occurred. When copy pasting the .asc in firefox, it seems to get garbled (I don't know if newlines are acceptable). Anyone else having similar problems?
[07:03] <carlos> neutrinomass: is not off topic, don't worry
[07:04] <neutrinomass> carlos Ok :)
[07:04] <carlos> neutrinomass: could you give us the error code you got?
[07:04] <carlos> OOPS-
[07:04] <neutrinomass> I'm not getting an error code. Just those two strings.
[07:04] <jordi> carlos: all the pending product series pot files are waiting for replies or clarification.
[07:04] <jordi> ie, it's "clean"
[07:05] <carlos> neutrinomass: oh, I thought you got first the rejection and then an error page
[07:05] <carlos> jordi: ok, you should remove/import all those next Monday as the last day
[07:05] <jordi> yeah
[07:06] <carlos> salgado: could you take a look to neutrinomass' problem?
[07:06] <neutrinomass> carlos: No, just the rejection. I've never really worked with gpg before, but I've been following instructions and everything seems ok. Only thing that doesn't appeal to me is that my .asc file starts with -----BEGIN PGP SIGNED MESSAGE-----, but doesn't end similarly.
[07:06] <carlos> neutrinomass: you should have an ending tag or the signature is broken
[07:07] <neutrinomass> carlos: I have this: -----END PGP SIGNATURE-----. But should a ---- END PGP SIGNED MESSAGE ---- be present ? (gpg doesn't output such a string in the .asc)
[07:09] <carlos> I really don't know... let me check
[07:11] <sivang> carlos: I eventually re-got everything last night, now I'm pulling for updates and getting: 
[07:11] <sivang> Using saved location: sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/launchpad/devel
[07:11] <sivang> bzr: ERROR: Revision {pqm@pqm.ubuntu.com-20060507115829-e0e65b77a04377e6} not present in inventory.
[07:11] <sivang> Using saved location: sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/launchpad/devel
[07:11] <sivang> bzr: ERROR: Revision {pqm@pqm.ubuntu.com-20060507115829-e0e65b77a04377e6} not present in inventory.
[07:11] <sivang> Using saved location: sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/launchpad/devel
[07:11] <sivang> bzr: ERROR: Revision {pqm@pqm.ubuntu.com-20060507115829-e0e65b77a04377e6} not present in inventory.
[07:11] <sivang> Using saved location: sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/launchpad/devel
[07:11] <sivang> bzr: ERROR: Revision {pqm@pqm.ubuntu.com-20060507115829-e0e65b77a04377e6} not present in inventory.
[07:11] <sivang> oops, that got duplicated few times - my laptop is itchy today..:-/
[07:12] <carlos> neutrinomass: seems like is correct, you will get the BEGIN PGP SIGNED MESSAGE, the Code of conduct and at the end a BEGIN PGP SIGNATURE and END PGP SIGNATURE
[07:12] <carlos> neutrinomass: at least that's what I got
[07:13] <carlos> sivang: so you did a bzr get from sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/launchpad/devel ?
[07:13] <neutrinomass> carlos: Yes. And if you try to copy paste it in the form provided at launchpad, it doesn't get copy pasted "correctly". The formatting breaks, which is probably why I get the "this is not the code of conduct" type error. Makes me wonder though, how did everybody else sign it ? :)
[07:14] <sivang> carlos: I acutally used jblack's rocketfuel-get
[07:14] <carlos> neutrinomass: it's pasted ok here...
[07:14] <sivang> carlos: I have rough idea what it does inside
[07:15] <neutrinomass> carlos: Weird. Thanks....
[07:15] <carlos> sivang: what's doing the sftp download then?
[07:15] <carlos> neutrinomass: I guess the problem is the different new lines you have when pasting it
[07:15] <carlos> neutrinomass: how did you copy it?
[07:15] <neutrinomass> copy, paste, from gedit
[07:16] <neutrinomass> Actually it shouldn't be related to that. I minimized firefox and increased it's width to double my screen and it gets copy pasted correctly. Let me do-things-at-random in case I fix it ....
[07:20] <carlos> neutrinomass: right, my signed coc was rejected too
[07:20] <carlos> neutrinomass: I think you will need to wait for salgado
[07:20] <neutrinomass> carlos: Ok. Thanks for your time :) 
[07:22] <carlos> you are welcome
[07:23] <sivang> carlos: I believe it's using rsync, not sftp
[07:23] <carlos> sivang: I know, but the error message you showed me says sftp ;-)
[07:24] <sivang> carlos: crap, it was using sftp :)
[07:24] <jordi> I love signed cocs
[07:24] <carlos> sivang: rocketfuel-refresh uses sftp
[07:24] <jordi> ok
[07:24] <jordi> carlos: I just accepted xaralx
[07:25] <carlos> sivang: but it should be used inside the launchpad directory
[07:25] <jordi> which leaves us with 3 pot files.
[07:25] <carlos> jordi: I saw it, cool ;-)
[07:25] <neutrinomass> Aha. I signed 1.0 just fine, it seems that coc 1.0.1 is causing the problems...
[07:25] <sivang> carlos: this is what I did :)
[07:25] <jordi> two of them will be deleted, very probably
[07:25] <carlos> jordi: would be better if you pointed them to the new URL where they should import any po file so we don't need to approve anything
[07:25] <jordi> the blender one I dunno what
[07:25] <jordi> carlos: what new url?
[07:26] <carlos> jordi: the URL to the +upload form for the new created template
[07:26] <sivang> carlos: can I just do bzr pull without using rf-refresh?
[07:26] <carlos> sivang: well, the idea behind refresh is to get updated trees at sourcecode/
[07:27] <jordi> https://launchpad.net/products/xaralx/0.4/+translations-upload ?
[07:27] <jordi> this one?
[07:27] <carlos> and it should not be done for launchpad if you execute it from within launchpad/
[07:28] <carlos> jordi: no, https://launchpad.net/products/xaralx/0.4/+pots/xaralx/+upload
[07:28] <sivang> carlos: okay, so from launcpad/ plain pull,
[07:28] <carlos> the one you gave is the one that will require our review
[07:28] <sivang> carlos: and from lp/sourcecode -refresh?
[07:29] <jordi> ok, so what's the difference between both?
[07:29] <jordi> why aren't both "smart"?
[07:29] <carlos> sivang: aren't you changing anything on that tree?
[07:29] <jordi> I'm missing something.
[07:29] <carlos> jordi: because the second one knows the potemplate were you are attaching the files
[07:29] <sivang> carlos: not yet, I just wanted to make sure I'm up to date with commits from today and from after the last night when I first checked all out
[07:29] <carlos> and with the first one you don't have such information
[07:29] <matsubara> carlos: I think neutrinomass is running into bug 39547
[07:29] <Ubugtu> Malone bug 39547 in launchpad "Code of Conduct 1.0.1 signatures not accepted" [Critical,Confirmed]  http://launchpad.net/bugs/39547
[07:30] <carlos> sivang: rocketfuel-refresh should give you that information 
[07:30] <carlos> sivang: it will create a fresh tree 
[07:30] <neutrinomass> matsubara: Heh, it didn't occur to me to search for the bug. Thanks. ( I signed 1.0 after all )
[07:31] <jordi> carlos: ah
[07:31] <jordi> ok
[07:31] <jordi> that makes sense :)
[07:31] <carlos> sivang:  on $WORKDIR
[07:31] <carlos> jordi: ;-)
[07:32] <jordi> carlos: does it make sense to hide the other link if the product series is setup for translation, then?
[07:32] <jordi> no
[07:32] <jordi> because you might add more templates
[07:32] <jordi> ignore me
[07:32] <carlos> right
[07:32] <jordi> I need sleep these days
[07:32] <sivang> carlos: oops
[07:33] <jordi> kiko is now fed
[07:33] <matsubara> sivang: i'm back.
[07:34] <kiko> I am
[07:34] <sivang> matsubara: cool
[07:34] <carlos> kiko: I think something is going wrong on production and the po import script
[07:35] <carlos> kiko: either is stalled or is not being executed
[07:35] <kiko> carlos, more firefighting? :)
[07:35] <kiko> oh
[07:35] <kiko> no launchpad error mail?
[07:35] <matsubara> sivang: well, the problem seems to be with the new binary package hint. when you report a bug in a binary package it automatically adds a Binary package hint in the description, changing the original description.
[07:35] <kiko> can you see it being executed?
[07:35] <carlos> kiko: no, and the imports are not being imported
[07:35] <kiko> hmmmm
[07:35] <kiko> mmmmmmmmm
[07:35] <carlos> kiko: I'm talking with you to know who could take a look while stuart is sleeping ;-)
[07:35] <kiko> carlos, what script should be running, how is it supposed to be run, and can we ask elmo or Znarl?
[07:36] <matsubara> sivang: it's better to talk with bradb about it to really confirm if it's a bug or a by design.
[07:36] <carlos> kiko: the script is called rosetta-poimport.py
[07:36] <kiko> matsubara, can you summarize the problem sivang is having?
[07:36] <kiko> carlos, cron or daemon?
[07:36] <carlos> kiko: and it's a cron job so I guess is a matter of checking first if it's running
[07:36] <carlos> kiko: cron
[07:37] <kiko> okay
[07:37] <kiko> Znarl, elmo: ping
[07:37] <kiko> carlos, what user does it run as?
[07:37] <Znarl> kiko : Pong?
[07:37] <carlos> I think launchpad
[07:37] <carlos> and it's executed on gangotri, or at least the cron output comes from there
[07:37] <kiko> Znarl, can you help carlos see why a certain script is not being run in production?
[07:38] <carlos> Znarl: hi
[07:38] <sivang> matsubara: okay, will do.
[07:38] <Znarl> kiko : Sure, glad to help.
[07:38] <Znarl> carlos : Hello. What do you want me to check?
[07:38] <carlos> first, I need to know if there is a process called rosetta-poimport.py running
[07:39] <carlos> Znarl: I think the user is launchpad
[07:39] <sivang> bradb: ping
[07:39] <matsubara> kiko: bug 43463
[07:39] <Ubugtu> Malone bug 43463 in malone "duplicated note when reporting a bug against a distro package." [Normal,Unconfirmed]  http://launchpad.net/bugs/43463
[07:39] <Znarl> carlos : Yes, rosetta-poimport.py is running.
[07:39] <carlos> Znarl: how old is it?
[07:39] <carlos> and would you check if it's stalled?
[07:40] <carlos> because it's taking a lot of time to finish
[07:40] <Znarl> carlos : 1000     31085  5.0  2.8 255312 113288 ?       Ssl  17:36   3:15 python /srv/launchpad.net/production/launchpad/cronscripts/rosetta-poimport.py -q
[07:40] <sivang> carlos: so rf-refresh was meant to always be executed in ~/canonical/rocketfuel/$WORKDIR(=launchpad) ? and not in ~/canonical/lptrees/rocketfuel/launchpad ?
[07:40] <matsubara> kiko: if you report a bug in a binary package, we change the original description adding a "Binary Package hint: $binarypackage" and the original description is appended as the first comment.
[07:41] <sivang> carlos: (given $WORKDIR was automatically created with rf-get)
[07:41] <carlos> sivang: right
[07:41] <carlos> the one on lptrees is updated already with the rsync
[07:42] <carlos> Znarl: hmm, is not normal that it takes so much time, would you kill it, please?
[07:42] <Znarl> carlos : ok.
[07:42] <carlos> Znarl: the cron daemon will execute it again without any data lose
[07:42] <carlos> Znarl: thank you
[07:43] <Znarl> carlos : It's dead.
[07:44] <carlos> Znarl: ok, thanks
[07:45] <sivang> matsubara: so https://launchpad.net/malone/bugs/+package is always for filing bugs against bin pkgs?
[07:45] <sivang> matsubara: what's the way to report a bug against a source package? or are we only allowing reports against bin pkgs?
[07:46] <bradb> sivang: pong
[07:48] <bradb> sivang: ah, interesting
[07:48] <matsubara> sivang: no, ideally you would report a bug in a sourcepackage. If you don't know the name of the sourcepackage, you can report it in a bin package (as you did) and we try to re-assign it to the correct sourcepackage, leaving the binary-package hint. 
[07:48] <bradb> sivang: You've found a bug with the recent bin pkg change, I think.,
[07:48] <matsubara> sivang: but bradb can clarify this better to you.
[07:48] <sivang> matsubara: k, thanks
[07:49] <jordi> carlos: hmm, I don't think that DB update I requested happened?
[07:49] <bradb> sivang: +filebug is for reporting bugs on packages, whether bin or src
[07:49] <jordi> a
[07:49] <carlos> jordi: did you get Stuart's confirmation?
[07:49] <sivang> bradb: so how do I know if I file it against src or bin?
[07:49] <jordi> nope
[07:49] <carlos> jordi: he always send a confirmation
[07:50] <carlos> so I guess it was not done
[07:50] <bradb> sivang: The rule is that a Malone user shouldn't care about the difference between a bin or src pkg. Malone figures it out.
[07:50] <sivang> bradb: (to file this amarok bug, I just did what seemed intuitive, as noted in the reproduction scenario)
[07:50] <sivang> bradb: I wouldn't mind too much about the note getting duplicated, it's just that at first sight I was sure I did something wrong :) 
[07:51] <bradb> sivang: You did the right thing. It appears that the Malone bug is that it didn't add the binary package hint to the initial comment, only to the description. This is incorrect, and has the side effect of the duplicate message you're seeing.
[07:51] <jordi> carlos: ok, up to date on activity reports again
[07:51] <carlos> jordi: cool, thanks
[07:52] <sivang> bradb: okay, good to know.
[07:53] <bradb> sivang: Can you please report a bug on that, btw?
[07:53] <sivang> bradb: ofcourse.
[07:53] <bradb> sweet, thanks
[07:54] <sivang> bradb: when you fix, I'd be interested in knowing where / what modifications were actually needed inside the code , or better be guided by you to try and come up with a patch myself. but the former is more realistic :)
[07:55] <bradb> sivang: I can send you a patch with a test in about 10-15 minutes, which might be helpful to figuring things out.
[07:56] <sivang> bradb: cool, please do.
[07:57] <jordi> carlos: ok, I'm done for today I think
[07:57] <jordi> carlos: do you need anything from me, from what you said in the morning?
[07:58] <carlos> Znarl: I will send you an email if I see tonight that it's stalled again. Thanks for your help
[07:58] <jordi> carlos: I'm so up to date I have a half-written activity report for this week even.
[07:58] <carlos> jordi: no, I think you did it perfect ;-)
[07:58] <carlos> jordi: thank you
[07:58] <carlos> see you tomorrow!
[07:58] <sivang> later carlos 
[07:58] <sivang> and jordi 
[07:59] <Znarl> carlos : Best results if that email goes to RT.
[07:59] <jordi> laters
[07:59] <jordi> hmm
[07:59] <jordi> I know what I'm missing
[07:59] <jordi> gah
[07:59] <carlos> Znarl: sure!
[08:00] <carlos> jordi: your brain?
[08:01] <kiko> hmmm, Znarl , very strange that that script hung. it never happened before
[08:02] <sivang> malone #43560
[08:02] <Ubugtu> Malone bug 43560 in example-content "Interesting files in Examples folder" [Normal,Unconfirmed]  http://launchpad.net/bugs/43560
[08:02] <sivang> err
[08:02] <sivang> malone #43650
[08:02] <Ubugtu> Malone bug 43650 in malone "New binary package hint causes duplication of initial bug report note." [Normal,Unconfirmed]  http://launchpad.net/bugs/43650
[08:02] <sivang> bradb: ^^
[08:03] <Znarl> kiko : We've not had any network problems, core machines crashing or other events which may have caused it to hang.
[08:04] <matsubara> sivang: why not update bug 43463?
[08:04] <Ubugtu> Malone bug 43463 in malone "duplicated note when reporting a bug against a distro package." [Normal,Unconfirmed]  http://launchpad.net/bugs/43463
[08:05] <bradb> I'll fix both of them! :P
[08:05] <sivang> more Karma for brad ! :)
[08:06] <sivang> matsubara: I had the wrong impressions, due to brain damage I must opne a new one in order to change original descripiont
[08:06] <sivang> matsubara: will do next time.
[08:08] <sivang> still getting that PQM error when pulling, /me goes to check if keys are all signed propely as noted in RFS
[08:08] <bradb> sivang: patch: https://chinstrap.ubuntu.com/~dsilvers/paste/filelCPWPt.html
[08:10] <bradb> It's pretty simple one, but at least it shows: 1. a fix starts with a test and ends with the implementation to make the test pass and 2. a few hints about where various bits of code live
[08:11] <sivang> bradb: taking a look now, I don't have the HTTP password so I need to scp it ;-)
[08:12] <bradb> ah, heh
[08:14] <sivang> bradb: so bug.py is the test? seems more like the fix 
[08:14] <bradb> sivang: The test is in bug-pages.txt.
[08:16] <sivang> bradb: k, that is more logical. thanks, I'll look now to see about those various bits of code and there living place.
[08:27] <sivang> does anybody know if scott's and jbailey's rookery repos are needed if one is using dapper? (this is the source list setup in RFS)
[08:28] <kiko> sivang, shouldn't be
[08:28] <sivang> kiko: thanks, that's what I thought.
[08:30] <sivang> heh, launchpad-depdencies got fatter since last time I used it :)
[08:30] <Keybuk> sivang: iirc, the current bzr is uploaded to dapper now
[08:30] <Keybuk> you should be using that, rather than the dailies
[08:32] <sivang> Keybuk: I already am, thanks for the note :)
[08:42] <sivang> hmm, has the location for the importd public key has changed? I can't seem to import it from /home/importd/public_html/importd@chinstrap.pub
[08:42] <sivang> (again , from the RFS instructions)
[08:59] <kiko> why do you need it
[09:07] <sivang> kiko: good question. Been following RFS like a blind. don't you need to have it, and sign it in order to be able to push branches? (and pqm's as well)
[09:13] <sivang> kiko: never mind, I'll leave it for now and go on with setup.
[09:57] <bradb> lamont: One way, I think, is to use bzr diff -r1..2
[09:57] <bradb> stub's the cherry pick master though
[09:58] <lamont> bradb: yeah - I figured that part out...  my next question is how confused will I be later... :0)(
[09:59] <bradb> heh
[10:07] <kiko> don't use diff
[10:07] <kiko> unless you want to loose history
[10:08] <kbrooks> huh?
[10:08] <kbrooks> kiko: svn diff doesnt automatically lose history in the diffed files. so why should bzr diff do that?
[10:09] <kiko> phone
[10:10] <kiko> well, how is lamont going to apply the diff to a tree?
[10:10] <kiko> if he uses patch...
[10:10] <kbrooks> kiko: ahhh
[10:11] <kbrooks> kiko: <rcs> diff loses history by design. ok. got that
[10:12] <lamont> kiko: I used bzr merge
[10:12] <kiko> yeah
[10:13] <lamont> but then, bzr log doesn't show the log entries for the merged versions (it wasn't the full set, you see..)(
[10:13] <kbrooks> kiko: "yeah" to me?
[10:13] <kiko> kbrooks, no and I am curious bout your reply
[10:41] <dilys> Merge to devel/launchpad/: [r=spiv]  Fixes bug 39312 (Launchpad pages grab focus when they finish loading). Fixes bug 43261 (Advanced search page lacks style sheet), and puts the page on a markup diet. Clarifies '[tab] ' explanation in Rosetta. (r3541: Matthew Paul Thomas)
[10:41] <Ubugtu> Malone bug 39312 in launchpad "Launchpad pages grab focus when they finish loading" [Normal,In progress]  http://launchpad.net/bugs/39312
[10:41] <Ubugtu> Malone bug 43261 in launchpad "Advanced search page lacks style sheet." [Major,In progress]  http://launchpad.net/bugs/43261
[10:50] <sivang> hmm , is stub supposed to come online ?
[10:54] <sivang> make schema is failing for me, after following DatabaseSetup
[10:55] <sivang> traceback goes deep to:
[10:55] <sivang>   File "/home/sivan/canonical/rocketfuel/launchpad/database/schema/../../lib/zope/proxy/__init__.py", line 21, in ?
[10:55] <sivang>     from zope.proxy._zope_proxy_proxy import *
[10:55] <sivang> ImportError: No module named _zope_proxy_proxy
[10:55] <elmo> run make
[10:56] <sivang> elmo: thanks, now move forward to make schema?
[10:56] <elmo> right
[10:56] <sivang> weird, same thing. maybe I need a clean tree and retry?
[10:57] <elmo> eh, how is your current tree not clean?
[10:57] <sivang> elmo: failing make schema before make
[10:57] <elmo> no that shouldn't matter
[10:57] <elmo> hang on - just 'make' gives you that error?
[10:58] <sivang> nope, it does not. it just spits:
[10:58] <sivang> python2.4 utilities/shhh.py make -C sourcecode build PYTHON=python2.4 \ PYTHON_VERSION=2.4 LPCONFIG=default
[10:58] <sivang> and that's all
[10:59] <elmo> do you have a sourcecode/zope/src/zope/proxy/_zope_proxy_proxy.so
[11:00] <kbrooks> who are you, elmo? :-)
[11:00] <kiko> link_external_sourcecode, sivang?
[11:00] <sivang> elmo: I do
[11:00] <sivang> kiko: ?
[11:06] <salgado> sivang, try adding a 'import zope; print zope.__file__' line before the import that is failing in lib/zope/proxy/__init__.py
[11:15] <sivang> salgado: did that
[11:16] <salgado> sivang, and what did it print?
[11:16] <BjornT> sivang: try: make -C sourcecode/zope
[11:17] <sivang> salgado: /home/sivan/canonical/rocketfuel/launchpad/database/schema/../../lib/zope/__init__.pyc
[11:18] <sivang> BjornT: done, no erros
[11:19] <sivang> BjornT: make schema still fails
[11:19] <BjornT> sivang: and does sourcecode/zope/src/zope/proxy/_zope_proxy_proxy.so exist?
[11:20] <sivang> BjornT: correct
[11:23] <elmo> sivang: does lib/zope ?
[11:25] <BjornT> sivang: hmm, not sure what is wrong. do you have read access to _zope_proxy_proxy.so?
[11:27] <sivang> elmo: yep. lib/zope is there full of stuff
[11:28] <sivang> elmo: launchpad/lib/zope/proxy doesn't have the produced .so, only sourcecode/zope/src/zope/proxy/_zope_proxy_proxy.so
[11:28] <sivang> BjornT: checking
[11:28] <elmo> sivang: lib/zope should be a symlink
[11:28] <elmo> your tree is fux0red
[11:29] <elmo> just rsync a working pre-built tree off of chinstrap
[11:29] <sivang> BjornT: -rwxr-xr-x
[11:30] <BjornT> sivang: yeah, what elmo said
[11:30] <sivang> elmo, BjornT : thanks *alot* guys, I will fix that now
[11:36] <sivang> elmo: is this the only symlink full dir on the tree? 
[11:39] <lifeless> kiko: they were disabled at steves request
[11:39] <lifeless> kiko: because the time to run their test suites was non trivial. 
[11:39] <salgado> sivang, almost everything inside lib/ is a symlink to a directory inside sourcecode/
[11:40] <lifeless> and as had no evidence of how big a problem it *would* be, all I could do is say *I think* it will be a problem.
[11:40] <lifeless> sivang: bzr st should tell you
[11:40] <lifeless> sivang: as it tracks teh symlinks