[01:31] <mpt> Goooooooooooooooood morning Launchpadders!
[01:32] <Fujitsu> Good morning, mpt!
[02:41] <jamesh> lifeless: https://devpad.canonical.com/~jamesh/productrelease-sourcepackagerelease.txt <- results of matching product release files with source package release files on demo.launchpad.net
[02:42] <jamesh> had to run librarian-gc before getting those results
[02:42] <lifeless> cool. let me finish this release and I'll peek
[04:30] <jamesh> mpt: ping?
[04:35] <mpt> jamesh, pong
[04:36] <jamesh> mpt: I was working on a fix for bug 55649: adding a "Product..development_focus" field pointing at a product series, and Bjorn noted that the way I displayed it on the product page was a bit confusing
[04:36] <Ubugtu> Malone bug 55649 in launchpad "Product does not record an explicit main series" [Untriaged,In progress]  http://launchpad.net/bugs/55649
[04:37] <jamesh> mpt: at the moment I just have the text "This series is the current development focus" below the nominated series in the main content area
[04:37] <jamesh> I was wondering if you have any better ideas
[04:41] <mpt> jamesh, perhaps use a pastel background to highlight the series in the list, keeping "Current focus of development" at the bottom of that highlighted section
[04:42] <jamesh> interesting.  Any particular colour or CSS class we use for this sort of thing elsewhere?
[04:44] <mpt> There's class="highlighted"
[04:45] <jamesh> thanks.
[06:05] <jamesh> mpt: what do you think of removing the class="discreet" bit for the series listing?
[06:23] <mpt> jamesh, good idea
[07:43] <jamesh> lifeless: I posted the results of the product release/source package release matching to the list.  It shows up at least one bad release file pattern in our current data
[07:43] <lifeless> thank you for examining this closley
[07:44] <jamesh> I think we might want to adopt a slightly more complex pattern matching syntax
[07:44] <jamesh> one that can also be used to extract version numbers from the file name like the uscan one can
[07:48] <lifeless> yeah
[07:48] <lifeless> I would like to just invoke uscan TBH
[08:00] <jamesh> stub: would you be able to review the DB patch in "jamesh/launchpad/bug-55649"?
[08:39] <SteveA> morning
[08:43] <lifeless> jamesh: so is it worth my reading the report yet ? 
[08:43] <lifeless> jamesh: or do you think its too broken to go forward with until a better pattern matcher is in place ?
[08:43] <lifeless> hi SteveA 
[08:45] <jamesh> lifeless: I think the matching report gave pretty good results -- the matches we got were correct in as far as the data created by product-release-finder was correct
[08:47] <jamesh> lifeless: the only issues were (1) the pattern for redland was too loose, so picked up tarballs for another release, and (2) the version number inferred from some tarball names was incorrect
[08:48] <lifeless> interesting
[08:48] <lifeless> not all that many hits
[08:48] <lifeless> thats on demo ?
[08:48] <jamesh> yeah
[08:49] <lifeless> not automake matches ?
[08:49] <lifeless> 'no'
[08:49] <jamesh> the automake tarballs might be repacked to remove GFDL docs ...
[08:49] <lifeless> yeah
[08:49] <jamesh> (for the Ubuntu packages, that is)
[08:49] <lifeless> I'm trying to get a handle on how big the damage is
[08:50] <jamesh> there are some source packages where the debian/ dir has been merged into the .orig.tar.gz too, iirc
[08:51] <lifeless> eww
[08:51] <jamesh> (I think the libtool package was like that last time I looked)
[08:51] <lifeless> mm
[08:51] <lifeless> ok
[08:52] <lifeless> I think we should be good to go
[08:52] <lifeless> but we still need to fix this form :
[08:52] <lifeless> https://demo.launchpad.net/products/bzr/bzr.dev/+source
[08:52] <jamesh> yeah
[08:52] <lifeless> try filling out the release details
[08:52] <lifeless> theres a bug open on this
[08:52] <jamesh> I think we should remove everything from that form except upstream VCS details
[08:52] <jamesh> and have a "no VCS details registered" radio button
[08:53] <lifeless> that works for me, as long as theres a 'edit series FTP/HTTP file location' button somewhere visible
[08:53] <lifeless> can you do a report that shows:
[08:54] <lifeless> tarball, series name (i.e. trunk) and version (0.10) only - no cross reference to the distro side ?
[08:54] <lifeless> I'd like to review that 
[08:55] <jamesh> didn't I include one like that earlier?
[08:55] <lifeless> I don tthink so
[08:56] <lifeless> maybe I missed it if it wasn't cced to me
[08:56] <lifeless> the one you put https://devpad.canonical.com/~jamesh/productrelease-sourcepackagerelease.txt has the spr - which is distro side
[08:56] <jamesh> the mail titled "product-release-finder test results", which was CC'd to you
[08:56] <lifeless> oops, blush
[08:56] <jamesh> from 4 days ago
[08:56] <lifeless> ah, middle of the pre-freeze sprint
[08:59] <lifeless> should we special case the .orig issue ?
[09:00] <lifeless> I'm not entirely sure whyh l-k-h is a product at all, but ...
[09:00] <jamesh> probably should.  (in hct's splitversion method, probably)
[09:00] <lifeless> ok
[09:01] <lifeless> publib too is affected
[09:01] <jamesh> yep.  Those were the two I identified in the email :)
[09:01] <carlos> morning
[09:04] <lifeless> jamesh: emailed
[10:27] <stub> jamesh: Please add a comment to comments.sql for the development_focus column, and maybe update the existing table comment on product series to say there should always be at least one per product.
[10:27] <stub> jamesh: Otherwise, r=stub. patch-67-20-0.sql
[10:29] <jamesh> stub: thanks
[10:30] <Ubugtu> New bug: #61024 in malone "+packagebugs with a large number of packages approaches uselessness" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61024
[10:32] <jordi> carlos, danilos: so I spent most of my time last week bringing the queue up to date.
[10:32] <carlos> jordi: yeah, I saw it. Good work!!
[10:33] <jordi> Most if not all of what's in there now is dubious or waiting for some action from requesters
[10:33] <jordi> thx!
[10:33] <jordi> if only wordpress would get their stuff sorted out
[10:34] <carlos> jordi: did you talked with mvo about the 'broken' locales he's uploading ?
[10:34] <danilos> jordi: hi! cool, only ~120 unreviewed templates left!
[10:34] <danilos> jordi: ah, so they are reviewed as well, great job :)
[10:34] <jordi> I was tempted to approve the wordpress stuff, given they *know* about and document rosetta in their webpage
[10:34] <jordi> danilos: I'm talking about products :)
[10:34] <jordi> carlos: nope, I didn't catch him on irc during the WE
[10:35] <jordi> I'll do now
[10:35] <carlos> jordi: ok, thanks
[10:35] <carlos> danilos: I did the distro work ;-)
[10:35] <danilos> jordi: ok :)
[10:35] <danilos> carlos: ok :)
[10:35] <danilos> danilos: ok :)
[10:35] <jordi> so, so
[10:35] <carlos> jordi: what's exactly the problem with duplicate messages?
[10:35] <jordi> if jordi did products, and carlos did distro, WHAT DID DANILO DO
[10:35] <carlos> jordi: Firefox!
[10:35] <carlos> :-D
[10:35] <danilos> jordi: I slept longer, thanks to you guys :)
[10:35] <jordi> heh
[10:36] <jordi> duplicate messages?
[10:36] <carlos> jordi: I read something about that as the problem to import wordpress
[10:36] <jordi> hm, no mvo
[10:36] <jordi> oh
[10:36] <jordi> they document rosetta in their webpage as one of the ways of translating wordpress
[10:36] <jordi> but they also have other ways of doing translations
[10:36] <jordi> = mess
[10:36] <Ag4Ms> Hi Room..!
[10:37] <carlos> jordi: ok, forget what I told you....
[10:37] <carlos> I see, I misunderstood that 
[10:38] <danilos> carlos: jordi needs not forgetting, he didn't hear you the first time, he never listens :)
[10:38] <carlos> :-P
[10:39] <carlos> jordi: well, in that case, if they still want the import... we should do it, the mess is their fault...
[10:39] <carlos> I mean, we cannot force them to use a concrete way to handle their translations...
[10:39] <jordi> http://codex.wordpress.org/Translating_WordPress
[10:40] <jordi> yeah
[10:40] <jordi> That was my new POV during the weekend
[10:40] <jordi> want mess? all yours :)
[10:40] <jordi> "     Note: many translators have found Rosetta to be a good starting point, but once it comes time to proofread the entire list of translations, many have opted to switch hand-editing the PO file or using a program like poEdit or KBabel, since the Rosetta UI lacks a search feature and other things that become essential when proofreading and editing. "
[10:40] <jordi> hrm
[10:41] <jordi> ok
[10:41] <jordi> decided, I'm accepting these
[10:46] <carlos> just note to them, that they could use Rosetta as the place to get back those .po files 
[10:47] <carlos> is not a matter if they use Kbabel or poEdit, just upload them into rosetta so they don't get conflicts to solve on their side
[10:51] <jordi> yeah
[10:51] <jordi> I'll try
[10:51] <jordi> Ryan is not exactly responsive
[10:53] <jordi> accepted
[10:53] <jordi> to bad we've been rejecting many WP files for months.
[10:54] <carlos> well, we still need the .pot file and I think we got them before we got the request to import the .pot file...
[10:57] <jordi> we had a pot file and two translations 
[10:57] <jordi> I renamed the template to "wordpress", too
[10:57] <jordi> carlos: btw, you should get rid of the "reuse" me templates soon
[10:58] <jordi> or you'll run out :)
[10:58] <jordi> only 10 left :)
[10:58] <carlos> jordi: ;-)
[10:58] <carlos> less work for us :-P
[11:01] <jordi> carlos: is it possible to get rid of "projects"?
[11:02] <jordi> wordpress the project, and wordpress, wordpress2 the products
[11:02] <jordi> this is a mess
[11:02] <jordi> and how do I change the "recommended" template?
[11:02] <jordi> can't remember tghis
[11:03] <jordi> ugh
[11:03] <jordi> so there's a wordpress-2 product which is deactivated but still shows up in navigation
[11:03] <carlos> jordi: talk with kiko and/or stub about it
[11:04] <jordi> k
[11:04] <jordi> about the navigation, I guess
[11:04] <carlos> jordi: kiko deactivated a lot of products recently so I guess he should know exactly what's going on there
[11:04] <jordi> what about the recommended template?
[11:04] <jordi> kiko: wake up man
[11:04] <carlos> jordi: URL?
[11:06] <carlos> jordi: mpt changed the templates to show the recomended ones... I don't know what rule he used to decide which one is the recommended one for products
[11:06] <jordi> http://launchpad.net/products/wordpress
[11:06] <carlos> mpt: ?
[11:06] <SteveA> mpt: ping
[11:06] <jordi> SteveA: hey dude
[11:06] <carlos> In fact
[11:06] <carlos> jordi: https://launchpad.net/products/wordpress/+translations 
[11:06] <carlos> that page is broken
[11:07] <carlos> you don't see all available templates
[11:07] <jordi> yeah
[11:07] <carlos> jordi: also, could you change the flag for wordpress to say 'It uses Rosetta'
[11:07] <jordi> well, I can't
[11:07] <jordi> I can't edit it
[11:07] <mpt> carlos: on a product page, product, Ubuntu package, other package
[11:08] <carlos> mpt: talking about products, no distro packages
[11:08] <mpt> I didn't change the selection, just the order
[11:08] <mpt> hi SteveA 
[11:08] <carlos> mpt: I see
[11:08] <carlos> mpt: what happens if there are two templates for different productseries?
[11:09] <carlos> jordi: how's that? you are a 'registry' expert/admin, aren't you?
[11:09] <mpt> carlos, I don't know, I didn't change anything about that
[11:10] <carlos> ok
[11:10] <mpt> I didn't change the selection, just the order.
[11:11] <carlos> jordi: seems like support for multiple templates in products is broken right now
[11:11] <mpt> so that product templates were prioritized first instead of last.
[11:11] <carlos> jordi: we should add a translation_focus field to Product to use the same procedure we use with distributions
[11:11] <carlos> jordi: to decide the productseries that should have the translation focus
[11:12] <carlos> jordi: anyway... are there any other release for 1.x  branch?
[11:12] <carlos> jordi: shouldn't they use 'trunk'?
[11:14] <jordi> I don't know
[11:14] <jordi> we really should find a way to make 2.0 show up there tho :)
[11:15] <carlos> jordi: I guess just the first one appears....
[11:15] <carlos> let me try something...
[11:15] <carlos> jordi: but I still think they should use the 'trunk' standard way...
[11:17] <carlos> jordi: it requires code changes
[11:17] <carlos> (to show 2.x over 1.x)
[11:23] <jordi> nod
[11:23] <jordi> everyone loves the 2h slots :)
[11:43] <jordi> carlos: down to 9 files
[11:43] <jordi> some of them are cruft for sure :)
[11:46] <carlos> jordi: ;-)
[11:48] <ddaa> You know it's going to be a bad day when:
[11:48] <ddaa> you forget to put milk in your scrambled eggs
[11:49] <ddaa> your coffee pot makes strange fizzling noises
[11:49] <LarstiQ> there goes milk into scrambled eggs?
[11:50] <ddaa> Yup, otherwise it's just a weird omelette.
[11:50] <ddaa> One coffee spoon of milk per egg
[11:51] <mpt> Though, caffeinated eggs could be interesting
[11:51] <ddaa> uh?!?
[11:52] <jamesh> ddaa: a coffee spoon isn't a standard measure in most english speaking countries
[11:52] <ddaa> jamesh: mh... in my understanding, a teaspoon is a bit smaller
[11:53] <jamesh> ddaa: maybe you mean a table spoon?
[11:53] <ddaa> no, that's much large
[11:53] <ddaa> * larger
[11:53] <ddaa> teaspoon < coffee spoon < table spoon
[11:53] <ddaa> but maybe it's just me
[11:53] <jamesh> dessert spoon?
[11:54] <ddaa> nah, coffee spoon < dessert spoon < table spoon
[11:54] <ddaa> bah, I'll call that a teaspoon
[11:54] <malcc> I guess it just depends whether tea or coffee was the more traditional drink in any given country, when the spoons were named
[12:06] <carlos> jordi, danilos: dudes... what are Evince people thinking on?
[12:07] <carlos> jordi, danilos: latest release uses 'Evince' instead of 'evince' as the translation domain....
[12:16] <jordi> sigh
[12:16] <danilos> carlos: "yay" for them
[12:17] <carlos> what should we do to reflect that fact?
[12:17] <carlos> because our system doesn't allow us to do it...
[12:17] <carlos> without changing Dapper and Breezy's translation domains too...
[12:17] <carlos> unless we give it a 'evince-edgy' name
[12:17] <danilos> hum, I have no idea; ask for a patched ubuntu package? :)
[12:18] <danilos> ooh fuck, Serbian translation in Rosetta should be banned... some of these guys are not only using Latin script, but Latin script without *any* diacritics (which are separate letters in Serbian like )
[12:18] <seb128> carlos: how did they change it? the .mo are named "evince.mo"
[12:20] <Ubugtu> New bug: #60614 in rosetta "Wrong string in gtk20 po file" [High,In progress]  http://launchpad.net/bugs/60614
[12:20] <seb128> carlos: the configure has "GETTEXT_PACKAGE=evince"
[12:24] <mpt> danilos, send jordi in there to sort them out :-)
[12:24] <danilos> mpt: The Jordi of Fury, I will :)
[12:25] <danilos> I should probably report a bug and assign it to jordi ;)
[12:25] <danilos> or send them The Fury of Jordi, whatever works better :)
[12:26] <jordi> but, what seb says.
[12:27] <danilos> jordi: this is about Serbian "translation" in Rosetta, I'll let you handle that :P
[12:27] <mpt> the Fury Engine, like the Emotion Engine but cooler
[12:28] <jordi> oh, serbian
[12:28] <jordi> we should merge with croatian translations
[12:30] <danilos> jordi: yeah, that would work too :)
[12:30] <danilos> jordi: don't forget the bosnian, though ;)
[12:35] <danilos> carlos: ping
[12:36] <carlos> seb128: the .pot file is Evince.pot
[12:36] <carlos> seb128: if the official .mo files is evince.mo then, it's all right
[12:36] <seb128> carlos: 
[12:36] <seb128> $ ls evince-0.6.0/po/*.pot
[12:36] <seb128> evince-0.6.0/po/evince.pot
[12:36] <carlos> seb128: hmmm, latest .pot file for evince that we got in Rosetta has 'po/Evince.pot'
[12:37] <seb128> carlos: that's a local build of the edgy package
[12:37] <seb128> maybe somebody did upload that template?
[12:37] <carlos> seb128: hmmm, sorry, it's not latest, it's from last month...
[12:37] <carlos> perhaps it was a bug that they already fixed....
[12:37] <carlos> seb128: it came from the automatic import queue
[12:38] <carlos> seb128: atm only Rosetta admins are allowed to use the upload form for Ubuntu
[12:38] <seb128> $ find . -name "*.pot"
[12:38] <seb128> ./evince-0.5.5/po/Evince.pot
[12:38] <seb128> ./evince-0.6.0/po/evince.pot
[12:38] <seb128> ./evince-0.6.0/help/evince.pot
[12:38] <seb128> ./build/evince-0.6.0/po/evince.pot
[12:38] <seb128> ./build/evince-0.6.0/help/evince.pot
[12:38] <jordi> ah, so it's fixed
[12:38] <seb128> carlos: right, it was a 0.5.5 issue
[12:38] <carlos> seb128: I see, ok
[12:38] <seb128> how many packages do you have lagging behind?
[12:38] <seb128> you just figured glib, gtk and evince were outdated in a few min
[12:39] <seb128> :p
[12:39] <carlos> seb128: not really, just that one was lagging behind
[12:39] <carlos> because it changed its filename
[12:39] <seb128> ok
[12:39] <carlos> in fact, later releases are already imported
[12:39] <carlos> when it was fixed
[12:39] <seb128> cool
[12:39] <seb128> so you just have to drop the "Evince" variant
[12:39] <carlos> right
[12:39] <carlos> already done
[12:40] <carlos> seb128: ;-)
[12:49] <lifeless> reviewer meeting in 11
[12:52] <jordi> people calling carlos "mr. carlos" :)
[12:57] <carlos> jordi: well.... some girls in the university told me that already when asking for the 'time', really depressing...
[12:57] <jordi> haha
[12:57] <jordi> hey man
[12:57] <jordi> I just shaved after nearly two months
[12:57] <jordi> and people say I got rid of 5 years :)
[12:58] <lifeless> review meeting in 2
[12:58] <carlos> well, that was being shaved.... so you are depressing me even more....
[12:58] <carlos> ;-)
[01:00] <lifeless> reviewer meeting starts now
[01:00] <lifeless> == Agenda ==
[01:00] <lifeless>  * Roll call
[01:00] <lifeless>  * Queue status.
[01:01] <lifeless> = Roll Call =
[01:01] <SteveA> hi
[01:01] <lifeless> ho
[01:01] <jamesh> hi
[01:01] <lifeless> its off to work we go
[01:01] <BjornT> hi
[01:02] <lifeless> so the queue is in good shape
[01:02] <lifeless> its packed, but nothing is overdue
[01:02] <lifeless> congrats all
[01:02] <spiv> hi
[01:03] <lifeless> 10 items oldest is 4 days, which is 2 adjusting for the weekend. They'll be overdue tomorrow though ;)
[01:03] <lifeless> any comments or questions arond this ?
[01:03] <jamesh> I'll make sure to finish off BjornT's branch soon
[01:03] <lifeless> (1 minute to say so)
[01:04] <lifeless> thanks jamesh 
[01:05] <lifeless> I suck, as I still haven't documented the escalation process
[01:05] <lifeless> for post-merge reviews that should not have been done
[01:05] <lifeless> whats the general feeling about those reviews? worth doing? many abuses? few abuses?
[01:05] <SteveA> for post-merge reviews that reveal that merge should not have been done
[01:06] <SteveA> I think they are good
[01:06] <jamesh> there were a few problems in some revisions I reviewed that would have been caught during review, but no huge problems
[01:07] <lifeless> I think we should keep doing this. I'll pickup the trivials weekly and allocate them. How does that sound ?
[01:08] <BjornT> i think post-merge reviews have been useful. they are quick to do, and there have been some remarks on [trivial]  merges.
[01:08] <BjornT> weekly sounds good.
[01:09] <lifeless> ok
[01:09] <spiv> lifeless: +!
[01:09] <spiv> er, +1
[01:14] <lifeless> haha
[01:14] <lifeless> ok, thats preserved in the log ;)
[01:14] <lifeless> any new business?
[01:14] <SteveA> there was an issue ddaa brought up
[01:14] <SteveA> in the last lp devel meeting
[01:14] <lifeless> is that like a furball ?
[01:14] <SteveA> that I told him to add to this meeting's agenda if he wanted it discussed
[01:14] <SteveA> apparently he didn't, and I don't remember what it was
[01:14] <SteveA> so, that's that then :-)
[01:14] <lifeless> is it in the transcript from the meeting ?
[01:14] <SteveA> yes
[01:14] <lifeless> heh
[01:14] <SteveA> in the literal log anyway
[01:14] <BjornT> actually, there is a proposed item from ddaa on ReviewerMeetingAgenda
[01:14] <lifeless> oh, I read right past that
[01:14] <lifeless> my bad
[01:14] <SteveA> ah, so ddaa did add it
[01:14] <lifeless>     *
[01:14] <lifeless>       Pending reviews to be assigned in two working days at most (ddaa)
[01:14] <SteveA> thanks BjornT 
[01:14] <lifeless> ddaa: your floow
[01:14] <lifeless> *floor*
[01:14] <lifeless> hmm
[01:14] <SteveA> save it for next time then?
[01:14] <lifeless> SteveA: do you know what it was about specifically? I allocate daily, so I'm not sure what it means
[01:14] <lifeless> when I'm away I ask another reviewer to allocate
[01:14] <SteveA> I don't know.  I think ddaa needs to explain.
[01:14] <lifeless> agreed
[01:14] <lifeless> ddaa: please explain
[01:15] <SteveA> I have things to do
[01:15] <lifeless> likewise
[01:15] <lifeless> ok, ddaa can resubmit it when he reads scrollback
[01:15] <lifeless> or bring it up with me, as its not a team wide issue
[01:16] <lifeless> I have one item of 'other'
[01:16] <lifeless> jamesh: hows the pending-reviews load ?
[01:16] <ddaa> last week there was two days when allocation did not seem to have been done
[01:16] <jamesh> for runs when no changes have taken place, it takes about 2 minutes to run now
[01:17] <lifeless> jamesh: excellent
[01:17] <ddaa> wed and thu .au time
[01:17] <jamesh> so combined with locking against parallel runs, we could probably bump the frequency up a bit
[01:17] <lifeless> ddaa: my routine is to allocate daily. Occasionally I dont manage to usually due to being insanely busy : i.e. last minute sprint for the smart server for bzr.
[01:18] <SteveA> we discussed once-per-day for w-i-p
[01:18] <SteveA> and much more frequently for branches for review
[01:18] <jamesh> this might result in a run getting missed, occasionally, but it wouldn't be as important if it is more frequent
[01:18] <lifeless> well lets start with the higher frequency i
[01:18] <ddaa> lifeless: ack you were busy. Maybe at this point you could have somebody do the assigning for you.
[01:18] <lifeless> its a smaller change in terms of human effourt
[01:19] <lifeless> *effort*
[01:19] <jamesh> SteveA: yeah.  I haven't looked at doing that bit yet
[01:19] <SteveA> ok
[01:19] <lifeless> jamesh: what frequency do you think is feasible ?
[01:19] <lifeless> jamesh: 30 minutes ?
[01:20] <lifeless> 1 hr ?
[01:20] <jamesh> SteveA: preventing unnecessary work was a bigger win, and I'd probably have needed to do the changes anyway to reduce the frequency of w-i-p branches
[01:20] <jamesh> lifeless: it is currently on 1 hour.  30 minutes should be doable
[01:20] <lifeless> cool
[01:20] <lifeless> next week I'll be asking again
[01:20] <lifeless> I'd like to understand where we can dial up to ;)
[01:20] <jamesh> lifeless: previously the rsync jobs for oops reports seemed to be piling up due to the IO bandwidth being saturated
[01:21] <lifeless> it might be worth doing an in-memory merge
[01:21] <jamesh> I don't think they're locked against multiple runs too
[01:21] <jamesh> so we were ending up with multiple rsync runs for the same data at times
[01:21] <lifeless> ok, this is covered for now for me
[01:22] <lifeless> jamesh: thats filed with the sysadmins right ?
[01:22] <jamesh> lifeless: not yet.  I'll do it after the meeting
[01:22] <lifeless> jamesh: thanks
[01:22] <lifeless> any other other business ?
[01:23] <lifeless> ddaa: if someone else wants to take it on, I'm happy to ask them to do it with SteveA/kiko's ok. However I consider myself responsible for getting the reviews allocated, so we'd be getting into matrix-mgmt territory, which is not so hot.
[01:23] <lifeless> hmm, we are already in some ways. 
[01:24] <lifeless> SteveA: what do you think? Daily allocations are not fundamentally interesting, and the system seems to be ticking along very well now.
[01:24] <ddaa> lifeless: I'm just suggesting that when you get into "insanely busy" mode, you just temporarily pass the pumpkin to someone else, so reviews keeps being assigned timely. Probably the same as you would do when going on vacation.
[01:25] <lifeless> ddaa: I do - this case I didn't realise how much lilfting we had to do
[01:25] <SteveA> thanks for raising the issue ddaa.  let's leave things as they are and see if we get any problems in this area in the future
[01:25] <lifeless> short of having two people doing the reviews daily each, I'm not sure how to prevent occasional glitches
[01:25] <ddaa> Then let's consider that issue closed. I just though I had to complain about the hiccup last week :)
[01:26] <lifeless> its nowhere near the Service level issues that we had some time ago with weeks going by
[01:26] <lifeless> so I'm not very concerned about it
[01:26] <lifeless> SteveA: agreed.
[01:26] <ddaa> Sure, things are going on very smoothly. I'd hate to see that degrade.
[01:27] <ddaa> lifeless: note that is an indirect praise :)
[01:27] <lifeless> ok meeting closed
[01:27] <lifeless> thanks y'all
[01:28] <ddaa> lifeless: so, talk about BatchProgress?
[01:29] <lifeless> sure
[01:29] <ddaa> my problem with testing that is that Progress classes provide an API for bzrlib to use, and I do not see how to fail when the API used by bzrlib somehow changes
[01:29] <lifeless> so
[01:30] <ddaa> On problem I had was when nested progress was introduced, it caused BatchProgress to miss most of the progress because it was based on DummyProgress
[01:30] <lifeless> you consider it a fault when the bzr api changes? or just when it changes such that BatchProgress does not output what its meant to for the operations used in importd ?
[01:31] <lifeless> I'm trying to phrase a sentence like :
[01:31] <ddaa> It's not clear cut. I think the former would generate fewer false errors than checking for literal output of importd operations at full verbosity.
[01:31] <lifeless> "it is a fault when XXX"
[01:31] <lifeless> so for instance
[01:32] <lifeless> "it is a fault if an importd commit does not output at least five status lines, one for each progress bar currently used by bzrlib"
[01:32] <lifeless> and 
[01:32] <ddaa> it is a fault when the bzr api changes in a way that prevents importd from reporting progress frequently enough
[01:32] <lifeless> "it is a fault if an importd push does not output at least 4 status lines plus one per 50 revisions"
[01:33] <lifeless> ddaa: no, thats a *cause*
[01:33] <lifeless> ddaa: *causes* cause *faults*
[01:33] <lifeless> tests FAIL when they detect a FAULT
[01:35] <ddaa> lifeless: I think part of the issue is that I have difficulty articulating the requirement accurately.
[01:35] <lifeless> so things about your statement we need to tighten up: frequently enough - is it time based or time + activity ?
[01:36] <ddaa> rather the second one: "as long as bzr is doing progress, BatchProgress needs to get frequent messages"
[01:36] <lifeless> well thats a unit level requirement
[01:36] <lifeless> but its one we can test
[01:36] <lifeless> setup a branch
[01:36] <lifeless> set the ui factory to an instrumented batch progress
[01:37] <lifeless> assert that you get at least X messages, where X is some figure you are comfortable with. This wont catch 'no messages at the end' and 'no messages at the start' corner cases but it will ensure the common case does not regress
[01:39] <lifeless> now, how can we ensure that no activity happens outside of a progress bar ? I dont think you can without a timing based test (flakey) or a viciously intrusive system-activity-introspection approach (blag)
[01:39] <ddaa> What about not subclassing DummyProgress, and having tests in bzrlib to check that Progress classes provide the whole required interface?
[01:39] <lifeless> so I'd ask - what is the likely hood of bzr doing 'no progress at the start or end' - and thats low, because it would be a bad ui defect
[01:39] <lifeless> ddaa: you might provide the whole interface but still suffer bugs
[01:40] <lifeless> ddaa: your requirement is not about the interface, its about the output.
[01:40] <lifeless> so we should test the interface as it relates to the output: which is whether your code is called
[01:40] <ddaa> I'm comfortable with testing the output as long as BatchProgress gets all the messages.
[01:40] <lifeless> mirroring a branch with 2 revisions for instance should generate a predictable event count
[01:40] <lifeless> and committing a tree with 4 files of which 2 are modified should also do something reliable
[01:41] <lifeless> and even if we change the api then, you'll know your code is getting called
[01:41] <lifeless> which is AIUI the key thing
[01:41] <lifeless> note that I'm not talking about testing the output
[01:41] <lifeless> I'm talking about instrumenting your BatchProgress in a test subclass, and testing the calls made *into* it.
[01:42] <ddaa> Nah it's not testing the right thing. I tests that for some operation, the BatchProgress gets some number of messages. It does not test that it explicitely handles all messages.
[01:42] <lifeless> ddaa: Why do you think that handling all messages is a requirement ?
[01:43] <ddaa> Yes. Then it does the throttling. Mere message count is not enough because API changes can cause BatchProgress to _see_ "no progress at start", although bzrlib does send the message, because they are just ignored by the DummyProgress base class.
[01:45] <lifeless> testing that everything is implemented is also insufficient
[01:45] <ddaa> Sure. How do I do that?
[01:46] <ddaa> I saw no test in bzrlib to check that a Progress class implements the required interface.
[01:46] <lifeless> you can't, its prove a negative in the general case, unless/until we get interface scenarios for progress, which we dont have
[01:46] <lifeless> and even if we had it,*you can still have bugs*
[01:46] <lifeless> I honestly think you are over engineering here
[01:47] <lifeless> I dont have much more to offer
[01:47] <ddaa> so, you say no integration test?
[01:47] <lifeless> I've been talking integration test
[01:47] <lifeless> testing that during a branch and commit your progress bar gets at least some arbitrary count of messages is an integration test
[01:48] <lifeless> so, I've now been working for 14h 45m and would like an hour to myself before bed. Send an email to continue this if thats ok ?
[01:49] <ddaa> Okay. I'll test mirroring and committing as you suggested.
[01:49] <ddaa> But I'm concerned it's going to be a very brittle test.
[01:49] <lifeless> say that you get 15 events when you write it
[01:49] <lifeless> set your test to require 12
[01:50] <lifeless> that allows bzr to become a little more efficient without breaking the test
[01:50] <lifeless> but if we become a lot more efficient it might break : but equally if we become a lot less informative it will also break
[01:50] <lifeless> which is what we want
[01:50] <lifeless> the problem is that you want 'messages while bzr is active'
[01:51] <lifeless> and we need to translate that to some metric
[01:51] <ddaa> I think this approach is bogus, but your are the quality guy and bzr guy, so I'll assume you know better. Now, get out and have your private time before bed.
[01:51] <lifeless> but 'less informative' and 'more efficient' shadow each other
[01:51] <lifeless> ddaa: well, BjornT and salgado are both still in their daytime
[01:51] <lifeless> ddaa: so feel free to seek other opinions.
[01:51] <sidarus> Hi... does anybody speack french ?
[01:52] <ddaa> sidarus: I do.4
[01:52] <lifeless> ddaa: I'm only offering you what I would do to get a test thats fairly robust, cheap to write and maintain.
[01:52] <lifeless> ddaa: ...because you asked!
[01:52] <lifeless> anyhow, tchau
[01:52] <sidarus> ddaa> mp
[01:52] <ddaa> lifeless: thank you, I appreciate the effort.
[01:53] <ddaa> and as I said, I'll do as your suggested.
[01:53] <lifeless> night all
[01:55] <sidarus> ddaa> Je cherche une solution de developpemnt pour osCSS. Un truc du genre TRAC (repository + bugtracker + wiki ...).
[01:55] <ddaa> sidarus: oui?
[01:56] <sidarus> connais tu oscss.org ?
[01:56] <ddaa> non, je regarde
[01:57] <sidarus> ddaa> www.oscss.org
[01:57] <sidarus> au fait c'est un ecommerce open source
[01:57] <sidarus> un fork d'osCommerce
[01:58] <ddaa> une minute
[02:00] <ddaa> sidarus: donc je suppose que tu veux savoir ce que offre Launchpad en comparaison  TRAC?
[02:00] <sidarus> ddaa> exactement :)
[02:01] <ddaa> Je ne connais pas bien TRAC, mais je peux rpondre  "repository + bugtracker + wiki"
[02:01] <sidarus> (je viens de dcouvrir Launchpad)
[02:01] <ddaa> Launchpad offre un service d'hbergement et de mirroir pour les branches Bazaar.
[02:01] <ddaa> http://bazaar-vcs.org et #bzr
[02:02] <sidarus> Mmmmm
[02:03] <sidarus> y a une demo qq part ?
[02:03] <ddaa> Il offre aussi un gestionnaire bug assez puissant, qui offre actuellement une intgration rudimentaire avec bzr. Des fonctionalits d'intgration plus pousses sont actuellement en cours de conception.
[02:04] <ddaa> sidarus: tu peux jouer avec l'interface web sur staging.launchpad.net, la base de donnes de ce site est remplace tous les jours par un copie de la base de donnes de launchpad.net
[02:04] <ddaa> je ne crois pas que staging.launchpad.net support le service SFTP qui permet d'hberger des branches sur launchpad.net.
[02:04] <sidarus> J'ai tent d'installer subversion mais ne suis pas parvenu. Serait ce le meilleurs choix ?
[02:06] <ddaa> bzr vise  tre trs simple d'emploi, si tu n'est pas dj familier avec subversion, cela peut tre plus simple.
[02:06] <sidarus> ddaa>ok je vois
[02:06] <ddaa> en plus bzr te permet de publier des branhes sur des serveur web tout simple sans logiciel spcifique
[02:07] <ddaa> Il y a une personne qui traduit la doc en franais, mais tu aurais certainement un communaut francophone plus large avec subversion.
[02:07] <sidarus> ddaa: osCSS a besoin de certain outils avec lequels nous sommes tres stisfait (DokuWiki, PHPXref, UNB). Peut-on les garder ?
[02:08] <ddaa> Launchpad est conu comme une addition au site du projet. Pas un replacement. En particulier il n'offre pas de wiki en tant que tel.
[02:10] <LarstiQ> then again, who needs a wiki when you have bzr branches and irc.
[02:10] <sidarus> ddaa>a fait plaisir de tomber direct sur qq1 qui connais le sujet et qui de plus te repond :)
[02:10] <ddaa> sidarus: je suis le dvelopeur qui chapeaute tout ce qui concerne l'intgration entre launchpad et bzr.
[02:11] <sidarus> ddaa>donc je pouvais pas mieux tomber :)
[02:12] <ddaa> sidarus: un avantage de launchpad est son service de traduction. Il y a une communaut de traducteurs trs actifs. Tu publies les .po d'une application, et quelques semaines plus tard tu as des traductions en N>10 langues.
[02:12] <ddaa> Mais cela implique de communiquer avec les quipes de traducteurs je suppose. Les spcialistes de la trad sont carlos (espagnol) et danilos (serbe).
[02:13] <LarstiQ> et jordi!
[02:13] <jordi> Catalan!
[02:13] <sidarus> ddaa>oui justement j'ai remarqu le ssteme de traduction. Notre problme est qu' la base le site est francophone mais il est cruciale qu'il soit traduit en englais et l'englais c'est pas mon fort
[02:14] <ddaa> et jordi (catalan), c'est un ancien employ qui est toujours trs actif avec la communaut
[02:14] <sidarus> jordi>Hola toreror :)
[02:14] <ddaa> mh... je ne sais pas si launchpad est appropri pour traduire un site
[02:14] <sidarus> je parle couramment : FR|SP
[02:15] <sidarus> EN informatique
[02:15] <ddaa> le systme de trad est concu pour des applicatifs utilisant gettext
[02:15] <LarstiQ> wouldn't it work for a website using gettext though?
[02:15] <ddaa> sidarus: dans ce cas l, carlos et jordi sont tes interlocuteurs pour rosetta.
[02:15] <spiv> LarstiQ: sure
[02:15] <sidarus> mais pour traduire osCSS c'est la crois et la bannire
[02:15] <jordi> sidarus: toreros are saddists :)
[02:16] <jordi> LarstiQ: yeah
[02:16] <sidarus> @all> merci pour tout.... je risque de revwenir avec des tas de question boulets. Je vais dja install tout a en local pour me faire la main.
[02:17] <SteveA> jamesh: have you seen a bzr problem using pqm-submit where it says AttributeError: 'LocationConfig' object has no attribute '_get_global_config'
[02:17] <ddaa> sidarus: sidarus les questions concernant bzr (hors intgration avec launchpad) sont  poser sur #bzr
[02:17] <jamesh> SteveA: what version of pqm-submit are you using?
[02:17] <SteveA>  ?
[02:18] <sidarus> ddaa>ok merci c'est not
[02:18] <SteveA> no idea
[02:18] <SteveA> how would I tell?
[02:18] <ddaa> sidarus:  ton service
[02:18] <jamesh> SteveA: I'm just wondering if you are using the bzr0.8 pqm-submit branch with newer bzr
[02:19] <SteveA> what package is pqm-submit in?
[02:20] <sidarus> derniere question : peut-on mettre notre repository dans launchpad ?
[02:20] <jamesh> I don't think it is packaged yet.  You probably have a checkout of it in ~/.bazaar/plugins
[02:20] <sidarus> atuellement il est sur sourceforge.net
[02:20] <jamesh> (yes, we do need it packaged)
[02:22] <jamesh> SteveA: the branch to use with current bzr is http://bazaar.launchpad.net/~bzr-pqm-devel/bzr-pqm/devel  
[02:23] <SteveA> hmm, just did a bzr pull, nd get 7 revisions of http://bzr.arbash-meinel.com/plugins/pqm-submit/
[02:23] <SteveA> seems to have worked
[02:24] <jamesh> you should switch to the bazaar.launchpad.net version
[02:25] <jamesh> it is the official version now
[02:26] <SteveA> got 5 more revs from the URL you gave
[02:26] <jamesh> and I don't think John's branch has the "don't submit merges to bzr.dev by default" patch
[02:26] <SteveA> thanks
[02:27] <theCore> is it a good idea to close old, and badly asked tickets requests? 
[02:27] <theCore> or should I leave them open?
[02:28] <ddaa> sidarus: il y a une fonctionalit pour importer de svn vers bzr sur launchpad. Mais pas d'hbergement svn natif.
[02:31] <sidarus> ddaa>ok merci
[02:39] <theCore> here an example of tickets I would like to close https://launchpad.net/distros/ubuntu/+ticket/14
[02:43] <theCore> I think this one also show another problem
[02:44] <theCore> peoples should be able to request tickets in their native language
[02:45] <theCore> they could be translatable, too
[02:46] <SteveA> having tickets in a native language is coming soon
[02:48] <theCore> SteveA, cool
[02:55] <SteveA> theCore: flacoste is working on it.
[02:55] <theCore> SteveA, thanks for the info
[02:56] <carlos> jordi: did you approved pt_PT translation for ddtp?
[03:02] <sidarus> ddaa> j'essaye d'importer cvs > launchpad mais j'y arrive pas
[03:04] <ddaa> sidarus: pourquoi le nom de produit de osscss est "sidarus" (regarde dans l'url)?
[03:04] <ddaa> sidarus: quelle est la commande que tu tapes pour faire un checkout avec CSS?
[03:05] <ddaa> sidarus: une fois que les coordonnes du CVS sont dans launchpad, je dois faire quelques action manuelles
[03:05] <ddaa> * pour fair un checkout avec CVS
[03:05] <sidarus> ddaa>CVS root =  :pserver:anonymous@oscss.cvs.sourceforge.net:/cvsroot/oscss
[03:06] <ddaa> et le module?
[03:06] <sidarus> le pb est qu'il y a 3 modules : admin catalog sql
[03:06] <ddaa> mh, ca fait trois branches
[03:07] <sidarus> a pose pb ?
[03:07] <ddaa> en principe, dans launchpad, ca fait trois produits distincts, mais c'est pas ncessaire si a ne correspond pas a l'organisation du projet (releases distinctes)
[03:08] <ddaa> si au niveau packaging c'est trois .rpm ou deb distincts, tu devrais enregistrer trois produits sur launchpad. Tu peux les grouper dans un mme projet
[03:09] <ddaa> si c'est juste un seul product en trois pieces, tu peux just crer trois "release series" dans launchpad pour contourner le probleme.
[03:09] <ddaa> bon, je vais m'occuper de catalog pour commencer
[03:10] <sidarus> ddaa>ok je vois. Au fait il a 3 branche : catalog=fontend, admin=backend et sql
[03:11] <sidarus> ddaa>je vois que j'ai tout fais faux :P
[03:11] <ddaa> sidarus: tu devrais changer le nom du produit pour tre "osscss" or "osscss-catalog"
[03:11] <ddaa> sidarus: pas de problme, c'est pas vraiment vident la premire fois si on a un project un tant soit peu atypique
[03:12] <sidarus> ddaa>tu me suggere donc de faire 3 projets : oscss-catalog, oscss-admin, oscss-sql ?
[03:13] <ddaa> ca depend de la maniere dont le projet est organise...
[03:13] <ddaa> et c'est trois "products" que tu grouperais dans un mme "project".
[03:13] <sidarus> ddaa>organisation d'osCSS :: 1) catalog=fontend, 2) admin=backend 3) sql
[03:14] <ddaa> est-ce que les trois pices sont releases et packages independamment? Si oui, trois products, si non, trois series dans un meme product.
[03:15] <sidarus> ddaa>1 seul package
[03:16] <sidarus> ddaa>faut que je m'y colle  la logique de launchpad
[03:17] <ddaa> donc trois release series. T'en fait pas, normalement c'est plus simple mais oscss a l'air d'tre organis de manire un peu bizarre.
[03:19] <sidarus> ddaa>je suis ouvert a toute critique. Tu suggere quoi comme organisation ?
[03:19] <SteveA> jamesh: I like the stuff you've done for improving finding specific parts of the template in page tests
[03:19] <SteveA> jamesh: please add an agenda item on it for thursday's meeting, so we can be sure everyone is aware of it
[03:20] <ddaa> sidarus: si aucune des trois parties n'est utile sans les deux autres, je pense que a devrait tre une seule branche.
[03:21] <ddaa> sidarus: ca permet de garder facilement l'histoire de l'ensemble, et a evite d'avoir des morceaux correspondant  des revisions differentes
[03:22] <ddaa> surtout avec bzr qui contrairement a CVS enregistre l'histoire de toute une arborescence et non de fichier individuels
[03:22] <sidarus> ddaa>au fait "admin" est un sous-dossier de "catalog"
[03:23] <sidarus> ddaa>le pb est que "admin" peut etre install ailleurs ou renomm pour des raisons de securit
[03:24] <ddaa> dans ce cas, l'import de catalog contiendra admin
[03:24] <sidarus> oui tout a fait
[03:25] <sidarus> dans l'installation par defaut
[03:25] <ddaa> le fait que les utilisateurs soit susceptible de change l'organisation n'est pas pertinente  ce niveau. On est just en train de reprsenter le logiciel tel qui'l est distribu et versionn.
[03:26] <sidarus> ddaa>ok l je comprend mieux
[03:27] <sidarus> ddaa> au fait : https://launchpad.net/products/sidarus/trunk <= y a erreur ?
[03:27] <ddaa> sidarus: a te drange si je demande  un launchpad-admin de changer le nom du product de "sidarus" en "oscss"?
[03:27] <sidarus> non au contraire :)
[03:29] <ddaa> kiko: please change name of product "sidarus" to "oscss".
[03:29] <kiko> hey ddaa 
[03:29] <sidarus> thx kiko & ddaa
[03:29] <ddaa> kiko: hey, I'm guiding a potential new adopter to setting up launchpad and bzr stuff for his project.
[03:29] <sidarus> osCSS is possible ?
[03:30] <sidarus> osCSS must be lowercase ?
[03:30] <ddaa> sidarus: the "name" is only used in urls, it's all lower case. The name used in human text is "display name" and can have anything you want.
[03:31] <ddaa> sidarus: and it's already "osCSS". Besides you can change it yourself
[03:31] <sidarus> ddaa>ok thx
[03:32] <kiko> ddaa, sidarus: done.
[03:32] <sidarus> kiko>thank's a lot
[03:32] <ddaa> sidarus: https://launchpad.net/products/oscss
[03:33] <sidarus> great :)
[03:34] <ddaa> sidarus: I'm currently running a test import of oscss/trunk. If it works, I'll do a product import and you'll get access to bzr branch when that completes.
[03:34] <ddaa> note that will produce a branch that's read-only for you. Only launchpad will update it by looking at the cvs repo. To publishes your changes with bzr you'll put your branch on launchpad.
[03:35] <sidarus> ddaa>Merci beaucoup !
[03:35] <ddaa> sidarus: a ta place, je changerais le nom de "trunk" pour etre "catalog", et je rajouterai un release series pour sql.
[03:36] <ddaa> tu pourra ensuite crer un autre "trunk" qui correspondrait  la combinaison des deux.
[03:36] <sidarus> ddaa>ok je vais faire le ncessaire
[03:37] <ddaa> tu peux appeler les series comme tu veux, c'est juste une question de convention.
[03:37] <sidarus> ddaa>juste pour pas mourir con... trunk a signifie quoi ?
[03:37] <ddaa> "tronc"
[03:37] <sidarus> mouaaaaaaarf
[03:37] <ddaa> i.e. la branche principale d'o partent toutes les autres branches
[03:38] <sidarus> i.e. tree
[03:38] <sidarus> enfin merci, je suis mort de rire
[03:39] <ddaa> En fait "tree" signifie autrechose. L'arborescence des fichiers dans une branche. Les branches forment plutt un rseau :)
[03:39] <ddaa> mtaphores bogues :)
[03:39] <sidarus> On en apprend tous les jours :)
[03:43] <sidarus> ddaa>au fait nommer "trunk" > "http" a passe ?
[03:43] <ddaa> sidarus: pourquoi pas.
[03:44] <ddaa> L'ide est surtout que si c'est packag dans ubuntu, les packages soient associs  trunk (de manire conventionelle) et que la branch associe est le contenu qui correspond au package.
[03:47] <ddaa> okay, dit moi quand c'est bon et je lancerai la conversion en production
[03:49] <sidarus> ddaa>bon ben va pour "trunk". J'aime pas bousculer les conventions.
[03:51] <ddaa> okay, c'est parti. L'import devrait tre en ligne dans moins d'une heure
[03:52] <sidarus> :)
[04:02] <danilos> carlos: ping (again ;))
[04:02] <carlos> danilos: pong
[04:03] <carlos> I didn't see your first ping...
[04:03] <imbrandon> cprov: ping, does that mean the fix for backports is live
[04:03] <danilos> carlos: ping (just playing a game of table-tennis ;)
[04:03] <carlos> :-P
[04:03] <cprov> imbrandon: no, needs rollout
[04:04] <imbrandon> cprov: ahh ok , just seen the reply in my mail, wasent sure
[04:04] <imbrandon> okies thanks
[04:04] <kristog> hello *
[04:05] <kristog> i wonder if i could setup a *commit-message-system* on a specific baz branch
[04:05] <kristog> bzr*
[04:05] <kiko> thanks BjornT 
[04:05] <cprov> imbrandon: fine, we will try to rollout soyuz this week, earlier than the LP itself, I'll ping when it happen
[04:05] <kiko> BjornT, if you have another moment and want to unblock me, I have another fix that is up for review with jamesh. It's not very long. Are you game?
[04:06] <imbrandon> cprov: great , thanks a ton 
[04:06] <cprov> imbrandon: np, glad to help
[04:06] <kiko> malcc, cprov: I see that branch finally landed. how are we looking on the test?
[04:06] <BjornT> kiko: sure.
[04:07] <kiko> BjornT, I'll bounce it to you, one moment.
[04:07] <cprov> kiko: seems to be fine, was pending one more run with all the issues set during the weekend. malcc how did it go ?
[04:07] <kiko> cprov, oof, finally.
[04:09] <kiko> BjornT, sent.
[04:09] <malcc> kiko, cprov: I spent some time at the weekend getting mostly set up with a more solid baseline, incorporating the experience from the previous runs
[04:09] <kiko> awesome
[04:10] <cprov> malcc: nice !
[04:10] <malcc> kiko, cprov: I'm planning to do one final test run only once we've got a candidate codeline from rocketfuel, so right now I'm working on the soyuz-fixes branch instead, as I can finish off getting ready to test while that lands and we set up our candidate
[04:10] <kiko> okay, cool.
[04:10] <malcc> Otherwise, any re-testing now will end up being on a slightly different codeline than what we'll end up using
[04:11] <cprov> malcc: [r=kiko]  I suppose ?
[04:11] <kiko> ?
[04:12] <malcc> cprov: I'm working on addressing the last of kiko's suggestions, so the soyuz-fixes branch will end up r=kiko in all likelihood, after I've responded to the review. Is that what you mean?
[04:12] <kiko> ah. I misunderstood as well.
[04:12] <spiv> 
[04:14] <cprov> malcc: yes, i was just suggestion kiko might be a good candidate to review those changes  ... well done
[04:19] <kiko> matsubara, OOPS-259B935 seems to have been fixed already. is that true?
[04:19] <Ubug2> https://devpad.canonical.com/~jamesh/oops.cgi/259B935
[04:20] <matsubara> kiko: yes, bug 59249
[04:20] <Ubug2> Malone bug 59249 in launchpad-bazaar "Edit branch details form need input validation for non-existent product" [High,Fix committed]  http://launchpad.net/bugs/59249
[04:22] <kristog> (second try ;) ) do you know how i can send mail after a commit on a LP bzr branch?
[04:23] <kiko> thanks matsubara 
[04:24] <cprov> nice ... custom setUp now works for build-notification.txt test, ITestMailBox is present for Zopeless layer, thanks flacoste/jamesh/malcc
[04:26] <jordi> carlos: I did, as "pt"
[04:27] <jordi> carlos: did you see my request about removing that Swedish translation that slipped as Northern Sami?
[04:27] <carlos> jordi: oh, really, I didn't see it correctly then ;-)
[04:28] <carlos> jordi: yes, but I cannot do it, Stuart should do it, I will send the request later today, don't worry
[04:29] <jordi> yup, thanks
[04:29] <jordi> danilos: and, you got a Cc for me regarding some plural forms :)
[04:31] <jordi> danilos: agreed that translatable strings with \r are bad? :)
[04:32] <matthewrevell>  /leave
[04:32] <matthewrevell> sorry
[04:32] <matthewrevell> :)
[04:33] <ddaa> jamesh: ping?
[04:33] <jordi> carlos: hm, interesting bug report
[04:33] <jordi> Message-ID: <bc2bd34a0609171512q3e20c44bx702f6c4861b1395b@mail.gmail.com>
[04:33] <carlos> jordi: I would prefer links to the bug
[04:34] <jordi> in rosetta-users
[04:34] <jordi> there is none :)there's no bug filed yet
[04:34] <jordi> I can give you a link to the archive, wait
[04:34] <jordi> oh man, the lag
[04:35] <jordi> https://lists.ubuntu.com/archives/rosetta-users/2006-September/001805.html
[04:35] <carlos> jordi: don't worry, I saw it already
[04:35] <carlos> jordi: well, actually, that's a bug in that .pot file
[04:35] <carlos> I mean... mixing \r with \r\n is a bit broken....
[04:36] <jordi> 16:31 < jordi> danilos: agreed that translatable strings with \r are bad? :)
[04:36] <jordi> :)
[04:36] <jordi> still, there's plenty of files out there with \r
[04:36] <carlos> I didn't say that \r is bad
[04:36] <carlos> is not the best thing in the world... but we can live with that
[04:37] <carlos> jordi: I said that mixing both '\r' and '\r\n' is bad
[04:37] <danilos> jordi: well, it sucks, but it's still bug on our side, imho
[04:37] <carlos> in the same string...
[04:37] <jordi> iirc the gettext manual has something abotu \r ?
[04:37] <carlos> jordi, danilos: I guess that our bug is that we don't handle '\r' to show it with the special symbol for new line char
[04:38] <carlos> but in this case, upstart should be fixed
[04:38] <danilos> carlos: right, agreed
[04:38] <carlos> oh, another bug in our side is that we shouldn't accept .pot files broken that way....
[04:38] <carlos> the web form does that check, but seems like .po/.pot imports aren't
[04:39] <jordi> https://launchpad.net/people/ubuntu-l10n-dv <-- can you assign[1~carlos: 
[04:39] <carlos> sure
[04:40] <carlos> jordi: done
[04:40] <jordi> again, the lag
[04:40] <jordi> this is so laggy it's not even funny
[04:41] <carlos> danilos, jordi: I'm pinging Scott to talk about upstart .pot file
[04:41] <jordi> 9k
[04:41] <danilos> carlos: ok, thanks
[04:45] <Ubug2> New bug: #61081 in rosetta "PO template +edit form needs better validation for priority field" [Medium,Confirmed]  http://launchpad.net/bugs/61081
[04:46] <Ubug2> Malone bug 61086 in rosetta "Filter please" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61086
[04:46] <kiko> matsubara, what bug is bug 60730 a dupe of?
[04:46] <Ubug2> Malone bug 60730 in malone "Malone breaks patches by messing with whitespace" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/60730
[04:47] <kiko> Nafallo, that's a pretty weird bug summary
[04:48] <Nafallo> kiko: hmm, indeed. I should be able to make that a bit more verbose I think ;-).
[04:49] <Nafallo> that should be better then :-)
[04:52] <carlos> danilos, jordi: Bad news
[04:52] <danilos> carlos: yes?
[04:53] <kiko> malcc, is there time to sneak in another patch in your test run? or am I being evil? It may improve the performance of domination significantly..
[04:53] <carlos> danilos, jordi: Seems like it's not broken, but it's the first application that actually needs to handle '\r' and '\r\n' in the same message
[04:53] <malcc> kiko: Yes there's time. If the test run reveals a problem with it, we can decide then if there's time to fix it and retry, or if we need to leave it for later
[04:53] <danilos> carlos, how can that be? what is it actually doing?
[04:53] <carlos> danilos: it does exactly what those chars mean
[04:54] <kiko> malcc, okay, let me see if I can get it fixed in time for your run. ping me when you need it
[04:54] <carlos> move to the start of the line (without moving one line down), write something and move to the next line
[04:54] <malcc> kiko: Next run won't be until after this soyuz-fixes branch I'm responding to the review for has landed, you've got some time
[04:54] <carlos> danilos: text console 'magic'
[04:55] <danilos> carlos: hum, what is it, some vt emulation program, or what?
[04:55] <carlos> danilos: I guess this could be a good example of tags that should be removed from translatable strings, like we try to do with XML translations
[04:55] <danilos> hum, why would init-replacement need things like that... well, whatever
[04:55] <carlos> danilos: it's the new init implementation for Ubuntu
[04:55] <matsubara> kiko: https://launchpad.net/products/launchpad/+bug/2627 maybe
[04:55] <Ubug2> New bug: #61086 in rosetta "Filter at pot-listings" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61086
[04:55] <carlos> danilos: for booting status 
[04:56] <danilos> carlos: agreed, we need something like <unchangeable>
[04:56] <carlos> danilos: well, I still think it's a bug in upstart, it shouldn't extract those 'tags' to be translated
[04:56] <carlos> but I also agree that Rosetta should allow people to translate such strings
[04:57] <danilos> carlos: the string is particularly silly
[04:57] <carlos> danilos: but it's valid
[04:57] <danilos> carlos: indeed
[04:57] <carlos> if it's valid, Rosetta should allow people to work with it
[05:02] <carlos> jordi: would be possible that you file a bug about upstart problem and assign it to me?
[05:06] <kiko> matsubara, I believe that's right. 
[05:07] <matsubara> kiko: I'll dupe accordingly. I wonder why 2627 is marked as private. Do you see any reason for that?
[05:18] <ddaa> There's something excessively strange going on with the branch puller
[05:21] <kiko> matsubara, not really..
[05:30] <ddaa> fantastic, some early branch makes it crash
[05:30] <kiko> BjornT, well, you tell me -- in what case could self.bugattachments == other.bugattachments?
[05:30] <kiko> BjornT, I think that's really not the right thing to check.
[05:32] <BjornT> kiko: only when self.bugattachments == other.bugattachments == [] 
[05:32] <kiko> BjornT, I think doing a check for != makes that much more obscure.
[05:32] <kiko> malcc, ping?
[05:32] <malcc> kiko: pong
[05:33] <kiko> malcc, can source packages never be in the publication status PENDING?
[05:33] <malcc> kiko: They can, but not for very long
[05:34] <malcc> kiko: process-accepted puts them there, and then a couple minutes later, publish-distro moves them along to published; it all happens during one cron.daily run
[05:34] <BjornT> kiko: interesting, i think not using != is much more obscure :) since the method name is 'isIdenticalTo', it makes much more sense (to me) to check for equality, not for presense of attachments.
[05:34] <ddaa> it's the oscss import... grmbl...
[05:35] <kiko> BjornT, but we can't ever check if attachments are identical, which is why if any of the comments has them, we should bail out.
[05:35] <kiko> BjornT, that fact is lost when you use !=
[05:35] <kiko> there is no way of comparing ==
[05:35] <kiko> unless they are empty lists
[05:35] <jamesh> ddaa: pong
[05:36] <kiko> malcc, do you understand why the dominator queries binaries for PENDING and PUBLISHED, but sources only for PUBLISHED?
[05:36] <malcc> kiko: No idea at all. Unless something is very strange, there can't be any binaries in PENDING at that time either, as we're not between process-accepted and publish-distro's first phase
[05:36] <malcc> kiko: I suspect it's cruft
[05:37] <kiko> malcc, hmm. should I try and drop PENDING as well, or just XXX it for later?
[05:37] <ddaa> jamesh: can you look at https://launchpad.net/products/launchpad-bazaar/+bug/60418 ?
[05:37] <Ubugtu> Malone bug 60418 in launchpad-bazaar "configurable default syncinterval for vcs imports" [High,Confirmed]  
[05:37] <malcc> kiko: I'd say put in an XXX. Querying on another state which has no rows won't be slow, and perhaps it's the best conceptual thing to be querying for, so we might want to fix sources not binaries
[05:37] <ddaa> jamesh: lifeless and sabdfl would like me to step up the frequency of vcs syncs, but that problem is getting in the way
[05:38] <jamesh> ddaa: okay.  Is there anything more I'd need to know other than what's in the bug report?
[05:38] <ddaa> jamesh: the main open issue is that I'm not clear where the default value should be stored
[05:38] <kiko> malcc, ok.
[05:38] <jamesh> e.g. what the default sync intervals should be for cvs and svn
[05:39] <jamesh> ddaa: does the launchpad.conf file sound okay?
[05:39] <BjornT> kiko: well, if you prefer to check for presence of attachments, keep it. it's not a big issue, especially not since there's a comment explaining the check.
[05:40] <ddaa> jamesh: I guess... but that means changing it would require bouncing importd
[05:41] <ddaa> The most convenient thing for me would be having it stored in the database, so it can be changed without having to interrupt service. But there might be a policy problem with doing that.
[05:42] <ddaa> Mh... on second though... having it stored in the DB would not help much because importd sucks
[05:42] <ddaa> jamesh: okay with the lanchpad config
[05:43] <ddaa> jamesh: defaults should be 6h for svn, 12h for cvs.
[05:43] <jamesh> ddaa: changing it to some place other than launchpad.conf later on shouldn't be too difficult
[05:51] <jordi> carlos: sure, but tell me why \r\n is bad and \r isn't
[05:51] <carlos> jordi: all them are bad, but this is a corner case when it makes sense
[05:51] <carlos> jordi: anyway, I'm filing the bug right now, so don't worry
[05:51] <jordi> ah ok
[05:51] <carlos> jordi: it's just like <b>foo</b> in XML
[05:51] <jordi> nod
[05:51] <carlos> jordi: it should not be there
[05:52] <carlos> but the program extracts those special tags and translators could mess it... but we should allow it
[05:52] <carlos> until upstart came, no other template needed that
[05:54] <sidarus> by all see you soon
[05:54] <sidarus> ddaa>special thank's to you
[05:55] <ddaa> sidarus: you're welcome. I'm debugging some problem caused by the oscss import, I'll let you know when the import is published.
[05:55] <jordi> sidarus: laters!
[05:56] <sidarus> ddaa>many thank's for your help, see you later ;)
[05:57] <carlos> jordi, danilos: https://launchpad.net/products/rosetta/+bug/61096
[05:57] <Ubugtu> Malone bug 61096 in rosetta "Rosetta should allow '\r' and '\r\n' in the same msgid/translation" [Medium,Confirmed]  
[06:01] <carlos> jordi: the mail you wanted me to look into is the one about kdelibs, isn't it?
[06:03] <jordi> yes
[06:03] <kiko> BjornT, do you really think I should revert? I'd rather have r=BjornT than nothing ;-)
[06:05] <Ubugtu> New bug: #61096 in rosetta "Rosetta should allow '\r' and '\r\n' in the same msgid/translation" [Medium,Confirmed]  http://launchpad.net/bugs/61096
[06:06] <BjornT> kiko: i never said anything about reverting, did i? :) i did say that it wasnt such a big issue and you could keep it the way you have it. so you got r=BjornT
[06:09] <kiko> :)
[06:09] <kiko> thanks.
[06:15] <kiko> malcc, this turned into a more serious whack :-( see if you think it's worth doing, otherwise store in a branch of yours for further work.
[06:15] <kiko> malcc: https://sodium.ubuntu.com/~andrew/paste/file5wEqLs.html
[06:17] <malcc> kiko: Wow, looks like you've rewritten the whole thing. Can you summarise the approach behind your changes?
[06:18] <kiko> malcc, well... basically I got rid of _sortPackages, and used debversion_sort_key instead.
[06:19] <malcc> kiko: Not bad for a 635-line patch :)
[06:19] <carlos> jordi: seems like Ubuntu packages 'lost' those strings
[06:20] <carlos> jordi: it's not a Rosetta issue, but package problem
[06:20] <kiko> malcc, sorry. I think I got carried away by all that cruft. it's somewhat nicer now, though. :-(
[06:21] <malcc> kiko: Yes, de-crufting is good, it's just a bit overwhelming trying to work out which changes actually change anything and which are pure code-level refactoring
[06:25] <jordi> carlos: oh hmm.
[06:28] <carlos> jordi: https://launchpad.net/distros/ubuntu/+source/kdelibs/+bug/61107
[06:28] <Ubugtu> Malone bug 61107 in kdelibs "Some stock strings are not extracted to be translated" [Untriaged,Confirmed]  
[06:36] <kiko> salgado, have time to do a trivialish review?
[06:37] <kiko> salgado, https://sodium.ubuntu.com/~andrew/paste/file53br7Y.html
[06:44] <salgado> kiko, what do you think of storing SQLConstant("person_sort_key(Person.displayname, Person.name)") as Person._sort_key (or something similar)?
[06:45] <kiko> salgado, we already do -- Person.sortingColumns.
[06:47] <salgado> kiko, why not use it on activememberships and etc, then?
[06:47] <kiko> good point.
[06:48] <salgado> I guess you'll have to add a Person. on SQLConstant("person_sort_key(displayname,name)")
[06:48] <salgado> I mean, Person.[name,displayname] 
[06:49] <kiko> hmmm, right.
[06:50] <salgado> kiko, other than that, looks good to me
[06:51] <kiko> cool, salgado. thanks.
[07:11] <Ubugtu> New bug: #61112 in rosetta "Rosetta should display something for a "\r" in a msgid" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61112
[07:13] <ddaa> Does anybody know how I can debug a http request given its apache access log?
[07:13] <ddaa> I have that:
[07:13] <ddaa> 82.211.81.156 - - [18/Sep/2006:18:05:48 +0100]  "GET /000007ac/.bzr/repository/knits/3a/application_top.php.bak-20060918135605-1hhi6s5mwfczzdkr-198.knit HTTP/1.1" 206 667 "-" "bzr/0.10.0 (urllib)"
[07:14] <SteveA> debug in what sense?
[07:15] <ddaa> I presume this log gives enough information to rebuild the request. Then I would like to run it "manually" and see what the server answered
[07:16] <SteveA> you can try to do that
[07:16] <SteveA> it doesn't contain all the information that might have been passed
[07:16] <SteveA> for example in other HTTP headers
[07:16] <SteveA> but you can try it
[07:16] <SteveA> telnet host port
[07:16] <SteveA> GET /000007ac/.bzr/.... HTTP/1.1
[07:17] <SteveA> Host: externally.visible.hostname
[07:17] <SteveA>  (this line intentionally left blank)
[07:17] <ddaa> ATM it looks like it was a ranged request that did not give all the expected bytes
[07:17] <SteveA> well, you won't get the range headers in the log
[07:17] <ddaa> oh, what is the "206 667" bit then?
[07:18] <SteveA> that indicates that a partial request was made
[07:18] <SteveA> and successfully completed
[07:18] <SteveA> but, it was not logged what the range was
[07:21] <SteveA> ddaa: if you need to debug this, there should be a way to log the Range headers of requests, maybe sticking it o nthe end of the log lines
[07:22] <ddaa> yeah, there were some commented mutter statements in the code
[07:22] <ddaa> I just uncommented them
[07:22] <SteveA> oh, I meant in the apache logs
[07:22] <SteveA> but I guess having bzr log it too works
[08:03] <kiko> bradb... did you read my email? why are you removing stuff without giving proper time for further discussion?
[08:04] <bradb> kiko: urgh
[08:05] <bradb> kiko: I didn't think a small change like that needed consensus, tbh.
[08:05] <bradb> But it's easy to change back.
[08:09] <kiko> bradb, the date was exposed in the spec mockups too. I think it would be more practical to discuss things before going ahead and firing changes off into RF.
[08:10] <SteveA> bradb: principle of least surprise... if people will be in the least bit surprised, then stick to what was agreed before
[08:10] <bradb> SteveA: sure, UI 101. but we have no info either way right now. i just went with what mpt said.
[08:11] <bradb> but anyway, i'll hold off landing other changes like that unless they're explicitly agreed on.
[08:11] <SteveA> this is the principle of least surprise for working on a team, rather than the principle for UI design
[08:11] <kiko> bradb, I'm also now asking myself why you didn't include the package/product icons that we had specd together, bradb?
[08:11] <SteveA> I'm just abusing the same name to make a point
[08:12] <kiko> or the collapsing...
[08:12] <bradb> SteveA: oh, ISWYM
[08:13] <bradb> kiko: I didn't intentionally leave those icons out, fwiw. I can add it to my todo.
[08:14] <kiko> IIRC we thought they were a nice idea in that they helped differentiate upstream versus distro bug rows in the status table
[08:14] <kiko> man how I hate that actions menu.
[08:15] <bradb> kiko: the icons might help. hard to say.
[08:15] <Nafallo> https://launchpad.net/products/rosetta/+bug/61086 <-- could someone look if that might be unduplicated? ;-)
[08:15] <Ubugtu> Malone bug 61086 in rosetta "Filter at pot-listings" [Untriaged,Unconfirmed]  
[08:16] <kiko> Nafallo, what are "pot-listings"?
[08:16] <Nafallo> kiko: what we have on the URL pointed to :-)
[08:17] <kiko> Nafallo, hmm?
[08:17] <Nafallo> https://launchpad.net/distros/ubuntu/edgy/+lang/sv
[08:17] <Nafallo> that list with pots :-)
[08:17] <kiko> Nafallo, that's a distribution release language listing. and yes, that's a dupe.
[08:18] <kiko> Nafallo, bug 112.
[08:18] <Ubugtu> Malone bug 112 in rosetta "Search for packages per language" [Wishlist,Confirmed]  http://launchpad.net/bugs/112
[08:18] <Nafallo> hmm, oki. I read Simira's bug as if she wanted more than just the filter, but that might just be me then :-).
[08:20] <Nafallo> I just want to be able to filter out for example upstart's template so that I can work on it :-)
[08:35] <Ubugtu> New bug: #61123 in rosetta "Rosetta should display something for consecutive spaces in the middle of a line of a msgid" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61123
[08:44] <kiko> bradb, so the scenario I am concerned about is the following
[08:44] <kiko> we turn on release nominations
[08:44] <kiko> we have thousands of users using malone for ubuntu
[08:45] <kiko> and then one of the following happens:
[08:45] <kiko> a) the distro team is overwhelmed by the requests (are they emailed, btw? if not, is this feature very useful?)
[08:45] <kiko> b) we find out a bug that cases these nominations to misbehave somehow
[08:46] <kiko> c) the distro team finds the feature interesting but there are some serious bugs that make it very distracting to use the feature
[08:46] <kiko> bradb, in any of those scenarios we are kind of fucked if we have no way of disabling the addition of new notifications.
[08:47] <bradb> kiko: b and c seem to apply to a lot of significant feature additions, fwiw.
[08:47] <kiko> bradb, I agree, but that doesn't make it less important here.
[08:47] <kiko> this is a feature that has a lot of chance of getting us lambasted
[08:48] <bradb> re: a, no they aren't currently emailed. they could be, but that would just increase the pressure in the firehose. IMHO, the most useful way to deal with the flood of noms is listings.
[08:48] <kiko> (in particular the distro team did /not/ ask for it)
[08:48] <kiko> bradb, listings which we don't yet have.
[08:48] <bradb> kiko: indeed, though they are quick to add after it rolls out.
[08:49] <bradb> and, as much as being about nominations, it's also about release targeting
[08:49] <kiko> bradb, again, I don't agree on rolling this feature out half-baked.
[08:49] <kiko> it will only get us bad rep.
[08:49] <kiko> "Why does nobody look at these nominations?"
[08:49] <kiko> "How can I stop people from adding these nominations to my product!?"
[08:50] <kiko> "If you want me to use it, how can I see all nominations for my product?"
[08:50] <kiko> etc.
[08:50] <bradb> kiko: i don't agree on half-baked solutions either, though i do think it's practical to release early and often, particularly when what's missing can be added pretty quickly.
[08:50] <kiko> bradb, in some situations, I agree. in this one, I don't.
[08:50] <bradb> because right now we've made a lot of very important decisions on something we have very little, perhaps no, information about
[08:51] <kiko> I agree, but still think that the damage of the half-baked release outweighs that.
[08:51] <kiko> what we /should/ have done was rolled out to a test server, instead of landing into RF.
[08:51] <kiko> now that it is in RF, you can either back it out or deal with the fact that we may need to turn it off.
[08:52] <kiko> which is why I've been trying to point out in this last week of emails
[08:52] <bradb> kiko: I agree that I made a mistake in landing it in rf
[08:52] <bradb> I'm willing to back it out.
[08:52] <bradb> and work with stub to put it on a beta site
[08:53] <kiko> that's an acceptable solution if you prefer that
[08:53] <bradb> ok, i will back it out
[08:54] <kiko> I just think that conditionally disabling the feature may be less work
[08:54] <kiko> but that can be your call
[08:54] <bradb> i think i'd rather back it out for now
[08:55] <kiko> okidok
[08:55] <kiko> SteveA, do we have a box that would serve as an edge or test box?
[08:55] <kiko> bradb, otherwise that means carbon I guess
[08:57] <bradb> kiko: so, the affects revs are: 4047, 4046, 4032. should i just reverse apply each one, newest to oldest, then commit all that? what about reviews, etc?
[08:57] <bradb> s/affects/affected/
[08:58] <kiko> bradb, well.. if you can reverse apply them cleanly, I think it's fine.
[08:58] <kiko> rs=kiko on backing it out anyway.
[08:58] <bradb> ok
[09:16] <Nafallo> what's the correct way to Close bugs in changelogs? :-)
[09:22] <cprov> Nafallo: well, currently there is no Soyuz/Malone interface in this land. I didn't spend much attention on it (it's a regression from dak)
[09:23] <Nafallo> ah, oki.
[09:23] <Nafallo> thanks anyway then :-)
[09:31] <Ubugtu> New bug: #61129 in malone "minidom crashes with encoding errors while parsing external bug tracker pages" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61129
[09:38] <bradb> kiko: would it be relatively easy to kill just the current merge request in pqm?
[09:39] <kiko> bradb, I have no idea. you could have pushed a revision with a failing test earlier, but now..
[09:39] <kiko> you'll need admin help
[09:40] <bradb> elmo: can you bounce pqm? i.e. I want to "cancel" just the merge request pqm is currently processing, if possible.
[09:47] <dholbach> hello
[09:48] <dholbach> andrunko just tried to push a branch to sftp://andrunko@bazaar.launchpad.net/~telepathy/telepathy-qt/ubuntu and it created a sftp: file for him and pushed 0 revisions - his ssh key is ok and I added him to the telepathy team (the product created too) - does anybody have an idea, what's going wrong?
[09:49] <andrunko> it created sftp: dir
[09:49] <dholbach> ahhh a dir
[09:49] <kiko> an sftp: directory?
[09:49] <kiko> that's most weird
[09:49] <andrunko> yep
[09:50] <kiko> ddaa?
[09:50] <andrunko> anmagalh@andrunko:~/projects/tapioca/trunk/telepathy-qt$ bzr push --create-prefix sftp://andrunko@bazaar.launchpad.net/~telepathy/telepathy-qt/ubuntu
[09:50] <andrunko> 0 revision(s) pushed.
[09:50] <kiko> andrunko, hmm. --create-prefix should no longer be necessary or used IIRC
[09:51] <ddaa> I'm officially out, but what can I (quickly!) do to help?
[09:51] <andrunko> hmmm, let me try again without it
[09:51] <kiko> ddaa, see above
[09:51] <ddaa> well, there was a number of versions of bzr where this message was buggy
[09:52] <flacoste> andrunko: yeah, the first push always pushed 0 revision
[09:52] <andrunko> flacoste: no that's no the problem
[09:52] <andrunko> it did not push anything
[09:52] <ddaa> but it otherwise worked correctly
[09:52] <andrunko> it created a sftp: dir in  PWD
[09:53] <kiko> andrunko, oh, on your local box?
[09:53] <andrunko> yep
[09:53] <ddaa> well, I do not see any branch for telepathy-qt on launchpad
[09:53] <andrunko> it did not work
[09:53] <andrunko> i will try without --create-prefix
[09:54] <ddaa> https://launchpad.net/products/telepathy-qt
[09:54] <ddaa> a branch should appear here as soon as the push start
[09:55] <ddaa> otherwise, everything appears correct
[09:56] <ddaa> I mean here: https://launchpad.net/products/telepathy-qt/+branches
[09:57] <andrunko> anmagalh@andrunko:~/projects/tapioca/trunk/telepathy-qt/debian$ bzr push --create-prefix sftp://andrunko@bazaar.launchpad.net/~telepathy/telepathy-qt/ubuntu
[09:57] <andrunko> 0 revision(s) pushed.
[09:57] <andrunko> anmagalh@andrunko:~/projects/tapioca/trunk/telepathy-qt/debian$ ls
[09:57] <andrunko> changelog  cmake.mk  compat  control  copyright  rules  sftp:  telepathy-qt0.install  telepathy-qt-dev.install
[09:57] <andrunko> it just created the sftp: dir
[09:57] <ddaa> bah
[09:57] <BjornT> andrunko: do you have python-paramiko installed?
[09:57] <andrunko> i don't know what is happening
[09:57] <ddaa> BjornT++
[09:57] <dholbach> nghnghnghngh.
[09:58] <ddaa> I think that's a known bug. You need python-paramiko installed
[09:58] <ddaa> andrunko: try with a more recent release of bzr too
[09:58] <SteveA> win 14
[09:58] <andrunko> now it seems to work
[09:58] <dholbach> andrunko: sorry - I didn't think of that earlier
[09:58] <andrunko> np
[09:58] <andrunko> :)
[09:58] <andrunko> ddaa: i am using dapper here
[09:59] <andrunko> i will create a edgy chroot env 
[09:59] <dholbach> andrunko: I'll check it out once the branch is up on LP
[09:59] <andrunko> great
[10:00] <ddaa> andrunko: that's seriously obsolete... 0.8.2 according to http://packages.ubuntu.com/dapper/source/bzr
[10:00] <dholbach> ddaa: hahaha - we support for that 3 years? 5 years? :-)
[10:00] <ddaa> 0.11 will be released soon, there has been 0.9 and 0.10 since that, which brings plenty of love (major performance improvements)
[10:01] <andrunko> :)
[10:01] <ddaa> http://bazaar-vcs.org/DistroDownloads
[10:01] <ddaa> you'll get an apt.sources line there to get the latest love
[10:02] <andrunko> great, i should be updating to edgy soon
[10:02] <ddaa> dholbach: I seriously think that newer bzr should go in through dapper updates
[10:03] <dholbach> that's something that should be discussed with Colin and Matt
[10:03] <ddaa> bzr is < 1.0, it's early adopter stuff that we publicize actively
[10:03] <ddaa> dholbach: can you bring that up with them?
[10:04] <dholbach> I'd prefer it if you'd argue the case
[10:04] <dholbach> or somebody of your team, since you know better what's at stake
[10:04] <ddaa> Well, actually mpool should argue the case.
[10:04] <ddaa> he's coming back from vacation tomorrow
[10:05] <ddaa> there was a strong push before dapper so 0.8 could get in, because it brough in a new, incompatible, vastly improved branch format.
[10:06] <ddaa> And we really did not want dapper user to use the old format.
[10:10] <LarstiQ> ddaa: afaik, EtienneG is first seeing how 0.10 does in edgy before trying dapper
[10:11] <Nafallo> ddaa: what's this? https://launchpad.net/people/ubuntu-dev/+branch/gajim/ubuntu
[10:11] <Nafallo> ddaa: the warning that is...
[10:12] <Nafallo> hmm, still pushing :-P
[10:12] <ddaa> ha, there's a bug open on that
[10:12] <Nafallo> might be because of that maybe? :-)
[10:12] <Nafallo> :-)
[10:13] <ddaa> https://launchpad.net/products/launchpad-bazaar/+bug/49989
[10:13] <Ubugtu> Malone bug 49989 in launchpad-bazaar "branch puller reports failure for new hosted branches" [Low,Confirmed]  
[10:13] <ddaa> it's vaguely confusing, but much less so than many other things, thus the Low importance.
[10:14] <ddaa> Also, it's likely to be fixed as a side effect of other more important improvements.
[10:15] <Nafallo> oki :-). just wondered what the hell it was :-P
[10:46] <dholbach> good night everybody
[11:15] <Ubugtu> New bug: #61149 in malone "externalbugtracker.Bugzilla fails to query bugs on version 2.17.1" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61149
[11:49] <kiko> hmmm
[11:58] <bradb> kiko: Is there a spec other than CanonicalPillarNames that talks about the unique names magic? At least, I thought that was implemented, but, if it is, it doesn't work like the spec says.
[11:59] <bradb> (I was following up to bug 54985)
[11:59] <Ubugtu> Malone bug 54985 in malone "launchpad.net/bugs/product-name  as a shortcut" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/54985
[12:02] <kiko> bradb, it is implemented AFAIK.
[12:02] <theCore> how do I add a wiki page to a Team?
[12:02] <bradb> kiko: what's the syntax?
[12:03] <kiko> bradb, syntax?
[12:04] <bradb> kiko: yeah, like what's the shortest URL I can use to see a product's homepage? person? distro? etc.
[12:05] <kiko> bradb, only the names were made unique. the URLs are not shortened yet.
[12:05] <bradb> ah, ok
[12:05] <kiko> I believe there is API to make it easy to redirect however.
[12:06] <bradb> kiko: so, for bug 54985, can i say that bugs.launchpad.net/$product, ~$person, and $distro will work someday in the not too distant future?
[12:06] <Ubugtu> Malone bug 54985 in malone "launchpad.net/bugs/product-name  as a shortcut" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/54985
[12:07] <bradb> will/probably will/might, whatever :P