/srv/irclogs.ubuntu.com/2006/04/29/#launchpad.txt

=== mpool [n=mbp@ppp112-44.static.internode.on.net] has joined #launchpad
=== radix [n=radix@dsl092-068-248.bos1.dsl.speakeasy.net] has joined #launchpad
=== jinty [n=jinty@173.Red-83-56-136.dynamicIP.rima-tde.net] has joined #launchpad
=== Keybuk [n=scott@syndicate.netsplit.com] has joined #launchpad
=== mpt_ [n=mpt@219-89-151-215.jetstart.xtra.co.nz] has joined #launchpad
=== mpt__ [n=mpt@219-89-152-72.jetstart.xtra.co.nz] has joined #launchpad
=== Keybuk [n=scott@syndicate.netsplit.com] has left #launchpad [""]
=== jamesh [n=james@203-166-236-175.dyn.iinet.net.au] has joined #launchpad
jameshlifeless: I played around with siproxd a bit on the weekend: it doesn't seem to be 64-bit safe03:49
lifelessjamesh: aw crikey03:49
lifelessjamesh: filed bugs ?03:50
jameshI fixed a few crasher bugs in it, but it still seems to have some problems03:50
jameshhttps://launchpad.net/distros/ubuntu/+source/siproxd/+bug/4091403:50
UbugtuMalone bug 40914 in siproxd "siproxd segfaults on AMD64" [Normal,Unconfirmed]  03:50
lifelessheh, I meant upstream :)03:50
jameshapparently they didn't know that sizeof(size_t) isn't always equal to sizeof(int)03:50
lifelessmeh03:51
lifelesssizeof(not-my-type) == sizeof(mytype) is not a truism.03:51
lifelessits like the sizeof(int) == sizeof(void *) idiocy that I've seen people indulge in03:51
jameshso passing an (int *) to a function expecting a (size_t *) didn't do what they want03:52
lifelesssurely you get a compiler complaint on that ?03:52
jameshin fact, it seemed to zero out the port variable they then used to send UDP packets03:52
jameshyou get a complaint on AMD64 (which is how I found it)03:52
lifelessright03:52
lifelessbut not where it is -=03:52
=== jamesh goes to file bug upstream
jameshlifeless: well, shtoom seems to work through siproxd now, but ekiga isn't03:59
lifelessinteresting04:00
lifelesswhat happens with ekiga04:00
lifelesshave you unset its stun setting?04:00
jameshI turned off the stun stuff04:00
jameshsays "could not connect to remote host" in the status bar.  I haven't investigated further yet04:01
lifelessk04:08
lifelessI've shown you subunit now haven't I? 04:08
jameshyeah04:09
lifelessgood. with the shell/C/C++ extensions ?04:09
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:10
jameshyou told me about the extensions, but I haven't played with them04:11
=== mpt_ [n=mpt@219-89-152-72.jetstart.xtra.co.nz] has joined #launchpad
=== mpt__ [n=mpt@219-89-152-72.jetstart.xtra.co.nz] has joined #launchpad
=== stub [n=stub@ppp-58.8.4.140.revip2.asianet.co.th] has joined #launchpad
=== raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad
mpoolmpt__: ping?06:05
=== mpt_ [n=mpt@219-89-152-72.jetstart.xtra.co.nz] has joined #launchpad
=== LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad
SteveAgood morning06:34
=== mpt__ [n=mpt@222-154-152-137.jetstream.xtra.co.nz] has joined #launchpad
dilysMerge to devel/launchpad/: Refactor PostgreSQL session support, removing race condition embedded in SQL [r=BjornT]  (r1816: Stuart Bishop)06:37
mpoolhi SteveA06:45
SteveAhello martin06:50
=== egerds [n=free@68-115-12-52.dhcp.stpt.wi.charter.com] has joined #launchpad
stubEither Steve is getting earlier or my night outs are getting later...07:00
SteveAcouldn't sleep07:00
=== stub goes to grab breakfast
SteveAthere's a strange buzzing sound i could hear all night07:01
SteveAi thinkn my neighbour above has a noisy computer07:01
SteveAand it is touching something that makes it resonate into my bedroom07:01
egerdsI am trying to register for ubuntu07:01
egerdsnvm07:02
=== mdz [n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net] has joined #launchpad
=== egerds [n=free@68-115-12-52.dhcp.stpt.wi.charter.com] has left #launchpad []
=== Podovan [n=Miranda@n117h146.uncnet.ru] has joined #launchpad
PodovanHello anybody!07:35
=== mpt_ [n=mpt@219-89-141-214.jetstart.xtra.co.nz] has joined #launchpad
=== SnkBite [n=SnkBite@212.25.63.82] has joined #launchpad
SteveAmpt_: voice call?07:46
=== rlaager [n=rlaager@trcpe2-167.mncable.net] has joined #launchpad
rlaagerHas 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:51
BjornTrlaager: which bug? you should be able to close it.07:52
jameshrlaager: got a pointer to it?07:52
rlaager3899907:52
jameshwhat error do you get when you try to close it?07:53
rlaagerI don't get an error. There's just no arrow to click to get at the close stuff...07:54
jameshrlaager: just click on the row07:55
rlaagerHmm, perhaps that's moved now? I don't see it for bugs I filed either.07:55
rlaagerahh, thanks07:55
SteveABjornT: we should meet for lunch sometime07:57
SteveAand maybe a code review session or two07:57
lifelessmmm, code review07:59
BjornTSteveA: yeah we should, it's easier for me now that i have a car. how about lunch tomorrow?08:00
SteveAit's great weather for cycling.  i should pick up my bike from the POV office08:02
SteveAsure, lunch tomorrow08:02
BjornTyeah, the weather is great for cycling. that's why i suggested lunch tomorrow, since i'm planning to go for a ride today.08:04
sivangmorning all08:11
=== frodon_ido [n=patrick@ip-213-49-233-214.dsl.scarlet.be] has joined #launchpad
SteveABjornT, stub: what's the story about getting zero soft timeouts?08:41
BjornTSteveA: i sent a patch. do you want me to merge it without tests, or should i add tests first?08:42
=== rlaager [n=rlaager@trcpe2-167.mncable.net] has left #launchpad []
jameshSteveA: BjornT's patch and analysis sounds correct08:43
SteveAhi jamesh 08:43
jameshhi SteveA 08:43
SteveAplease merge it, get it onto staging, and see if we can provoke a soft timeout08:43
SteveAif you're feeling keen...08:43
SteveAadd a page that checks the logged in user for being a launchpad developer (or uses permissions)08:44
SteveAand does something evil to provoke a soft timeout08:44
SteveAby pausing for the length of time specified to be a soft timeout08:44
jameshBjornT: I suppose a special page that always timed out plus a page test that invoked it would be the way to go08:44
SteveAthen at least we can test it in practise08:44
SteveAjamesh: yes.  although, before running that page test, i'd be inclined to temporarily set the soft timeout value to be small, like a few secs08:45
jameshyeah08:45
=== rob [i=Robert@freenode/staff/ubuntu.member.rob] has left #launchpad ["Leaving"]
SteveABjornT: please merge the stuff, and do the test later if you need to08:46
SteveAi think it is important that we see soft timeouts08:46
BjornTok, i'll merge it now, and add the test later.08:47
lifelesswell, how long is it going to take to write the test? 08:47
SteveAmister testing fascist!08:48
lifelessindeed08:49
lifelesssoft timeouts are fragile. they have stopped more than once now.08:49
lifelessI'd like to stop that.08:49
BjornTi suppose the test won't take too long to write. i'll do it before i merge then.08:52
BjornTjamesh: what's the easiest way of checking that a soft timeout occurred?08:53
BjornTor rather, has been logged08:53
=== mpt [n=mpt@219-89-132-30.jetstart.xtra.co.nz] has joined #launchpad
=== ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad
jameshBjornT: I think globalErrrorUtility.lastid will get incremented (or reset if we pass from one day to the next)08:56
jameshBjornT: 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 OOPS08:57
=== mpt_ [n=mpt@219-89-157-151.jetstart.xtra.co.nz] has joined #launchpad
mpt_SteveA, sure09:28
SteveAmpt_: ok09:40
SteveAmpt_: i'm running skype now09:41
=== doko_ [n=doko@dslb-088-073-097-132.pools.arcor-ip.net] has joined #launchpad
SteveAmpt_: ping09:46
SteveAmpt_: 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.09:48
=== SnkBite [n=SnkBite@212.25.63.82] has joined #launchpad
=== snail_afk is now known as snail
=== raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad
=== frodon_ido [n=patrick@ip-213-49-233-214.dsl.scarlet.be] has left #launchpad []
=== sits [n=sits@cpc3-cwma2-0-0-cust739.swan.cable.ntl.com] has joined #launchpad
=== stub [n=stub@ppp-58.8.4.140.revip2.asianet.co.th] has joined #launchpad
=== WaterSevenUb [n=WaterSev@195-23-238-207.nr.ip.pt] has joined #launchpad
BjornTjamesh, SteveA: please someone review https://chinstrap.ubuntu.com/~dsilvers/paste/fileV3ytab.html10:36
=== SteveA looks
SteveABjornT: +from time import sleep, time10:38
SteveAi'd rather you imported "time" and used "time.time" and "time.sleep"10:38
jameshBjornT: any reason for calling sleep() in a loop, rather than just sleeping for the appropriate amount of time?10:39
=== mpt [n=mpt@222-154-113-84.jetstream.xtra.co.nz] has joined #launchpad
BjornTjamesh: well, is that reliable? is sleep() guaranteed to sleep at least the specified time?10:40
jameshBjornT: I suppose it can get interupted, yeah.10:41
SteveAyou could do max(time_left, 0.1)10:41
SteveAbut that's getting kinda complex10:41
SteveAyou already wait what should be the right time, and then busy loop the rest10:41
SteveAperhaps add a comment saying that10:41
BjornTyeah, i comment is probably good to have there10:42
SteveAr=me10:47
BjornTthanks10:47
ddaahey jamesh10:54
ddaahow much longer are you going to be around today?+10:54
jameshhi ddaa 10:56
jameshan hour or so10:57
jameshddaa: was looking at moving the branch pull list stuff into the authserver10:57
ddaajamesh: did I ask you for that already?10:58
ddaaI think not, in any case, I intended to :)10:58
jameshddaa: I also got the importd error reporting script working against the sample data you sent last week10:59
=== dsas [n=dean@host86-129-9-197.range86-129.btcentralplus.com] has joined #launchpad
=== Bluekuja [n=bluekuja@host122-214.pool8249.interbusiness.it] has joined #launchpad
=== erdalronahi [n=erdal@p50875EE4.dip.t-dialin.net] has joined #launchpad
erdalronahiHi all,11:54
erdalronahithe ooo-templates have once again been imported into Rosetta/Dapper11:54
erdalronahiand this time all our translations have been overridden by the English originals11:54
=== dsas [n=dean@host86-129-9-197.range86-129.btcentralplus.com] has joined #launchpad
erdalronahiIt's even worse than before11:55
erdalronahiBefore only the untranslated strings have become English, now ALL are overridden11:55
lifelessreview meeting in 511:56
dokoerdalronahi: your statement doesn't help, please submit a bug report, subscribing carlos and me11:59
erdalronahiyes, I'll do that11:59
erdalronahijust wanted to inform you,11:59
erdalronahibecause carlos said last week 11:59
erdalronahiI should tell him if it doesn't work12:00
=== sits [n=sits@cpc3-cwma2-0-0-cust739.swan.cable.ntl.com] has left #launchpad []
mptawesome12:07
mptSomeone found a bug report in Malone by googling the incorrect string he was seeing12:08
mptand the bug report is the first of 33 results12:08
mptyay Malone12:08
mptboo https://bugzilla.mozilla.org/robots.txt12:08
erdalronahidoko, ok, filed the bug12:08
mptboo http://bugzilla.gnome.org/robots.txt12:08
dokoerdalronahi: thanks12:09
erdalronahidoko, you're welcome12:09
erdalronahiin fact, thank you for all your efforts12:09
dokonp12:12
lifelesshi12:22
lifelesswho is here ?12:22
BjornTi'm here. lifeless, isn't the meeting in 35 minutes though?12:26
lifeless1100UTC12:28
lifelessmeh, yes12:28
lifelessmeeting in 3012:29
SteveAhi12:32
SteveAmpt: you're still around?12:33
=== mpt_ [n=mpt@219-89-142-251.jetstart.xtra.co.nz] has joined #launchpad
SteveAmpt_: you're still around?12:33
SteveAyou should think about getting a shell account somewhere, and using irssi12:33
SteveAso you don't drop off irc so much12:33
SteveAscreen + irssi12:34
lifelesslike chinstrap12:36
lifeless;)12:36
=== sivang [n=sivang@piware.de] has joined #launchpad
mpt_SteveA, yep12:38
SteveAmpt_: 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 solved12:39
=== jinty [n=jinty@173.Red-83-56-136.dynamicIP.rima-tde.net] has joined #launchpad
=== Bluekuja [n=bluekuja@host199-235.pool8254.interbusiness.it] has joined #launchpad
mpt_at least one of them being solved would be nice12:39
mpt_SteveA, sure12:39
=== SnkBite [n=SnkBite@212.25.63.82] has joined #launchpad
lifelessok12:59
lifelessmeeting time in 112:59
lifelessok, whose here now ?01:02
BjornTi'm here01:03
lifelessjamesh ?01:03
lifelessSteveA: ?01:03
lifelesskiko ?01:03
lifelessmpt_: ?01:03
mpt_Meeting now?01:03
mpt_what for?01:03
lifelessreview team01:03
lifelesswhich you are partof for the ui reviews ;001:04
mpt_Another evening I have to stay up late?01:04
mpt_yayfor01:04
lifelessnah01:05
lifelessif you are here, I appreciate your attendance01:05
lifelessif you aren't, its fine. its not a must-come-every week meeting01:05
mpt_ok01:05
lifelesspartly because the reviewers are all fairly self guided01:05
lifelessso next meeting, may 1st, same bat-time, same bat-channel ?01:06
BjornTmay 1st is a holiday in some countries01:06
lifelessmayday ?01:07
ddaahey mpt01:07
ddaa(no need to say more :)01:07
lifelessBjornT: is it a holiday for you ?01:07
BjornTlifeless: yeah01:07
lifelessok, well you get a day off then :)01:08
lifelessI think its varied enough to not worried, just note your absence after this meeting on the agenda for the next01:08
BjornTwill do01:09
lifelessqueue status01:09
lifelessI have to get to ddaa's branch-scanner for a re-review01:09
lifelessand the small-fixies branch in jamesh' queue is looking a little ripe01:09
lifelessother than that, the needs-review section is looking good.01:09
lifeless37  spiv  salgado/launchpad/shipit-for-dapper  3173  merge  7345  14:1501:10
lifeless31 BjornT spiv/launchpad/unicode-simple-sendmail 3284 merge (1) 149 17:0501:10
lifelessthose two are in needs reply.01:10
lifelessspiv is on leave..01:10
lifelessBjornT: what about your branch - is it likely to land soon ?01:10
lifelessmeh. my bad01:10
lifelesssalgado is the branch owner, hes still asleep01:10
lifelessmerge-conditional seems to be the killer region though01:11
lifelessdavids baz2bzr branch is at 54 days01:11
lifelesswhich has to be some sort of records01:11
BjornTlifeless: 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
lifelessBjornT: cool01:12
lifelessany comments, issues with reviews at the moment ?01:13
lifelessjamesh: the pending reviews page is not showing the branches in the ui queue - they are also in other peoples queues.01:14
lifelessjamesh: 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:14
=== ddaa is not sure exactly what baz2bzr is blocked on nowadays
lifelessand 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
lifelessddaa: on you from the look of it01:15
lifelesspossibly on the sourcecode/ merge fixes01:15
lifelessin which case make a note of that on the wiki :001:16
ddaaMh... I think it was related to some new test failure, related to to tarball fixtures or somesuch01:16
lifelessLet me take  moment to say - tarballs fixtures are really bad news.01:17
lifeless99% of the time. This may be that 1% where they make sense, but I don't believe so.01:17
ddaacan we talk about that now, or am I disrupting the reviewer meeting?01:19
lifelessBjornT: so, no comments/issues on reviews?01:19
BjornTno, no comments from me01:19
lifelessmpt_: how are you handling the ui review load? 01:19
lifelessmpt_: are there things the reviewers can watch out for ?01:19
lifelessddaa: also, please action the bzr-documentation branch, you have mail from me about that.01:20
lifelessddaa: tarballs, we can talk in a few minutes.01:20
ddaadoc-bazaar, date of the mail? I don't see anything new01:22
ddaa(oops, sorry for disrupting meeting)01:22
lifelessok, I'll take that as meeting-closed time.01:22
lifelessthanks for coming01:22
lifeless(unless there is other business01:22
lifeless)01:22
lifelessok, meeting-over01:23
ddaalifeless: doc-bazaar is already acted on01:25
ddaathat's why I set it up to needs-review again01:25
mpt_lifeless, my load is about 1 branch every 3 months, but currently I have 2 very large one01:26
mpt_s01:26
mpt_sabdfl's one is 800 K01:26
lifelessddaa: I didn't get a reply to my mail01:26
lifelessmpt_: it might be a good idea to put those branches in the wiki page01:26
lifelessddaa: ok, lets talk tarballs01:28
ddaaso, the use case there was: take a baz archives produced by cscvs, and feed it to baz_import01:29
ddaathree options:01:29
ddaa0. all in test: create cvs repo, run cscvs01:30
ddaa1. harcoded in test: create baz archive with hardcoded log messages01:30
ddaa2. tarball01:31
ddaa0 is ridiculously overcomplex for the case01:31
ddaa1. 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 code01:32
ddaa2. 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 baz2bzr01:32
ddaaat the rate it's going, it will be obsolete before being merged01:33
ddaalifeless: do you consider that's a fair assessment?01:33
lifelessmmm01:35
lifelessour converted archives are around now01:35
lifelesswhat are you specifically testing here ?01:35
ddaabaz2bzr is the stuff that does the incremental conversion in importd01:35
ddaait's testing end-to-end functionality of the conversion to bzr, both initially (new imports!) and incrementally (daily syncs).01:36
lifelessI think based on that that 2 is not a valid test01:36
ddaathen neither would be 101:37
lifelessbecause its avoiding being an end to end test01:37
ddaaand doing 0 would just be crazy01:37
lifeless1 is valid because it is testing that things created /now/ by the current code also import with the current code01:38
ddaaduh?01:38
ddaanow, 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-import01:39
ddaait's not buying anything functionaly. I understand 1 is more readable than 2, but that's all.01:39
ddaaand the "end-to-end" I was initially referring to was "both end of the baz2bzr script"01:40
mpt_lifeless, done01:40
lifelessddaa: are you testing invocation of baz2bzr? or baz2bzr internals ?01:40
lifelessddaa: speaking of baz2bzr, there is a pybaz urgent-bugfix-for-baz2bzr in your mailbox.01:41
=== stub [n=stub@ppp-58.8.4.140.revip2.asianet.co.th] has joined #launchpad
lifelessddaa: 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:42
ddaalifeless: testing both01:43
ddaathe baz_import behaviour is tested by running the baz2bzr script01:43
lifelessso, invocation of baz2bzr by importd ?01:43
ddaano, invocation of baz2bzr by the test case... hu...01:43
ddaausing the same CLI used by importd01:43
lifelessso, I'm confused.01:44
lifelessbecause baz2bzr already has unit tests for the cscvs headers, blackbox tests for its use as a command, etc.01:44
ddaasure01:44
lifelesssurely the only thing we need to be adding tests for is invocation by importd ?01:44
lifelessand cscvs-specific headers are really irrelevant to this.01:45
ddaabut the tests here checks that the _right_ bzrtools is being used01:45
=== cprov [n=cprov@201-43-145-81.dsl.telesp.net.br] has joined #launchpad
ddaaintegration testing01:45
lifelesswhat do you mean01:45
lifelessby 'right'01:45
ddaamakes 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
ddaaerrors happen01:46
cprovgood morning01:46
lifelessddaa: you know the hierarchy of testing? Many unit tests, some ui tests, very few end to end tests ?01:47
=== bradb [n=bradb@modemcable092.66-130-66.mc.videotron.ca] has joined #launchpad
ddaain particular, that test check things like "just the right revprops are there" (i.e. no branch-nick)01:47
lifelessddaa: what I am hearing from you sounds like a schizophrenic test01:47
ddaawhich, we have seen, is useful to check redundantly01:47
lifelessyou have said it is testing:01:49
lifelessend to end baz2bzr01:49
lifelessinvocation of baz2bzr by importd01:49
ddaanope01:49
lifelessbaz2bzr internals [cscvs-revision properties] 01:49
ddaaI do not think I said that.01:49
lifeless21:36 < ddaa> it's testing end-to-end functionality of the conversion to bzr, both initially (new imports!) and incrementally (daily  syncs).01:50
ddaaright01:50
lifeless21:43 < ddaa> no, invocation of baz2bzr by the test case... hu...01:50
lifeless21:43 < ddaa> using the same CLI used by importd01:50
ddaaand doing that, checks proper handling of cscvs metadata in the output of baz2bzr01:50
ddaathe interface to baz2bzr used is the CLI, importd uses the CLI too01:50
lifelessa good test tests one thing01:51
ddaait tests one thing01:51
lifelessit makes tests faster, easier to debug, more robust.01:51
lifelessif it testeed one thing, you could have told me that at the beginning.01:51
ddaait test "baz2bzr, run from the CLI, convert a baz branch produced by cscvs into the proper bzr data"01:52
lifelessddaa: and it tests that your custom ui factory is used01:52
ddaa"ddaa: so, the use case there was: take a baz archives produced by cscvs, and feed it to baz_import"01:52
ddaamh... right, I was being unclear01:53
lifelessI think the test is unclear too.01:53
lifelessfor instance.01:53
ddaalifeless: as as matter of fact, the test for the UI factory is distinct from the test for the bzr output01:53
mpt_ddaa, Wednesday-ish for your review01:54
lifeless'test that baz2bzr can be run from the cli by importd' 01:54
ddaano "by importd"01:54
lifelessddaa: its already tested that it can be run from the cli. No need to write a new test for that.01:54
ddaathis is a test for baz2bzr, no importd stuff here, no Job01:54
lifelessddaa: think about this in TDD terms, we want to write a test that will FAIL today.01:54
ddaaall that code was written in TDD01:55
lifelessddaa: so your tests should be testing stuff that isn't already tested and working - by definition.01:55
lifelessddaa: 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
ddaafirst, I wanted to test bzr output, then CLI factory for the conversion phase, then publishing, then CLI factoriy for the publishing phase01:56
ddaaI do not have fun. I think this conversion is wearing me down as much as it is wearing you down.01:56
=== jinty [n=jinty@84.Red-83-55-199.dynamicIP.rima-tde.net] has joined #launchpad
lifelessso, lets break this down into those bits01:59
lifelesswhat was wrong in the bzr output you wanted to fix  ?01:59
ddaalifeless: 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.01:59
ddaaBut I do not, because baz_import belong to a different tree, and may therefore not be the right version.02:00
lifelessddaa: I would write a single smoke test for the end to end behaviour desired. 02:00
lifelessddaa: as a smoke test, I'd seriously do cvs<-....>bzr02:00
lifelessbecause its a single test, meant to be incredibly sensitive to changes, not fine grained unit tests02:01
ddaaI agree that's the Right Way of doing it.02:01
lifelessbut in general we dont test across-trees in launchpad02:01
lifelesswe don't test that we have the right zope, the right cscvs, the right pybaz02:02
lifelessin production thats the responsibility of the person doing the rollout02:02
ddaaBut since it's throwaway code, cscvs and baz will be stable for the lifetime of the code, I decided to cut costs.02:02
lifelessas we dont run the test suite on the production servers, for good reasons, it *cannot* be caught by tests.02:02
ddaaI 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 catch02:04
lifelessI 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
lifelesssome people manage their databases like that - but we dont, and I dont see this as being functionally different for the described case.02:05
ddaacan turn that into an arch archive created by hand if you are concerned about readability.02:05
ddaaby hand = by the test case02:05
lifelessI'm worried about several things02:06
lifelessbzr is bad on binary files at the moment02:06
lifelessreally bad02:06
lifelessI'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:06
ddaaokay, will waste the tarball and create the archive in the test suite02:07
lifelessand clarity here - in a complex code base - is extremely important.02:07
lifelessI'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
lifelessthank you02:08
lifelesscan we chat about 2 other things quickly ?02:08
ddaalifeless: I think the coverage of baz2bzr is more than adequate02:08
ddaago on02:08
lifelesspybaz - I have sent you a patch log mangling patch02:09
lifelessthis may fix some of the blacklist imports02:09
lifelesscan you please as a priority give me a review for it? Its testless for a number of reasons. 02:09
lifelesswhat was the other thing... oh yeah02:10
ddaaI 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 wrong02:10
ddaaalso, I do not understand what can produce the problem.02:10
lifelessI want to update rocketfuel to baz2bzr and bzr 0.8 rc2 this week02:10
lifelessddaa: tla produced the problem ;002:10
ddaawhat input to tla02:11
lifelessit took a commit message from a user than had a pseudo header02:11
lifelesssummary: blah02:11
lifelesskeyworkds: more blah02:11
lifelessthis is not an rfc2822 header: foo bar02:11
lifeless02:11
lifelessmore content here02:11
ddaawould "applied patch not a header" override "applied-patches"?02:12
lifelessthe 'this is not'... line should have been put in the body of the message02:12
lifelessddaa: applied-patches isn't a tla internal header, and no, IIRC last header wins02:12
ddaaBTW, your mail does not appear to include a patch02:13
lifelessanyway, instead of putting them in the body, it leaves that 'this is not..' psuedo header in the header section of the message.02:13
ddaaso it's difficult for me to apply it :)02:13
lifelessdone02:14
ddaaokay I think I understand02:14
ddaawe ended up with non-RFC822 data02:14
lifelessyup02:14
ddaaand the stdlib that we use to parse the log message barfed02:15
lifelessand the email python module starts the body *at that line*.02:15
lifelessthus ignoring all the arch-added headers.02:15
ddaaesp. New-patches:02:15
ddaa-> KeyError when baz_import tries to access that02:16
lifelessits 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
lifelessddaa: exactly.02:16
lifelessddaa: also 'None' type has no attribute split02:16
ddaalifeless: I can understand how you can be offended by Tom ranting about baz design decisions.02:17
ddaaBut 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
lifelesshahha02:17
lifelessguess I'm being over sensitive.02:17
lifelessanyway, moving along ..02:18
ddaaif he were trying, he would actually realise that we were heading roughly towards arch2...02:18
lifelessyup02:18
ddaaand _that_ would distress him terribly02:18
lifelessI want to update the bzr and bzrtools in rocketfuel02:18
lifelessdo you have any concerns about that ?02:18
ddaanot enough hours in the week02:18
lifelessmajor changes: revision-history is normalised, and knits are defaults.02:19
ddaaotherwise, 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
lifelessok, I will try it and if it baulks, I will email you a FYI 02:19
lifelessI dont have time to do the integration myself if its non-trivial.02:19
ddaaneed 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 you02:20
lifelessok02:20
lifelesslets quickly do it now02:20
ddaaI'm not in condition02:20
lifelessok02:20
ddaaI'm being mildly sick too02:20
lifelessgnight then02:20
=== ddaa runs to the place
=== niemeyer [n=niemeyer@200.213.49.149] has joined #launchpad
=== matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad
=== salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad
=== Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad
=== WaterSevenUb [n=WaterSev@195-23-238-242.nr.ip.pt] has joined #launchpad
=== jinty [n=jinty@84.Red-83-55-199.dynamicIP.rima-tde.net] has joined #launchpad
=== kiko wakes up
kikohello there02:51
ddaahey kiko02:53
kikohey david, how's it going man?02:54
ddaaI noticed there are still a couple of crashing bugs in the branch puller, one appears to be a pyflakes-grade bug in an exception handler02:54
ddaathe other is the failure to catch connection errors (at socket level)02:54
kikohas the branch puller code been updated to the version salgado reviewed?02:54
ddaaphone02:55
salgadokiko, that I reviewed?02:55
kikowell, that you worked with jblack on, salgado 02:56
salgadoyes, that's the version that is running02:56
salgadothe 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 answer02:58
kikohe answered IIRC02:58
ddaaback02:58
ddaasalgado: want me to have a look? I think I can channel lifeless for that :)02:59
salgadoddaa, sure, that'd be great03:01
salgadoddaa, https://lists.ubuntu.com/mailman/private/launchpad/2006-April/008447.html03:01
salgado(that's the thread were we discussed it)03:01
=== Keybuk [n=scott@quest.netsplit.com] has joined #launchpad
ddaasalgado: there's another one in addition to those03:08
ddaaerror report: 23 Apr 2006 14:20:25 +0100 (BST)03:09
ddaasocket.error: (110, 'Connection timed out')03:09
=== salgado looks
ddaanot caught in branchtomirror.py, line 2803:09
=== mpt_ [n=mpt@219-89-142-251.jetstart.xtra.co.nz] has joined #launchpad
ddaathat 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
salgadoI thought I was subscribed to this topic, but apparently no03:10
ddaasalgado: so we have to interesting lines in branchtomirror.py, line 28 and 4203:12
ddaawe 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
ddaasalgado: are we in sync?03:13
salgadoone second03:13
salgadoddaa, yeah, looking at the code now03:14
salgadothat's right. we already have some tests for failures in line 2803:14
salgadobut we don't have tests for failures on line 4203:14
ddaathe 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 too03:15
ddaaSo, these lines do two things: opening srcbranch, and pulling scrbranch into dest_branch03:16
ddaaand we want to test that exception handling for those operations behave in a certain way, so we need to make those operations raise those errors03:17
ddaaWearing my lifeless hat, I'd recommend using a TemplateMethod03:17
ddaaactually, two TemplateMethods03:18
ddaaBranchToMirror.openSourceBranch(self) -> srcbranch03:18
ddaaactually, no return value, just stick the value in an instance variable03:19
ddaaSo, BranchToMirror._openSourceBranch(self) and BranchToMirror._pullSourceToDest(self)03:19
salgadothat'd be just to make it easier to test, I guess? or do you have something else in mind?03:21
ddaaJust to make easier to test.03:21
ddaaThen you can override or assign those methods in your tests, to make them raise whatever you want.03:21
ddaaI mean assigning the methods in the instance you use in the test.03:21
ddaasalgado: does that make sense?03:22
salgadoyes, definitelly03:22
salgados/ll/l03:23
=== Martolod [n=jeremy@ARennes-257-1-81-192.w86-199.abo.wanadoo.fr] has joined #launchpad
ddaaMh, interestingly pyflakes does not catch the problem with undefined e...03:23
ddaabut there's a couple of unused imports there03:24
ddaasalgado: can you fix this socket.error and that undefined e this week?03:24
salgadoddaa, I'm fixing them as we talk03:25
ddaafantastic03:25
=== bradb [n=bradb@modemcable092.66-130-66.mc.videotron.ca] has joined #launchpad
ddaasalgado: actually, I'd also factor out the self.branch_status_client.mirrorFailed(self.branch_id, str(e)) into a separate method03:27
ddaaso you can also override that in tests, and have nice pure unit tests for the exception handling03:27
salgadoddaa, what about line 37? should we be catching anything other than NotBranchError there?03:28
ddaaI do not think we should catch anything else03:28
ddaait's just implementing that logic: "if there's nothing to pull into, create the branch"03:28
ddaaany other exception would be bzrlib bug, an API change, or a deployment problem.03:29
salgadowhat 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 bug03:30
salgadomaybe it's impossible for line 37 to raise the socketerror? (I don't think so)03:31
ddaaline 37 is local only03:31
ddaait's just creating a target branch on the filesystem03:31
salgadoright03:31
ddaaif it blows, then there's something REALLY wrong03:31
salgadoI misread that as the source branch03:31
salgadoit's the dest branch03:31
ddaasalgado: on the socket.error03:32
ddaaI think you are right on both accounts03:32
ddaait is probably a bzrlib bug03:32
ddaaand it should be caught (IMO) in both places03:32
salgadowhat both places?03:32
ddaa28 and 4203:33
ddaaconnection time out can happen anytime03:33
ddaaI half expect that lifeless would argue that we should not catch it though03:33
ddaaand fix bzrlib instead03:34
ddaabut I'm not keen at having the branch puller go down in flames everytime a trivial bug like that creeps into bzrlib03:34
salgadobut if we find a bug in bzrlib, I'd rather get it fixed there than to stick extra error-handling code into the supermirror-puller03:37
salgadobecause this code will probably go away once the bzrlib bug get fixed03:37
ddaaI 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
ddaait's not like it's requiring a lot of extra hairy logic03:38
salgadoindeed it's not. as long as we don't start doing the same for other exceptions03:40
salgadoand I'll leave a comment there and log a WARNING message if we catch a socket.error03:40
ddaamakes much sense03:41
ddaawould motivate kiko to nag mpool into getting it fixed :)03:41
=== tambaqu1 [n=tambaqui@200-230-128-109-mns.cpe.vivax.com.br] has left #launchpad []
stubI'd flag the workaround in the Launchpad code with an XXX linked to a Malone bug.03:43
salgadostub, but then somebody could be tempted to remove that "workaround" when the bug gets fixed03:44
salgadoand what ddaa suggested is to leave the "workarround" there to prevent this in the future03:45
stubok.03:45
=== cprov [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad
kiko-afkthe WARNING idea is a good one03:51
bradbmpt_: ping03:51
kikoSteveA, salgado: can you confirm https://launchpad.net/products/launchpad/+bug/34310 is still an issue?03:54
UbugtuMalone bug 34310 in launchpad "people merge tests disabled temporarily" [Normal,In progress]  03:54
kikobradb, probably asleep, no?03:54
bradbprobably03:56
bradbThough you never know with New Zealanders03:56
=== sivang [n=sivang@piware.de] has joined #launchpad
=== luks [n=lx@unaffiliated/luks] has joined #launchpad
lukshi. is there some way to remove a translation from rosetta?04:07
=== Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad
luksi mistakenly added both 'no' and 'nb' translations, and would need to remove one of them :/04:07
kikomatsubara, why is bug 39879 still unfixed? :-)04:25
UbugtuMalone bug 39879 in rosetta "Translation string is crashing replacer function" [Major,Confirmed]  http://launchpad.net/bugs/3987904:25
=== ompaul [n=ompaul@ubuntu/member/ompaul] has joined #launchpad
=== ruffneck_ [n=ruffneck@intelligenzia.org.helsinki.fi] has joined #launchpad
matsubarakiko: couldn't reproduce it locally. I contacted the reporter to help me reproduce it.04:29
kikohe posted a comment today04:29
kikois it difficult to trace in the code?04:29
matsubarakiko: nope. I just don't know how the user ended up with the string that crashes the replacer function.04:30
kikoa string? I thought it was None?04:30
matsubarasorry, it's None. I just don't know how he entered that (an empty list) in that form. 04:32
=== ploum [n=ploum@ubuntu/member/ploum] has joined #launchpad
matsubarakiko: 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:38
BjornTmatsubara, kiko: by looking at the oops, i would assume that the function crashes because it gets a list instead of a string.04:40
=== kiko reads the oops
kikoand indeed we're getting a list for msgset 2446002 04:42
matsubaraBjornT, kiko: and the list ended there? 04:42
matsubaras/and/and how/04:42
kikoBjornT, is there something new in zope3.2 relating to how form variables are generated? I've been seeing quite a few of similar bugs04:43
SteveAyou'd get a list if the URL had two offset=whatever in it04:43
SteveAsame as in earlier zope04:43
kikoso nothing changed?04:43
matsubarathere'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
SteveAso, there's probably some code path that manages to insert two offset=whatever into the URL04:43
BjornTkiko: no, that hasn't changed. if you look at the url matsubara gave you, you'll see that 14 is listed twice.04:44
kikoyeah it is04:44
kikobut not in the UI04:45
BjornTwhat do you mean not in the UI?04:45
kikowell there's only one textarea for string 1404:45
BjornTreally? not in the page i'm looking at.04:46
BjornThttps://launchpad.net/distros/ubuntu/dapper/+source/ubuntu-docs/+pots/desktopguide/it/+translate?offset=1004:46
kikoI see only one.04:46
kikoyou see two?04:46
matsubarathe 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:47
kikobut there is only one textarea for string 14 -- right?04:48
kikoBjornT, do you see two entries marked for 14?04:48
BjornTkiko: yes, i see two. i wonder if it has something to do with permissions, i'm not an admin, but you are.04:49
=== erdalronahi [n=erdal@p50875EE4.dip.t-dialin.net] has joined #launchpad
kikookay -- matsubara only sees one too04:51
kikoI think it has to do with preferred languages04:51
kikoor your location languages04:52
=== SnkBite [n=SnkBite@212.25.63.82] has joined #launchpad
BjornTkiko, matsubara: this is what i see: http://people.ubuntu.com/~bjorn/rosetta.jpg04:56
kikoyeah, what I suspected -- I don't04:57
kikoBjornT, what are your preferred languages?04:58
matsubarakiko: it's browser related04:59
matsubarai just opened it on opera04:59
kikoah, really?04:59
kikohow interesting04:59
matsubaraand it shows twice04:59
kikologged in as you?04:59
matsubaraepiphany and firefox works normally04:59
matsubarayep04:59
BjornTkiko: English, [en] 04:59
kikothanks04:59
kikoHTTP_USER_AGENTMozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.105:00
kikomatsubara, that's the agent in the OOPS. So I'm not so sure I'd jump to that conclusion05:00
BjornTkiko, matsubara: i see 14 twice in firefox as well05:00
matsubarakiko: maybe firefox 1.5 has the same problem.05:00
kikono05:01
kikoI think it has to do with location and preferred languages05:01
kikoit's not a browser problem.05:01
BjornTin firefox i have en-us, en05:01
kikoI meant the languages that rosetta indicates as preferred/location05:02
kikonot necessarily the browser's indicated Accept-Languages05:02
BjornTkiko: oh. rosetta doesn't list any languages as my preferred ones.05:04
kikookay. I have English and Brazilian Portuguese05:04
=== BjornT notices that the widget for selecting preferred languages doesn't work in opera
=== tilix [n=ilia@87.120.12.127] has joined #launchpad
matsubaraI have none as preferred language.05:05
tilixhi. 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
kikosure.05:06
tilixkiko: what should I do?05:07
kikotilix, can you email me with details of the distribution?05:08
tilixok05:08
kikothanks!05:08
kikoI need a domain name, a title, summary and description.05:08
kikoonce done I will reassign it to you05:09
tilixkiko: done05:16
kikothanks05:16
=== salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad
=== matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad
bradbSteveA: 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
SteveAbradb: i haven't looked in a while, despite lifeless prompting me05:21
SteveAi'll take a look tomorrow05:21
bradbok, thanks05:21
salgadoddaa, would you like to have a look at the supermirror-puller patch?05:50
ddaasure05:50
salgadohttps://chinstrap.ubuntu.com/~dsilvers/paste/fileEicRbJ.html05:50
ddaa_openSourceBranch, that reads funny :)05:51
ddaasalgado: it would be nice to add docstrings to all those methods05:52
ddaadef _openSourceBranch(self):05:53
ddaa    """Open the branch to pull from, useful to override in tests."""05:53
salgadodefinitely. I just wanted to make sure it looks sane first05:53
ddaaplease: logger = logging.getLogger('supermirror-pull') => logger = logging.getLogger('branch-puller')05:55
ddaa+                logger.warn( +                    'Possible bug found in bzrlib:\n%s' % traceback.print_exc()) 05:57
ddaayou probably want to use canonical.launchpad.scripts.log.exception or shortException05:57
ddaascripts.logger.log, I mean05:58
salgadoddaa, why do you want me to use the 'branch-puller' logger?06:00
ddaabecause I'm just trying to get the terminology I introduced in doc/bazaar (not yet merged after two months) be used.06:01
ddaabranch-puller, branch-scanner, branch warehouse, etc.06:01
ddaaSupermirror is a collection of services, and I find it's to vague a term to be useful for technical discussion.06:01
salgadoah, I see. I thought there were a 'branch-puller' logger created somewhere06:02
ddaasalgado:  in stubMirrorFailed, I'd use a list to append to, to make sure it's called exactly once.06:03
ddaaalso, in testPullFailureHandler, I'd override all of _openSourceBranch, _openDestBranch, and _pullSourceToDest, and remove the bzr tree setup at the beginning.06:05
ddaaSo it's a pure unit test of the error handling.06:05
ddaaThen I'd test BzrError and socket.error explicitely for both error handlers06:07
ddaasalgado: I could come up with some more nits, but I think that's enough for today :)06:07
ddaaBut I think maybe I'm not a reviewer because I'm way too picky. So maybe you should ignore some of my comments.06:09
=== bradb & # lunch
=== stub [n=stub@ppp-58.8.1.90.revip2.asianet.co.th] has joined #launchpad
salgadoddaa, 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:12
ddaano, that's just a nice side effect. It's to have a test that only depends on what it intends to test.06:13
radixsalgado: when you're testing smaller units, when a bug happens it's easier to track down the actual problems06:13
ddaalifeless started lecturing me this morning about separation between unit tests, feature tests, and integration tests.06:13
radixyou find the smallest test that's failing06:13
ddaasalgado: what radix is saying06:14
radixwoops06:15
ddaalooks like the cat tripped on the wire...06:15
=== matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad
ddaamatsubara: what message did you get last?06:16
=== salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad
ddaahu06:16
ddaasalgado: what message did you get last? matsubara: ignore me06:16
salgadookay, I kicked the power cord again06:16
salgadoI asked you the rationale for the "pure unit test" and kicked the cord after that06:17
ddaa radix: salgado: when you're testing smaller units, when a bug happens it's easier to track down the actual problems06:18
ddaa radix: you find the smallest test that's failing06:18
ddaarunning faster is just a side effect, tests should only depend on exactly what they intend to test.06:19
kikoideally at least06:19
ddaayeah, yeah, you know the difference between theory and practice...06:20
salgadoI thought the 'pure unit test' meant just making it non-functional. I didn't realize you wanted me to split it06:26
ddaaI did not mean that.06:26
ddaaThough that was indeed one of the additional nits.06:26
ddaabetter to test the two try-except clauses separately06:27
ddaabut there is some light insanity down that road06:27
ddaaXP and refactoring purists try to write one line methods, each with its unit tests... I think that's slightly excessive :)06:28
kikoone-line methods are usually crack06:29
kikounless they are very special semantic or syntactically06:29
ddaathere are useful there, so they can be overriden for testing :)06:29
salgadoI could move it into a non-functional test class, put some stuff on setUp() and then have one test for each try-except clause06:29
ddaasalgado: how far down that road you want to go is your call. But I did not ask for it.06:30
ddaaBut I do think that would better.06:30
ddaa* would be better06:31
salgadoI don't like reading/writing non-doctests, so anything that I can do to make them nicer I think is worth06:32
=== kiko agrees wholeheartedly
kikobradb, did you confirm with mpt on the design for fixing bug 977?06:35
UbugtuMalone bug 977 in malone "Commenting on bug should optionally subscribe you" [Major,Fix committed]  http://launchpad.net/bugs/97706:35
=== beyond [n=beyond@200-171-140-32.dsl.telesp.net.br] has joined #launchpad
tilixdoes somebody know how to add a milestone to a distro in Launchpad?06:48
=== cprov [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad
salgadoddaa, 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)06:59
ddaasalgado: not offhand... looking07:01
ddaasalgado: any reason why you are not passing the logger instance down from the script?07:03
bradbkiko-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:03
ddaadoing that, you could just give the BranchToMirror instance a fake logger like in test_keyringtrustanalyser07:04
ddaasalgado: I have to run now07:04
salgadoddaa, you mean, passing the logger as an argument instead of using logging.getLogger() on BranchToMirror?07:04
ddaayup as an argument to __init__07:05
salgadoI 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
ddaaalternatively you could override canonical.launchpad.scripts.logger.log._log, but that would be hackish07:06
ddaadunno then, I'd like to help, but I have to leave07:06
salgadosure, no worries. thanks for the help. :)07:06
bradbsalgado: Any chance that you'll to following up on the malone-bug-dates review?07:15
salgadobradb, yeah, I'll do that later today07:21
bradbcool, thanks07:22
=== sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad
SteveAhey sabdfl!07:28
sabdflSteveA, how's it hanging?07:30
SteveAfast and loose^w^wcrisp and clean.07:32
sabdflfast crisp and clean I LIKE IT07:34
kikolike polished bacon 07:36
sabdfleeew07:42
=== sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has left #launchpad []
SteveAkiko: i think you meant "greased lightning"07:43
kikolightning-fried bacon07:43
salgadoSteveA, 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
salgados/clean/reset/07:44
SteveAsalgado: sorry, no.  mail the list.  stub or bjorn or jamesh may know.07:44
SteveAkiko will tell you, jamesh knows everything07:45
kikogrep(1) may know as well07:45
salgadobut grep's not as clear as jamesh. :)07:46
salgadobtw, I've already ask grep, and it seems that it's checking logging._handlerList07:47
salgadobut I made my tests restore that to the value before running the tests, and it still complains07:48
SteveAit may be that it wants an API to be used07:48
kikoquite likely07:48
salgadoI first thought that logger.removeHandler() would do it07:49
salgadobut it doesn't07:49
BjornTsalgado: how about canonical.testing.reset_logging()?07:54
stubsalgado: 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.07:57
=== beyond_ [n=beyond@200-171-140-32.dsl.telesp.net.br] has joined #launchpad
kikostub, any word on staging oops logs?08:05
=== lbm [n=lbm@82.192.169.174] has joined #launchpad
salgadoaha, that's great. thanks stub and BjornT. :)08:07
kikoanyone seen carlos?08:08
bradbmight be a holiday in spain?08:08
kikommmm08:09
bradband i think he said something about being far away from a computer, IIRC08:09
kikooookay08:09
=== ozamosi [n=ozamosi@ubuntu/member/ozamosi] has joined #launchpad
kikomatsubara, did you file any oops bugs today?08:32
kikoddaa, did you see the SOMTORError in today's OOPS report?08:32
matsubarakiko: yes08:36
kikomatsubara, which ones?08:36
matsubarakiko: let me check08:37
matsubarakiko: bugs 41139, 41138, 41108, 4110408:38
UbugtuMalone bug 41139 in rosetta "Export request form should check for uniqueness of entry" [Normal,Unconfirmed]  http://launchpad.net/bugs/4113908:38
UbugtuMalone bug 41138 in malone "+viewstatus crashes when opening a remote bug" [Normal,Confirmed]  http://launchpad.net/bugs/4113808:38
UbugtuMalone bug 41108 in launchpad "launchpad.net/foaf returns a blank page instead of a NotFound." [Normal,Confirmed]  http://launchpad.net/bugs/4110808:38
UbugtuMalone bug 41104 in soyuz "Validate query string in +builds/$builder" [Normal,Confirmed]  http://launchpad.net/bugs/4110408:38
kikomatsubara, is the poll crash an old one?08:39
matsubarakiko: missed that one. I'll look for a dupe otherwise I'll file a new bug.08:41
kikomatsubara, and the branch duplicity one? that looks like a serious bug -- ddaa?08:42
matsubarakiko: that one I think I've reported some time ago. I'll check it too08:43
kikomatsubara, also, can you tell me what bug is reported for the fti crash with exclamation marks?08:43
matsubarakiko: bug 3982808:44
UbugtuMalone bug 39828 in launchpad "FTI queries die if ! in or at the end of a word" [Normal,In progress]  http://launchpad.net/bugs/3982808:44
matsubarathat one?08:44
kikoyes08:45
kikothank you08:45
=== Goshawk [n=vincenzo@d83-176-29-58.cust.tele2.it] has joined #launchpad
Goshawkhi08:46
matsubarakiko: the poll oops looks like bug 273208:47
UbugtuMalone bug 2732 in launchpad "Adding a poll with a finish date before start date causes error" [Normal,Confirmed]  http://launchpad.net/bugs/273208:47
Goshawki'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:47
kikomatsubara, is it the same oops sig?08:48
matsubarakiko: 2732 doesn't have any oops id.08:49
matsubarabut according to the bug description and the constraint triggered by the oops looks like the same issue.08:49
kikookay, annotate with oops ID then08:50
=== LedStyle [n=ledstyle@c91554fb.virtua.com.br] has joined #launchpad
LedStyleCan someone help-me with a problem in Rosetta?08:54
mdkeLedStyle, ask away08:54
LedStyleI can't download the file compiled... the MO version!08:55
LedStyleAnd cant compile the PO here. There's an inconsistence08:55
kikowhat happens when you compile?08:55
LedStyleWell the log is in portuguese08:55
LedStyleinkscape.po:8199: definio duplicada de mensagem08:55
LedStyleinkscape.po:4151: ...esta  a localizao da primeira definio08:55
LedStylemsgfmt: encontrado 1 erro fatal08:55
LedStyleDuplicated message definition08:56
LedStylefatal error08:56
kikothat may be a bug08:56
kikoin rosetta. but I thought we had fixed that already...08:56
LedStyleCan i remove the duplicate part in the PO file and upload?08:56
kikoLedStyle, well, it's definitely weird.08:57
=== kiko scratches head
kikothe best person to answer is carlos but he is on holiday today08:57
kikoLedStyle, perhaps filing a bug and adding the file as an attachment is best08:57
kikolet me know what the bug # is08:58
LedStyleok08:58
LedStyleThanks for help!08:58
kikoBjornT, ping?08:59
=== coleSLAW [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad
=== niemeyer_ [n=niemeyer@200.213.49.149] has joined #launchpad
LedStylekiko, #4116309:05
kikothanks09:05
LedStylehttps://launchpad.net/distros/ubuntu/+bug/4116309:06
UbugtuMalone bug 41163 in Ubuntu "PO file can't be compiled" [Normal,Unconfirmed]  09:06
kikoLedStyle, you reported it against Ubuntu?09:06
LedStyleOhh Sorry...09:06
LedStylehahahah09:06
LedStyleHow can a remove?09:06
LedStylei*09:07
kikoyou do the following:09:07
kikoa) reject the Ubuntu status09:07
kikob) Report it as affecting Upstream09:07
=== tambaqui [n=tambaqui@200.231.108.172] has joined #launchpad
=== WaterSevenUb [n=WaterSev@195-23-238-180.nr.ip.pt] has joined #launchpad
LedStyleHow to reject?09:09
LedStyleFinded09:09
LedStyle:P09:09
matsubarakiko: about the SOMTORError in today's oops report, I couldn't find a bug, so I reported it as bug 4116409:11
UbugtuMalone bug 41164 in launchpad "IPerson.getBranch() should return only one result" [Normal,Unconfirmed]  http://launchpad.net/bugs/4116409:11
LedStylekiko, ehick packate?09:11
LedStylewhich*09:11
kikoLedStyle, rosetta09:11
=== uniq [n=frode@81.26.52.3] has joined #launchpad
LedStylekiko, rosetta is not in the list09:12
matsubaraLedStyle: https://launchpad.net/distros/ubuntu/+bug/41163/+upstreamtask09:12
UbugtuMalone bug 41163 in Ubuntu "PO file can't be compiled" [Normal,Rejected]  09:12
uniqdo I get a ubuntu.com e-mail forward automatically when registering in launchpad?09:13
kikoLedStyle, you are indicating it against a distribution -- it should be upstream, not in a package.09:13
kikouniq, no.09:13
=== highvoltage [n=Jono@mtngprs7.mtn.co.za] has joined #launchpad
highvoltagehi. do i file launchpad bugs at https://launchpad.net/malone/bugs/+package too?09:13
LedStyleSorry but i dont know anything about this Launchpad system!09:14
uniqkiko: do you know what the criterias are?09:14
kikouniq, being an Ubuntu member.09:14
uniqkiko: ok, i am.09:15
=== coleSLAW [i=sfllaw@206-248-157-37.dsl.teksavvy.com] has joined #launchpad
uniqdo you know who to ask to setup a forward?09:15
kikouniq, it should work automatically if you are a member09:15
mdkeuniq, it's automatic, on your launchpad username09:16
uniqin that case it doesn't work.09:16
=== pvdvyve [n=pvdvyve@ip-81-11-234-56.dsl.scarlet.be] has joined #launchpad
=== sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad
LedStylekiko, 09:18
kikoLedStyle?09:18
LedStyleInkscape bug tracker?09:18
kikoLedStyle, what?!09:18
LedStylekiko, sorry but im lost here hehehe09:19
mdkeuniq, you can complain to elmo about it not working09:19
LedStyleWere exactly i have to report the possible bug in rosetta?09:19
kikoLedStyle, report the bug upstream, on the product rosetta.09:19
kikomatsubara already showed you above:09:19
kiko<matsubara> LedStyle: https://launchpad.net/distros/ubuntu/+bug/41163/+upstreamtask09:19
UbugtuMalone bug 41163 in Ubuntu "PO file can't be compiled" [Normal,Rejected]  09:19
uniqmdke: ok, thanks :)09:19
LedStylekiko, but in the Remote Bug Tracker09:20
kikoLedStyle, it's not mandatory -- just leave it empty09:20
LedStyleAnd Remote bug to?09:21
kikoyeah09:21
LedStyleahhhh09:21
LedStylehttps://launchpad.net/products/rosetta/+bug/4116309:21
UbugtuMalone bug 41163 in rosetta "PO file can't be compiled" [Normal,Unconfirmed]  09:21
kikothanks09:21
LedStyletks kiko 09:22
kikoLedStyle, please include in the report the URL you used to download the po-file09:22
=== Bluekuja [n=bluekuja@host199-235.pool8254.interbusiness.it] has joined #launchpad
LedStyleDone kiko 09:25
kikothanks!09:25
LedStyleA friend here in the team say: This is happening with other packages to!09:26
kikoLedStyle, are you translating the ubuntu package or the upstream product?09:26
LedStyleubuntu package09:26
kikothanks.09:26
LedStylehttps://launchpad.net/distros/ubuntu/dapper/+source/inkscape/+pots/inkscape/pt_BR/+translate09:27
salgadokiko, do you have a box running dapper close to you?09:31
kikosorta, salgado 09:31
=== highvoltage [n=Jono@mtngprs7.mtn.co.za] has left #launchpad []
LedStyleAfff09:33
LedStyleHey kiko 09:33
LedStyleIm doing some tests here09:33
LedStyleIm think this can be a bug in gtranslator. But kiko the rosetta is not sending the MO file!09:34
sivangre09:36
=== luks [n=lx@unaffiliated/luks] has left #launchpad []
kikoLedStyle, mmm? I thought you said the file you /downloaded/ contained duplicate definitions?09:39
LedStylekiko, 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
kikothat's what I suspect as well09:41
LedStylekiko, are u brazilian? Can we talk in portuguese?09:42
kikoLedStyle, I don't have a lot of time unfortunately -- carlos will look at your report tomorrow, don't worry09:42
LedStylefine09:43
LedStyleAnd sorry because i dont know use launchpad very well!09:44
kikonothing to be sorry about09:44
kikowe're a bit too much on the complicated side09:44
kikobut we're working on it09:44
LedStyleRosetta dont like me... hehe09:45
=== pvdvyve [n=pvdvyve@ip-81-11-234-56.dsl.scarlet.be] has left #launchpad ["Kopete]
=== LedStyle [n=ledstyle@c91554fb.virtua.com.br] has left #launchpad ["Ex-Chat"]
=== mpt [n=mpt@219-89-142-251.jetstart.xtra.co.nz] has joined #launchpad
=== cprov [n=cprov@201-68-5-174.dsl.telesp.net.br] has joined #launchpad
=== erdalronah1 [n=erdalron@p50875904.dip.t-dialin.net] has joined #launchpad
=== bradb [n=bradb@modemcable092.66-130-66.mc.videotron.ca] has left #launchpad []
=== Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad
=== erdalronah1 [n=erdalron@p50875904.dip.t-dialin.net] has left #launchpad []
=== auth [n=auth@fiji.grd.sgsnet.se] has joined #launchpad
=== auth00 [n=auth@fiji.grd.sgsnet.se] has joined #launchpad
mdkeI 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 all11:57
=== mpt_ [n=mpt@219-89-130-196.jetstart.xtra.co.nz] has joined #launchpad
lifelesssalgado: ddaa - socket error is likely to not be caught by bzrlib12:01
lifelessand the nagging will be noise immediately. 12:01
lifelessso I don't think thats sane.12:01
lifelessif you consider it a bug in bzrlib, file a bug.12:02
lifelessalso 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 occurs12:03
lifeless(see the existing comments in that file)12:03
=== lakin [n=lakin@S01060013101832ce.cg.shawcable.net] has joined #launchpad
=== jinty [n=jinty@84.Red-83-55-199.dynamicIP.rima-tde.net] has joined #launchpad

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!