[01:48] <tvon> Does anyone else think the fonts are a bit big on launchpad?
[01:49] <tvon> launchpad.css scales them back up to 100% (after plone.css scales them down a bit).
[01:50] <tvon> with the comment 'Don't stomp on people's preferred font sizes:'
[01:50] <mpt> tvon: Which makes them whatever your preferred size is
[01:50] <mpt> as used on Slashdot, for example
[01:50] <tvon> hrm
[01:51] <mpt> If your preferred size is smaller or larger than your browser thinks it is, have a little chat with your browser's Preferences/Options
[01:52] <mpt> Launchpad does use bold text in quite a few places where it shouldn't
[01:53] <mpt> but I'm gradually getting rid of those
[01:53] <tvon> I understnad the logic in scaling the font size to 100%
[01:53] <mpt> yo cprov
[01:56] <tvon> Not that I've been checking, but I'd be pretty impressed if I could find a well designed site that didn't scale the fonts
[01:56] <mpt> Yeah, there's a constant tension between designers and readers
[01:57] <mpt> Designers usually want to cram more onto the page
[01:57] <mpt> reducing scrolling, at the expense of readability
[01:57] <tvon> this is true
[01:58] <mpt> This is one of the reasons browsers switched from a 12px default in the mid-1990s to a 16px default since 1999 or so
[01:58] <tvon> ah, I thought it was 14
[01:59] <mpt> Early Safari betas experimented with defaulting to Lucida Grande 14, but they were brow-beaten into changing to Times 16
[01:59] <mpt> that's the only browser I know of that has ever defaulted to 14.
[01:59] <tvon> ah
[02:00] <mpt> You're welcome to set your own preferred size to 14 if that suits you :-)
[02:00] <tvon> heh, no thank you
[02:03] <mpt> anyway, I'm starving, so I'm going home
[02:03] <tvon> thanks for the chat
[02:03] <mpt> no probs
[02:04] <mpt> tchau
[02:40] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Sync pgstats.py with production (patch-2319: stuart.bishop@canonical.com)
[02:57] <stub> cprov: ping
[02:57] <cprov> stub: pong
[02:57] <stub> cprov: Did I tie the countdown and the 'number of changes before committing' together in Gina?
[02:58] <stub> Urgh... yes I did. That would be a bug.
[02:59] <cprov> stub: yes, I has been done some time ago and never changed, bug me about it, I have plans to repair it, 
[02:59] <cprov> stub:  if you are not in hurry
[03:00] <stub> I will need to start running Gina on staging tomorrow. I'll add a new command line option if it is a problem (or will this cause conflicts with your work?)
[03:05] <cprov> stub: the merge should be in PQM now ...
[03:08] <stub> ok. Partial commits will be important on production to avoid locking stuff in the db for too long (but gina.py | grep -v Countdown would work right now, so it isn't urgent ;) )
[03:37] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=bjorn]  Fixing bug #1797, not found CoC doesn't cause a System Error anylonger. (patch-2320: celso.providelo@canonical.com)
[04:11] <dilys> Merge to rocketfuel@canonical.com/dists--devel--0: [trivial]  Tweak staging makefile and prune old production configs (patch-108: stuart.bishop@canonical.com)
[06:10] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=bjorn]  Fix Soyuz UI bits (patch-2321: celso.providelo@canonical.com, daniel.debonzi@canonical.com)
[06:14] <cprov> stub: done, if you want to modify something for gina on staging, I'm clean now
[07:07] <stub> lifeless: What is the procedure for syncing our Z3 tree with upstream? If I do a fresh import into a new version, I can't replay our patches against the new version.
[07:08] <stub> (Or is this correct, and I need to manually apply the deltas instead of using replay?)
[07:13] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  make sure authenticateEmail doesn't break on invalid signatures. (patch-2322: bjorn.tillenius@canonical.com)
[07:16] <lifeless> stub: there is no reliable procedure
[07:16] <lifeless> so yes, manual deltas or drop a copy on top of our tree and adjust until it looks right :/
[07:17] <interalia> aha, life in lifeless (sounds wrong somehow...)
[07:17] <interalia> lifeless: is there any reason cscvs is truncating summaries to 55 chars?
[07:17] <lifeless> yes, thats the heuristic, as cvs and svn dont have summaries they are inferred
[07:20] <interalia> I was thinking of more or less taking out that call to sanitize_summary()(). 
[08:08] <lifeless> summaries can't be multiline unless they are rfc822 formatted
[08:08] <lifeless> so, you need to sanitise them somehow ;0
[08:10] <jamesh> are summaries going or staying for baz-2.0?
[08:11] <lifeless> going I think
[08:11] <interalia> hmm? rfc 822 means lines of type 'Foo: Bar Quux ;comment' right?
[08:12] <lifeless> nope
[08:12] <lifeless> header: value
[08:12] <lifeless>  value continues
[08:12] <lifeless> another-header: value
[08:16] <interalia> lifeless: ah ok I think get what you mean.  so tla make-log stuff is in RFC 822 format.  and cscvs truncates to avoid having to continue the lines properly?
[08:16] <lifeless> in essence, yes. Note that the full cvs log is preserved in the body of the commit.
[08:16] <lifeless> there is no data loss.
[08:20] <stub> lifeless: Can you please mirror rocketfuel@canonical.com/launchpad--production--1.30 across (I just tagged it)
[08:22] <lifeless> done.
[08:34] <jblack> lifeless: Ping
[08:36] <lifeless> pong
[08:36] <jblack> I finished up the gnome audit. I emailed you a list, so that we can chat about it for a few
[08:37] <jblack> It was a painful, painstaking process, but I was able to find 79 out of 108. 
[08:39] <jblack> Some of them look easy (vino, libgnome-vfsmm). Others look awkward (libxml++), others are presumably afu (*-java, "gnome")
[08:40] <jblack> btw, this took quite a bit of time, because it involved comparing one list against another, with policy changes (for example, dropping version numbers in baz archives)
[08:41] <jblack> And having four sources didn't help either (wild archive and 4 gnome archives of various names with various numbers of branches)
[08:44] <lifeless> ok
[08:44] <jblack> So, first thing first. policy decision: What do you want to do with projects that have a + in the name? 
[08:45] <jblack> (oh, among those 29 "failures" are a handful of failure to imports)
[08:46] <lifeless> +->plus
[08:48] <jblack> The next question (more of a statement): These are dev branches, that list is against release. 
[08:48] <lifeless> jhbuild operates on dev
[08:48] <lifeless> and its dev where the action is
[08:49] <lifeless> I've mailed you back about the branding of bzr... 
[08:49] <jblack> Sure, we want to go against dev (durh!), but the list that was audited (as per jdub's suggestion) was.. 211 or something like that.
[08:49] <lifeless> please get a final draft of that announcement for me for my tomorrow, I really want that up
[08:50] <jblack> To your next comment: desync.
[08:50] <jblack> Didn't you write one? 
[08:51] <lifeless> I did a focused redraft of what you had.
[08:51] <jblack> Martin - this is the draft roadmap for bazaar..
[08:51] <jblack> Ok. I'll prettify the one you sent right now. 
[08:52] <lifeless> It needs you to go over it and : check the branding stuff for consistency (see my email as of 5 minutes back), check it for hang-togetherness, grammar etc.
[08:52] <jblack> Yeah. I'll do all that. 
[08:52] <jblack> This shouldn't take long. The thing is in good shape
[08:52] <lifeless> drop that back to me in mail for a final look and then we can go with it.
[08:54] <jblack> btw, you never told me. Where exactly is this going? 
[08:54] <lifeless> wiki, bazaar-announce, bazaar-ng, gnu-arch-users
[09:28] <jamesh> jblack: if you can think of things that jhbuild could do better w.r.t. arch/bazaar support, please tell me (at bugzilla.gnome.org)
[09:29] <jamesh> jblack: I haven't really done much with the support code since I started using Bazaar heavily
[09:29] <jblack> jamesh: Ok. Mind if I send you a list of what we already have imported, so you can give me a hunch of problems I've got coming? 
[09:29] <jamesh> sure.
[09:29] <jblack> jamesh@canonical.com ?
[09:31] <lifeless> jamesh: does it support baz urls' ?
[09:31] <jamesh> jblack: that'll get to me
[09:31] <jblack> ok. then its probably already 1/2 way there
[09:31] <jamesh> lifeless: not at present -- you need to give the URL -> archive mapping separate from the module def.
[09:32] <lifeless> jamesh: having urls would help hugely.
[09:32] <lifeless> baz supports urls itself ;0
[09:34] <jblack> lifeless: doublechecking -- we've guaranteed a migration tool
[09:34] <lifeless> yes
[09:34] <jblack> as in a program, not as in "pick it up at the supermirror"
[09:34] <lifeless> for 'baz -> bzr' yes
[09:35] <jblack> thats what I meant.
[09:35] <jblack> I think you'll like this
[09:35] <jblack> unless you thought the old one was too long.
[09:36] <jblack> are we additionally doing baz->bzr conversion at the sm ? 
[09:37] <lifeless> no
[09:37] <jblack> good thing I asked. :)
[09:37] <jblack> That surprises me, btw. Theres more than a couple orphaned archives at the sm
[09:37] <lifeless> I was happy with the amount of content in the draft I sent you
[09:38] <lifeless> ... is this for that draft ?
[09:38] <jblack> I'll provide one that is simply proofread as well.
[09:38] <jblack> (was already planning that)
[09:38] <jamesh> jblack: you have pkgconfig in bazaar, btw
[09:39] <jblack> There's _two_
[09:39] <jblack> That's why I said ambigious. I haven't disambiguated. :) 
[09:39] <jblack> There are two pkg-configs and a pkgconfig. 
[09:40] <jblack> Two of which have branches, one of which doesn't.
[09:40] <jamesh> james@gabe:/cvs/pkg-config$ ls -l
[09:40] <jamesh> total 8
[09:40] <jamesh> drwxrwxr-x  3  10019 pkgconfig   4096 2003-10-07 14:16 CVSROOT
[09:40] <jamesh> lrwxrwxrwx  1 tfheen freedesktop   11 2005-06-12 03:17 pkgconfig -> pkg-config/
[09:40] <jamesh> drwxrwxr-x  4  10019 pkgconfig   4096 2005-08-27 02:06 pkg-config
[09:40] <jamesh> so the two CVS modules are actually the same
[09:41] <jblack> jamesh: I haven't checked yet to make sure they're both gnome ones. Have you checked to make sure they're both pointing at that, and one isn't at some odd kde thing? 
[09:41] <jblack> btw, thanks for helping. ;)
[09:42] <jamesh> https://launchpad.net/products/pkgconfig/+series/main and https://launchpad.net/products/pkg-config/+series/main seem to indicate that they're the same
[09:42] <jamesh> pdx.fd.o == cvs.fd.o
[09:43] <jblack> Ok. I'll update the pkg-config one
[09:43] <jamesh> there is just one pkg-config, used by both Gnome and KDE (and other projects not related to any desktop)
[09:43] <jamesh> I think Mithrandir wants to use the name "pkg-config" rather than "pkgconfig"
[09:44] <jblack> I'll rephrase. I'll update to use the pkg-config one in the list I emailed you
[09:46] <jamesh> hmm.  the Launchpad "pkg-config" product tracks the "pkgconfig" CVS module and vice versa
[09:48] <jamesh> jblack: dbus and hal should probably be in the list too
[09:48] <jamesh> both of which seem to be imported
[09:56] <lifeless> later folk
[09:56] <jblack> lifeless: don't late. 
[09:56] <jblack> lifeless: can you wait 5 more minutes? 
[09:57] <lifeless> whats up
[09:58] <jblack> lifeless: read that.
[09:58] <lifeless> read which ?
[09:58] <jblack> Thats a full rewrite ( :) ). I'm doing a simple proofreading for you, which will be in yur mailbox by the time you get back (that'll only take 10 minutes)
[09:59] <lifeless> I'll do that tomorrow morning
[09:59] <lifeless> catch you guys
[10:24] <carlos> morning
[10:33] <SteveA> hi carlos
[10:33] <carlos> SteveA, morning
[10:36] <SteveA> it's a public holiday for me today.  i'll be around a bit though.
[10:43] <stub> SteveA: I've been working on testing Z3.1 with Launchpad. Starting to get bogged down.
[10:43] <SteveA> does that mean that it doesn't work out of the box?
[10:43] <stub> SteveA: I'll probably commit what I have and punt it to you to have a look at sometime
[10:43] <SteveA> okay
[10:43] <stub> SteveA: Nope. 
[10:43] <jamesh> hi carlos
[10:44] <SteveA> i have about 2 weeks of stuff i need to land, unless someone does some of it for me.  then i'll be able to look at zope 3.1.
[10:44] <carlos> jamesh, hi
[10:44] <carlos> I saw you sent me an email, but still need to read it (if you ping me because it)
[10:45] <jamesh> carlos: james.henstridge@canonical.com--2004/launchpad--smallfixes--0--patch-14 <- has an updated validate_translation() function
[10:45] <carlos> jamesh, ok, I will take a look later this morning
[10:46] <carlos> are you wrapping C code or did you added the checks as python code?
[10:46] <jamesh> carlos: Python code
[10:46] <carlos> jamesh, ok
[10:47] <jamesh> carlos: you can either merge from that branch, or I can put it up for review as is
[10:47] <jamesh> carlos: but this should catch the extra errors that msgfmt looks for
[10:48] <carlos> jamesh, let me check it and If I don't need to do any change, just ask for review directly
[10:48] <carlos> jamesh, cool
[10:49] <jamesh> carlos: I also added a few tests of validate_translation(), since I couldn't find any
[10:51] <carlos> jamesh, hmm, I'm using pagetest for that
[10:51] <carlos> jamesh, the code was calling directly your pygettext bindings that already have test so I think it was not needed 
[10:51] <jamesh> carlos: okay.  well the straight doctests can't hurt :)
[10:52] <carlos> now that you have other code there is better that way, yes
[10:52] <jamesh> carlos: I think part of the problem was a misunderstanding of what PoMessage.check_format() did
[10:52] <carlos> jamesh, yeah, I know
[10:52] <jamesh> it just checks to see if format strings get translated right
[10:52] <jamesh> which isn't the only test gettext does
[10:52] <carlos> I assumed that it checks all things
[10:53] <carlos> jamesh, I discovered the msgfmt extra checks last week after talking with kiko
[10:53] <stub> SteveA: btw. NotFoundError is deprecated. Z3.1 tells you to use one of the standard exceptions. There will be a tedious job of replacing them all with LookupError (or KeyError or IndexError).
[10:54] <SteveA> it will be easy
[10:54] <SteveA> here's how
[10:54] <SteveA> 1. write a script that replaces the import of zope.interfaces.NotFoundError with canonical.launchpad.interfaces.NotFoundError
[10:54] <SteveA> 2. run script
[10:55] <SteveA> 3. write c.l.i.NotFoundError
[10:55] <carlos> stub, I suppose the whitespaces script finished successful on staging, right?
[10:56] <SteveA> we'll probably want to make c.l.i.NotFoundError derive from LookupError
[11:00] <jamesh> carlos: w.r.t. bug 1036, one solution might be to replace leading and trailing newlines inside the textarea with &#xA;
[11:00] <jamesh> I wonder if an entity would get stripped in the same way as an actual newline?
[11:01] <jamesh> oh.  you already tried that
[11:02] <jordi> :q
[11:03] <carlos> jamesh, 1036 is already fixed
[11:03] <carlos> jamesh, and anyway, the whitespace problem is also fixed as we modify the submissions strip them and add the same whitespaces that msgid has
[11:03] <jordi> carlos: any update on the queue?
[11:04] <carlos> jordi, I just started to work, I hadn't time to look into it
[11:04] <carlos> jordi, I suppose it's a .po file that is breaking the script so new imports cannot be done
[11:06] <carlos> hmmm
[11:07] <carlos> stub, could you check on production if the poimport script is running?
[11:07] <zyga> hello
[11:07] <carlos> stub, last email I got from that script was on Friday
[11:07] <carlos> zyga, hi
[11:07] <zyga> I just came across a bug in launchpad
[11:08] <zyga> https://launchpad.net/malone/bugs/1942
[11:08] <zyga> I was wondering if the report is okay as I never had problems with it before
[11:11] <carlos> zyga, are you a member of the Polish translation team?
[11:11] <zyga> carlos: yes
[11:12] <carlos> zyga, can you define a bit more the problem
[11:12] <carlos> do you get a system error?
[11:12] <carlos> or the system just ignores your submission?
[11:12] <zyga> carlos: yes I do
[11:12] <carlos> ok
[11:12] <zyga> I go to the page describing what to do
[11:13] <zyga> (report a bug, note the url and such)
[11:13] <carlos> zyga, please, try it again and tell me it so I can see the exact error from the log
[11:13] <zyga> I can still reproduce the bug 
[11:13] <zyga> okay
[11:13] <zyga> trying now
[11:14] <zyga> I happened again
[11:14] <carlos> ok
[11:14] <stub> carlos: Sorry - my speaker was off
[11:15] <carlos> zyga, I don't see anything 
[11:15] <carlos> stub, no problem at all
[11:15] <stub> carlos: poimport is running right now.
[11:15] <zyga> carlos: I'm puzzled
[11:15] <carlos> zyga, let me try to change it myself
[11:15] <zyga> carlos: I can give you vncview stuff access if you want to click it yourself
[11:15] <carlos> stub, since Friday?
[11:15] <zyga> carlos: ok
[11:16] <carlos> zyga, no, don't worry
[11:16] <stub> carlos: Nope - but it might be hung - doesn't seem to be chewing any CPU
[11:16] <carlos> stub, could you kill it, please?
[11:16] <stub> What do I run to trace a running process under Ubuntu?
[11:16] <carlos> strace ?
[11:17] <carlos> zyga, hmm it works here
[11:17] <carlos> zyga, could you send me the messages that you change with the text you are trying to use?
[11:17] <carlos> zyga, carlos.perello at canonical.com
[11:17] <zyga> carlos: no problem, just a moment
[11:18] <carlos> ok
[11:18] <carlos> thanks
[11:18] <stub> carlos: It seems to be hung in poll()
[11:18] <stub> Killed
[11:18] <zyga> carlos: do you want a .po file? or just hand made orig: foo; polish: bar; ?
[11:18] <carlos> stub, thanks
[11:19] <carlos> zyga, hand made, there are only 10 strings
[11:19] <carlos> zyga, you don't need to copy the msgid
[11:19] <zyga> ok
[11:19] <carlos> just tell me the number you see in the translation form
[11:22] <zyga> 75 -> 105
[11:22] <zyga> argh...
[11:22] <zyga> sorry
[11:23] <zyga> 75, 79, 81, 82, 83, 84, 85, 86, 86, 105
[11:25] <dilys> Merge to rocketfuel@canonical.com/dists--devel--0: [trivial]  production-1.30 config (patch-109: stuart.bishop@canonical.com)
[11:29] <BjornT> lifeless: pqm seems to have hung
[11:29] <BjornT> lifeless: no it hasn't, wrong window....
[11:34] <carlos> zyga, I mean, in your email
[11:34] <zyga> carlos: ok
[11:34] <carlos> zyga, give me the numbers + the translations you try to submit
[11:35] <carlos> so I can try it too and see the error
[11:35] <carlos> jamesh, thanks for the bug report
[11:37] <zyga> carlos: done
[11:38] <carlos> zyga, thanks
[11:38] <carlos> zyga, next time you see this kind of problem, this extra information would be a good addition to the bug report so we can reproduce the problem
[11:39] <zyga> carlos: sure, this should be also added to the error page I guess
[11:40] <carlos> zyga, the problem is that the error page is not Rosetta specific
[11:40] <zyga> carlos: I see
[12:07] <zyga> carlos: any luck?
[12:08] <carlos> zyga, hadn't time to look at it yet
[12:09] <carlos> zyga, btw, did you selected a filter?
[12:09] <carlos> zyga, because I see the sequence numbers have holes
[12:09] <carlos> which option did you selected? the ones that need review?
[12:12] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Added Friulian plural forms information (patch-2323: carlos.perello@canonical.com)
[12:18] <zyga> carlos: yes I choosed fuzzy messages
[12:19] <carlos> zyga, I don't get that sequence numbers as fuzzy, the first one is higher than 100
[12:20] <zyga> carlos: maybe my update did commit
[12:20] <zyga> carlos: I un-checked some of those fuzzy markers
[12:20] <carlos> ok
[12:24] <carlos> zyga, found the problem
[12:24] <jordi> carlos: what was going on with the queue?
[12:24] <carlos> zyga, thank you!
[12:24] <carlos> jordi, don't know the status, waiting for the email that tells me about it
[12:26] <jordi> carlos: apparently mtpaint has messages right now
[12:26] <carlos> jordi, cool :-)
[12:27] <jordi> londonlaw too
[12:29] <zyga> carlos: hmmm... system error occurred, again
[12:29] <zyga> maybe I should refresh my page
[12:29] <carlos> zyga, bug found but not fixed :-)
[12:30] <carlos> zyga, so it's normal it still fails
[12:30] <zyga> ah :)
[12:30] <zyga> I missunderstood
[12:31] <carlos> zyga, it takes some days since we detect a bug, we fix it and the fix is applied to our production server
[12:31] <carlos> zyga, you can just jump to next page and continue translating and leave those messages to do later
[12:32] <zyga> carlos: that's okay, I'm already translating other packages
[12:32] <carlos> ok
[12:32] <carlos> zyga, I will tell you when it's fixed from the bug report
[12:52] <koke> carlos: is this for you? --> http://lists.ubuntu.com/archives/ubuntu-translators/2005-August/000260.html
[12:53] <carlos> koke, no, jordi
[01:04] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=bjornt]  Product and Project vocabularies should not contain inactive entries. Bug#1873 (patch-2324: stuart.bishop@canonical.com)
[01:24] <zyga> hmm
[01:24] <zyga> the 'top contributors' weblet is useless :)
[01:25] <zyga> top people obviously contributed huge amounts of translations in some automated manner, porbably importing existing stuff
[01:25] <carlos> zyga, we are going to fix that
[01:25] <carlos> zyga, don't worry
[01:31] <zyga> will translations from hoary will automatically be suggested in the exactly same package for breezy?
[01:37] <zyga> [after rejoin]  will translations from hoary will automatically be suggested in the exactly same package for breezy?
[01:53] <carlos> stub, hi, around?
[01:53] <carlos> zyga, yes
[01:53] <carlos> zyga, and we are planning to apply new translations automatically across all Ubuntu distros so you don't need to do that manually
[01:56] <stub> yo
[01:56] <carlos> stub, just sent you an email
[01:57] <carlos> I need your db admin powers :-P
[01:59] <stub> carlos: That will update 23 records.
[02:00] <carlos> stub, ok, go ahead. Thank you
[02:00] <stub> carlos: Should there be only 1 iscurrent entry per productseries?
[02:01] <carlos> stub, hmm not now
[02:01] <carlos> stub, I suppose it would be that way in the future
[02:01] <carlos> stub, we are using it only for distro translations
[02:03] <stub> launchpad_prod=# select count(*),productseries from potemplate where productseries is not null and iscurrent=true group by productseries having count(*) > 1;
[02:03] <stub>  count | productseries
[02:03] <stub> -------+---------------
[02:03] <stub>      4 |          3964
[02:03] <stub>      6 |          4219
[02:03] <stub>      2 |          4199
[02:03] <stub> I'll run the query - we already have some duds to repair if that is the case :-(
[02:05] <carlos> stub, in this case, it's not a problem at all as that field was not useful until last week production update
[02:05] <carlos> we started using it at that point but I assume that all rows had the iscurrent field set to true
[02:05] <stub> carlos: no - just checking that that query isn't going to break something else
[02:06] <carlos> ok
[02:06] <stub> Done.
[02:06] <stub> launchpad_prod=# select count(*),productseries from potemplate where productseries is not null and iscurrent=true group by productseries having count(*) > 1;
[02:06] <stub>  count | productseries
[02:06] <stub> -------+---------------
[02:06] <stub>      4 |          3964
[02:06] <stub>      6 |          4219
[02:06] <stub>      2 |          4199
[02:06] <stub>      6 |           178
[02:06] <stub> (4 rows)
[02:06] <stub> Only one more dud to repair.
[02:53] <zyga> who approves translations?
[02:55] <zyga> I've just commited about 1K of polish translations for gcc-4.0 breezy, and all of a sudden about 700 of them became approved
[02:55] <zyga> gcc had no polish translation before
[03:04] <bradb> morning
[03:06] <kiko> morning bradb 
[03:06] <kiko> how's that bike?
[03:06] <bradb> hey kiko, it's all good. my gf just brought hers into town (from her parents place, who live out of town.) it's at my place, so that she can take it to a shop in the neighbourhood for tuning up.
[03:07] <bradb> picked up a hydrapak the other day
[03:31] <kiko> sed -e 's/foo/bar' x.txt
[03:32] <mpt> actually, I probably more need awk here
[03:39] <mpt> yes!
[03:41] <mpt> ls -l lib/canonical/launchpad/templates/ | awk '{print "||`", $8, "`|| ? || ? || ? ||"}' > ~/template-wiki-table
[04:11] <mpt> kiko: Did you have any luck with the local travel agent? If not I'll e-mail Edward today
[04:11] <kiko> mpt, our agent is surefire, but I can ask nando to check
[04:12] <kiko> or better yet
[04:15] <mpt> kiko: because I have definite dates now
[04:16] <kiko> ah, good.
[04:17] <kiko> send me an email with the dates
[04:19] <kiko> mpt, why did you reduce the linktext on the add a comment to "log in"? 
[04:20] <kiko> it's a lot harder to click
[04:20] <mpt> what?
[04:20] <mpt> on bug reports?
[04:21] <mpt> I didn't touch that, as far as I can remember
[04:21] <kiko> hmm
[04:26] <bradb> https://launchpad.net/malone/bugs/1948
[04:27] <bradb> Reason #1948 for why, if a bit of code isn't tested, it's almost better for it to not exist (at least that way it won't be raising exceptions :P)
[04:29] <carlos> kiko, hi. I have a patch to add suggestions to multiline messages
[04:30] <jamesh> mpt: is the move of application menus from tabs to a portlet permanent?
[04:30] <carlos> kiko, but it uses "python:" in the pagetemplates, is that ok or should I add python methods and remove them when the pomsgsetview spec is implemented?
[04:31] <kiko> carlos, shold be okay.
[04:31] <mpt> jamesh: I hope not, but it's not my decision
[04:31] <carlos> kiko, ok
[04:32] <jamesh> mpt: okay.  The calendar pages looked a lot nicer with the app menus in tabs :)
[04:32] <mpt> yeah
[04:41] <bradb> mpt: Which bug icon should I use for wontfix?
[04:52] <carlos> what's going wrong with freenode today?
[04:53] <jamesh> they're probably making "improvements"
[04:55] <jamesh> http://freenode.net/news.shtml says they're rolling out changes to prevent unregistered users from using /msg
[04:55] <mpt> bradb: I'd like Wontfix to be removed from the Priority menu (as described in SimplifyingMalone). In the meantime, you could use the generic (grey) bug icon.
[04:58] <bradb> mpt: (yeah, me too) ok, thanks
[04:58] <carlos> jamesh, I hope they finish soon...
[05:53] <bradb> cprov: I mentioned in #launchpad that I had added an sp details portlet on my MaloneSearchResults branch. I guess you weren't around or something.
[05:54] <cprov> bradb: nice, is it working fine ? did something in my last commit damage it ?
[05:55] <bradb> cprov: Oh, maybe debonzi had added it on the branch you inherited from him. patch-2321 added a sourcepackage details portlet, coming from your archive.
[05:56] <cprov> bradb: yes, now I remember, it was asked by Mark in the br sprint, wasn't it ?
[05:57] <bradb> dunno. but it was to sabdfl that I noted on #launchpad that I had added it on my MSR branch.
[05:58] <cprov> bradb: is it much different of yours ? can't you simply merge your changes ?
[05:58] <bradb> cprov: I'm taking the one from your branch, because it contains useful data that mine didn't have.
[06:00] <cprov> bradb: yup, we should avoid do the same job twice in the future, sorry for that, we should coordinate it better, it's in part (or entirely) my fault. 
[06:02] <bradb> no worries, it was relatively minor, and the portlet on your branch provided extra (useful) details ;)
[06:08] <cprov> bradb:  I'm glad to help ... leaving with dsilvers, see you 
[06:08] <bradb> cheers
[06:09] <bradb> salgado: Might you have some time to review portlet mania, the finale today?
[06:22] <salgado> bradb, sorry, dude. I don't think I'll have time for it.
[06:22] <bradb> ok, no worries
[06:22] <salgado> bradb, I'll have a lot of work to do on ShipItNG this week, so I think it'd be better to move it to someone else's queue
[06:23] <bradb> ok
[06:24] <bradb> kiko-fud: The "General Queue" on the PendingReviews page seems to experience some serious bitrot. Do we need a "General Queue"?
[07:18] <zyga> hello
[07:18] <zyga> I'm reviewing polish translations and I've noticed massive corruptions 
[07:18] <zyga> it looks like latin2 was misinterpreted as utf8
[07:19] <zyga> as a result many translations are broken
[07:28] <siretart> hi
[07:29] <siretart> is it somehow possible to let launchpad list all open bugs that have been assigned to a team I'm a member of?
[07:31] <siretart> ah, ignore me. I am too blind to see the link. sorry
[07:31] <zyga> :)
[07:38] <kiko> bradb-lunch, I didn't understand your question?
[07:42] <zyga> anyone from the devel team?
[08:30] <jordi> zyga: really? can you show an example of this?
[08:35] <carlos> zyga, could you point us to any URL that shows that problem so we can check the original .po file ?
[08:48] <bradb> kiko: There's a "General Queue" on the PendingReviews page. It seems that review requests that go in there tend to get ignored. For example, there's branches in there from 11 days ago. Is there any reason why we need the "General Queue"?
[08:49] <kiko> let me answer that later
[08:49] <zyga> jordi: sure, gksu packages I've just fixed
[08:49] <zyga> carlos: I'll try
[08:49] <zyga> but It seems that the problem originated from broken encoding string in the po itself
[08:50] <zyga> the files IMHO were utf8 but were tagged as latin2
[08:50] <jordi> zyga: aww
[08:51] <carlos> zyga, that's not a Rosetta bug then, it needs manual fix...
[08:51] <carlos> uploading again those .po files with the right encoding
[08:51] <zyga> (I'm not sure though)
[08:52] <zyga> I'm still waiting for the import to happen I've fixed all bugs in gksu, libgksu and libgksuui 
[08:52] <bradb> BjornT: Will you have a chance to response to my MSR followup in the next little while?
[08:52] <zyga> https://launchpad.net/distros/ubuntu/breezy/+sources/libgksu1.2/+pots/libgksu1.2/pl/+translate
[08:52] <zyga> check this out
[08:52] <zyga> look at third string
[08:52] <zyga> the suggestion is totally corrupted
[08:53] <zyga> this is just an example, if someone can send me the all the .po files gzipped I could verify them quickly
[08:53] <carlos> zyga, could you check it with the contents of the source package?
[08:53] <zyga> carlos: apt-get source?
[08:53] <carlos> zyga, yes
[08:53] <zyga> I'm running hoary :/
[08:54] <zyga> I'll change to breezy for a moment and revert back
[08:54] <zyga> just a moment
[08:54] <carlos> zyga, ok,thank you
[08:58] <zyga> carlos: it's broken in the source package
[08:58] <zyga> check out gksu in breezy
[08:58] <zyga> po/pl.po
[08:58] <zyga> nothing there is corrupted (it's valid and perfect utf8) but the file is tagged as latin2
[08:58] <carlos> zyga, then I think you will need to fix one by one (and notify the maintainers)
[08:58] <zyga> it comes from a repository of gnomepl.org (I cooperate with that group from time to time)
[08:58] <zyga> gnomepl.org uses latin2 by default unfortunatly
[08:59] <jordi> zyga: you can find gksu's upstream on IRC, nickname kov, btw
[08:59] <carlos> zyga, but I don't understand why they mix that
[08:59] <jordi> zyga: all GTK2 po files have to be UTF-8
[08:59] <jordi> they should know that
[08:59] <zyga> carlos: they dont!
[08:59] <carlos> zyga, then?
[08:59] <zyga> they always use latin2 and the files are encoded correctly (well apart from not being utf8)
[09:00] <zyga> someone must have converted those files
[09:00] <zyga> and left the tag line intact
[09:00] <zyga> I'll ask again about getting all the .po files in one big package, downloading each one from rosetta is really tideous
[09:01] <zyga> I can upload them one by one
[09:01] <carlos> zyga, you can fix that problem using rosetta's export functionality?
[09:01] <zyga> I'll ask the group for support
[09:02] <zyga> carlos: yes: for I in packages; do rosetta-download-po $I; fix-po; rosetta-upload-po $I; done
[09:02] <zyga> bash-so-to-speak
[09:02] <carlos> zyga, the problem is that we don't have an easy way to do that kind of export
[09:02] <zyga> carlos: ah :/
[09:02] <carlos> zyga, but I suppose you can get that from breezy's language pack
[09:02] <zyga> maybe they could help me
[09:02] <zyga> hmm
[09:03] <zyga> good idea! :)
[09:03] <zyga> should I convert everything to UTF8 ?
[09:04] <carlos> I think so, yes
[09:04] <carlos> anyway, Rosetta will accept any encoding
[09:05] <zyga> I've written a bash script that does the conversion automatically
[09:05] <zyga> this should help :>
[09:05] <carlos> cool
[09:12] <bradb> kiko: Got a moment to discuss the canonical URL of a bug under the new URL scheme? It's really starting to be a bit of a blocker.
[09:15] <kiko> bradb, I liked the launchbag idea.
[09:16] <bradb> kiko: Cool. The other issue though is, for example, there's a portlet listing the dups of the current bug: where does each dup href link to?
[09:16] <kiko> I'd just take the simple way out and link to the same context.
[09:17] <bradb> ah, that's a fuurickin good idea actually
[09:17] <bradb> that's an amazingly good idea; why the heck didn't i think of that
[09:17] <mpt> same context if it exists, first context if it doesn't
[09:17] <bradb> mpt: same context all the time should be ok, no?
[09:17] <mpt> bradb: I'm not up to speed with what's supposed to happen when you visit a bug in a context for which it's not reported
[09:18] <mpt> do you get redirected to the first context?
[09:18] <mpt> or a 404?
[09:18] <mpt> or what?
[09:18] <bradb> IMHO, it should be basically the same in every way as if it were reported, except that it would have a button to say "Also exists in <this context>"
[09:18] <bradb> (or something like that)
[09:18] <bradb> s/it were reported/it were reported in that context/
[09:19] <mpt> I see
[09:19] <mpt> We're going to need an indexing strategy for that
[09:19] <mpt> otherwise Googlebot will realize we have 10000 bug reports * 10000 contexts and say "fugeddaboudit, I'm not indexing that many pages"
[09:20] <bradb> We could nofollow those pages
[09:20] <mpt> noindex, yes.
[09:21] <mpt> <meta name="robots" content="noindex /> in the head slot
[09:21] <mpt> +"
[09:21] <bradb> Whatever works for you
[09:26] <bradb> kiko: I will note though that it's not quite the "simple" way it. Simple to create the link, but it'll take extra time to make that link actually work (though, still, I think it's by far the most sensible way to do the linking, because jumping randomly from one context to another would be very bad, IMHO.)
[09:26] <kiko> bradb, I don't understand what you mean? all contexts should have all bugs.
[09:27] <bradb> kiko: It'll be like a "ghost" context. The context of the bug page is (in my branch, anyway) an IBugTask. except, in this case, there may not actually be a "real" IBugTask at the URL /products/foo/+bugs/1
[09:27] <kiko> mpt, I doubt googlebot would give up indexing, though.
[09:27] <kiko> bradb, why did you change the context to be an IBugTask, btw?
[09:27] <kiko> I guess there's no other sensible way to do this, is there?
[09:28] <kiko> well, you /could/ use bug and then the launchbag...
[09:28] <mpt> kiko: Well, it wouldn't *give up*, we'd just get poorer coverage.
[09:28] <bradb> Not that I could think of. I couldn't see how to make it anything other than an IBugTask while still making that page contextually aware.
[09:28] <mpt> because some of its resources would be being spent on duplicates.
[09:28] <mpt> (duplicates in the page sense, not in the bug sense:-)
[09:28] <kiko> bradb, launchbag.
[09:28] <bradb> if the context is a bug though, a bug task was never traversed
[09:28] <kiko> mpt, the pages will be slightly different if we have our way.
[09:29] <mpt> kiko: Sure, but not enough, they'd fall under the "some pages very similar to these ones" label
[09:30] <bradb> hmph
[09:31] <bradb> SteveA: ping
[09:31] <kiko> bradb, that's how I thought it was going to work, at least...
[09:33] <bradb> kiko: This would involve also creating the request/launchbag: TALES adapter, right?
[09:33] <zyga> carlos: should I start uploading converted translations?
[09:33] <kiko> bradb, ideally, yes
[09:34] <carlos> zyga, if you are an official translator, yes, please
[09:34] <carlos> zyga, if you are not, you will need that someone do that for you
[09:34] <bradb> I *think*, at this moment, that is also implies some tricky in the traversal functions to stuff the task into the launchbag by hand (because it won't happen automatically, if, in fact, it hasn't actually been traversed, per se.)
[09:34] <zyga> carlos: official translator? 
[09:34] <zyga> carlos: I'm a member of my translation team, and an ubuntie
[09:34] <zyga> is that enough?
[09:35] <kiko> bradb, you don't need the task, do you? just the context
[09:35] <carlos> zyga, upload them as "published"
[09:35] <kiko> you can then just do a function on the context to get task by bug id
[09:35] <carlos> zyga, yeah, that's enough
[09:35] <zyga> BTW: what's a .poe file, they are in language-pack-pl package
[09:35] <carlos> .poe?
[09:35] <carlos> no idea
[09:35] <kiko> bradb, then you'd do context/bug_to_bugtask/233/
[09:35] <kiko> and that would be the task
[09:35] <zyga> they conatin everything that .po file has
[09:35] <kiko> anyway, that was my idea, bradb 
[09:35] <zyga> and seem to be utf8 already
[09:35] <kiko> SteveA to the rescue?
[09:35] <bradb> kiko: there could be more than one bug with that id in that context
[09:36] <bradb> i.e. more than one task with that bug id for that context
[09:36] <carlos> zyga, please, ask Martin Pitt about that (his nick is pitti)
[09:36] <zyga> carlos: ok
[09:38] <kiko> bradb, hmmm. return a sequence then?
[09:38] <bradb> perhaps, yeah
[09:39] <zyga> carlos: pitti is leaving today so that has to wait
[09:39] <zyga> carlos: why are language-pack-gnome-pl source packages empty?
[09:40] <carlos> zyga, no idea, pitti is on charge of those packages
[09:40] <zyga> right
[09:42] <bradb> kiko: I'm still not 100% sure that this is a simpler solution though. e.g. If the $url in question has an IBug as its context, what do you traverse to to render $url/+{view,edit}status?
[09:43] <bradb> if the context is an IBugTask, it's obvious. if the context is an IBug, it may be that the specific task information needed to do that is lost.
[09:44] <bradb> but maybe i'm missing something
[09:44] <kiko> bradb, well, you were the first one to say that you could have multiple bugtasks for the same bug and context.
[09:44] <kiko> I can't see how you are intending to traverse to +view/+edit directly...
[09:45] <bradb> yep, it's not exactly that unusual to have multiple packages affected by a bug, at least by my reading of recent USN's.
[09:45] <bradb> s/USN's/USNs/
[09:47] <bradb> ugh.../me tries to demushify brain for a second
[09:51] <bradb> kiko: e.g. you're looking at warty bugs at /distros/ubuntu/warty/+bugs
[09:51] <mpt> multiple packages != multiple tasks for the same context
[09:52] <mpt> packages + products = contexts, right?
[09:52] <bradb> mpt: it does mean ==, unfortunately
[09:52] <bradb> you're looking at warty bugs...
[09:52] <bradb> bug #42 could be filed on 3 warty packages
[09:52] <mpt> ok, that's a distro release package
[09:52] <bradb> the urls are warty specific, they don't drilldown into each package
[09:52] <mpt> "Ubuntu Warty Firefox"
[09:52] <kiko> bradb, I have no clue how you're going to deal with that
[09:53] <bradb> kiko: with IBugTask as the context it's trivial (it's that that that breaks a lot of other things :/)
[09:53] <kiko> bradb, how do you know which IBugTask to traverse to? bug id?
[09:53] <kiko> err task id?
[09:55] <bradb> have to use the task id, AFICT
[09:55] <bradb> well, first, presumably drilling down in sp context from the distro release listing is a Bad Thing, right?
[09:59] <bradb> mm, admittedly, i doesn't necessarily have to be a bad thing, since sp-specific URLs can still show useful DR context, where applicable
[09:59] <bradb> s/i/it/
[10:08] <carlos> see you
[10:29] <kiko> bradb, I think exposing task IDs is crack
[10:29] <kiko> but whatever
[10:29] <bradb> kiko: So do I; that won't happen.
[10:29] <bradb> (I've already gone through hell once to make sure that doesn't happen anymore.)
[10:29] <kiko> it wouldn't be a problem if our URLs were obfuscated, but since they're readable, it's ironically evil
[10:31] <bradb> kiko: Should links from the DR bug listing point to sp bug URLs?
[10:31] <kiko> bradb, probably.
[10:32] <bradb> That would be a useful improvement. It seems as though that must be broken right now, but we haven't had enough data in there to notice (i.e. same bug tracked in two different packages.)
[11:16] <bradb> kiko: If you had an IUpstreamBugTask, filed on firefox, bug #42, what would you expect to be returned by canonical_url(upstream_firefox_task)?
[11:57] <HiddenWolf> Help. I want to file a bug, launchpad tells me to log in, so I do, then it tells me I'm already logged in. I go back, and it'll ask me to log in again.
[11:58] <HiddenWolf>  To log in, enter your e-mail address and Launchpad password.
[11:58] <kiko> HiddenWolf, really? did it ever work?
[11:59] <HiddenWolf> Typical, the moment i start bitching it works.
[12:01] <kiko> heh
[12:03] <bradb> kiko: what would the canonical url of a distro bug task (with an sp) be?
[12:03] <bradb> It appears that we don't have distro-wide sp bug URLs, and that the SourcePackage object doesn't even support that
[12:03] <kiko> that's correct
[12:04] <kiko> everything's in a distro release
[12:04] <kiko> but hey, you can be creating, and add source packages to distro releases :-)
[12:04] <kiko> err