[12:06] <sivang> daf: thanks for helping my karma raise :)
[12:33] <carlos> night
[12:48] <daf> kiko: pong
[12:48] <daf> sivang: what did I do? :)
[12:52] <sivang> daf: you confirmed almost all the bugs I had file against LP, and fixed them. It seems that this acknowledges that the bug report was good, and gives you more Karma :)
[12:58] <dooglus> can I list all the bugs I've raised?
[12:58] <Kamion> https://launchpad.net/people/YOURLAUNCHPADNAME/+reportedbugs
[12:58] <dooglus> ooh, thanks.
[12:59] <Kamion> (go to your personal page, -> Bugs -> Reported
[12:59] <Kamion> )
[12:59] <dooglus> does the 'advanced' button work for anyone?
[01:00] <Kamion> dooglus: a fix for that landed earlier today, so I'm guessing should be in the next update
[01:00] <dooglus> Kamion: OK.  (I'm taking about the 'advanced'button on https://launchpad.net/distros/ubuntu/+bugs for example)
[01:00] <Kamion> yeah
[01:01] <Kamion> 20:47 < dilys> Merge to devel/launchpad/: [trivial]  Fix bug 30690 ('Advanced...' button on bugs listing doesn't do anything) (r3179: Brad Bollenbach)
[01:01] <Ubugtu> malone bug 30690 in malone "'Advanced...' button on bugs listing doesn't do anything" [Normal,Fix committed]  http://launchpad.net/bugs/30690
[02:34] <looksaus> would it be appropriate for a non-software project to register in launchpad?
[02:36] <looksaus> I'm thinking of a velomobile project
[02:36] <looksaus> a velomobile is a bicycle-in-an-aerodynamic-shell
[03:17] <stub> looksaus: Launchpad is a system for helping develop software. If there are software components to the velomobile, then sure. If not it would be pointless.
[04:52] <codept> hola
[08:07] <fabbione> The reference for this error is OOPS-53D101. Please include it in your bug report or email.
[08:07] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/53D101
[08:07] <fabbione> (timeout accessing malone)
[08:36] <BjornT> fabbione: that timeout was probably caused by db contention or something. that page renders quite quickly for me now.
[08:37] <fabbione> ok
[08:43] <BjornT> stub: ping
[08:46] <SteveA> morning
[08:47] <BjornT> SteveA: good morning. could you take a final look at https://chinstrap.ubuntu.com/~dsilvers/paste/file1H9XgX.html and see if it looks ok? it's the patch for not rendering the page on redirects.
[08:49] <SteveA> +    def __call__(self):
[08:49] <SteveA> +        return NoRenderingOnRedirect.__call__(self)
[08:49] <SteveA> why?
[08:51] <SteveA> neither AddView nor EditView define a __call__ as far as i can see
[08:52] <SteveA> BjornT: maybe we should have an assert to ensure that update() is called only once?
[08:53] <SteveA> when returning an empty page, is would be a little better to return u''
[08:53] <SteveA> rather than ''
[08:53] <SteveA> I'd like to see a direct test of the __call__ logic in NoRenderingOnRedirect
[08:54] <SteveA> its behaviour depends on the result of response.getStatus(), and the presence or absence, and value of __page_attribute__
[08:54] <SteveA> it also calls update() before any of these
[08:55] <SteveA> this can be tested by using a minimal class that derives from NoRenderingOnRedirect and gives output to test these things
[08:55] <SteveA> and has __page_attribute__ and self.request.response set appropriately for testing the different combinations
[08:56] <SteveA> other than these comments, it is good to go
[08:57] <BjornT> SteveA: well, it doesn't work if i don't define __call__, NoRenderingOnRedirect.__call__ won't be called
[08:57] <SteveA> really?
[08:57] <SteveA> do you know why that is?
[08:58] <SteveA> if that is so, then the __call__ methods that appear to do nothing in particular need comments saying this.
[08:59] <BjornT> SteveA: no, no idea why that is. i'll add a comment about it.
[08:59] <SteveA> it should be an XXX comment, in fact
[08:59] <BjornT> ok
[09:00] <SteveA> i suspect something fishy in the zope3/zcml magic to generate view classes
[09:00] <SteveA> which i'd like to remove...
[09:00] <BjornT> SteveA: how do you want to assert that update() is called only once? it's called at least twice actually, once in __call__, and once from the template getting the status. it returns at once if it has been called before though.
[09:01] <SteveA> i see
[09:01] <SteveA> that's okay than
[09:01] <SteveA> um, then
[09:02] <BjornT> ok. i'll add a test and all the other changes you suggested
[09:03] <SteveA> great.  thanks.
[09:06] <SteveA> jamesh: ping
[09:06] <jamesh> SteveA: pong
[09:06] <SteveA> hi james
[09:07] <SteveA> can you provide some "ideal hours" estimates on the remaining tasks, for ddaa?
[09:07] <jamesh> okay
[09:07] <SteveA> these are meant to give just a rough idea of the complexity and size of the work
[09:11] <SteveA> mpt: is there a new Malone Simplifications I should look at?
[09:13] <SteveA> lifeless: ping?
[09:20] <mpt> SteveA, https://wiki.launchpad.canonical.com/MaloneSimplifications
[09:28] <stub> BjornT: pong
[09:32] <SteveA> stub: could you find out how many bugs have short descriptions that are not yet closed?
[09:32] <stub> closed == FIX_RELEASED?
[09:33] <SteveA> rejected or released or committed
[09:37] <stub> 754
[09:37] <stub> If we want to drop it, we can combine both the summary and description into the description
[09:38] <stub> oops.... wrong statuses.
[09:38] <stub> 422
[09:39] <stub> 422 bugs with short desriptions that are not whitespace or null and that are still open
[09:41] <BjornT> stub: i will send a merge request soon that will stop a lot of pages from rendering if they are being redirected. do you think it's worth cherrypicking it into production? it might improve performance, but i'm not sure.
[09:41] <SteveA> thanks stub
[09:42] <stub> BjornT: Scary patch or trivial patch?
[09:42] <stub> We won't know how much it helps until we roll it out
[09:44] <BjornT> stub: it's quite trivial, even though it's quite large since a lot of page tests were changed. you can look at it at https://chinstrap.ubuntu.com/~dsilvers/paste/file1H9XgX.html
[09:44] <BjornT> (minus the changes suggested by SteveA)
[09:46] <SteveA> stub: i reckon that provided all tests pass, and it merges okay into production, then it is as good as rolling it out later.  we won't get any more testing of it unless we get someone to manually do stuff on staging.
[09:46] <SteveA> i think this patch will help with some locking issues, because it minimizes the reads that are made during transactions that involve a write.  this ought to reduce the amount and duration of locks held.
[09:47] <stub> Yup Unless the developer is unsure, likely due to suppressed knowledge of missing test cases ;)
[09:47] <SteveA> mpt: i added some stats from stub to the spec
[09:48] <SteveA> There are 422 open bugs (that is, not rejected, fix committed or fix released) that have short descriptions.
[09:48] <BjornT> stub: i'm quite sure it won't break anything. i've even done some manual testing in a browser :)
[09:49] <mpt> SteveA, cool
[09:51] <SteveA> mpt: small point: "The Priority field doesn't suffer from the same problem, because it more obviously belongs to the assignee."
[09:51] <SteveA> actually, it belongs to the person who directs the assignee's work.  in many cases this is the assignee.  in many other cases, it is the client or manager or some such person.  
[09:52] <SteveA> not important for the spec, just thought i'd mention
[09:52] <SteveA> mpt: so, i think the spec reads very well now, and very thoroughly examines the issues.  there is an XXX left for the implementation of collecting weblinks into a box.
[09:53] <SteveA> i approve it.  i leave it up to kiko to decide what to do next.
[09:53] <stub> 'client or manager' is pushing it for open source development
[09:53] <stub> at least 'in many other cases'
[09:54] <mpt> SteveA, I mailed BjornT earlier asking him to fill in the XXX
[09:54] <mpt> SteveA, why wouldn't a client or manager assign a bug to the developer?
[09:55] <ddaa> mhh... when __file__ is a relative path, what is it relative to?
[09:55] <mpt> SteveA, oh, sorry, misread you
[09:55] <mpt> yes, you're right
[09:56] <SteveA> ddaa: cwd?
[09:56] <ddaa> SteveA: something like that, but what if the cwd has changed?
[09:56] <SteveA> mpt: this is important for some of the management views on projects and teams.
[09:56] <SteveA> ddaa: changing the CWD is evil.
[09:57] <ddaa> SteveA: test cases involving baz requires that
[09:57] <ddaa> bah, I can retrieve the original cwd...
[09:57] <ddaa> a bit ugly to have to introduce that coupling, that's all
[09:57] <SteveA> when does __file__ have a relative path?
[09:58] <SteveA> mpt: so, i think in the far-flung future, we might reintroduce Priority, perhaps...
[09:58] <ddaa> generally, I do not know. In that specific case it has one, and dunno why. I need to __file__ to find some test data that's stored in the same directory as the module.
[09:58] <SteveA> but more as a personal todo list kind of thing
[09:59] <mpt> A way to subvert what your manager thinks is important? :-)
[10:00] <SteveA>  here = os.path.dirname(os.path.realpath(__file__))
[10:00] <SteveA>     testsdir = os.path.abspath(
[10:00] <SteveA>             os.path.normpath(os.path.join(here, '..', 'doc'))
[10:00] <SteveA>             )
[10:00] <SteveA> 
[10:00] <SteveA> ddaa: that's from the doctest infrstructure of launchpad
[10:01] <ddaa> assumes to chdir
[10:01] <ddaa> it's okay, I know how to hack around the problem
[10:02] <mpt> ok, 10pm, time for sleep
[10:02] <ddaa> * assumes _no_ chdir
[10:04] <ddaa> mh... actually maybe that code does not absolutely need to change the cwd... too much work to find out
[10:05] <mpt> SteveA, next if you have time is <https://wiki.launchpad.canonical.com/FixingProjects>, please
[10:05] <SteveA> mpt: i shall be travelling all tomorrow.  is there anything you need from me before next week?
[10:08] <stub> __file__ has a relative path if it was found in a relative path (such as from '.' in your PYTHONPATH))
[10:09] <dilys> Merge to devel/launchpad/: [r=stevea]  stop pages using {Add,Edit,GeneralForm}View from rendering if they are being redirected. (r3180: Bjorn Tillenius)
[10:09] <SteveA> hurrah
[10:10] <stub> I'll shove that through (waiting for tests too run.... now I remember why I always get PQM to run them for me ;) )
[10:10] <ddaa> stub: okay, then also when the current module was run as script with a relative path as sys.argv[0] 
[10:11] <stub> ddaa: I think that would depend if you ran the script using 'python script.py' or './script.py', as the OS would probably send the full path to the interpreter
[10:11] <stub> in the latter form
[10:11] <ddaa> well, I did not specify how the script was run, but I actually run it as ./script.py
[10:12] <ddaa> so, that one is explained, but I'll leave the hack in because it's just too damn confusing
[10:12] <SteveA> stub: i think lifeless will be enabling a bunch more tests that were previously disabled
[10:12] <ddaa> stuff like cscvs, buildbot, etc...
[10:12] <stub> SteveA: better land this Z3.2 branch before that then :0
[10:13] <ddaa> bzrtools
[10:14] <daf> morning
[10:17] <lifeless> SteveA: pongish
 SteveA, ideally reviews of FixingProjects, MaloneSearch, and DuplicateBugHandling  <mpt> so I can fix whatever needs fixing in them
