[12:24] <kikoX> Ahoy
[12:24] <kikoX> jordi?
[12:24] <kikoX> Wtf?
[12:34] <bradb_> kikoX: hey dude
[12:35] <bradb_> got your message the other night, but not until the next morning
[12:35] <bradb_> where are you now?
[12:36] <kikoX> in NH
[12:37] <kikoX> how's it going
[12:38] <bradb_> not bad...an apparently nasty email machinery bug over the weekend that caused a ton of dups to be filed
[12:38] <kikoX> wow?
[12:38] <kikoX> hey mpt
[12:39] <bradb_> apparently if the db connection doesn't close cleanly, the message doesn't get removed from the processing queue, and was getting reprocessed every time the cron script ran again
[12:39] <kikoX> aaargh
[12:39] <bradb_> so, siretart sent two emails, which created about 20-30 bugs in Malone :)
[12:40] <bradb_> i think BjornT had submitted the patch to pqm, but not having checked my mail in a bit, i'm not sure if it's in
[12:40] <kikoX> I see
[12:42] <bradb_> looks like it's in. BjornT, Rev 2825 is the one that should be cherry picked then, i take it?
[12:43] <kikoX> how's montreal 
[12:43] <bradb_> windy today
[12:44] <bradb_> there was a huge xmas parade on st-cath on saturday
[12:44] <bradb_> and...i got a new cell phone!
[12:44] <bradb_> a nice one too, an ericsson, Z520a
[12:45] <bradb_> it's more complex than it needs to be though. my mobile does *not* need a dedicated side button for the camera.
[12:49] <lifeless> bradb_: its in
[12:51] <bradb_> lifeless: did BjornT ask for it to be cherry picked?
[12:53] <kikoX> cool. does it have bluetooth?
[12:53] <lifeless> bradb_: oh, no.
[12:53] <bradb_> kikoX: yep
[12:54] <bradb_> lifeless: can you cherry pick, or should i ask stub?
[12:56] <kikoX> I envy you bradb
[12:57] <kikoX> I might get one for me this year
[12:59] <bradb_> heh
[12:59] <dholbach_> good night everybody
[12:59] <kikoX> the 77O needs one
[12:59] <bradb_> i might take this one back though. there's some bright pixels in the bottom left corner of the screen.
[02:39] <jordi> kikoX: hey
[02:39] <jordi> dude I am in Boston at mako's
[02:39] <jordi> if you're around do pop up because we're having party
[04:34] <kiko> jordi, I will only be in boston tomorrow evening
[04:34] <kiko> jordi, will you have split?
[04:35] <kiko> jordi, my phone doesn't work in VT or NH
[04:35] <kiko> it's fucked
[04:36] <kiko> does mako have a phone?
[04:50] <jamesh> so bzr's sftp impl doesn't support compression
[04:50] <jamesh> so downloading the inventory weave takes 13MB rather than 2MB
[04:59] <spiv> That's a shame.  Shouldn't be too hard to fix.
[04:59] <spiv> I seem to recall Conch can do it.
[05:01] <jamesh> "* support compression" is on the missing features list in the paramiko README
[05:02] <jamesh> "sftp pipelining" is also on that list
[05:02] <elmo> why not just spawn sftp(1) again?
[05:02] <jamesh> don't ask me
[05:03] <jamesh> gnome-vfs spawns ssh and implements the SFTP protocol itself
[05:03] <jamesh> which is another option
[05:03] <bob2> is lp using bzr now?
[05:03] <jamesh> bob2: yeah
[06:10] <lifeless> bob2: read bazaar-ng, see the pie, news @ 11.
[06:10] <lifeless> :)
[06:11] <bob2> haha
[06:14] <\sh> hmm...how do I get a buglist in xml != xhtml from LP, e.g. all bugs reported or assigned to a LP member/team? or retrieve an xml doc of a specific bug search query?
[06:14] <jamesh> \sh: I don't think we have that yet.
[06:17] <\sh> jamesh: k...so I have to find another way of getting some lists out of malone
[06:18] <stub> \sh: You might want to file a bug stating what queries you want, and if XML-RPC is a good interface or if you need plain old HTTP GET. They were working on the remote API for this stuff at UBZ
[06:18] <kiko> \sh, what sort of list do you need?
[06:18] <jordi> oh kiko is online
[06:18] <kiko> so I am
[06:19] <\sh> kiko: actually buglists like https://launchpad.net/people/shermann/+assignedbugs but only in a good xml notation  
[06:20] <kiko> \sh, XML format would indeed be sweet. shouldn't be hard to do
[06:20] <\sh> or better xmlrpc interface 
[06:21] <\sh> i'm writing on this glpbugs tiny tool
[06:21] <\sh> which will be a mixture of reportbugs and kbugbuster ,) 
[06:21] <kiko> you said k
[06:22] <\sh> only better and for launchpad
[06:22] <\sh> kiko: k as in "an example" of programm....and please see "Glpbugs" ,)
[06:22] <kiko> okay just this once
[06:25] <\sh> btw...when I'm the bug reporter and the reported bug is set to pending upload..the bug is removed from the reported bugs list ... that reminds me to search for it in malone and/or file a bug against malone...
[06:36] <stub> lifeless: I'm getting the 'success' and 'failure' messages from pqm. I'm getting log output from successful merges that other people land. However, I'm not receiving the test output from failed merges I submit, nor log output from successful merges I submit.
[06:37] <kiko> what do you get instead stub?
[06:37] <stub> nothing
[06:38] <stub> kiko: Did you get a commit message from my landing yesterday? Probably r2822?
[06:39] <kiko> lemme see
[06:39] <kiko> yes
[06:39] <kiko>   [r=SteveA]  Database adapter features
[06:39] <stub> Hmm... so it got to the mailing list
[06:43] <stub> Oh... take that back. I did get output from the test suite. Just no output from that successful merge. Maybe the log message was tooo biig and got blocked somewhere?
[06:44] <stub> yer - I have a bounce score :-/
[06:45] <kiko> oh-oh
[06:47] <stub> I wonder if it is because I'm subscribed with my canonical.com email address? I think my primary account has a 10MB limit or something so that shouldn't be the issue
[08:19] <Burgundavia> lifeless, piong
[08:21] <lifeless> Burgundavia: pong
[08:22] <Burgundavia> lifeless, I realized I don't have an email for you. I wanted to add you in linkedin
[08:23] <jamesh> Burgundavia: firstname.lastname@canonical.com or @ubuntu.com works for pretty much all Canonical employees
[08:24] <Burgundavia> jamesh, ok
[08:24] <robitaille> Burgundavia,  https://launchpad.net/people/lifeless
[08:27] <Burgundavia> also, anybody got a current email for lamont.
[08:27] <Burgundavia> ?
[08:30] <bob2> Burgundavia: lamont has had the same email address for about 20 years
[08:31] <robitaille> Burgundavia,  https://launchpad.net/people/lamont
[08:34] <Burgundavia> bob2, that is about 3 years less than I have been alive, and about 19 more than I have known him
[08:34] <Burgundavia> not long now
[08:37] <Burgundavia> hmm, when did LP get suppport for irc/jabber ids?
[08:37] <robitaille> Burgundavia,  months ago...
[08:38] <robitaille> I think it has always been around in your profile
[08:43] <SteveA> morning
[09:28] <robitaille> is there a way to remove a remote bug watch from a Malone bug report?  Someone added 3 Bugzilla bug watches to bug #2051, and they have nothing to do with that Malone bug...
[09:28] <Ubugtu> Malone bug #2051: player (Ubuntu) - flashplugin-nonfree and flash-player contain the same files Fix req. for: flash-player (Ubuntu), Severity: Normal, Assigned to: MOTU, Status: New http://launchpad.net/malone/bugs/2051
[09:31] <Burgundavia> robitaille, what do you think of listing in the bug watches inline with the bugs in LP?
[09:32] <Burgundavia> ie, create a line above the "flash-player (Ubuntu)"
[09:32] <SteveA> robitaille: no.  there is no way to do it other than asking the DBA to do so.  i just checked the database security config, and these things can't be deleted.
[09:32] <SteveA> robitaille: however, there ought to be some way to do it, whether this is deleting the watch, or saying that it no longer applies.
[09:32] <SteveA> robitaille: maybe you can file a bug for bradb?
[09:33] <robitaille> SteveA,  I'm about to file one
[09:33] <robitaille> Burgundavia,  actually I like the bug watches in that box on the right-hand side.
[09:34] <Burgundavia> robitaille, why do you like them seperate from the bug listings? (just asking)
[09:35] <jamesh> Burgundavia: you can link a bug watch to a bug task
[09:35] <Burgundavia> jamesh, I am confused by your statement
[09:35] <jamesh> Burgundavia: see https://staging.ubuntu.com/distros/ubuntu/+source/metacity/+bug/12962
[09:36] <jamesh> the "metacity (upstream)" task is linked to a bug watch
[09:36] <Burgundavia> nice
[09:36] <Burgundavia> why are not all the bug watches listed like that?
[09:36] <jamesh> when the bug watch sync scripts run, the task status and severity get updated to match the remote bug tracker
[09:37] <Burgundavia> I am talking about the UI
[09:37] <Burgundavia> I wonder why all the bug watches are not listed up there with the actual bug report
[09:37] <Burgundavia> it seems odd to relegate them to a portlet
[09:45] <jamesh> there is a bunch of information in portlets that arguably should be in the main content area
[09:45] <jamesh> any reason for bug watches in particular?
[09:46] <Burgundavia> just thinking about it on my walk to work this morning
[09:49] <BjornT> stub: did my fix for bug 4396 make it into production yet?
[09:49] <Ubugtu> Error: I cannot access this bug
[09:50] <stub> BjornT: No
[09:53] <stub> BjornT: It will go out in the next production rollout, either tomorrow or Thursday. We have only seen the issue happen once (?), so it isn't urgent
[09:53] <SteveA> bug 4396
[09:53] <Ubugtu> Error: I cannot access this bug
[09:54] <BjornT> stub: if you're happy with that, sure
[09:55] <SteveA> ewww... the text formatter for bug messages doesn't understand the leading ">" email convention
[09:55] <stub> After discussions at UBZ we determined we should only be cherry picking 'urgent' fixes into production to avoid daily rollouts.
[09:57] <SteveA> it's like italian sheet music publishers
[09:57] <SteveA> no idea what they do now, but in the days before computer typesetting, they had a policy of never issuing corrections
[09:58] <SteveA> because it was more likely to cause more harm than good.  so you had to make do with what was published, until there was a whole new edition.
[10:02] <sivang> hehe
[10:02] <sivang> morning all
[10:02] <stub> I vote for a sniffer that detects Firefox and IE and uses <pre style="white-space: -moz-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"> because I've yet to see any indication that formatting them correctly is possible
[10:02] <jamesh> we should probably force a newline if we see a ">" in fmt:text-to-html
[10:03] <stub> Without using the non-standard CSS
[10:03] <jamesh> stub: if you include "white-space: pre-wrap" in there too, it will work with browsers that support CSS3 too
[10:04] <stub> But how do you test it ;)
[10:05] <SteveA> easy when unit testing
[10:05] <SteveA> difficult for a large scale functional test
[10:07] <stub> I meant that pre-wrap renders things correctly, since there are no CSS3 capable browsers yet (?)
[10:14] <jamesh> other than the ">" quote issue, are there any other major problems with the current formatting?
[10:21] <SteveA> stub: so, we'd write a test that ensures that pre-wrap appears in a style that affects the pre element we care about, and write that CSS3 says that is what we want.
[10:21] <SteveA> jamesh: it is hard to tell without the ">" being fixed ;-)
[10:25] <stub> SteveA: My point is that until there is a CSS3 capable browser, we have no empirical evidence that it does what it is supposed to. For all we know a developer might stuff up and it renders as <blink> in Firefox 3.5. I was picking on CSS3 and its current non-existance, not being serious
[10:26] <SteveA> we could do CSS3 in launchpad; make it render areas of pages as .png files
[10:26] <stub> jamesh: We seem to be finding new ones regularly although I'm still happy to be proven wrong ;)
[10:27] <stub> SteveA: Bitmaps? Are you crazy? Output as XML-FO and use client side XSL transformation to convert it to what the user wants. Bitmaps aren't accessible.
[12:01] <Lathiat> 
[12:29] <StevenK> There seems to be a little problem with Launchpad - I'm currently listed as "Ubuntero: Yes" and my Karma is 435 -- it wasn't yesterday, and the list on my karma is a whole bunch of Rosetta stuff that I didn't do ...
[12:29] <Kinnison> Wow
[12:30] <Kinnison> What is your person name?
[12:30] <StevenK> stevenk
[12:30] <Kinnison> Hmm, so it does
[12:31] <Kinnison> Unfortunately our dba headed to the gym 5 minutes ago
[12:31] <StevenK> Heh, whee.
[12:31] <Kinnison> stub: upon your return, can you please check out stevenk's problem ^^ ?
[12:31] <Kinnison> he'll have that in his scrollback on his return now
[12:31] <SteveA> StevenK: are you asking about just the karma thing, or about the 'ubuntero' thing too?
[12:32] <StevenK> SteveA: Both.
[12:32] <SteveA> StevenK: did you sign the code of conduct?
[12:32] <StevenK> Yup.
[12:32] <SteveA> so, that'll explain the 'ubuntero' thing
[12:32] <StevenK> Ahhh, okay.
[12:32] <SteveA> an ubuntero is someone who has agreed to behave according to the code of conduct
[12:33] <StevenK> Well, I'm helping people on IRC and looking at the wiki, so I thought I'd be nice and sign it.
[12:33] <StevenK> Well, I don't mind having a karma of 435, but I didn't do it. :-)
[12:33] <Kinnison> That is a bit odd
[12:34] <carlos> StevenK, did you translate anything for GNOME, KDE or any other free software we have in launchpad?
[12:35] <StevenK> carlos: I barely speak English well, so no. :-)
[12:35] <carlos> StevenK, and did you upload any .po file for any product we have ?
[12:36] <StevenK> carlos: Not to Rosetta, I do maintain a product you potiently have - Linda, the Debian package checker.
[12:37] <carlos> hmmm
[12:38] <carlos> ok, we need our DBA
[12:39] <StevenK> Okay, I just thought I should actually let someone know, if I've managed to get someone else's karma or something.
[12:39] <Kinnison> Your karma events show up as happening last wednesday
[12:40] <StevenK> Kinnison: I don't remember learning a new language last Wednesday ...
[12:40] <carlos> Kinnison, did you see it on staging?
[12:40] <carlos> if it was done on Wednesday I can do the checks myself
[12:40] <StevenK> Kinnison: I didn't know you were a Ubuntu person, btw ...
[12:40] <Kinnison> StevenK: well, for now, I'm a launchpad person :-)
[12:40] <StevenK> Kinnison: :-)
[12:50] <Kinnison> it's just some output from a test
[12:50] <Kinnison> I wouldn't be so upset if I were you :-)
[12:50] <StevenK> Kinnison: :-) At the moment, I'm trying to avoid studying for an exam, so *any* distraction is welcome.
[12:53] <LarstiQ> StevenK: for a distraction, looked at bzr yet? ;)
[12:56] <StevenK> Heh.
[12:56] <StevenK> Actually, I just got so annoyed at tla-buildpackage that I ripped everything over to SVN, so I'm quite happy with my VCS at the moment.
[12:57] <StevenK> If I knew my wife wouldn't notice, I'd install Ubuntu on this machine.
[12:57] <LarstiQ> heh, what is it running atm?
[12:57] <StevenK> sid
[01:00] <carlos> StevenK, hmmm, ok, I see why you got karma 
[01:00] <StevenK> carlos: Cool. Should I have?
[01:01] <carlos> StevenK, I think  the pl.po and en.po for linda have your name as the last translator
[01:01] <carlos> StevenK, could you confirm me it, please?
[01:01] <StevenK> Ah, yes, that is the case.
[01:02] <carlos> StevenK, https://launchpad.net/distros/ubuntu/dapper/+source/linda/+pots/linda/
[01:02] <StevenK> Linda is a little strange - I use PO files to lookup strings from tags.
[01:02] <carlos> StevenK, that's still a bug because you should not get karma in that case
[01:03] <carlos> Kinnison, I think that I finally found the path that gives you it (I fixed some other cases)
[01:03] <Kinnison> carlos: cool
[01:04] <StevenK> It's a neat bug, in any case - I haven't done anything, and already have karma > 400. :-)
[01:04] <carlos> StevenK, about the Ubuntero status.. no idea
[01:05] <StevenK> carlos: Ah, SteveA answered that.
[01:05] <StevenK> carlos: It's due to me signing the Code of Conduct.
[01:05] <carlos> oh, you did? I didn't see it, sorry :-P
[01:28] <cprov> jordi: ping
[01:30] <StevenK> carlos: Will my ill-gotten karma be ripped away?
[01:31] <carlos> StevenK, the karma is reduced if you don't do new translations
[01:33] <Kinnison> The atrophy of cosmic energy
[01:34] <StevenK> carlos: ... but I will ... since I'll upload new versions of Linda.
[01:35] <carlos> StevenK, well, when we fix the bug, you will not get new karma
[01:37] <Kinnison> stub: upon your return, I could do with a blessing for https://chinstrap.ubuntu.com/~dsilvers/paste/file9eWaU2.html
[01:47] <carlos> StevenK, anyway... you should not put your name as last translator of those files if you are not really a translator
[02:11] <stub> Kinnison: Approved - I'll give you a number in a bit
[02:12] <Kinnison> stub: thanks
[02:17] <carlos> see you later
[02:54] <Seveas> is there/will there be a mailinglist like ubuntu-bugs@lists.ubuntu.com (auto-subscribed to all bugs) for malone?
[02:58] <bradb> (first snowfall)++ # pretty
[02:58] <bradb> (20th snowfall)-- # IS IT SUMMER YET?
[03:11] <sivang> bradb: lol, shame I'm not there to see it :)
[03:48] <Kinnison> stub: got a patch number for me yet?
[03:51] <stub> Kinnison: patch-40-01-0.sql, assuming my landing lands
[03:51] <Kinnison> stub: Right, okay
[03:52] <stub> 1 hour 10 mins in pqm - should be any day now
[03:53] <Kinnison> cool
[03:59] <SteveA> hi salgado 
[03:59] <SteveA> how's it going?
[04:01] <kiko-zzz> hey dudes
[04:05] <Kinnison> Urgh, forbidden attribute arse
[04:05] <salgado> hi SteveA, kiko 
[04:06] <kiko> how's it going salgado 
[04:06] <kiko> made it back in one piece?
[04:06] <Kinnison> zope.security.interfaces.ForbiddenAttribute: ('section', <SourcePackageRelease at 0x-4953ad34>)
[04:06] <Kinnison> anyone know why that'd happen when section is in the interface?
[04:06] <kiko> that's happened to me before
[04:06] <kiko> www or doctest?
[04:07] <Kinnison> script
[04:08] <Kinnison> I really don't need this. I'm feeling quite ill and I just want to finish this queue management script so I can rest
[04:09] <kiko> hmmmm
[04:09] <kiko> Kinnison, so initzopeless?
[04:09] <Kinnison> yes
[04:09] <Kinnison>     ztm = initZopeless(dbuser=config.uploadqueue.dbuser)
[04:09] <kiko> why are you getting a security proxied instance?
[04:09] <Kinnison>     execute_zcml_for_scripts()
[04:09] <kiko> getutility?
[04:09] <Kinnison>     distro = getUtility(IDistributionSet).getByName(options.distro)
[04:09] <Kinnison> it all stems from there :-)
[04:09] <Kinnison> and zope spanks me for it :-(
[04:09] <kiko> hmmm
[04:10] <kiko> so you get a distroset and when querying from it you get back packages with forbidden section?
[04:10] <Kinnison> after drilling through a few layers yes
[04:10] <Kinnison> distro -> distrorelease -> queue -> queuesource -> sourcepackagerelease
[04:10] <Kinnison> I can read the sodding section
[04:11] <Kinnison> just not write to it
[04:11] <Kinnison> and nothing I can find suggests it should be in the least bit readonly
[04:12] <jordi> cprov-away: pong
[04:12] <kiko> you need to write to section, then?
[04:12] <kiko> hey jordi 
[04:12] <kiko> how's boston?
[04:12] <Kinnison> kiko: yes, this is an override adjustment in the queue
[04:12] <Kinnison> this involves writing to the section/component/priority of things
[04:12] <kiko> I see.
[04:13] <jordi> Kinnison: I haven't been in the city yet
[04:13] <jordi> I've been in Cambridge/MIT
[04:13] <jordi> today is Boston and finally airport.
[04:13] <kiko> Kinnison, I wonder. What user does your script run as -- not the dbuser, but the user.
[04:13] <Kinnison> kiko: me
[04:13] <jordi> damn
[04:13] <BjornT> Kinnison: iirc, <allow interface="..."> only specify read permissions. for write you need to specify <allow set_schema="..."> as well in sourcepackagerelease.zcml
[04:13] <jordi> sorry daniel :)
[04:13] <Kinnison> BjornT: you what?!
[04:13] <kiko> Kinnison, and you have launchpad.Edit on the SPR?
[04:13] <BjornT> Kinnison: sorry, i'm tired atm :)
[04:14] <Kinnison> kiko: I'm not logged in
[04:14] <Kinnison> kiko: This is a script running on an appserver
[04:14] <BjornT> Kinnison: look in sourcepackagerelease.zcml
[04:14] <Kinnison> BjornT: right?
[04:14] <BjornT> Kinnison: you'll see a section <content class="...ISourcePackageRelease">
[04:14] <Kinnison> without the I yes
[04:15] <BjornT> in that section you have <allow interface="...ISourcePackageRelease">
[04:15] <Kinnison> yep
[04:15] <BjornT> Kinnison: yes, withouth the I
[04:15] <BjornT> Kinnison: that tells you that you allow reading, but since you haven't set up any write permissions, you're not allowed to set any attributes
[04:16] <Kinnison> urgh
[04:16] <BjornT> Kinnison: so that first question is, who should be allowed to set attributes?
[04:17] <Kinnison> Erm, in terms of the UI, probably only those people in a team not yet defined
[04:17] <Kinnison> in terms of the scripts, it should just work goddamnit
[04:17] <Kinnison> at this rate, I'm gonna unwrap the proxy to just get on with it
[04:18] <BjornT> Kinnison: so then you can use <require permission="launchpad.Edit" set_schema="...ISourcePackageRelease"> for now
[04:20] <BjornT> i think scripts are allowed to get/set attributes as long as a security declaration exists
[04:20] <Kinnison> okay
[04:21] <Kinnison> BjornT: didn't help
[04:22] <Kinnison> It'd be really handy if it told you why it was forbidden
[04:25] <kiko> such is life
[04:25] <kiko> I'm outta here
[04:26] <kiko> stay safe loafers
[04:27] <uws> I never dare to put XXX in my code
[04:27] <Kinnison> why not?
[04:28] <Kinnison>     # XXX: dsilvers: 20051115: Should not need this, but until ZCML makes more
[04:28] <Kinnison>     # sense to me, it's quicker than fighting the security model.
[04:28] <uws> I'm too scared a colleague trying to find porn on my machine will find it
[04:28] <Kinnison>     from zope.security.proxy import removeSecurityProxy
[04:28] <Kinnison> aah, FIXME and TODO mean different things
[04:28] <uws> grep -e TODO -i FIXME
[04:28] <Kinnison> codepaths which touch XXXs should warn
[04:29] <Kinnison> code which hits a FIXME should error
[04:29] <Kinnison> code which passes a TODO is an info
[04:29] <uws> not in my code :)
[04:29] <Kinnison> not in my code either, but this is work, not play
[04:29] <uws> Heh. that's the same her :P
[04:29] <uws> here*
[04:30] <uws> I get paid to hack on a personal project ;)
[04:30] <uws> (which I use at work too)
[04:30] <Kinnison> lucky you
[04:30] <uws> nah
[04:30] <uws> not really
[04:30] <uws> (my laptop battery is dying, if I don't respond you know why)
[04:31] <uws> I'm the only linux user in a win32 company
[04:34] <LarstiQ> uws: aww
[04:35] <uws> LarstiQ: bear with me! :)
[07:10] <bradb> BjornT: Hi. Are you interested in reviewing the X-Malone-Bug bit of the malone-initial-bug-contacts branch?
[07:11] <BjornT> bradb: how big is the diff?
[07:12] <bradb> BjornT: 7 files changed, 210 insertions(+), 23 deletions(-) approximately. (I haven't yet figured out how to get bzr to tell me what changes I've made from the "parent" branch.)
[07:13] <stub> bzr diff -r branch:/my/local/mirror/of/the/parent/branch
[07:13] <stub> (branch is a keyword)
[07:13] <bradb> ah, that seems like a well hidden feature
[07:14] <stub> Indeed. I'm sure there is some even more obscure syntax lurking in there to diff against a particular revision too.
[07:15] <stub> I suspect that will be changed - enough people have found it to be 'non discoverable'
[07:15] <Kinnison> stub: Happy for me to have 40-01-0 for my patch?
[07:15] <stub> Kinnison: yes
[07:15] <Kinnison> cool
[07:15] <bradb> i did bzr diff -r2821..2822, because at least that much was documented. branch: is not (in the place where i'm looking for it, which is 'bzr help diff'
[07:16] <Kinnison> bradb: 'bzr diff /some/other/branch' is intended to work at some-future-time. See bzr-devel for more info
[07:16] <stub> Its kinda obvious what you mean if you specify a path name to a totally different working tree. Not sure what the issue is
[07:16] <bradb> Kinnison: I'm as keen to follow bzr-devel as bzr developers are to follow LP development discussion, tbh. :)
[07:17] <stub> 367 unread messages in there ;)
[07:17] <bradb> BjornT: So, it's 7 files changed, 224 insertions(+), 25 deletions(-)
[07:17] <Kinnison> bradb: the issue with diff /some/other/branch is what you mean if there are uncommitted changes over in the other branch
[07:18] <BjornT> bradb: sure, send it to me.
[07:18] <bradb> ok
[07:24] <bradb> BjornT: sent
[08:06] <mdke> i have a question about specs on LP
[08:07] <mdke> i wrote a spec recently and requested some feedback. the page now shows "no feedback requests outstanding", but I never received anything, despite being subscribed to the page, AND the wiki page. I _think_ the reviewer made a change to the status (Needs Discussion, Needs Guidance) but I have no way of telling, because I can't find any kind of comment history. What can I do?
[08:16] <ddaa> mdke: ask the reviewer?
[08:17] <ddaa> optionally, fill a bug about lack of status history :)
[09:02] <sivang> ddaa: I already filed a bug about lack of review emailing interface :)
[09:12] <mdke> did I miss a reply to my question earlier?
[09:12] <mdke> (network issues)
[09:27] <lifeless> bradb: bzr log --help
[09:27] <lifeless> bradb: does that explain how to get the 'last 10' well enogh ?
[09:28] <bradb> lifeless: As best I can see, it doesn't mention anything about getting the last N logs.
[09:29] <lifeless> 'To request a range of logs, you can use the command -r begin..end
[09:29] <lifeless> -r revision requests a specific revision, -r ..end or -r begin.. are
[09:29] <lifeless> also valid.
[09:29] <lifeless> '
[09:29] <bradb> The documentation for -r informs me enough to let me know that if my brain is willing to calculate this all, there is a way to show the last 10 revisions.
[09:29] <lifeless> ok
[09:43] <ddaa> lifeless: hey
[09:44] <ddaa> I'd like your advice
[09:44] <ddaa> what do you think would be the proper thing to do:
[09:44] <ddaa> harass you and niemeyer until you adress the review items I punted to you, or fix them myself so the branch can land this week?
[09:45] <lifeless> ddaa: well, I have emailed the review list, ccd you I think, so you know exactly what my fixes would be.
[09:45] <lifeless> ddaa: I did that email up with steve.
[09:45] <lifeless> in terms of proper, 'pragmatism beats purity'
[09:48] <ddaa> I'm not sure I can parse your last two messages
[09:49] <lifeless> Steve and I reviewed the review feedback on the code I wrote
[09:49] <lifeless> I did up an email saying how those points would be address which he was happy with.
[09:49] <lifeless> thats the first two lines.
[09:49] <ddaa> okay
[09:49] <lifeless> the last line is a quote from the python Tao.
[09:49] <lifeless> ;)
[09:50] <lifeless> by which I mean 'do it yourself is probably better'.
[09:50] <ddaa> Approximative quote.
[09:50] <lifeless> paraphrase then.
[09:50] <ddaa> "Special cases aren't special enough to break the rules.
[09:50] <ddaa> Although practicality beats purity."
[09:51] <ddaa> yeah, I got the gist of your misquote :)
[09:51] <lifeless> I've been trying to get to it since you mailed it to me
[09:51] <lifeless> but had various mishaps
[09:51] <lifeless> given its your branch to land, and the changes needed to the code I wrote are miniscule, I think its better you do it.
[09:51] <sivang> lifeless: I didn't know python had a Tao :)
[09:52] <ddaa> lifeless: sure, sure... niemeyer has more things to fix. But most of it he wrote during the sprint and I should have reviewed anyway.
[09:52] <niemeyer> ddaa: I'm aware about the changes, and may work on them ASAP if you want (e.g. tomorrow, today is holiday).
[09:53] <niemeyer> ddaa: But you may choose not to wait for me to fix tab issues and the like.. :)
[09:54] <ddaa> niemeyer: that would be real cool. I'm going to fix lifeless' stuff tomorrow. And I would really really like to have the branch merged by thursday. Launchpad meeting time is patch freeze for monday rollout.
[09:54] <niemeyer> ddaa: I was going to fix them yesterday, but the branch took forever to sync.
[09:54] <lifeless> ddaa: I'd like you to consider one further thing
[09:55] <lifeless> ddaa: It might be better not to delete *all* the branches, rather to just nuke their referenced content but keep their current baz url. That way we keep the link from product to branch for the baz2bzr process.
[09:56] <ddaa> gn?
[09:56] <ddaa> baz url?
[09:56] <ddaa> no provision for that in the new database
[09:57] <ddaa> and not needed IMO. We can associate baz branches to products using the productseries.targetarch* fields.
[09:58] <lifeless> we *can*, but we dont *have to*.
[09:58] <ddaa> but maybe I do not understand what you mean.
[09:58] <lifeless> http://bazaar.ubuntu.com/$archive/$branch is the baz url for the current branches.
[09:58] <ddaa> Couple of things:
[09:58] <lifeless> the problem with using the productseries fields is that a lot of them are not relevant because they have not managed to publish yet.
[09:58] <ddaa> We need to do it anyway because we want to associate branches to productseries properly. Not just products.
[09:59] <ddaa> lifeless: productseries.importstatus tells us what is relevent.
[10:00] <lifeless> sure. I'm just pointing out that a rush to production is not needed, it might be better to get these remaining things locked down, because once we delete the dbdata, its gone. Its much harder to recover from.
[10:00] <ddaa> Well. We can ask our beloved db to dump it. I can put it back if needed using importd superpowers.
[10:01] <lifeless> so the question is, is it easier to infer it again later, or record it explicitly now ?
[10:01] <ddaa> But I do not think that's going to be needed, really. And that's a great occasion to get rid of plenty of ugly data. Like the archnamespace used as title...
[10:02] <ddaa> I do think it would be easier to clean it out. No data migration to worry about. Easy to infer. Need to infer anyway.
[10:02] <lifeless> ok.
[10:02] <ddaa> BTW
[10:03] <ddaa> maybe get a word to jblack about an annoucement that imports for baz are going away within a couple of months.
[10:03] <lifeless> jblack: ^^
[10:04] <ddaa> I should mail jblack about it myself, but the jetlag has got the best of me...
[10:19] <mpt> SteveA, was it you who fixed bug 3588?
[10:19] <Ubugtu> Malone bug #3588: I'm told I have to log in, right after I've been logged in Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Stuart Bishop, Status: Accepted http://launchpad.net/malone/bugs/3588
[11:05] <jblack> ddaa: ??
[11:06] <lifeless> jblack: the imports will become bzr only sooin
[11:07] <jblack> Good.
[11:08] <jblack> And I'l be happy to make that statement.
[11:08] <jblack> I haven't worked out the statement for the supermirror yet either. And people have been looking for info.
[11:15] <jblack> lifeless: I think we could use an intenal and external baz list/email alias 
[11:21] <lifeless> ?
[11:21] <jblack> Basically a ng version of team@bazaar.canonical.com and some sort of internal team@bazaar.canonical.com
[11:22] <jblack> The internal one probably isn't necessary, but I think there's use for a team one.
[11:30] <lifeless> uhm
[11:31] <lifeless> I don't consider them separate teams
[11:31] <jblack> Is mpool, abentley and jameinel on it? 
[11:32] <lifeless> AFAIK yes
[11:32] <jblack> Oh, then that's great. =) 
[11:32] <lifeless> certainly they could be if they aren't.
[11:32] <bradb> question about the email module's behaviour when folding headers:
[11:32] <bradb>     >>> msg.get_all("X-Malone-Bug")
[11:32] <bradb>     ['product=firefox; status=New; priority=None; assignee=None;', 'distribution=debian; sourcepackage=mozilla-firefox;\n\tcomponent=None; status=New; priority=None; assignee=None; '] 
[11:33] <bradb> The folded header there (distribution=debian...etc) ends with an extra space. Anyone know what an extra space seems to get added to folded header values?
[11:33] <bradb> s/what an/why an/
[11:54] <mpt> hi bradb 
[11:54] <bradb> hey mpt 
[11:55] <mpt> we should sort out what New and Accepted mean, I think :-)
[11:55] <mpt> e.g. you marked bug 2633 as Accepted whie simultaneously asking what sort of fix was wanted
[11:55] <Ubugtu> Malone bug #2633: Graphing &amp; reporting of bug activity Fix req. for: malone (upstream), Severity: Minor, Assigned to: Nobody, Status: Accepted http://launchpad.net/malone/bugs/2633
[11:56] <mpt> ... Accepted by nobody, even!
[11:56] <mpt> So what do you think of the idea of having Unconfirmed, Confirmed, and Accepted?
[11:57] <LarstiQ> then, who can set it to confirmed, everybody, or only the maintainer?
[11:58] <mpt> LarstiQ, I think any logged-in person would be able to change it from Unconfirmed to Confirmed, but only the assignee would be able to change it to Accepted
[11:58] <mpt> because Accepted would mean "I'm working on this bug right now"
[11:58] <bradb> mpt: At the moment, Accepted means the opposite of Rejected. i.e. it's Accepted as a problem needing fixing. as per bug 971, I think they should just be Unconfirmed/Confirmed
[11:58] <Ubugtu> Malone bug #971: New/Accepted task statuses might be better named Unconfirmed/Confirmed Fix req. for: malone (upstream), Severity: Normal, Assigned to: Brad Bollenbach, Status: Accepted http://launchpad.net/malone/bugs/971
[11:59] <mpt> bradb, I read bug 971 and commented, that's what I'm talking about.
[11:59] <Ubugtu> Malone bug #971: New/Accepted task statuses might be better named Unconfirmed/Confirmed Fix req. for: malone (upstream), Severity: Normal, Assigned to: Brad Bollenbach, Status: Accepted http://launchpad.net/malone/bugs/971
[11:59] <mpt> Ubugtu, you shouldn't give details for the same bug more than once in five minutes.
[11:59] <bradb> mpt: Where did you write the comment?
[12:00] <mpt> bradb, in both the bug report, and in #launchpad five minutes ago :-)
[12:00] <bradb> I don't see a comment from you in the bug report, despite refreshing several times
[12:00] <mpt> or at least, I updated the description to mention the possible conflict
[12:01] <bradb> Oh...that makes it harder to figure out what changed. :)
[12:02] <mpt> So implement BugHistory :-P
[12:02] <bradb> e.g. if I were looking at a "last updated" type bug listing, I'd expect that probably the last one or two comments shown on that page are related to whatever that recent change was
[12:02] <mpt> Yes, there should be a collapsed line at the bottom saying "Matthew Paul Thomas changed the description"
[12:03] <mpt> which you can expand to see the diff
[12:03] <mpt> anyway
[12:03] <mpt> What do you think about Unconfirmed + Confirmed + Accepted, bradb?
[12:04] <mpt> or perhaps Unconfirmed + Confirmed + In Progress
[12:04] <bradb> I was thinking of something more like the latter