[03:49] <jamesh> lifeless: I played around with siproxd a bit on the weekend: it doesn't seem to be 64-bit safe
[03:49] <lifeless> jamesh: aw crikey
[03:50] <lifeless> jamesh: filed bugs ?
[03:50] <jamesh> I fixed a few crasher bugs in it, but it still seems to have some problems
[03:50] <jamesh> https://launchpad.net/distros/ubuntu/+source/siproxd/+bug/40914
[03:50] <Ubugtu> Malone bug 40914 in siproxd "siproxd segfaults on AMD64" [Normal,Unconfirmed]  
[03:50] <lifeless> heh, I meant upstream :)
[03:50] <jamesh> apparently they didn't know that sizeof(size_t) isn't always equal to sizeof(int)
[03:51] <lifeless> meh
[03:51] <lifeless> sizeof(not-my-type) == sizeof(mytype) is not a truism.
[03:51] <lifeless> its like the sizeof(int) == sizeof(void *) idiocy that I've seen people indulge in
[03:52] <jamesh> so passing an (int *) to a function expecting a (size_t *) didn't do what they want
[03:52] <lifeless> surely you get a compiler complaint on that ?
[03:52] <jamesh> in fact, it seemed to zero out the port variable they then used to send UDP packets
[03:52] <jamesh> you get a complaint on AMD64 (which is how I found it)
[03:52] <lifeless> right
[03:52] <lifeless> but not where it is -=
[03:59] <jamesh> lifeless: well, shtoom seems to work through siproxd now, but ekiga isn't
[04:00] <lifeless> interesting
[04:00] <lifeless> what happens with ekiga
[04:00] <lifeless> have you unset its stun setting?
[04:00] <jamesh> I turned off the stun stuff
[04:01] <jamesh> says "could not connect to remote host" in the status bar.  I haven't investigated further yet
[04:08] <lifeless> k
[04:08] <lifeless> I've shown you subunit now haven't I? 
[04:09] <jamesh> yeah
[04:09] <lifeless> good. with the shell/C/C++ extensions ?
[04:10] <lifeless> (I want to get some really good unit testing tools into the common lingo for gnome, and you are about the most hard core gnome guy I talk with regularly)
[04:11] <jamesh> you told me about the extensions, but I haven't played with them
[06:05] <mpool> mpt__: ping?
[06:34] <SteveA> good morning
[06:37] <dilys> Merge to devel/launchpad/: Refactor PostgreSQL session support, removing race condition embedded in SQL [r=BjornT]  (r1816: Stuart Bishop)
[06:45] <mpool> hi SteveA
[06:50] <SteveA> hello martin
[07:00] <stub> Either Steve is getting earlier or my night outs are getting later...
[07:00] <SteveA> couldn't sleep
[07:01] <SteveA> there's a strange buzzing sound i could hear all night
[07:01] <SteveA> i thinkn my neighbour above has a noisy computer
[07:01] <SteveA> and it is touching something that makes it resonate into my bedroom
[07:01] <egerds> I am trying to register for ubuntu
[07:02] <egerds> nvm
[07:35] <Podovan> Hello anybody!
[07:46] <SteveA> mpt_: voice call?
[07:51] <rlaager> Has the permission model in Malone changed recently? There's a bug, which I assigned to myself not too long ago, that I can't close.
[07:52] <BjornT> rlaager: which bug? you should be able to close it.
[07:52] <jamesh> rlaager: got a pointer to it?
[07:52] <rlaager> 38999
[07:53] <jamesh> what error do you get when you try to close it?
[07:54] <rlaager> I don't get an error. There's just no arrow to click to get at the close stuff...
[07:55] <jamesh> rlaager: just click on the row
[07:55] <rlaager> Hmm, perhaps that's moved now? I don't see it for bugs I filed either.
[07:55] <rlaager> ahh, thanks
[07:57] <SteveA> BjornT: we should meet for lunch sometime
[07:57] <SteveA> and maybe a code review session or two
[07:59] <lifeless> mmm, code review
[08:00] <BjornT> SteveA: yeah we should, it's easier for me now that i have a car. how about lunch tomorrow?
[08:02] <SteveA> it's great weather for cycling.  i should pick up my bike from the POV office
[08:02] <SteveA> sure, lunch tomorrow
[08:04] <BjornT> yeah, the weather is great for cycling. that's why i suggested lunch tomorrow, since i'm planning to go for a ride today.
[08:11] <sivang> morning all
[08:41] <SteveA> BjornT, stub: what's the story about getting zero soft timeouts?
[08:42] <BjornT> SteveA: i sent a patch. do you want me to merge it without tests, or should i add tests first?
[08:43] <jamesh> SteveA: BjornT's patch and analysis sounds correct
[08:43] <SteveA> hi jamesh 
[08:43] <jamesh> hi SteveA 
[08:43] <SteveA> please merge it, get it onto staging, and see if we can provoke a soft timeout
[08:43] <SteveA> if you're feeling keen...
[08:44] <SteveA> add a page that checks the logged in user for being a launchpad developer (or uses permissions)
[08:44] <SteveA> and does something evil to provoke a soft timeout
[08:44] <SteveA> by pausing for the length of time specified to be a soft timeout
[08:44] <jamesh> BjornT: I suppose a special page that always timed out plus a page test that invoked it would be the way to go
[08:44] <SteveA> then at least we can test it in practise
[08:45] <SteveA> jamesh: yes.  although, before running that page test, i'd be inclined to temporarily set the soft timeout value to be small, like a few secs
[08:45] <jamesh> yeah
[08:46] <SteveA> BjornT: please merge the stuff, and do the test later if you need to
[08:46] <SteveA> i think it is important that we see soft timeouts
[08:47] <BjornT> ok, i'll merge it now, and add the test later.
[08:47] <lifeless> well, how long is it going to take to write the test? 
[08:48] <SteveA> mister testing fascist!
[08:49] <lifeless> indeed
[08:49] <lifeless> soft timeouts are fragile. they have stopped more than once now.
[08:49] <lifeless> I'd like to stop that.
[08:52] <BjornT> i suppose the test won't take too long to write. i'll do it before i merge then.
[08:53] <BjornT> jamesh: what's the easiest way of checking that a soft timeout occurred?
[08:53] <BjornT> or rather, has been logged
[08:56] <jamesh> BjornT: I think globalErrrorUtility.lastid will get incremented (or reset if we pass from one day to the next)
[08:57] <jamesh> BjornT: recording the value before and after should tell you that an OOPs was generated.  Getting the normal page output from the page test will tell you that it wasn't a normal OOPS
[09:28] <mpt_> SteveA, sure
[09:40] <SteveA> mpt_: ok
[09:41] <SteveA> mpt_: i'm running skype now
[09:46] <SteveA> mpt_: ping
[09:48] <SteveA> mpt_: i'm going out for a while.  if you've gone to sleep when i get back, we should make sure we catch up tomorrow.
[10:36] <BjornT> jamesh, SteveA: please someone review https://chinstrap.ubuntu.com/~dsilvers/paste/fileV3ytab.html
[10:38] <SteveA> BjornT: +from time import sleep, time
[10:38] <SteveA> i'd rather you imported "time" and used "time.time" and "time.sleep"
[10:39] <jamesh> BjornT: any reason for calling sleep() in a loop, rather than just sleeping for the appropriate amount of time?
[10:40] <BjornT> jamesh: well, is that reliable? is sleep() guaranteed to sleep at least the specified time?
[10:41] <jamesh> BjornT: I suppose it can get interupted, yeah.
[10:41] <SteveA> you could do max(time_left, 0.1)
[10:41] <SteveA> but that's getting kinda complex
[10:41] <SteveA> you already wait what should be the right time, and then busy loop the rest
[10:41] <SteveA> perhaps add a comment saying that
[10:42] <BjornT> yeah, i comment is probably good to have there
[10:47] <SteveA> r=me
[10:47] <BjornT> thanks
[10:54] <ddaa> hey jamesh
[10:54] <ddaa> how much longer are you going to be around today?+
[10:56] <jamesh> hi ddaa 
[10:57] <jamesh> an hour or so
[10:57] <jamesh> ddaa: was looking at moving the branch pull list stuff into the authserver
[10:58] <ddaa> jamesh: did I ask you for that already?
[10:58] <ddaa> I think not, in any case, I intended to :)
[10:59] <jamesh> ddaa: I also got the importd error reporting script working against the sample data you sent last week
[11:54] <erdalronahi> Hi all,
[11:54] <erdalronahi> the ooo-templates have once again been imported into Rosetta/Dapper
[11:54] <erdalronahi> and this time all our translations have been overridden by the English originals
[11:55] <erdalronahi> It's even worse than before
[11:55] <erdalronahi> Before only the untranslated strings have become English, now ALL are overridden
[11:56] <lifeless> review meeting in 5
[11:59] <doko> erdalronahi: your statement doesn't help, please submit a bug report, subscribing carlos and me
[11:59] <erdalronahi> yes, I'll do that
[11:59] <erdalronahi> just wanted to inform you,
[11:59] <erdalronahi> because carlos said last week 
[12:00] <erdalronahi> I should tell him if it doesn't work
[12:07] <mpt> awesome
[12:08] <mpt> Someone found a bug report in Malone by googling the incorrect string he was seeing
[12:08] <mpt> and the bug report is the first of 33 results
[12:08] <mpt> yay Malone
[12:08] <mpt> boo https://bugzilla.mozilla.org/robots.txt
[12:08] <erdalronahi> doko, ok, filed the bug
[12:08] <mpt> boo http://bugzilla.gnome.org/robots.txt
[12:09] <doko> erdalronahi: thanks
[12:09] <erdalronahi> doko, you're welcome
[12:09] <erdalronahi> in fact, thank you for all your efforts
[12:12] <doko> np
[12:22] <lifeless> hi
[12:22] <lifeless> who is here ?
[12:26] <BjornT> i'm here. lifeless, isn't the meeting in 35 minutes though?
[12:28] <lifeless> 1100UTC
[12:28] <lifeless> meh, yes
[12:29] <lifeless> meeting in 30
[12:32] <SteveA> hi
[12:33] <SteveA> mpt: you're still around?
[12:33] <SteveA> mpt_: you're still around?
[12:33] <SteveA> you should think about getting a shell account somewhere, and using irssi
[12:33] <SteveA> so you don't drop off irc so much
[12:34] <SteveA> screen + irssi
[12:36] <lifeless> like chinstrap
[12:36] <lifeless> ;)
[12:38] <mpt_> SteveA, yep
[12:39] <SteveA> mpt_: skype call?
[12:39] <mpt_> SteveA, I'm getting a new ISP in about four days, so hopefully the connectivity, Toshiba+iBook simultaneous connectivity, and SMTP problems should all be solved
[12:39] <mpt_> at least one of them being solved would be nice
[12:39] <mpt_> SteveA, sure
[12:59] <lifeless> ok
[12:59] <lifeless> meeting time in 1
[01:02] <lifeless> ok, whose here now ?
[01:03] <BjornT> i'm here
[01:03] <lifeless> jamesh ?
[01:03] <lifeless> SteveA: ?
[01:03] <lifeless> kiko ?
[01:03] <lifeless> mpt_: ?
[01:03] <mpt_> Meeting now?
[01:03] <mpt_> what for?
[01:03] <lifeless> review team
[01:04] <lifeless> which you are partof for the ui reviews ;0
[01:04] <mpt_> Another evening I have to stay up late?
[01:04] <mpt_> yayfor
[01:05] <lifeless> nah
[01:05] <lifeless> if you are here, I appreciate your attendance
[01:05] <lifeless> if you aren't, its fine. its not a must-come-every week meeting
[01:05] <mpt_> ok
[01:05] <lifeless> partly because the reviewers are all fairly self guided
[01:06] <lifeless> so next meeting, may 1st, same bat-time, same bat-channel ?
[01:06] <BjornT> may 1st is a holiday in some countries
[01:07] <lifeless> mayday ?
[01:07] <ddaa> hey mpt
[01:07] <ddaa> (no need to say more :)
[01:07] <lifeless> BjornT: is it a holiday for you ?
[01:07] <BjornT> lifeless: yeah
[01:08] <lifeless> ok, well you get a day off then :)
[01:08] <lifeless> I think its varied enough to not worried, just note your absence after this meeting on the agenda for the next
[01:09] <BjornT> will do
[01:09] <lifeless> queue status
[01:09] <lifeless> I have to get to ddaa's branch-scanner for a re-review
[01:09] <lifeless> and the small-fixies branch in jamesh' queue is looking a little ripe
[01:09] <lifeless> other than that, the needs-review section is looking good.
[01:10] <lifeless> 37  	spiv  	salgado/launchpad/shipit-for-dapper  	3173  	merge  	7345  	14:15
[01:10] <lifeless> 31 	BjornT 	spiv/launchpad/unicode-simple-sendmail 	3284 	merge (1) 	149 	17:05
[01:10] <lifeless> those two are in needs reply.
[01:10] <lifeless> spiv is on leave..
[01:10] <lifeless> BjornT: what about your branch - is it likely to land soon ?
[01:10] <lifeless> meh. my bad
[01:10] <lifeless> salgado is the branch owner, hes still asleep
[01:11] <lifeless> merge-conditional seems to be the killer region though
[01:11] <lifeless> davids baz2bzr branch is at 54 days
[01:11] <lifeless> which has to be some sort of records
[01:12] <BjornT> lifeless: i pointed out an issue with the unicode-simple-sendmail to spiv while in london. he said that he would either re-implement the fix, or simply drop the branch. it hasn't been a priority to resolve the issue, though.
[01:12] <lifeless> BjornT: cool
[01:13] <lifeless> any comments, issues with reviews at the moment ?
[01:14] <lifeless> jamesh: the pending reviews page is not showing the branches in the ui queue - they are also in other peoples queues.
[01:14] <lifeless> jamesh: perhaps we can show them as 'spiv,mpt' which while not quite accurate (it conflates the respective statii) will at least hint that there are multiple reviewers, to set expectations.
[01:15] <lifeless> and perhaps take the worst-case status (i.e. needs-review if any reviewer is set to that, needs-reply , then merge-condition etc)
[01:15] <lifeless> ddaa: on you from the look of it
[01:15] <lifeless> possibly on the sourcecode/ merge fixes
[01:16] <lifeless> in which case make a note of that on the wiki :0
[01:16] <ddaa> Mh... I think it was related to some new test failure, related to to tarball fixtures or somesuch
[01:17] <lifeless> Let me take  moment to say - tarballs fixtures are really bad news.
[01:17] <lifeless> 99% of the time. This may be that 1% where they make sense, but I don't believe so.
[01:19] <ddaa> can we talk about that now, or am I disrupting the reviewer meeting?
[01:19] <lifeless> BjornT: so, no comments/issues on reviews?
[01:19] <BjornT> no, no comments from me
[01:19] <lifeless> mpt_: how are you handling the ui review load? 
[01:19] <lifeless> mpt_: are there things the reviewers can watch out for ?
[01:20] <lifeless> ddaa: also, please action the bzr-documentation branch, you have mail from me about that.
[01:20] <lifeless> ddaa: tarballs, we can talk in a few minutes.
[01:22] <ddaa> doc-bazaar, date of the mail? I don't see anything new
[01:22] <ddaa> (oops, sorry for disrupting meeting)
[01:22] <lifeless> ok, I'll take that as meeting-closed time.
[01:22] <lifeless> thanks for coming
[01:22] <lifeless> (unless there is other business
[01:22] <lifeless> )
[01:23] <lifeless> ok, meeting-over
[01:25] <ddaa> lifeless: doc-bazaar is already acted on
[01:25] <ddaa> that's why I set it up to needs-review again
[01:26] <mpt_> lifeless, my load is about 1 branch every 3 months, but currently I have 2 very large one
[01:26] <mpt_> s
[01:26] <mpt_> sabdfl's one is 800 K
[01:26] <lifeless> ddaa: I didn't get a reply to my mail
[01:26] <lifeless> mpt_: it might be a good idea to put those branches in the wiki page
[01:28] <lifeless> ddaa: ok, lets talk tarballs
[01:29] <ddaa> so, the use case there was: take a baz archives produced by cscvs, and feed it to baz_import
[01:29] <ddaa> three options:
[01:30] <ddaa> 0. all in test: create cvs repo, run cscvs
[01:30] <ddaa> 1. harcoded in test: create baz archive with hardcoded log messages
[01:31] <ddaa> 2. tarball
[01:31] <ddaa> 0 is ridiculously overcomplex for the case
[01:32] <ddaa> 1. is manageable but still a bit of an annoyance because it involve significant arch goo code, and I consider it's not worth the trouble for a throwaway piece of code
[01:32] <ddaa> 2. is simple to set up, leads to short code. It hampers evolution and maintenance of the code, but we DO NOT care about evolution and maintenance of baz2bzr
[01:33] <ddaa> at the rate it's going, it will be obsolete before being merged
[01:33] <ddaa> lifeless: do you consider that's a fair assessment?
[01:35] <lifeless> mmm
[01:35] <lifeless> our converted archives are around now
[01:35] <lifeless> what are you specifically testing here ?
[01:35] <ddaa> baz2bzr is the stuff that does the incremental conversion in importd
[01:36] <ddaa> it's testing end-to-end functionality of the conversion to bzr, both initially (new imports!) and incrementally (daily syncs).
[01:36] <lifeless> I think based on that that 2 is not a valid test
[01:37] <ddaa> then neither would be 1
[01:37] <lifeless> because its avoiding being an end to end test
[01:37] <ddaa> and doing 0 would just be crazy
[01:38] <lifeless> 1 is valid because it is testing that things created /now/ by the current code also import with the current code
[01:38] <ddaa> duh?
[01:39] <ddaa> now, 1 is testing that baz (which is not evolving) can create an archive with _hardcoded_ logs (therefore not end-to-end) that is processed correctly with baz-import
[01:39] <ddaa> it's not buying anything functionaly. I understand 1 is more readable than 2, but that's all.
[01:40] <ddaa> and the "end-to-end" I was initially referring to was "both end of the baz2bzr script"
[01:40] <mpt_> lifeless, done
[01:40] <lifeless> ddaa: are you testing invocation of baz2bzr? or baz2bzr internals ?
[01:41] <lifeless> ddaa: speaking of baz2bzr, there is a pybaz urgent-bugfix-for-baz2bzr in your mailbox.
[01:42] <lifeless> ddaa: please escuse me if I'm a little unclear right now, its late and I'm coming down with some illness - lynne's boss got sick, lynne got sick, I'm getting sick.
[01:43] <ddaa> lifeless: testing both
[01:43] <ddaa> the baz_import behaviour is tested by running the baz2bzr script
[01:43] <lifeless> so, invocation of baz2bzr by importd ?
[01:43] <ddaa> no, invocation of baz2bzr by the test case... hu...
[01:43] <ddaa> using the same CLI used by importd
[01:44] <lifeless> so, I'm confused.
[01:44] <lifeless> because baz2bzr already has unit tests for the cscvs headers, blackbox tests for its use as a command, etc.
[01:44] <ddaa> sure
[01:44] <lifeless> surely the only thing we need to be adding tests for is invocation by importd ?
[01:45] <lifeless> and cscvs-specific headers are really irrelevant to this.
[01:45] <ddaa> but the tests here checks that the _right_ bzrtools is being used
[01:45] <ddaa> integration testing
[01:45] <lifeless> what do you mean
[01:45] <lifeless> by 'right'
[01:46] <ddaa> makes no good that bzrtools says "I'm passing" if it's not doing what importd wants it to do with the cscvs metadata.
[01:46] <ddaa> errors happen
[01:46] <cprov> good morning
[01:47] <lifeless> ddaa: you know the hierarchy of testing? Many unit tests, some ui tests, very few end to end tests ?
[01:47] <ddaa> in particular, that test check things like "just the right revprops are there" (i.e. no branch-nick)
[01:47] <lifeless> ddaa: what I am hearing from you sounds like a schizophrenic test
[01:47] <ddaa> which, we have seen, is useful to check redundantly
[01:49] <lifeless> you have said it is testing:
[01:49] <lifeless> end to end baz2bzr
[01:49] <lifeless> invocation of baz2bzr by importd
[01:49] <ddaa> nope
[01:49] <lifeless> baz2bzr internals [cscvs-revision properties] 
[01:49] <ddaa> I do not think I said that.
[01:50] <lifeless> 21:36 < ddaa> it's testing end-to-end functionality of the conversion to bzr, both initially (new imports!) and incrementally (daily  syncs).
[01:50] <ddaa> right
[01:50] <lifeless> 21:43 < ddaa> no, invocation of baz2bzr by the test case... hu...
[01:50] <lifeless> 21:43 < ddaa> using the same CLI used by importd
[01:50] <ddaa> and doing that, checks proper handling of cscvs metadata in the output of baz2bzr
[01:50] <ddaa> the interface to baz2bzr used is the CLI, importd uses the CLI too
[01:51] <lifeless> a good test tests one thing
[01:51] <ddaa> it tests one thing
[01:51] <lifeless> it makes tests faster, easier to debug, more robust.
[01:51] <lifeless> if it testeed one thing, you could have told me that at the beginning.
[01:52] <ddaa> it test "baz2bzr, run from the CLI, convert a baz branch produced by cscvs into the proper bzr data"
[01:52] <lifeless> ddaa: and it tests that your custom ui factory is used
[01:52] <ddaa> "ddaa: so, the use case there was: take a baz archives produced by cscvs, and feed it to baz_import"
[01:53] <ddaa> mh... right, I was being unclear
[01:53] <lifeless> I think the test is unclear too.
[01:53] <lifeless> for instance.
[01:53] <ddaa> lifeless: as as matter of fact, the test for the UI factory is distinct from the test for the bzr output
[01:54] <mpt_> ddaa, Wednesday-ish for your review
[01:54] <lifeless> 'test that baz2bzr can be run from the cli by importd' 
[01:54] <ddaa> no "by importd"
[01:54] <lifeless> ddaa: its already tested that it can be run from the cli. No need to write a new test for that.
[01:54] <ddaa> this is a test for baz2bzr, no importd stuff here, no Job
[01:54] <lifeless> ddaa: think about this in TDD terms, we want to write a test that will FAIL today.
[01:55] <ddaa> all that code was written in TDD
[01:55] <lifeless> ddaa: so your tests should be testing stuff that isn't already tested and working - by definition.
[01:56] <lifeless> ddaa: but you are mentioning things that I know are tested and working. So either an axiom is faulty, or you are having fun making me play 20 questions.
[01:56] <ddaa> first, I wanted to test bzr output, then CLI factory for the conversion phase, then publishing, then CLI factoriy for the publishing phase
[01:56] <ddaa> I do not have fun. I think this conversion is wearing me down as much as it is wearing you down.
[01:59] <lifeless> so, lets break this down into those bits
[01:59] <lifeless> what was wrong in the bzr output you wanted to fix  ?
[01:59] <ddaa> lifeless: I think we differ on that you would assume that if baz_import does not break noisily it works right because it's tested somewhere else.
[02:00] <ddaa> But I do not, because baz_import belong to a different tree, and may therefore not be the right version.
[02:00] <lifeless> ddaa: I would write a single smoke test for the end to end behaviour desired. 
[02:00] <lifeless> ddaa: as a smoke test, I'd seriously do cvs<-....>bzr
[02:01] <lifeless> because its a single test, meant to be incredibly sensitive to changes, not fine grained unit tests
[02:01] <ddaa> I agree that's the Right Way of doing it.
[02:01] <lifeless> but in general we dont test across-trees in launchpad
[02:02] <lifeless> we don't test that we have the right zope, the right cscvs, the right pybaz
[02:02] <lifeless> in production thats the responsibility of the person doing the rollout
[02:02] <ddaa> But since it's throwaway code, cscvs and baz will be stable for the lifetime of the code, I decided to cut costs.
[02:02] <lifeless> as we dont run the test suite on the production servers, for good reasons, it *cannot* be caught by tests.
[02:04] <ddaa> I understand it's not ideal best practice either. But I consider it useful there because 1. rolling back a mistake there is incredibly painful 2. it's easy to test 3. it's meant to caught regression in the mainline code (e.g. bad merge, bad test fix)
[02:04] <ddaa> * meant to catch
[02:05] <lifeless> I need to go. I see tarballs as valid when there really is no way to describe the scenario except as a binary snapshot.
[02:05] <lifeless> some people manage their databases like that - but we dont, and I dont see this as being functionally different for the described case.
[02:05] <ddaa> can turn that into an arch archive created by hand if you are concerned about readability.
[02:05] <ddaa> by hand = by the test case
[02:06] <lifeless> I'm worried about several things
[02:06] <lifeless> bzr is bad on binary files at the moment
[02:06] <lifeless> really bad
[02:06] <lifeless> I'm worried about maintainability, yes its throwaway code, but its *still* code that you and possibly me and possibly jamesh and possibly spiv will be touching until the changeover is complete.
[02:07] <ddaa> okay, will waste the tarball and create the archive in the test suite
[02:07] <lifeless> and clarity here - in a complex code base - is extremely important.
[02:08] <lifeless> I'm also worried that the stuff you are talking about testing may be being done too far out from baz2bzr, there may be tests that need to be done to baz2bzr itself that are not done yet.
[02:08] <lifeless> thank you
[02:08] <lifeless> can we chat about 2 other things quickly ?
[02:08] <ddaa> lifeless: I think the coverage of baz2bzr is more than adequate
[02:08] <ddaa> go on
[02:09] <lifeless> pybaz - I have sent you a patch log mangling patch
[02:09] <lifeless> this may fix some of the blacklist imports
[02:09] <lifeless> can you please as a priority give me a review for it? Its testless for a number of reasons. 
[02:10] <lifeless> what was the other thing... oh yeah
[02:10] <ddaa> I read the email you sent (not the patch), but I'm not sure I undertand it very thoroughly, in particular I'm not sure about the cases where it could go wrong
[02:10] <ddaa> also, I do not understand what can produce the problem.
[02:10] <lifeless> I want to update rocketfuel to baz2bzr and bzr 0.8 rc2 this week
[02:10] <lifeless> ddaa: tla produced the problem ;0
[02:11] <ddaa> what input to tla
[02:11] <lifeless> it took a commit message from a user than had a pseudo header
[02:11] <lifeless> summary: blah
[02:11] <lifeless> keyworkds: more blah
[02:11] <lifeless> this is not an rfc2822 header: foo bar
[02:11] <lifeless> 
[02:11] <lifeless> more content here
[02:12] <ddaa> would "applied patch not a header" override "applied-patches"?
[02:12] <lifeless> the 'this is not'... line should have been put in the body of the message
[02:12] <lifeless> ddaa: applied-patches isn't a tla internal header, and no, IIRC last header wins
[02:13] <ddaa> BTW, your mail does not appear to include a patch
[02:13] <lifeless> anyway, instead of putting them in the body, it leaves that 'this is not..' psuedo header in the header section of the message.
[02:13] <ddaa> so it's difficult for me to apply it :)
[02:14] <lifeless> done
[02:14] <ddaa> okay I think I understand
[02:14] <ddaa> we ended up with non-RFC822 data
[02:14] <lifeless> yup
[02:15] <ddaa> and the stdlib that we use to parse the log message barfed
[02:15] <lifeless> and the email python module starts the body *at that line*.
[02:15] <lifeless> thus ignoring all the arch-added headers.
[02:15] <ddaa> esp. New-patches:
[02:16] <ddaa> -> KeyError when baz_import tries to access that
[02:16] <lifeless> its when I run into bugs like this that toms rhetoric about how we made bad design decisions and are failing makes me physically sick.
[02:16] <lifeless> ddaa: exactly.
[02:16] <lifeless> ddaa: also 'None' type has no attribute split
[02:17] <ddaa> lifeless: I can understand how you can be offended by Tom ranting about baz design decisions.
[02:17] <ddaa> But since he never bothered to actually try and understand what we were doing, it's all canned bullshit as far as I'm concerned.
[02:17] <lifeless> hahha
[02:17] <lifeless> guess I'm being over sensitive.
[02:18] <lifeless> anyway, moving along ..
[02:18] <ddaa> if he were trying, he would actually realise that we were heading roughly towards arch2...
[02:18] <lifeless> yup
[02:18] <ddaa> and _that_ would distress him terribly
[02:18] <lifeless> I want to update the bzr and bzrtools in rocketfuel
[02:18] <lifeless> do you have any concerns about that ?
[02:18] <ddaa> not enough hours in the week
[02:19] <lifeless> major changes: revision-history is normalised, and knits are defaults.
[02:19] <ddaa> otherwise, no special concern, except that there's a bunch of deprecation warnings e.g. in importdcheck, and I fully expect something will break.
[02:19] <lifeless> ok, I will try it and if it baulks, I will email you a FYI 
[02:19] <lifeless> I dont have time to do the integration myself if its non-trivial.
[02:20] <ddaa> need to talk about revision history things soon, I think I understand how that affects my stuff, but I'd like to sanity check properly with you
[02:20] <lifeless> ok
[02:20] <lifeless> lets quickly do it now
[02:20] <ddaa> I'm not in condition
[02:20] <lifeless> ok
[02:20] <ddaa> I'm being mildly sick too
[02:20] <lifeless> gnight then
[02:51] <kiko> hello there
[02:53] <ddaa> hey kiko
[02:54] <kiko> hey david, how's it going man?
[02:54] <ddaa> I noticed there are still a couple of crashing bugs in the branch puller, one appears to be a pyflakes-grade bug in an exception handler
[02:54] <ddaa> the other is the failure to catch connection errors (at socket level)
[02:54] <kiko> has the branch puller code been updated to the version salgado reviewed?
[02:55] <ddaa> phone
[02:55] <salgado> kiko, that I reviewed?
[02:56] <kiko> well, that you worked with jblack on, salgado 
[02:56] <salgado> yes, that's the version that is running
[02:58] <salgado> the problem is that I don't know how to write a test that exercises the code path that is failing (the exception handler that ddaa said). I've mailed lifeless (you were cc:ed, IIRC), but I didn't get any answer
[02:58] <kiko> he answered IIRC
[02:58] <ddaa> back
[02:59] <ddaa> salgado: want me to have a look? I think I can channel lifeless for that :)
[03:01] <salgado> ddaa, sure, that'd be great
[03:01] <salgado> ddaa, https://lists.ubuntu.com/mailman/private/launchpad/2006-April/008447.html
[03:01] <salgado> (that's the thread were we discussed it)
[03:08] <ddaa> salgado: there's another one in addition to those
[03:09] <ddaa> error report: 23 Apr 2006 14:20:25 +0100 (BST)
[03:09] <ddaa> socket.error: (110, 'Connection timed out')
[03:09] <ddaa> not caught in branchtomirror.py, line 28
[03:10] <ddaa> that bzrlib does not catch and convert it to a BzrError might be considered a bug in bzrlib, but I'm inclined to to be quite inclusive in the class of errors BranchToMirror should catch.
[03:10] <salgado> I thought I was subscribed to this topic, but apparently no
[03:12] <ddaa> salgado: so we have to interesting lines in branchtomirror.py, line 28 and 42
[03:13] <ddaa> we want to have test cases for those lines raising all sorts of interesting exceptions, which is annoying because they are calling into bzrlib.
[03:13] <ddaa> salgado: are we in sync?
[03:13] <salgado> one second
[03:14] <salgado> ddaa, yeah, looking at the code now
[03:14] <salgado> that's right. we already have some tests for failures in line 28
[03:14] <salgado> but we don't have tests for failures on line 42
[03:15] <ddaa> the socket.error I mentioned happens in line 28, and since we want to be fine grained, it would be worth a test of its own too
[03:16] <ddaa> So, these lines do two things: opening srcbranch, and pulling scrbranch into dest_branch
[03:17] <ddaa> and we want to test that exception handling for those operations behave in a certain way, so we need to make those operations raise those errors
[03:17] <ddaa> Wearing my lifeless hat, I'd recommend using a TemplateMethod
[03:18] <ddaa> actually, two TemplateMethods
[03:18] <ddaa> BranchToMirror.openSourceBranch(self) -> srcbranch
[03:19] <ddaa> actually, no return value, just stick the value in an instance variable
[03:19] <ddaa> So, BranchToMirror._openSourceBranch(self) and BranchToMirror._pullSourceToDest(self)
[03:21] <salgado> that'd be just to make it easier to test, I guess? or do you have something else in mind?
[03:21] <ddaa> Just to make easier to test.
[03:21] <ddaa> Then you can override or assign those methods in your tests, to make them raise whatever you want.
[03:21] <ddaa> I mean assigning the methods in the instance you use in the test.
[03:22] <ddaa> salgado: does that make sense?
[03:22] <salgado> yes, definitelly
[03:23] <salgado> s/ll/l
[03:23] <ddaa> Mh, interestingly pyflakes does not catch the problem with undefined e...
[03:24] <ddaa> but there's a couple of unused imports there
[03:24] <ddaa> salgado: can you fix this socket.error and that undefined e this week?
[03:25] <salgado> ddaa, I'm fixing them as we talk
[03:25] <ddaa> fantastic
[03:27] <ddaa> salgado: actually, I'd also factor out the self.branch_status_client.mirrorFailed(self.branch_id, str(e)) into a separate method
[03:27] <ddaa> so you can also override that in tests, and have nice pure unit tests for the exception handling
[03:28] <salgado> ddaa, what about line 37? should we be catching anything other than NotBranchError there?
[03:28] <ddaa> I do not think we should catch anything else
[03:28] <ddaa> it's just implementing that logic: "if there's nothing to pull into, create the branch"
[03:29] <ddaa> any other exception would be bzrlib bug, an API change, or a deployment problem.
[03:30] <salgado> what about that socket error? I think we need to be consistent and either catch it on both (lines 37 and 42) or don't catch it at all and assume it's a bzrlib bug
[03:31] <salgado> maybe it's impossible for line 37 to raise the socketerror? (I don't think so)
[03:31] <ddaa> line 37 is local only
[03:31] <ddaa> it's just creating a target branch on the filesystem
[03:31] <salgado> right
[03:31] <ddaa> if it blows, then there's something REALLY wrong
[03:31] <salgado> I misread that as the source branch
[03:31] <salgado> it's the dest branch
[03:32] <ddaa> salgado: on the socket.error
[03:32] <ddaa> I think you are right on both accounts
[03:32] <ddaa> it is probably a bzrlib bug
[03:32] <ddaa> and it should be caught (IMO) in both places
[03:32] <salgado> what both places?
[03:33] <ddaa> 28 and 42
[03:33] <ddaa> connection time out can happen anytime
[03:33] <ddaa> I half expect that lifeless would argue that we should not catch it though
[03:34] <ddaa> and fix bzrlib instead
[03:34] <ddaa> but I'm not keen at having the branch puller go down in flames everytime a trivial bug like that creeps into bzrlib
[03:37] <salgado> but if we find a bug in bzrlib, I'd rather get it fixed there than to stick extra error-handling code into the supermirror-puller
[03:37] <salgado> because this code will probably go away once the bzrlib bug get fixed
[03:38] <ddaa> I think it's reasonable to catch some simple network errors explicitely, just to be protected against bzrlib regressions or bugs in new transports.
[03:38] <ddaa> it's not like it's requiring a lot of extra hairy logic
[03:40] <salgado> indeed it's not. as long as we don't start doing the same for other exceptions
[03:40] <salgado> and I'll leave a comment there and log a WARNING message if we catch a socket.error
[03:41] <ddaa> makes much sense
[03:41] <ddaa> would motivate kiko to nag mpool into getting it fixed :)
[03:43] <stub> I'd flag the workaround in the Launchpad code with an XXX linked to a Malone bug.
[03:44] <salgado> stub, but then somebody could be tempted to remove that "workaround" when the bug gets fixed
[03:45] <salgado> and what ddaa suggested is to leave the "workarround" there to prevent this in the future
[03:45] <stub> ok.
[03:51] <kiko-afk> the WARNING idea is a good one
[03:51] <bradb> mpt_: ping
[03:54] <kiko> SteveA, salgado: can you confirm https://launchpad.net/products/launchpad/+bug/34310 is still an issue?
[03:54] <Ubugtu> Malone bug 34310 in launchpad "people merge tests disabled temporarily" [Normal,In progress]  
[03:54] <kiko> bradb, probably asleep, no?
[03:56] <bradb> probably
[03:56] <bradb> Though you never know with New Zealanders
[04:07] <luks> hi. is there some way to remove a translation from rosetta?
[04:07] <luks> i mistakenly added both 'no' and 'nb' translations, and would need to remove one of them :/
[04:25] <kiko> matsubara, why is bug 39879 still unfixed? :-)
[04:25] <Ubugtu> Malone bug 39879 in rosetta "Translation string is crashing replacer function" [Major,Confirmed]  http://launchpad.net/bugs/39879
[04:29] <matsubara> kiko: couldn't reproduce it locally. I contacted the reporter to help me reproduce it.
[04:29] <kiko> he posted a comment today
[04:29] <kiko> is it difficult to trace in the code?
[04:30] <matsubara> kiko: nope. I just don't know how the user ended up with the string that crashes the replacer function.
[04:30] <kiko> a string? I thought it was None?
[04:32] <matsubara> sorry, it's None. I just don't know how he entered that (an empty list) in that form. 
[04:38] <matsubara> kiko: here's the form with the problem: https://launchpad.net/distros/ubuntu/dapper/+source/ubuntu-docs/+pots/desktopguide/it/+translate?offset=10. According to the OOPS message 14 is the one which is crashing the replacer function.
[04:40] <BjornT> matsubara, kiko: by looking at the oops, i would assume that the function crashes because it gets a list instead of a string.
[04:42] <kiko> and indeed we're getting a list for msgset 2446002 
[04:42] <matsubara> BjornT, kiko: and the list ended there? 
[04:42] <matsubara> s/and/and how/
[04:43] <kiko> BjornT, is there something new in zope3.2 relating to how form variables are generated? I've been seeing quite a few of similar bugs
[04:43] <SteveA> you'd get a list if the URL had two offset=whatever in it
[04:43] <SteveA> same as in earlier zope
[04:43] <kiko> so nothing changed?
[04:43] <matsubara> there's also another thing that could be causing it, if you check message 13 in the translation form, you'll notice there's lots of garbage in it.
[04:43] <SteveA> so, there's probably some code path that manages to insert two offset=whatever into the URL
[04:44] <BjornT> kiko: no, that hasn't changed. if you look at the url matsubara gave you, you'll see that 14 is listed twice.
[04:44] <kiko> yeah it is
[04:45] <kiko> but not in the UI
[04:45] <BjornT> what do you mean not in the UI?
[04:45] <kiko> well there's only one textarea for string 14
[04:46] <BjornT> really? not in the page i'm looking at.
[04:46] <BjornT> https://launchpad.net/distros/ubuntu/dapper/+source/ubuntu-docs/+pots/desktopguide/it/+translate?offset=10
[04:46] <kiko> I see only one.
[04:46] <kiko> you see two?
[04:47] <matsubara> the same string is listed in textarea 14 and 13, but textarea 13 has lots of other things, including html markup. you'll have to scroll it down inside the textarea.
[04:48] <kiko> but there is only one textarea for string 14 -- right?
[04:48] <kiko> BjornT, do you see two entries marked for 14?
[04:49] <BjornT> kiko: yes, i see two. i wonder if it has something to do with permissions, i'm not an admin, but you are.
[04:51] <kiko> okay -- matsubara only sees one too
[04:51] <kiko> I think it has to do with preferred languages
[04:52] <kiko> or your location languages
[04:56] <BjornT> kiko, matsubara: this is what i see: http://people.ubuntu.com/~bjorn/rosetta.jpg
[04:57] <kiko> yeah, what I suspected -- I don't
[04:58] <kiko> BjornT, what are your preferred languages?
[04:59] <matsubara> kiko: it's browser related
[04:59] <matsubara> i just opened it on opera
[04:59] <kiko> ah, really?
[04:59] <kiko> how interesting
[04:59] <matsubara> and it shows twice
[04:59] <kiko> logged in as you?
[04:59] <matsubara> epiphany and firefox works normally
[04:59] <matsubara> yep
[04:59] <BjornT> kiko: English, [en] 
[04:59] <kiko> thanks
[05:00] <kiko> HTTP_USER_AGENT	Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
[05:00] <kiko> matsubara, that's the agent in the OOPS. So I'm not so sure I'd jump to that conclusion
[05:00] <BjornT> kiko, matsubara: i see 14 twice in firefox as well
[05:00] <matsubara> kiko: maybe firefox 1.5 has the same problem.
[05:01] <kiko> no
[05:01] <kiko> I think it has to do with location and preferred languages
[05:01] <kiko> it's not a browser problem.
[05:01] <BjornT> in firefox i have en-us, en
[05:02] <kiko> I meant the languages that rosetta indicates as preferred/location
[05:02] <kiko> not necessarily the browser's indicated Accept-Languages
[05:04] <BjornT> kiko: oh. rosetta doesn't list any languages as my preferred ones.
[05:04] <kiko> okay. I have English and Brazilian Portuguese
[05:05] <matsubara> I have none as preferred language.
[05:06] <tilix> hi. I`m the creator of the first bulgarian Linux distribution - Tilix. Version 2.0 will be based on Ubuntu. I would like to ask is it possible to register it on Launchpad?
[05:06] <kiko> sure.
[05:07] <tilix> kiko: what should I do?
[05:08] <kiko> tilix, can you email me with details of the distribution?
[05:08] <tilix> ok
[05:08] <kiko> thanks!
[05:08] <kiko> I need a domain name, a title, summary and description.
[05:09] <kiko> once done I will reassign it to you
[05:16] <tilix> kiko: done
[05:16] <kiko> thanks
[05:21] <bradb> SteveA: Are you off reviews ATM? I notice one of my branches has been assigned to you, but it's been on PendingReviews for five days.
[05:21] <SteveA> bradb: i haven't looked in a while, despite lifeless prompting me
[05:21] <SteveA> i'll take a look tomorrow
[05:21] <bradb> ok, thanks
[05:50] <salgado> ddaa, would you like to have a look at the supermirror-puller patch?
[05:50] <ddaa> sure
[05:50] <salgado> https://chinstrap.ubuntu.com/~dsilvers/paste/fileEicRbJ.html
[05:51] <ddaa> _openSourceBranch, that reads funny :)
[05:52] <ddaa> salgado: it would be nice to add docstrings to all those methods
[05:53] <ddaa> def _openSourceBranch(self):
[05:53] <ddaa>     """Open the branch to pull from, useful to override in tests."""
[05:53] <salgado> definitely. I just wanted to make sure it looks sane first
[05:55] <ddaa> please: logger = logging.getLogger('supermirror-pull') => logger = logging.getLogger('branch-puller')
[05:57] <ddaa> +                logger.warn( +                    'Possible bug found in bzrlib:\n%s' % traceback.print_exc()) 
[05:57] <ddaa> you probably want to use canonical.launchpad.scripts.log.exception or shortException
[05:58] <ddaa> scripts.logger.log, I mean
[06:00] <salgado> ddaa, why do you want me to use the 'branch-puller' logger?
[06:01] <ddaa> because I'm just trying to get the terminology I introduced in doc/bazaar (not yet merged after two months) be used.
[06:01] <ddaa> branch-puller, branch-scanner, branch warehouse, etc.
[06:01] <ddaa> Supermirror is a collection of services, and I find it's to vague a term to be useful for technical discussion.
[06:02] <salgado> ah, I see. I thought there were a 'branch-puller' logger created somewhere
[06:03] <ddaa> salgado:  in stubMirrorFailed, I'd use a list to append to, to make sure it's called exactly once.
[06:05] <ddaa> also, in testPullFailureHandler, I'd override all of _openSourceBranch, _openDestBranch, and _pullSourceToDest, and remove the bzr tree setup at the beginning.
[06:05] <ddaa> So it's a pure unit test of the error handling.
[06:07] <ddaa> Then I'd test BzrError and socket.error explicitely for both error handlers
[06:07] <ddaa> salgado: I could come up with some more nits, but I think that's enough for today :)
[06:09] <ddaa> But I think maybe I'm not a reviewer because I'm way too picky. So maybe you should ignore some of my comments.
[06:12] <salgado> ddaa, I think most of them make sense. I just don't see why you want a "pure unit test". is it just to have it running faster than it would run as a functional test?
[06:13] <ddaa> no, that's just a nice side effect. It's to have a test that only depends on what it intends to test.
[06:13] <radix> salgado: when you're testing smaller units, when a bug happens it's easier to track down the actual problems
[06:13] <ddaa> lifeless started lecturing me this morning about separation between unit tests, feature tests, and integration tests.
[06:13] <radix> you find the smallest test that's failing
[06:14] <ddaa> salgado: what radix is saying
[06:15] <radix> woops
[06:15] <ddaa> looks like the cat tripped on the wire...
[06:16] <ddaa> matsubara: what message did you get last?
[06:16] <ddaa> hu
[06:16] <ddaa> salgado: what message did you get last? matsubara: ignore me
[06:16] <salgado> okay, I kicked the power cord again
[06:17] <salgado> I asked you the rationale for the "pure unit test" and kicked the cord after that
[06:18] <ddaa>  radix: salgado: when you're testing smaller units, when a bug happens it's easier to track down the actual problems
[06:18] <ddaa>  radix: you find the smallest test that's failing
[06:19] <ddaa> running faster is just a side effect, tests should only depend on exactly what they intend to test.
[06:19] <kiko> ideally at least
[06:20] <ddaa> yeah, yeah, you know the difference between theory and practice...
[06:26] <salgado> I thought the 'pure unit test' meant just making it non-functional. I didn't realize you wanted me to split it
[06:26] <ddaa> I did not mean that.
[06:26] <ddaa> Though that was indeed one of the additional nits.
[06:27] <ddaa> better to test the two try-except clauses separately
[06:27] <ddaa> but there is some light insanity down that road
[06:28] <ddaa> XP and refactoring purists try to write one line methods, each with its unit tests... I think that's slightly excessive :)
[06:29] <kiko> one-line methods are usually crack
[06:29] <kiko> unless they are very special semantic or syntactically
[06:29] <ddaa> there are useful there, so they can be overriden for testing :)
[06:29] <salgado> I could move it into a non-functional test class, put some stuff on setUp() and then have one test for each try-except clause
[06:30] <ddaa> salgado: how far down that road you want to go is your call. But I did not ask for it.
[06:30] <ddaa> But I do think that would better.
[06:31] <ddaa> * would be better
[06:32] <salgado> I don't like reading/writing non-doctests, so anything that I can do to make them nicer I think is worth
[06:35] <kiko> bradb, did you confirm with mpt on the design for fixing bug 977?
[06:35] <Ubugtu> Malone bug 977 in malone "Commenting on bug should optionally subscribe you" [Major,Fix committed]  http://launchpad.net/bugs/977
[06:48] <tilix> does somebody know how to add a milestone to a distro in Launchpad?
[06:59] <salgado> ddaa, do you know how to reset the logging framework on a test's tearDown() method? (I'm getting some "** Test did not reset logging framework." messages)
[07:01] <ddaa> salgado: not offhand... looking
[07:03] <ddaa> salgado: any reason why you are not passing the logger instance down from the script?
[07:03] <bradb> kiko-fud: No, tried to earlier, but he wasn't around, and I can't see anything too atrocious about how I did it (though I'm sure mpt_ could improve upon it.)
[07:04] <ddaa> doing that, you could just give the BranchToMirror instance a fake logger like in test_keyringtrustanalyser
[07:04] <ddaa> salgado: I have to run now
[07:04] <salgado> ddaa, you mean, passing the logger as an argument instead of using logging.getLogger() on BranchToMirror?
[07:05] <ddaa> yup as an argument to __init__
[07:06] <salgado> I was told this is no good. and I kind of think it's correct. after all, that's why we have logging.getLogger()
[07:06] <ddaa> alternatively you could override canonical.launchpad.scripts.logger.log._log, but that would be hackish
[07:06] <ddaa> dunno then, I'd like to help, but I have to leave
[07:06] <salgado> sure, no worries. thanks for the help. :)
[07:15] <bradb> salgado: Any chance that you'll to following up on the malone-bug-dates review?
[07:21] <salgado> bradb, yeah, I'll do that later today
[07:22] <bradb> cool, thanks
[07:28] <SteveA> hey sabdfl!
[07:30] <sabdfl> SteveA, how's it hanging?
[07:32] <SteveA> fast and loose^w^wcrisp and clean.
[07:34] <sabdfl> fast crisp and clean I LIKE IT
[07:36] <kiko> like polished bacon 
[07:42] <sabdfl> eeew
[07:43] <SteveA> kiko: i think you meant "greased lightning"
[07:43] <kiko> lightning-fried bacon
[07:44] <salgado> SteveA, I'm getting some "** Test did not reset logging framework." messages when running a test in which I do a logging.getLogger('foo').addHandler(). do you know how am I supposed to clean it?
[07:44] <salgado> s/clean/reset/
[07:44] <SteveA> salgado: sorry, no.  mail the list.  stub or bjorn or jamesh may know.
[07:45] <SteveA> kiko will tell you, jamesh knows everything
[07:45] <kiko> grep(1) may know as well
[07:46] <salgado> but grep's not as clear as jamesh. :)
[07:47] <salgado> btw, I've already ask grep, and it seems that it's checking logging._handlerList
[07:48] <salgado> but I made my tests restore that to the value before running the tests, and it still complains
[07:48] <SteveA> it may be that it wants an API to be used
[07:48] <kiko> quite likely
[07:49] <salgado> I first thought that logger.removeHandler() would do it
[07:49] <salgado> but it doesn't
[07:54] <BjornT> salgado: how about canonical.testing.reset_logging()?
[07:57] <stub> salgado: What Bjorn said. Keep the logger.removeHandler() in though too - it is just the test framework being too dumb to know that you reset stuff, but if we can fix that the reset_logging() will be unnecessary.
[08:05] <kiko> stub, any word on staging oops logs?
[08:07] <salgado> aha, that's great. thanks stub and BjornT. :)
[08:08] <kiko> anyone seen carlos?
[08:08] <bradb> might be a holiday in spain?
[08:09] <kiko> mmmm
[08:09] <bradb> and i think he said something about being far away from a computer, IIRC
[08:09] <kiko> oookay
[08:32] <kiko> matsubara, did you file any oops bugs today?
[08:32] <kiko> ddaa, did you see the SOMTORError in today's OOPS report?
[08:36] <matsubara> kiko: yes
[08:36] <kiko> matsubara, which ones?
[08:37] <matsubara> kiko: let me check
[08:38] <matsubara> kiko: bugs 41139, 41138, 41108, 41104
[08:38] <Ubugtu> Malone bug 41139 in rosetta "Export request form should check for uniqueness of entry" [Normal,Unconfirmed]  http://launchpad.net/bugs/41139
[08:38] <Ubugtu> Malone bug 41138 in malone "+viewstatus crashes when opening a remote bug" [Normal,Confirmed]  http://launchpad.net/bugs/41138
[08:38] <Ubugtu> Malone bug 41108 in launchpad "launchpad.net/foaf returns a blank page instead of a NotFound." [Normal,Confirmed]  http://launchpad.net/bugs/41108
[08:38] <Ubugtu> Malone bug 41104 in soyuz "Validate query string in +builds/$builder" [Normal,Confirmed]  http://launchpad.net/bugs/41104
[08:39] <kiko> matsubara, is the poll crash an old one?
[08:41] <matsubara> kiko: missed that one. I'll look for a dupe otherwise I'll file a new bug.
[08:42] <kiko> matsubara, and the branch duplicity one? that looks like a serious bug -- ddaa?
[08:43] <matsubara> kiko: that one I think I've reported some time ago. I'll check it too
[08:43] <kiko> matsubara, also, can you tell me what bug is reported for the fti crash with exclamation marks?
[08:44] <matsubara> kiko: bug 39828
[08:44] <Ubugtu> Malone bug 39828 in launchpad "FTI queries die if ! in or at the end of a word" [Normal,In progress]  http://launchpad.net/bugs/39828
[08:44] <matsubara> that one?
[08:45] <kiko> yes
[08:45] <kiko> thank you
[08:46] <Goshawk> hi
[08:47] <matsubara> kiko: the poll oops looks like bug 2732
[08:47] <Ubugtu> Malone bug 2732 in launchpad "Adding a poll with a finish date before start date causes error" [Normal,Confirmed]  http://launchpad.net/bugs/2732
[08:47] <Goshawk> i've registered a project but i don't use CVS neither svn. I use bzr (Bazaar-NG). How can i import it in launchpad?
[08:48] <kiko> matsubara, is it the same oops sig?
[08:49] <matsubara> kiko: 2732 doesn't have any oops id.
[08:49] <matsubara> but according to the bug description and the constraint triggered by the oops looks like the same issue.
[08:50] <kiko> okay, annotate with oops ID then
[08:54] <LedStyle> Can someone help-me with a problem in Rosetta?
[08:54] <mdke> LedStyle, ask away
[08:55] <LedStyle> I can't download the file compiled... the MO version!
[08:55] <LedStyle> And cant compile the PO here. There's an inconsistence
[08:55] <kiko> what happens when you compile?
[08:55] <LedStyle> Well the log is in portuguese
[08:55] <LedStyle> inkscape.po:8199: definio duplicada de mensagem
[08:55] <LedStyle> inkscape.po:4151: ...esta  a localizao da primeira definio
[08:55] <LedStyle> msgfmt: encontrado 1 erro fatal
[08:56] <LedStyle> Duplicated message definition
[08:56] <LedStyle> fatal error
[08:56] <kiko> that may be a bug
[08:56] <kiko> in rosetta. but I thought we had fixed that already...
[08:56] <LedStyle> Can i remove the duplicate part in the PO file and upload?
[08:57] <kiko> LedStyle, well, it's definitely weird.
[08:57] <kiko> the best person to answer is carlos but he is on holiday today
[08:57] <kiko> LedStyle, perhaps filing a bug and adding the file as an attachment is best
[08:58] <kiko> let me know what the bug # is
[08:58] <LedStyle> ok
[08:58] <LedStyle> Thanks for help!
[08:59] <kiko> BjornT, ping?
[09:05] <LedStyle> kiko, #41163
[09:05] <kiko> thanks
[09:06] <LedStyle> https://launchpad.net/distros/ubuntu/+bug/41163
[09:06] <Ubugtu> Malone bug 41163 in Ubuntu "PO file can't be compiled" [Normal,Unconfirmed]  
[09:06] <kiko> LedStyle, you reported it against Ubuntu?
[09:06] <LedStyle> Ohh Sorry...
[09:06] <LedStyle> hahahah
[09:06] <LedStyle> How can a remove?
[09:07] <LedStyle> i*
[09:07] <kiko> you do the following:
[09:07] <kiko> a) reject the Ubuntu status
[09:07] <kiko> b) Report it as affecting Upstream
[09:09] <LedStyle> How to reject?
[09:09] <LedStyle> Finded
[09:09] <LedStyle> :P
[09:11] <matsubara> kiko: about the SOMTORError in today's oops report, I couldn't find a bug, so I reported it as bug 41164
[09:11] <Ubugtu> Malone bug 41164 in launchpad "IPerson.getBranch() should return only one result" [Normal,Unconfirmed]  http://launchpad.net/bugs/41164
[09:11] <LedStyle> kiko, ehick packate?
[09:11] <LedStyle> which*
[09:11] <kiko> LedStyle, rosetta
[09:12] <LedStyle> kiko, rosetta is not in the list
[09:12] <matsubara> LedStyle: https://launchpad.net/distros/ubuntu/+bug/41163/+upstreamtask
[09:12] <Ubugtu> Malone bug 41163 in Ubuntu "PO file can't be compiled" [Normal,Rejected]  
[09:13] <uniq> do I get a ubuntu.com e-mail forward automatically when registering in launchpad?
[09:13] <kiko> LedStyle, you are indicating it against a distribution -- it should be upstream, not in a package.
[09:13] <kiko> uniq, no.
[09:13] <highvoltage> hi. do i file launchpad bugs at https://launchpad.net/malone/bugs/+package too?
[09:14] <LedStyle> Sorry but i dont know anything about this Launchpad system!
[09:14] <uniq> kiko: do you know what the criterias are?
[09:14] <kiko> uniq, being an Ubuntu member.
[09:15] <uniq> kiko: ok, i am.
[09:15] <uniq> do you know who to ask to setup a forward?
[09:15] <kiko> uniq, it should work automatically if you are a member
[09:16] <mdke> uniq, it's automatic, on your launchpad username
[09:16] <uniq> in that case it doesn't work.
[09:18] <LedStyle> kiko, 
[09:18] <kiko> LedStyle?
[09:18] <LedStyle> Inkscape bug tracker?
[09:18] <kiko> LedStyle, what?!
[09:19] <LedStyle> kiko, sorry but im lost here hehehe
[09:19] <mdke> uniq, you can complain to elmo about it not working
[09:19] <LedStyle> Were exactly i have to report the possible bug in rosetta?
[09:19] <kiko> LedStyle, report the bug upstream, on the product rosetta.
[09:19] <kiko> matsubara already showed you above:
 LedStyle: https://launchpad.net/distros/ubuntu/+bug/41163/+upstreamtask
[09:19] <Ubugtu> Malone bug 41163 in Ubuntu "PO file can't be compiled" [Normal,Rejected]  
[09:19] <uniq> mdke: ok, thanks :)
[09:20] <LedStyle> kiko, but in the Remote Bug Tracker
[09:20] <kiko> LedStyle, it's not mandatory -- just leave it empty
[09:21] <LedStyle> And Remote bug to?
[09:21] <kiko> yeah
[09:21] <LedStyle> ahhhh
[09:21] <LedStyle> https://launchpad.net/products/rosetta/+bug/41163
[09:21] <Ubugtu> Malone bug 41163 in rosetta "PO file can't be compiled" [Normal,Unconfirmed]  
[09:21] <kiko> thanks
[09:22] <LedStyle> tks kiko 
[09:22] <kiko> LedStyle, please include in the report the URL you used to download the po-file
[09:25] <LedStyle> Done kiko 
[09:25] <kiko> thanks!
[09:26] <LedStyle> A friend here in the team say: This is happening with other packages to!
[09:26] <kiko> LedStyle, are you translating the ubuntu package or the upstream product?
[09:26] <LedStyle> ubuntu package
[09:26] <kiko> thanks.
[09:27] <LedStyle> https://launchpad.net/distros/ubuntu/dapper/+source/inkscape/+pots/inkscape/pt_BR/+translate
[09:31] <salgado> kiko, do you have a box running dapper close to you?
[09:31] <kiko> sorta, salgado 
[09:33] <LedStyle> Afff
[09:33] <LedStyle> Hey kiko 
[09:33] <LedStyle> Im doing some tests here
[09:34] <LedStyle> Im think this can be a bug in gtranslator. But kiko the rosetta is not sending the MO file!
[09:36] <sivang> re
[09:39] <kiko> LedStyle, mmm? I thought you said the file you /downloaded/ contained duplicate definitions?
[09:41] <LedStyle> kiko, yeah, but i use only gtranslator here. Ive never tried open the file in gedit for example. But why the rosetta cant send-me the MO file compiled in this package? The system maybe cant compile them!
[09:41] <kiko> that's what I suspect as well
[09:42] <LedStyle> kiko, are u brazilian? Can we talk in portuguese?
[09:42] <kiko> LedStyle, I don't have a lot of time unfortunately -- carlos will look at your report tomorrow, don't worry
[09:43] <LedStyle> fine
[09:44] <LedStyle> And sorry because i dont know use launchpad very well!
[09:44] <kiko> nothing to be sorry about
[09:44] <kiko> we're a bit too much on the complicated side
[09:44] <kiko> but we're working on it
[09:45] <LedStyle> Rosetta dont like me... hehe
[11:57] <mdke> I just closed 3 or 4 bugs which were marked as duplicates of a bug which had been fixed already. I know that malone doesn't have any sane duplicate handling yet, I was wondering if there is a quick workaround for this. Like producing a list of the bugs which are marked as fixed and have the most number of duplicates? then we can go and close em all
[12:01] <lifeless> salgado: ddaa - socket error is likely to not be caught by bzrlib
[12:01] <lifeless> and the nagging will be noise immediately. 
[12:01] <lifeless> so I don't think thats sane.
[12:02] <lifeless> if you consider it a bug in bzrlib, file a bug.
[12:03] <lifeless> also the log comment isn't accurate: its not about bzr regressions, its about this being an exception that we've decided its safe to continue running after it occurs
[12:03] <lifeless> (see the existing comments in that file)