[10:27] <SteveA> mpt: probably won' t happen before next week
[10:27] <SteveA> i'll try to look at one of them
[10:30] <daf> stub: can you update me about what's happening wrt Retry exceptions?
[10:40] <daf> BjornT: hi
[10:42] <SteveA> daf: are we getting a lot of Retry exceptions?
[10:42] <daf> more than anything else
[10:43] <daf> 61 yesterday
[10:43] <SteveA> interesting
[10:44] <SteveA> maybe it needs a geometric back-off
[10:44] <daf> (ignoring the KeyErrors from the production update)
[10:49] <stub> daf: I was going to look at it after the Zope3.2 upgrade - it might be a Z3.0 bug for all I know.
[10:50] <daf> stub: ahh, I see
[10:50] <daf> stub: thanks
[10:51] <daf> SteveA: how is the Z3.2 change going?
[10:51] <stub> If someone else wants to wade through the publisher, they are welcome to btw :)
[10:51] <stub> daf: I'm doing that
[10:52] <stub> Slowly working though the test suite failures and fixing things.
[10:53] <SteveA> stub: i need to wade through it anyway later
[10:57] <BjornT> hi daf 
[11:02] <daf> BjornT: I have an interesting Malone oops
[11:02] <daf> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-21/B408
[11:04] <SteveA> daf: call?
[11:05] <Seveas> assigning bugs to people times oiy half the time today
[11:05] <Seveas> eg OOPS-53C161
[11:05] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/53C161
[11:06] <Seveas> if I try again immediately after a timeout it works
[11:06] <BjornT> daf: yeah, i know about that one. bug 31650
[11:06] <Ubugtu> malone bug 31650 in launchpad "OOPS When filing a bug on launchpad" [Normal,Confirmed]  http://launchpad.net/bugs/31650
[11:13] <stub> Seveas: Database queries that have been executed recently will execute much faster as the database rows they need will be in RAM. It indicates a page is borderline but still needs fixing.
[11:14] <Seveas> stub, I filed a bug about it
[11:15] <Seveas> (32438)
[11:29] <jblack> Anybody need bzr stuff before I count sheep?
[12:19] <SteveA> carlos: ping
[12:19] <carlos> SteveA: pong
[12:20] <SteveA> carlos: i want to set up a meeting with you, kiko, me and pitti in a couple of hours, when kiko is here
[12:20] <carlos> SteveA: skype?
[12:20] <SteveA> no, irc
[12:20] <carlos> ok
[12:20] <SteveA> will you be around then?
[12:20] <carlos> yes
[12:21] <SteveA> great
[12:21] <carlos> SteveA: what are we going to talk about?
[12:22] <SteveA> the plan for translation imports, what needs to happen when, who can help and that kind of thing
[12:22] <SteveA> when cprov and kiko arrive, we'll have an irc meeting
[12:25] <carlos> SteveA: ok
[12:39] <mpt> Is this going to be a giant march like the 1001 baz imports?
[12:44] <LarstiQ> ddaa: how are the bzr imports going?
[01:00] <cprov> morning guys
[01:03] <ddaa> LarstiQ: late
[01:03] <ddaa> working on it, if all goes well the first bit should be up in two weeks
[01:04] <ddaa> LarstiQ: the initial plan sorta blew up on the deadline, and I've been writing docs and plans ever since.
[01:04] <ddaa> now, the plan is finished, and I'm coding again
[01:06] <SteveA> hi cprov 
[01:07] <cprov> SteveA: hi
[01:07] <SteveA> i'd like to have a meeting with you, kiko, pitti and carlos, when kiko is here
[01:07] <SteveA> to go through the plan for translation imports
[01:07] <daf> SteveA: I found the problem that was preventing me from running the page tests
[01:07] <daf> SteveA: I have a patch
[01:07] <daf> https://chinstrap.ubuntu.com/~dsilvers/paste/fileDHUqHa.html
[01:08] <daf> the test runner was assuming that the module path only occurred in the working directory once
[01:08] <stub> well, the tests passed :-(
[01:09] <daf> right, but not on my machine
[01:09] <daf> because of the location of my source code in the filesystem
[01:09] <SteveA> daf: you can move the if statement elsewhere now
[01:09] <SteveA>          if not len(segments):
[01:09] <SteveA>              raise PageTestError('Test script dir %s not in packages %s' % 
[01:09] <SteveA>                                  (storydir_or_single_test, self._package))
[01:09] <SteveA> 
[01:09] <SteveA> if it is still pertinent
[01:09] <jbailey> launchpad homepage oops's.
[01:10] <SteveA> stub: ...
[01:10] <daf> ProgrammingError: ERROR: column "official_malone" does not exist SELECT id, domainname, bugcontact, translationgroup, owner, title, uploadsender, uploadadmin, lucilleconfig, displayname, description, translationpermission, official_malone, members, name, official_rosetta, summary FROM Distribution WHERE name = 'ubuntu'
[01:10] <daf> (from the front page oops)
[01:10] <daf> jbailey: thanks for telling us!
[01:11] <stub> yer - I'm looking at it. I screwed up the cherry pick
[01:11] <daf> SteveA: hmm, the test should still be made, but it should be made differently
[01:19] <SteveA> daf: also, add a comment above explaining what is happening and why in plain english
[01:19] <daf> yes, it needs it
[01:22] <SteveA> stub: looks like launchpad is back.  is it really back?
[01:23] <stub> yes. I can't cherry pick that patch either - conficts
[01:23] <SteveA> bjorn's one?
[01:23] <stub> yup
[01:24] <SteveA> ok.
[01:29] <daf> SteveA: https://chinstrap.ubuntu.com/~dsilvers/paste/fileNaeoWh.html
[01:29] <daf> it's a bit verbose, but I think it's clear
[01:29] <daf> oops, I left some debugging cruft in there
[01:30] <daf> hmm, actually, perhaps I can simplify the code
[01:32] <matsubara> good morning!
[01:32] <daf> bom dia!
[01:33] <matsubara> bom dia daf, como vai?
[01:33] <daf> todo bem
[01:34] <ddaa> shit, the progress reporting in baz-import-branch is a friggin mess
[01:40] <Kamion> ftpmaster operations seem to be hanging
[01:41] <Kamion> lp_archive@drescher:/tmp/cjwatson$ queue override evolution-scalix binary universe//
[01:41] <Kamion> says what it's going to override, and then hangs
[01:42] <cprov> Kamion: let me check, one sec
[01:42] <Kamion> thanks
[01:42] <daf> list could do with .startswith() and .endswith()
[01:43] <Kamion> wow. by creatively not paying *quite* enough attention while processing NEW, it's possible to end up with a binary in main on some architectures and in universe on others
[01:43] <daf> rather than having to do a[len(b):]  == b, etc
[01:43] <daf> Kamion: fun fun :)
[01:43] <Kamion> hoping change-override.py can sort it out once ftpmaster ops work again
[01:45] <cprov> Kamion: it works, what was hanging ? DB access ?
[01:46] <cprov> Kamion: it's already overridden ...
[01:46] <Kamion> ok, wasn't last time I tried, maybe it was just really slow
[01:46] <Kamion> I have no idea what was hanging
[01:46] <Kamion> the last line of output was:
[01:46] <Kamion>          | evolution-scalix/10.0.0.337-evo-2.6-0ubuntu1/powerpc Component: universe Section: gnome Priority: OPTIONAL
[01:46] <Kamion> and then nothing
[01:47] <Kamion> yeah, change-override.py seems to work now, maybe just a glitch
[01:47] <Kamion> thanks
[01:49] <cprov> Kamion: send me the traceback 
[01:49] <Kamion> there was no traceback
[01:49] <Kamion> if there had been a traceback, I would have said "I got a traceback" rather than "it hangs". It was hanging with no output.
[01:49] <Kamion> but it's not doing it any more, so I guess it was transient slowness
[01:52] <cprov> Kamion: .
[01:56] <daf> stub: while Zope 3.2 is in the works, do you think it might be worthwhile to add information about the queries concerned to the Retry exceptions?
[01:56] <daf> stub: or would it not be useful
[01:58] <stub> Its not that useful - it is just hiding serialization and deadlock database exceptions and they can happen more or less arbitrarily.
[01:59] <daf> I see
[01:59] <daf> then maybe we should reject the bug I opened about it
[02:02] <stub> worth doing in the long term. once the retry exceptions are being handled properly, we want to know wtf is going on if they ever make it to the end user
[02:02] <daf> ah, ok
[02:02] <daf> thanks for clarifying
[02:09] <dilys> Merge to devel/launchpad/: [r=SteveA]  batch the distribution all packages page (bug #5411) (r3181: Dafydd Harries)
[02:12] <daf> stub: Steve has suggested I get r3181 cherrypicked
[02:12] <daf> stub: could you see if the tests pass with it included?
[02:18] <carlos> SteveA: I'm leaving soon to have lunch, are we going to have the meeting soon or can we do it in a couple of hours?
[02:23] <SteveA> daf, stub... maybe we should wait
[02:31] <SteveA> carlos: we should have the meeting
[02:31] <carlos> kiko is the only one missing, right?
[02:31] <carlos> kiko: ?
[02:31] <SteveA> carlos, cprov : c-m
[02:32] <lifeless> night all
[02:40] <dilys> Merge to devel/launchpad/: [r=SteveA]  batch the distribution all packages page (bug #5411) (r3182)
[02:41] <daf> !
[02:43] <SteveA> stub: is there any legit reason to use / need librarian.ubuntu.com ?
[02:49] <SteveA> daf: the message you sent to me and spiv could have been sent to the list too
[02:49] <SteveA> err on the side of using the list
[02:50] <daf> I considered it before sending
[02:50] <daf> I thought that it would be noise for most
[02:50] <SteveA> adjust your filters for more noise
[02:50] <daf> but then again, there's already plenty of stuff on the list that I don't read
[02:53] <BjornT> daf: is the oops milestone only for web-ui oopses, or for system breakage in general? for example unexpected exceptions in the email interface.
[02:54] <SteveA> BjornT: I think such unhandled exceptions should cause an OOPS report to be generated, with a code-letter that indicates "email cron script"
[02:55] <SteveA> i had suggested using X[A-Z]  for this
[02:55] <SteveA> so an oops from the incoming email handler would be OOPS-54XE123
[02:55] <SteveA> and then we deal with them in the same way as other oopses
[02:55] <BjornT> yeah, that would be useful.
[02:55] <SteveA> so, from that point of view, these errors are morally oopses
[02:56] <SteveA> so errors about them should be on the oops milestone
[02:56] <BjornT> is it hard to do? or should i file a bug and assign it to jamesh?
[02:56] <SteveA> jamesh will be busy for a while, helping ddaa out
[02:56] <SteveA> so don't do that
[02:56] <SteveA> but maybe have a skype call with jamesh tomorrow morning (.lt time)
[02:56] <SteveA> and chat about how to do it.
[02:57] <kiko> meeting?
[02:57] <kiko> SteveA, carlos: ahoy?
[02:57] <BjornT> ok. i'll send him an email about it
[02:58] <ddaa> kiko: makes me think, how about bringing us some of your brazilian magic potion?
[02:58] <kiko> ddaa, which of the potions are you talking about?
[02:58] <ddaa> "cachassa" if that's the right way to spell it
[02:59] <kiko> aha
[02:59] <kiko> yes I can bring some
[02:59] <ddaa> well, brazil has no end of potent potions, but bringing a bunch of Guarana bottles by plane would probably be too much to ask :)
[03:00] <ddaa> so I'd rather ask about what packs the most punch in smallest weight
[03:00] <kiko> okay, leave it to me
[03:00] <ddaa> thank you sugar daddy!
[03:01] <matsubara> ddaa: cachaa
[03:09] <kiko> BjornT, rock and roll!
[03:09] <SteveA> salgado: i'm off to lunch, but in answer to your database question in that bug, yes, the updates will be queued.  probably need a flushupdates call in there.
[03:10] <SteveA> salgado: good thinking!
[03:10] <kiko> hey daf, want to look through oops and bugs with matsubara and I later today?
[03:10] <salgado> SteveA, any idea why that doesn't happen more often, then?
[03:12] <daf> kiko: sure
[03:12] <daf> kiko: when's good?
[03:15] <daf> BjornT, SteveA: agreed -- the "oops" milestone is for any crash that users are exposed to during normal operation
[03:15] <daf> as Steve says, we're moving towards using OOPS reports for non-web crashes
[03:16] <kiko> phone 1m
[03:21] <kiko> daf, in 30 minutes?
[03:22] <daf> fine
[03:23] <ohoel> is there any place I can read up on how translations in rosetta are synched with gnome proper?
[03:23] <daf> hi ohoel 
[03:23] <daf> we don't have such a docment, I think
[03:23] <ohoel> hello :)
[03:23] <daf> currently, it's up to GTP language coordinators to arrange whether to synchronise between Launchpad and GNOME CVS
[03:24] <ohoel> I'm working hard to push my locale to 100% in gnome cvs, but I've seen some regressions in packages that appear in the ubuntu repos
[03:24] <daf> ah, right
[03:24] <ohoel> hmm, I'll have to have a chat with kmaraas then
[03:24] <daf> no, wait
[03:24] <daf> Launchpad -> GNOME is up to GTP coordinators
[03:24] <daf> but GNOME -> Launchpad is done by us
[03:25] <daf> currently, Launchpad is not up to date
[03:25] <daf> we will be importing updated translations shortly
[03:25] <ohoel> how are mismatching strings handled? do mismatching strings end up as fuzzy or do gnome strings get prioritized?
[03:25] <daf> good question
[03:26] <kiko> can this be added to a FAQ?
[03:26] <ohoel> I've been thinking about this ever since I got my cvs account, and it's been ruining my sleep :P
[03:26] <daf> https://wiki.ubuntu.com/RosettaFAQ
[03:26] <kiko> pulease!
[03:27] <daf> I don't think that answers the question about priority
[03:27] <daf> carlos will be able to answer that
[03:28] <carlos> strings from Rosetta have always preference
[03:28] <ohoel> ouch
[03:28] <carlos> ohoel: if we have something Ubuntu specific and you change it upstream
[03:29] <carlos> we should not change it in our Ubuntu version
[03:29] <carlos> or our translators will not be happy
[03:29] <ohoel> yeah, ubuntu specific as in not upstream iis ofcourse good, but the same string translated in both rosetta and upstream
[03:30] <ohoel> if that doesnt get updated automatically in rosetta, I have a lot of work to do the next month ;)
[03:30] <carlos> ohoel: there are some situations where Ubuntu translators want to unify terms and they would be different from upstream
[03:30] <ohoel> yeah, tough nut to crack
[03:30] <daf> carlos: is it easy to see "this file has X translations different to upstream"?
[03:30] <carlos> ohoel: they are added as suggestions and as soon as our review interface is done that will be really easy for you
[03:30] <carlos> daf: not atm
[03:30] <ohoel> all sources are handled the same? ie gnome, obscure packages in universe, kde?
[03:30] <daf> carlos: I think that would be a really nice feature
[03:31] <daf> carlos: also, if you could filter by "different from upstream"
[03:31] <carlos> ohoel: I'm talking about Ubuntu translations
[03:31] <carlos> ohoel: if you want to translate directly for upstream you don't have this problem, you see ubuntu's translations as suggestions
[03:31] <carlos> ohoel: but only upstream translations and your changes from the web will be used
[03:32] <carlos> daf: yeah, sounds good. Please, file bugs so we don't forget them
[03:36] <daf> carlos: https://launchpad.net/products/rosetta/+bug/32471
[03:36] <Ubugtu> malone bug 32471 in rosetta "display differences from upstream" [Wishlist,Unconfirmed]  
[03:36] <daf> carlos: can the FAQ explain which translations take priority?
[03:38] <ohoel> that's the 6th time I press ctrl-alt-backspace while typing on irc today
[03:38] <kiko> stub, daf: anyone know why we updated production today, and to what revision?
[03:38] <ohoel> xgl isn't particulary fond of it either
[03:38] <daf> kiko: we updated production?
[03:38] <daf> ohoel: oops -- you can turn that off, I think
[03:40] <ohoel> carlos: Say I translate something in gnome cvs which dapper later synchs - then someone changes a string in rosetta, which I later change/fix in gnome cvs.  Later dapper decides to synch with gnome again, and my updated string is imported into rosetta. Will my cvs string be the actual translation for dapper with the "rosetta-edited" string as a suggestion, or the other way around?
[03:41] <ohoel> you might need to read that heavy brick of a modernistic question thrice, sorry ;)
[03:41] <kiko> daf, it appears so -- the errors mail I got suggests it.
[03:41] <carlos> daf: sure, I gave already that answer to Jordi and he's supposed to add it. I will ask him to do it
[03:41] <kiko> stub?
[03:41] <ohoel> daf; know where? ;)
[03:41] <carlos> jordi: ?
[03:43] <carlos> ohoel: the other way around
[03:43] <carlos> talking about Ubuntu translations
[03:43] <carlos> well, and talking also about handling GNOME translations directly with Rosetta
[03:44] <carlos> the only difference is that the changes done for Ubuntu will not change the translations for GNOME upstream
[03:45] <daf> ohoel: http://cbenz.tuxfamily.org/index.php?n=Xorg.Conf -- see the "DontZap" part
[03:45] <carlos> they will be translated on two different URLs and both will see each other but, unless the translator has rights for both, the changes to one of them will appear as suggestions for the other
[03:45] <cprov> carlos: did you have lunch ?
[03:45] <carlos> cprov: not yet :-(
[03:45] <daf> ohoel: even better -- here's the manual: http://wiki.x.org/X11R6.8.0/doc/xorg.conf.5.html
[03:45] <carlos> cprov: I'm preparing it now
[03:46] <cprov> carlos: ehe I need to have mine, in 30 min, I'll try to fix the dogfood chroot before leaving
[03:46] <ohoel> daf: cheers :)
[03:48] <carlos> cprov: I'm around, I'm not 100% available but If you want we can start with the tests before you leave (or leave it for later)
[03:48] <ohoel> carlos: that clears it up, thanks :) 
[03:49] <ohoel> wish it was the other way around for non-ubuntu-specific strings, but there's no real way of telling what's what :/
[03:50] <carlos> ohoel: we are going to improve the review interface so merging translations between branches is as easy as possible
[03:51] <ohoel> ie, list the different versions (including original gnome pofile and rosetta branches), "click shiny button to use this string instead" ?
[03:51] <ohoel> that'd seriously rock :)
[03:52] <kiko> matsubara, daf, is it time?
[03:53] <cprov> carlos: leave it for after lunch, I need to restore dogfood DB and it takes 30 min, will have lunch during the process
[03:54] <matsubara> kiko: ok
[03:54] <daf> kiko: sure -- where do you want us?
[03:55] <kiko> matsubara, daf: #canonical-meeting2 ?
[03:56] <matsubara> kiko: i'm there
[03:56] <daf> canonical meeting 2: agenda's revenge
[03:58] <bradb> jamesh: ping
[03:58] <carlos> cprov-lunch: ok
[04:11] <Xof> OOPS-53C324
[04:11] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/53C324
[04:11] <kiko> Xof, one moment
[04:12] <Xof> Oh, I can't see what's at that URL anyway
[04:12] <kiko> Xof, it's a known problem
[04:12] <kiko> it'll be fixed by next tuesday
[04:12] <kiko> sorry for the inconvenience
[04:12] <Xof> thank you
[04:13] <kiko> enjoy
[04:13] <Xof> (there's a rant brewing, but it's probably not entirely fair to you guys, so I will refrain)
[04:13] <kiko> aieee
[04:13] <kiko> don't we all have our rants
[04:22] <Xof> ok, well, thank you anyway
[04:22] <kiko> Xof, feel free to complain, jokes aside
[04:23] <Xof> you don't want to say that
[04:23] <kiko> salgado, what are the main vocabulary timeout bugs, do you know?
[04:23] <kiko> Xof, maybe I don't :-)
[04:25] <salgado> kiko, the bug numbers?
[04:25] <kiko> yeah
[04:25] <Xof> my basic complaint about the ubuntu setup as it stands is my perception of basic (but technical) users not being taken seriously.  Even when said users are also upstream for some things which ubuntu distributes
[04:26] <kiko> Xof, that's an #ubuntu issue, not #launchpad :)
[04:26] <Xof> oh, you want launchpad specifics?  Why do I have to create an account to report a bug?
[04:27] <Xof> (divide and conquer!  good debating trick, kiko ;-)
[04:27] <kiko> Xof, most bug trackers work that way. it's done for a few reasons 
[04:27] <kiko> - it makes it easy to contact the original reporter and give him better support and feedback
[04:28] <kiko> - it reduces the risk of people spamming bugs with comments
[04:28] <Xof> sure, there are tradeoffs.  You managed to get me off the main rant
[04:28] <kiko> - account creation is a trivial step
[04:28] <kiko> :)
[04:28] <daf> wow, that reads like a FAQ entry
[04:28] <daf> ;)
[04:29] <kiko> I'm adding it as we speak
[04:29] <daf> faqtastic
[04:29] <Xof> can you also add the sentence "we consider these to outweigh ease of use to those who do not consider account creation a trivial step"?
[04:30] <kiko> Xof, now you're being mean to a poor brazilian
[04:30] <Xof> well, yeah.  I did tell you that you didn't want to say that I was to feel free to complain
[04:31] <kiko> creating an account is done once in your lifetime. it is as hard as, say, flossing. :)
[04:32] <kiko> we won't spam you or give your address out 
[04:32] <Xof> for my reporting of ubuntu bugs it's done at least twice
[04:32] <Xof> over the period of a year
[04:32] <Xof> that's already once more than what I consider my absolute maximum
[04:32] <kiko> well, we moved bugtrackers.
[04:33] <kiko> it won't ever happen again, though
[04:33] <Xof> I know the reason.  I don't happen to consider it a good one
[04:33] <LarstiQ> mja
[04:34] <Xof> I should stop being mean
[04:35] <Xof> well, that's nice, but both as a reporter and a receiver of bug reports I have found that the advantages of the open system outweigh the disadvantages.  YM obviously V.
[04:36] <Xof> just don't expect me to be happy about it :-)
[04:36] <kiko> it's not like we don't get enough bug reports as it is mind you :-)
[04:36] <LarstiQ> Xof: MM indeed V
[04:36] <Xof> you may never get the patches from those who would submit them if there were an easy way to do so
[04:37] <kiko> I am not sure that is not just flagwaving
[04:37] <LarstiQ> can one register a branch without an account? probably not
[04:37] <Xof> I appreciate that we're talking different markets of bug reporters, though
[04:37] <LarstiQ> kiko: there are people who do not want to use malone and instead report bugs on #bzr
[04:37] <kiko> that's fine
[04:37] <LarstiQ> or the list for that matter
[04:37] <kiko> their bugs will go unfixed, or others will report it for them
[04:38] <Xof> those reporting bugs in desktop environments are probably not going to be as focussed as those reporting bugs in, say, language runtimes
[04:38] <kiko> if it's serious enough, something will happen
[04:38] <kiko> Xof, you're right there.
[04:38] <bradb> ISTR that craigslist allows anonymous posting, but requires email address confirmation before a post is published.
[04:39] <LarstiQ> Xof: and the debian bts is fine for keeping the markets seperate too, but with gforge I get a lot of crappy reports with no way to contact the submitter
[04:40] <Xof> if you're not careful you'll start the rant again
[04:40] <kiko> Xof, the volume of reports we get is very high. maybe that's a reasonable explanation for the policy decision.
[04:43] <Xof> Oh, most of these explanations have been reasonable.  (Some have also been somewhat misanthropic.)  I consider you to be optimizing for the wrong things, but it's not my call.  However, I hope it explains my perception that I stated up front.
[04:43] <Xof> daf: where's near, then?
[04:43] <daf> Cambridge
[04:43] <Xof> daf: we've probably met at parties
[04:44] <daf> Xof: quite possibly
[04:44] <Xof> daf: if we've met at parties, mjg59 doesn't want to kill you.  If that's the case, you have nothing to fear from me.
[04:45] <daf> ha, I live with mjg59
[04:45] <Xof> then I met you just before Christmas
[04:45] <daf> I'm sure I'd recognise you if I met you again
[04:46] <daf> oh, we were discussing CLOS?
[04:46] <Xof> quite possibly
[04:46] <Xof> do I owe you a paper reference?  I mailed fanf some
[04:46] <Xof> http://citeseer.ist.psu.edu/kiczales90efficient.html
[04:47] <Xof> LarstiQ: OK, in a nutshell: among the people you keep out by not making bug reporting maximally convenient are those who will give you good reports
[04:49] <carlos> cprov-lunch: Ping me when you are ready, please
[04:49] <LarstiQ> Xof: true
[04:51] <kiko> statistically, of course
[04:52] <Kamion> LarstiQ's two examples are interesting because one is e-mail reporting and the other is web reporting
[04:52] <Xof> in a slightly larger nutshell, and this has been repeated in approximately every interaction I've had with ubuntu where I wasn't known personally to the other end: the presumption is that the interlocutor is not competent, and filtering done on that basis.
[04:52] <Kamion> which I'm fairly sure explains the difference in quality of reports
[04:53] <Kamion> the bar is higher to those not in the habit of producing good reports, and lower to those in the habit of producing good reports
[04:53] <atie> hi
[04:53] <Xof> (I consider myself lucky to have an inside channel or two; woe betide those who do as the book says and go to #ubuntu for their community technical support)
[04:53] <Kamion> again that's slightly misanthropic, but hey
[04:53] <LarstiQ> Kamion: that was my thought too
[04:54] <Xof> I don't mind misanthropy when it's based in evidence ;-)
[04:54] <Kamion> I wouldn't like to say evidence, but anecdotes at least
[04:54] <Xof> yeah
[04:54] <Kamion> realising that the plural of anecdote is not data
[04:54] <Xof> it is in computer science
[04:54] <Kamion> :-)
[04:55] <Kamion> #ubuntu has been rendered pretty bitter by experience I think
[04:55] <LarstiQ> it's been a while since I visited #ubuntu, is it like #debian now?
[04:55] <daf> atie: hi
[04:55] <Xof> most places with an established community will forge intra-community links which tend to rebuff outsiders, on IRC as off it
[04:56] <Xof> however, the frustration I have with #ubuntu as a regular user is that my questions were, I suspect, too hard.
[04:56] <atie> daf, hi
[04:56] <Xof> that may be maligning the participants; they might instead have been too boring
[04:56] <Xof> but whatever the reason, they go unanswered.
[04:58] <daf> cprov: can you tell me if there's any news on https://launchpad.net/products/launchpad/+bug/5390?
[04:58] <Ubugtu> malone bug 5390 in launchpad "DistroArchReleaseBinaryPackageRelease index template assumes it has a PUBLISHED record" [Normal,Confirmed]  
[04:58] <Kamion> it's true that we do those who fall between the stools of "basic non-technical users" and "developers who can read the source themselves" something of a disservice
[04:58] <Kamion> I'm not sure what can be done, unfortunately; #ubuntu-devel's S:N ratio needs to be kept as high as possible, and throwing it open for questions sort of defeats that
[05:00] <Xof> well, enlisting them for MOTU and giving them a playground probably helps (at least in the short term) if that is what they want to do
[05:00] <cprov> daf: no news, actually first time I read that
[05:00] <kiko> cprov, no worries, I'll look into it
[05:00] <jbailey> Xof: The best I can suggest is that in many of those cases, it would be nice to have questions go into the support tracker.  Mid range technical users would probably (IMO) give  us the best usability feedback.
[05:01] <Xof> but, as with debian, it's those who don't want to be packagers who seem to fall through the cracks
[05:01] <jbailey> Xof: Building a community around things in the support tracker is going to take us quite a while, though.
[05:01] <Xof> oo, you're getting close to rant territory again
[05:02] <cprov> kiko: daf: okay, IMO, DARBPR publisher once mean status in PUBLISHED, SUPERSEDED, PENDINGREMOVAL ; so the template and the should be aware and use something else then current_published
[05:03] <kiko> yeah, correct
[05:03] <daf> cprov: sounds good -- just asking about it because kiko brought it up
[05:03] <kiko> yeah
[05:03] <kiko> bradb, BjornT: can you tell me if https://launchpad.net/malone/bugs/6010 is a dupe?
[05:04] <Ubugtu> malone bug 6010 in malone "error when putting non-number into bug number field: OOPS-B192" [Normal,Confirmed]  
[05:04] <cprov> daf: it's already time to sort it out (2005-12-05)
[05:05] <daf> cprov: well, yeah, but I know you have a lot to do right now
[05:06] <kiko> I can do it
[05:06] <kiko> no worries
[05:06] <cprov> good good
[05:06] <bradb> kiko: Hm, I can't find a dupe of that bug.
[05:06] <kiko> bradb, okay, no worries
[05:06] <kiko> I'll look into it
[05:07] <BjornT> kiko: well it's basically the same as bug 1160
[05:07] <Ubugtu> malone bug 1160 in malone "Malone's bug not found (for /bugs/321421412121) doesn't say anything useful." [Minor,Confirmed]  http://launchpad.net/bugs/1160
[05:08] <kiko> BjornT, I'm not sure, because the redirect seems broken
[05:08] <bradb> I think they're somewhat different
[05:08] <kiko> right
[05:08] <kiko> the latter is a bit of a wishlist IMO
[05:09] <SteveA> matsubara: hello
[05:09] <BjornT> yeah, that's why i said basically
[05:09] <kiko> hey SteveA 
[05:09] <kiko> matsubara and daf are busy with me in #canonical-meeting2
[05:09] <SteveA> matsubara: there's someone asking for launchpad support, to change their wiki name, on the sounder list.  maybe you can help them out?
[05:09] <SteveA> ah, okay
[05:09] <kiko> SteveA, forward the email to him
[05:10] <SteveA> ok
[05:10] <kiko> and thank you for your diligence
[05:10] <matsubara> hi SteveA, sure, just forward the email and I'll take a look asap
[05:10] <BjornT> actually, the redirect bug is only mention as 'note double "bugs"'
[05:16] <salgado> SteveA, have you seen my question (here on IRC) right after you left for lunch?
[05:16] <SteveA> salgado: it's best to assume not
[05:16] <SteveA> although i did just look
[05:16] <kiko> SteveA, I /msged it to you
[05:16] <SteveA> i don't know why this would in fact work
[05:17] <kiko> aha
[05:17] <SteveA> i mean, i don't know how the code works right now, practically speaking
[05:17] <SteveA> maybe you're by chance hitting some sqlobject cache sometimes
[05:17] <SteveA> i don't know
[05:17] <SteveA> i don't have time today to analyze it in the debugger
[05:21] <salgado> I'd like to analyze it when I get to work on shipit for dapper. should I do the quick fix now (add the flush_database_updates call) or should I wait to properly fix it when I have time?
[05:21] <salgado> I think that if I fix it quickly now it'll be forgotten and we won't know what the real cause was
[05:21] <SteveA> i think fix it now, and leave an XXX in there with a bug number
[05:29] <salgado> right, I'll do this
[05:41] <seb128> carlos: around?
[05:42] <seb128> carlos: is dapper already imported to rosetta?
[05:47] <carlos> seb128: hi
[05:47] <carlos> seb128: not yet
[05:47] <carlos> seb128: we had a meeting about it today
[05:47] <seb128> carlos: any idea of when?
[05:47] <carlos> we are going to test the infrastructure today and I hope at the end of this week we will have most of it imported
[05:48] <carlos> (talking about main)
[05:48] <seb128> cool, thank you
[05:48] <carlos> you are welcome
[05:55] <carlos> cprov: hi, how is going? we have only one hour for the meeting to talk about the tests
[05:55] <carlos> cprov: is there anything  I can do to help you? Can we start the tests?
[05:56] <cprov> carlos: building stuff in dogfood, see the new builds via web UI. None of them have translations, but I can see the pkgstriptrans acting via buildlog
[05:57] <cprov> carlos: you're welcome to help me to inspect them
[05:57] <carlos> cprov: which packages are you building?
[05:57] <carlos> cprov: did you try the ones I provide you?
[05:57] <carlos> cprov: there are some packages without translations. Could be that you are building those kind of packages....
[05:57] <cprov> carlos: yes, they don't translations
[05:57] <carlos> hmmm
[05:58] <cprov> carlos: look at mawson
[05:58] <carlos> cprov: URL? or path?
[06:00] <cprov> carlos: dude, it's launchpad ;) start at https://dogfood.ubuntu.com/+builds/dogfood-builder-2, see the buildlist
[06:00] <carlos> cprov: I don't know how soyuz works.... O:-)
[06:01] <carlos> cprov: the translation import queue is empty so it's not importing anything for sure
[06:01] <cprov> carlos: are you sure about the version of pkgstriptrans you gave me ?
[06:02] <carlos> cprov: it's what pitti gave me
[06:02] <cprov> carlos: read the log, check the changesfile content, the translation isn't specified
[06:02] <carlos> let's ping pitti
[06:02] <cprov> carlos: yup
[06:02] <pitti> hi
[06:02] <carlos> pitti: hi
[06:03] <carlos> pitti: seems like the .changes file is not updated with the pkgstriptranslations version you gave us last week
[06:03] <carlos> pitti: http://librarian.dogfood.ubuntu.com/1566980/buildlog_ubuntu-dapper-i386.pmount_0.9.7-2ubuntu2_FULLYBUILT.txt.gz
[06:03] <carlos> pitti: it shows that the translations are extracted but the .changes file does not include the tarball
[06:03] <cprov> pitti: looks like the old style pkgstriptrans
[06:03] <carlos> cprov: which version did you installed?
[06:03] <cprov> carlos: 22
[06:04] <carlos> that's what it's at http://people.ubuntu.com/~pitti/packages/
[06:04] <carlos> pitti: could you check if that's the right version?
[06:04] <pitti> btw, please note that a different version 22 is already in the archive now
[06:05] <pitti> are you sure that didn't get overwritten accidentially?
[06:05] <carlos> cprov: ?
[06:05] <cprov> carlos: let me see
[06:05] <pitti> cprov: yep, confirmed, the deb on p.u.c is right
[06:07] <cprov> pitti: I have 22 installed, possibly anything in /etc/pkgstriptranslation.conf ?
[06:08] <pitti> cprov: grep distaddfile /usr/bin/pkgstriptranslations
[06:08] <cprov> cprov@ferraz:~$ grep distaddfile /usr/bin/pkgstriptranslations
[06:08] <cprov>         dpkg-distaddfile "$tarball" raw-translations -
[06:08] <pitti> so that's how it should be, hm
[06:10] <cprov> pitti: have you seen the respective 2 lines in the buildlog. can you recognize what is going on ?
[06:12] <pitti> cprov: yes, I saw it, looks pretty good
[06:12] <cprov> pitti: it is disable in /etc/...conf by defaul
[06:12] <cprov> default
[06:12] <pitti> right
[06:12] <pitti> but you apparently enabled it correctly
[06:12] <carlos> but the log is saying that the strip is done
[06:13] <pitti> can you check /etc/pkgstriptranslations.conf?
[06:13] <pitti> the 'enable' value
[06:14] <cprov> pitti: false
[06:14] <cprov> pitti: the translations are in webdir
[06:15] <cprov> pitti: old-style yet
[06:15] <pitti> *boggle*
[06:15] <carlos> pitti: how is possible that it's disabled and it still strips translations?
[06:15] <cprov> pitti: look in ferraz.buildd
[06:15] <cprov> pitti: maybe are we acting inside the chroot
[06:16] <cprov> pitti: I should install it INSIDE the chroot
[06:16] <pitti> [ -f "$CONFFILE" ]  || exit 0
[06:16] <pitti> readctrl "$CONFFILE" "enable"
[06:16] <pitti> [ "$RET" = "true" ]  || exit 0
[06:16] <pitti> these are the very first three commands
[06:16] <pitti> cprov: !!!
[06:16] <pitti> :)
[06:17] <cprov> pitti: does it mean "yes, you should do it, stupid !!!" ?
[06:17] <pitti> cprov: no, rather 'Yes, that sounds pretty plausible, sir' :)
[06:18] <cprov> pitti: so here we go, chroot job
[06:18] <carlos> :-D
[06:23] <pitti> hi mdz 
[06:25] <pitti> cprov: I'm going to have some dinner now, I'll read scrollback
[06:25] <cprov> pitti: okay, still fighting with chroot
[06:39] <kiko-fud> daf, I'm not sure why you duped 32430 to 5411
[06:39] <kiko-fud> nothing there suggests it.
[06:42] <daf> interesting
[06:43] <daf> I wonder what I was thinking
[06:46] <pitti> cprov: I'm back
[06:46] <kiko> daf, you also lack a comment saying that the OOPS and URL in the report do not match at all.
[06:46] <cprov> pitti: install pkgstriptrans in chroot is just wrong
[06:46] <kiko> which to me would be basis to reject the report
[06:47] <cprov> pitti: could not figure out from where is it called when building
[06:47] <pitti> cprov: why is it wrong? where else should it be installed?
[06:48] <cprov> pitti: in the builder itself, like sbuild 
[06:48] <daf> kiko: oh, the OOPS does match bug #5411
[06:48] <Ubugtu> malone bug 5411 in soyuz "Distribution's "List all packages" (+allpackages) times out, needs batching" [Major,Fix committed]  http://launchpad.net/bugs/5411
[06:48] <pitti> cprov: well, yes, I thought that's what you meant with 'chroot'
[06:48] <cprov> pitti: it was my "just wrong" mind
[06:48] <daf> kiko: the description and the OOPS are totally at odds, though
[06:49] <kiko> daf, really? bug 5411?
[06:49] <Ubugtu> malone bug 5411 in soyuz "Distribution's "List all packages" (+allpackages) times out, needs batching" [Major,Fix committed]  http://launchpad.net/bugs/5411
[06:49] <kiko> daf, because the traceback IIRC suggests people/+index, no?
[06:50] <cprov> pitti: let's think together, sbuild has a patch to move translation as we want, but not for generate than, so what invokes pkgstriptranslation in the build process ?
[06:50] <cprov> pitti: I suspect the same thing that invokes the dh_xxx, what is this ?
[06:50] <daf> kiko: uh
[06:50] <pitti> cprov: ooh, I see, let me explain
[06:50] <daf> kiko: sorry, I clearly have a blind spot when it comes to this bug
[06:51] <daf> kiko: I'm talking crap
[06:51] <pitti> cprov: pkgstriptranslations dpkg-diverts dpkg-deb
[06:51] <cprov> pitti: please
[06:51] <pitti> cprov: i. e. the build fully takes care of calling pkgstriptranslations on its own
[06:51] <daf> kiko: I think salgado ifxed all the people/+index issues we had
[06:51] <pitti> cprov: sbuild does not need to call pkgstriptranslations explicitly
[06:52] <daf> back later
[06:52] <kiko> daf, I think I agree
[06:52] <kiko> daf, I'll invalidate for you.
[06:52] <pitti> cprov: the sbuild patch to move translation tarballs to the http-accessible directory is a gross hack that shuold disappear after direct rosetta import works
[06:52] <cprov> pitti: who is "the build" ? dpkg ? 
[06:52] <pitti> cprov: yes
[06:52] <pitti> cprov: debian/rules eventually calls dpkg-deb, which calls pkgstriptranslations
[06:53] <cprov> pitti: right, but which pkgstriptranslation has been called ? who says that ?
[06:54] <cprov> pitti: I mean where I can specify it ?
[06:54] <pitti> cprov: 'which'?
[06:54] <pitti> /usr/bin/dpkg-deb:
[06:54] <pitti> case "$1" in
[06:54] <pitti>         --build | -b)
[06:54] <pitti>                 [ -x /usr/bin/pkgstriptranslations ]  && /usr/bin/pkgstriptranslations
[06:54] <pitti>                 ;;
[06:54] <pitti>         *)
[06:54] <pitti>                 ;;
[06:54] <pitti> esac
[06:54] <pitti> exec -a /usr/bin/dpkg-deb /usr/bin/dpkg-deb.pkgstriptranslations "$@"
[06:55] <pitti> cprov: so, it calls /usr/bin/pkgstriptranslations
[06:55] <cprov> pitti: so something must be wrong in the current /usr/bin/pkgstriptranslations
[06:56] <salgado> matsubara, would you like to take bug 32493 for some extra karma points?
[06:56] <Ubugtu> malone bug 32493 in launchpad "Need to check if an email address is not already registered when creating a new account" [Normal,Confirmed]  http://launchpad.net/bugs/32493
[06:56] <pitti> cprov: so you installed it into the build chroot now? what happens then?
[06:57] <cprov> pitti: didn't install it, gave up 
[06:57] <matsubara> salgado: assign it to me, but i'll not be able to fix it soon. Have some other priorities atm
[06:59] <kiko> yeah let matsubara fix some topcrashers
[06:59] <cprov> pitti: installed, it replaces the version 21, repacking chroot
[07:03] <pitti> cprov: and still no fun? what's in the build log?
[07:05] <cprov> pitti: just request a new job with new chroot
[07:06] <pitti> cprov: I don't understand what you mean
[07:06] <cprov> pitti: the new job in progress are using the chroot with new pkgstriptrans, need to wait they finish 
[07:09] <cprov> pitti: shit, hacked the wrong chroot
[07:16] <kiko> does anyone have a log of this channel? I'm looking for the quote I gave to answer the question on why we require an account to report a bug
[07:17] <Kamion> http://people.ubuntu.com/~fabbione/irclogs/
[07:17] <kiko> thanks Kamion 
[07:17] <carlos> cprov: I will need to leave in 15 minutes
[07:18] <cprov> carlos: wait wait 
[07:18] <carlos> but will be able to check anything later tonight
[07:18] <kiko> Kamion, no log for today?
[07:18] <kiko> it was earlier today
[07:23] <Kamion> kiko: -current
[07:23] <Kamion> otherwise you get to wait, I suppose
[07:24] <kiko> thanks Kamion you rock
[07:34] <carlos> cprov: do you need anyting from me? I need to leave....
[07:35] <cprov> carlos: to be honest, yes I need you to check if things are ok in mawson db, but not in the next 30 min
[07:35] <cprov> carlos: I'm publishing more sources to build
[07:36] <carlos> cprov: please, give me any instruction you need and I will check it when I'm back in a couple of hours or so
[07:36] <carlos> cprov: is that ok?
[07:37] <cprov> carlos: sure, check if the translations are sane within rosetta domain, basically ensure you last code works. I'll send email report to LP, anyway 
[07:37] <cprov> carlos: see you
[07:39] <dilys> Merge to devel/launchpad/: [trivial]  Add a flush_database_updates() call after creating a new shipit request in an attempt to fix https://launchpad.net/products/shipit/+bug/32425. Will get back to investigate it carefully later (r3183: Guilherme Salgado)
[07:42] <carlos> cprov: ok, thanks
[08:02] <atie> Does launchpad support uploading translations for products to upstream?
[08:44] <kiko> atie, indeed it does
[08:46] <atie> kiko, does it? I just sent a mail to rosetta-user ml to ask it.
[08:46] <kiko> mmm
[08:47] <kiko> sorry
[08:47] <kiko> do you really mean /to/ upstream?
[08:47] <atie> yes, to product projects like as abisource...
[08:47] <kiko> well, not exactly
[08:48] <kiko> anyone can download the updated pot and pofiles
[08:48] <kiko> so if upstream are actively interested they can pull and check those new files into their source control system
[08:48] <atie> that I know. :)
[08:49] <kiko> I wonder what you mean by "uploading translations [...]  to upstream"
[08:49] <atie> is there any predefined rules between Rosetta and the product projects?
[08:49] <kiko> I don't understand the question
[08:50] <atie> mean I have recently translated some products registered in Rosetta.
[08:50] <kiko> okay so far
[08:50] <atie> not for the packages in Ubuntu versions
[08:50] <kiko> yes, okay.
[08:50] <atie> Then I'd like ask for Rosetta will upload them to the product project.
[08:51] <kiko> I don't understand that part
[08:51] <kiko> what do you mean by "upload"?
[08:51] <atie> Since the projects have no ko_KR translations.
[08:51] <kiko> atie, you should contact the project's lead
[08:51] <kiko> and explain to them that they can pull a translation from rosetta
[08:52] <kiko> rosetta can't forseeably "push" your translation into the project
[08:52] <kiko> they need to pull it
[08:52] <kiko> the project, after all, is under their control
[08:53] <atie> that's ok for a couple of projects, I think.
[08:53] <atie> but I have several of them, do I need to to same thing for all of them?
[08:53] <kiko> yes.
[08:54] <kiko> there is a bug open to notify upstream automatically when new translations are received
[08:54] <kiko> but that has not yet been implemented
[08:54] <kiko> and it is controversial because some upstreams might not appreciate the spam
[08:54] <atie> Rosetta will support it soon? :)
[08:56] <atie> we sign codes of conduct and translate the product for them, these are not enough?
[08:56] <kiko> some upstreams are not aware of rosetta
[08:56] <kiko> other upstreams may choose not to use rosetta
[08:56] <kiko> that makes the situation not so simple
[08:56] <atie> that mean who registered the project to begin with?
[08:57] <atie> into Rosetta
[08:57] <kiko> anyone, potentially.
[08:57] <kiko> it says in the Rosetta page for the project, I believe
[08:58] <atie> can we make rules with projects before registering them to Rosetta?
[08:58] <kiko> I'm not sure what you mean by "rules"
[08:58] <kiko> if you mean that the projects should be contacted, I think it's a reasonable request, worth discussing in rosetta-users
[09:00] <atie> So Rosetta only provides mean, rest of works are up to translators including contact to projects?
[09:01] <kiko> atie, that is the current situation, yes.
[09:02] <atie> I am bit disappointed. :)
[09:02] <kiko> well, think of all the good things Rosetta gives you in return for this small shortcoming? :)
[09:05] <atie> Well... then I got to explain that to 25 ubuntu-ko translators.
[09:08] <atie> is it same for KDE and GNOME?
[09:08] <atie> if we will translate for packages in Dapper, those won't be uploaded to KDE and GNOME, only for Ubuntu/Kubuntu?
[09:08] <atie> Actually I am holding members to translate GNOME packages in Dapper.
[09:15] <kiko> correct
[09:16] <atie> kiko, thank you for kindly answering my questions. :)
[09:18] <kiko> sorry for not having more good news!
[09:18] <kiko> we are working to get there, though
[09:18] <atie> how soon do you know?
[09:19] <kiko> for what specifically?
[09:21] <atie> setting rules with projects registered in Rosetta. If projects have no translators, they will welcome our translations I think.
[09:23] <atie> Then translators don't need to contact projects individually.
[09:27] <atie> And, I doubt how much I can encourage people to use Rosetta while translations in Rosetta only update Ubuntu/Kubuntu.
[09:38] <atie> kiko, I got to go. Thanks again. 
[09:38] <atie> bye all
[09:40] <sistpoty> just a quick question... if I sponsor an upload which needs to go through new, and it get's rejected. will I get an rejected mail?
[09:40] <kiko> I believe so. cprov-away is the best guy to ask, or anyone that has uploaded -- seb128?
[09:41] <kiko> matsubara, can you check https://launchpad.net/products/rosetta/+bug/5807 and confirm?
[09:41] <Ubugtu> malone bug 5807 in rosetta "IndexError on +upload" [Normal,Needs info]  
[09:41] <seb128> kiko: is the changelog entry using your name?
[09:42] <sistpoty> seb128: for the rejected mail-question or are you talking bout s.th. different?
[09:42] <seb128> rejected
[09:43] <seb128> the changelog email is mailed
[09:43] <sistpoty> seb128: I'm not in the changed-by field, but I get accepted mails for these packages (if I sponsor)
[09:43] <kiko> seb128, sorry, I didn't understand your question.
[09:44] <seb128> kiko: sorry the reply was not for you, I just started to reply to the highlight
[09:44] <seb128> (ie: you mentionned my nickname)
[09:44] <kiko> :)
[09:46] <matsubara> kiko: I don't really know what caused that bug. It is one of those I reported for you when you asked me to report from the OOPS logs. Remember?
[09:48] <kiko> ah, really?
[09:48] <kiko> okay, I'll update.
[09:50] <elmo> cprov-away: around?
[09:59] <kiko> he's out for a bit, elmo 
[09:59] <kiko> can I help?
[10:00] <elmo> nah, it doesn't matter, I just cowboyed it and will mail him about the rest
[10:01] <kiko> yes!
[10:08] <cprov> elmo: here
[10:08] <cprov> elmo: cowboyed code ? where ?
[10:08] <elmo> not code, so what happened is
[10:09] <elmo> kinnison wrote a process-incoming.sh for the sync queue, but it was still pointed at staging
[10:09] <elmo> I ran it.  noticed it was moving stuff to staging.  swore a lot.  cowboyed the upload from accepted, back to incoming, fixed the script and reran it
[10:09] <elmo> a) is that ok, b) can I just firewall drescher from talking to anything other than emperor? :P
[10:10] <elmo> (sync queue == /home/lp_queue/sync-queue for some reason)
[10:10] <cprov> elmo: firewall it will cause trouble when transfering file to home or rsyncing tree 
[10:11] <cprov> elmo: is the script in question in the LP worktree ?
[10:11] <elmo> sorry, I only mean firewall it from talking on postgres (5432 or whatever) port
[10:11] <elmo> cprov: no :/
[10:11] <elmo> kinnison put it in /home/lp_queue/sync-queue/ too
[10:11] <elmo> I think we should move the script to the LP tree, and the queue to /srv/launchpad.net
[10:11] <cprov> elmo: ok, fix it in place and may LP (I think, just for history)
[10:12] <kiko> I agree with elmo 
[10:12] <cprov> elmo: agreed, mail me I can do it tomorrow morning
[10:12] <kiko> less of a hack
[10:13] <cprov> elmo: sure firewalling postgres is ok
[10:14] <elmo> hmm, the upload got sent out as Ubuntu Installer instead of under Martin's name
[10:19] <cprov> elmo: weird, which policy were you using ?
[10:20] <elmo> the 'sync' policy
[10:22] <elmo> what does soyuz send mail based on?  Changed-By or Maintainer?
[10:22] <elmo> maybe the problem is martin doesn't have his @ubuntu.com address in launchpad?
[10:23] <elmo> hmm, nope "pkgstriptranslations 22" got sent out as him, with a Maintainer of m.p@c.c and a Changed-By of m.p@u.c
[10:26] <elmo> what's the bzr-ese for 'wtf is this branch and where did it come from?'
[10:27] <cprov> elmo: sorry the delay, I don't know why the email got sent as Ubuntu.. instead of martin, need to investigate maybe something is flaky in sync policy
[10:40] <kiko> salgado, is there a bug for the +newaccount timeout when inserting into Person?
[10:41] <salgado> kiko, I don't think so
[10:43] <kiko> thanks.
[10:44] <cprov> elmo: file a bug about this issue, add the uploader output if you have, I can look on this tomorrow and say exactly how to fix
[10:45] <elmo> cprov: ok, I'm going to have a quick look myself, 'cos I can't do all the pending syncs without this being resolved
[10:45] <elmo> will I could, but it'd be ugly
[10:45] <elmo> anyway, where is the soyuz production bzr branch, so I can pull it down locally and avoid drescher lag?
[10:46] <cprov> cprov/launchpad/uploader-tests/
[10:47] <elmo> hum?
[10:47] <elmo> oh, I suppose I could just rsync copy it off of drescher, never mind
[10:49] <cprov> elmo: my branch in chinstrap, the name doesn't help .. I'm about to release a soyuz-production anyway
[11:01] <lifeless> elmo: bzr info might tell you, but as each branch is independent theres no real indicator
[11:01] <lifeless> elmo: also cat .bzr/parent might help
[11:02] <salgado> lifeless, I have a question for you
[11:02] <salgado> the python-codespeak-lib package is now installed on pqm's box, but I think I need to add it as a launchpad dependency, as we need it to run a make check_merge
[11:02] <lifeless> shoot
[11:03] <salgado> the problem is that this package is not available in breezy. should I just add a link on the wiki to a .deb placed somewhere and mail launchpad@?
[11:04] <salgado> or do I need to get a proper backport of that package into breezy-backports?
[11:04] <salgado> (I have no idea who I have to bother to get the latter)
[11:05] <lifeless> I think you need to talk to stevea
[11:05] <lifeless> adding it to the lp dependencies is a good idea
[11:05] <kiko> getting a backport shouldn't be difficult.
[11:06] <lifeless> but if its been manually installed on balleny we don't strictly speaking need it in lp-deps
[11:06] <lifeless> but its much easier to not forget things if they are in lp-deps
[11:06] <salgado> but developers might have problems if they try to run all tests
[11:08] <salgado> anyway, I'll check with Steve tomorrow
[11:08] <salgado> gooooodnight everybody!
[11:09] <SteveA> salgado won't check anything with me tomorrow
[11:09] <SteveA> i'll be traveling
[11:09] <kiko> heh
[11:09] <SteveA> taxi comes in 6 hours
[11:38] <cprov> see you tomorrow
[11:48] <dilys> Merge to devel/launchpad/: [trivial]  DB permission for queued insert new librarian files, required for rosetta/soyuz integration. (r3184: Celso Providelo)