=== 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 [03:49] lifeless: I played around with siproxd a bit on the weekend: it doesn't seem to be 64-bit safe [03:49] jamesh: aw crikey [03:50] jamesh: filed bugs ? [03:50] I fixed a few crasher bugs in it, but it still seems to have some problems [03:50] https://launchpad.net/distros/ubuntu/+source/siproxd/+bug/40914 [03:50] Malone bug 40914 in siproxd "siproxd segfaults on AMD64" [Normal,Unconfirmed] [03:50] heh, I meant upstream :) [03:50] apparently they didn't know that sizeof(size_t) isn't always equal to sizeof(int) [03:51] meh [03:51] sizeof(not-my-type) == sizeof(mytype) is not a truism. [03:51] its like the sizeof(int) == sizeof(void *) idiocy that I've seen people indulge in [03:52] so passing an (int *) to a function expecting a (size_t *) didn't do what they want [03:52] surely you get a compiler complaint on that ? [03:52] in fact, it seemed to zero out the port variable they then used to send UDP packets [03:52] you get a complaint on AMD64 (which is how I found it) [03:52] right [03:52] but not where it is -= === jamesh goes to file bug upstream [03:59] lifeless: well, shtoom seems to work through siproxd now, but ekiga isn't [04:00] interesting [04:00] what happens with ekiga [04:00] have you unset its stun setting? [04:00] I turned off the stun stuff [04:01] says "could not connect to remote host" in the status bar. I haven't investigated further yet [04:08] k [04:08] I've shown you subunit now haven't I? [04:09] yeah [04:09] good. with the shell/C/C++ extensions ? [04:10] (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] you told me about the extensions, but I haven't played with them === 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 [06:05] mpt__: ping? === 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 [06:34] good morning === mpt__ [n=mpt@222-154-152-137.jetstream.xtra.co.nz] has joined #launchpad [06:37] Merge to devel/launchpad/: Refactor PostgreSQL session support, removing race condition embedded in SQL [r=BjornT] (r1816: Stuart Bishop) [06:45] hi SteveA [06:50] hello martin === egerds [n=free@68-115-12-52.dhcp.stpt.wi.charter.com] has joined #launchpad [07:00] Either Steve is getting earlier or my night outs are getting later... [07:00] couldn't sleep === stub goes to grab breakfast [07:01] there's a strange buzzing sound i could hear all night [07:01] i thinkn my neighbour above has a noisy computer [07:01] and it is touching something that makes it resonate into my bedroom [07:01] I am trying to register for ubuntu [07:02] nvm === 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 [07:35] Hello anybody! === mpt_ [n=mpt@219-89-141-214.jetstart.xtra.co.nz] has joined #launchpad === SnkBite [n=SnkBite@212.25.63.82] has joined #launchpad [07:46] mpt_: voice call? === rlaager [n=rlaager@trcpe2-167.mncable.net] has joined #launchpad [07:51] 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] rlaager: which bug? you should be able to close it. [07:52] rlaager: got a pointer to it? [07:52] 38999 [07:53] what error do you get when you try to close it? [07:54] I don't get an error. There's just no arrow to click to get at the close stuff... [07:55] rlaager: just click on the row [07:55] Hmm, perhaps that's moved now? I don't see it for bugs I filed either. [07:55] ahh, thanks [07:57] BjornT: we should meet for lunch sometime [07:57] and maybe a code review session or two [07:59] mmm, code review [08:00] SteveA: yeah we should, it's easier for me now that i have a car. how about lunch tomorrow? [08:02] it's great weather for cycling. i should pick up my bike from the POV office [08:02] sure, lunch tomorrow [08:04] 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] morning all === frodon_ido [n=patrick@ip-213-49-233-214.dsl.scarlet.be] has joined #launchpad [08:41] BjornT, stub: what's the story about getting zero soft timeouts? [08:42] SteveA: i sent a patch. do you want me to merge it without tests, or should i add tests first? === rlaager [n=rlaager@trcpe2-167.mncable.net] has left #launchpad [] [08:43] SteveA: BjornT's patch and analysis sounds correct [08:43] hi jamesh [08:43] hi SteveA [08:43] please merge it, get it onto staging, and see if we can provoke a soft timeout [08:43] if you're feeling keen... [08:44] add a page that checks the logged in user for being a launchpad developer (or uses permissions) [08:44] and does something evil to provoke a soft timeout [08:44] by pausing for the length of time specified to be a soft timeout [08:44] 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] then at least we can test it in practise [08:45] 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] yeah === rob [i=Robert@freenode/staff/ubuntu.member.rob] has left #launchpad ["Leaving"] [08:46] BjornT: please merge the stuff, and do the test later if you need to [08:46] i think it is important that we see soft timeouts [08:47] ok, i'll merge it now, and add the test later. [08:47] well, how long is it going to take to write the test? [08:48] mister testing fascist! [08:49] indeed [08:49] soft timeouts are fragile. they have stopped more than once now. [08:49] I'd like to stop that. [08:52] i suppose the test won't take too long to write. i'll do it before i merge then. [08:53] jamesh: what's the easiest way of checking that a soft timeout occurred? [08:53] or rather, has been logged === 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 [08:56] BjornT: I think globalErrrorUtility.lastid will get incremented (or reset if we pass from one day to the next) [08:57] 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 === mpt_ [n=mpt@219-89-157-151.jetstart.xtra.co.nz] has joined #launchpad [09:28] SteveA, sure [09:40] mpt_: ok [09:41] mpt_: i'm running skype now === doko_ [n=doko@dslb-088-073-097-132.pools.arcor-ip.net] has joined #launchpad [09:46] mpt_: ping [09:48] 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. === 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 [10:36] jamesh, SteveA: please someone review https://chinstrap.ubuntu.com/~dsilvers/paste/fileV3ytab.html === SteveA looks [10:38] BjornT: +from time import sleep, time [10:38] i'd rather you imported "time" and used "time.time" and "time.sleep" [10:39] BjornT: any reason for calling sleep() in a loop, rather than just sleeping for the appropriate amount of time? === mpt [n=mpt@222-154-113-84.jetstream.xtra.co.nz] has joined #launchpad [10:40] jamesh: well, is that reliable? is sleep() guaranteed to sleep at least the specified time? [10:41] BjornT: I suppose it can get interupted, yeah. [10:41] you could do max(time_left, 0.1) [10:41] but that's getting kinda complex [10:41] you already wait what should be the right time, and then busy loop the rest [10:41] perhaps add a comment saying that [10:42] yeah, i comment is probably good to have there [10:47] r=me [10:47] thanks [10:54] hey jamesh [10:54] how much longer are you going to be around today?+ [10:56] hi ddaa [10:57] an hour or so [10:57] ddaa: was looking at moving the branch pull list stuff into the authserver [10:58] jamesh: did I ask you for that already? [10:58] I think not, in any case, I intended to :) [10:59] ddaa: I also got the importd error reporting script working against the sample data you sent last week === 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 [11:54] Hi all, [11:54] the ooo-templates have once again been imported into Rosetta/Dapper [11:54] and this time all our translations have been overridden by the English originals === dsas [n=dean@host86-129-9-197.range86-129.btcentralplus.com] has joined #launchpad [11:55] It's even worse than before [11:55] Before only the untranslated strings have become English, now ALL are overridden [11:56] review meeting in 5 [11:59] erdalronahi: your statement doesn't help, please submit a bug report, subscribing carlos and me [11:59] yes, I'll do that [11:59] just wanted to inform you, [11:59] because carlos said last week [12:00] I should tell him if it doesn't work === sits [n=sits@cpc3-cwma2-0-0-cust739.swan.cable.ntl.com] has left #launchpad [] [12:07] awesome [12:08] Someone found a bug report in Malone by googling the incorrect string he was seeing [12:08] and the bug report is the first of 33 results [12:08] yay Malone [12:08] boo https://bugzilla.mozilla.org/robots.txt [12:08] doko, ok, filed the bug [12:08] boo http://bugzilla.gnome.org/robots.txt [12:09] erdalronahi: thanks [12:09] doko, you're welcome [12:09] in fact, thank you for all your efforts [12:12] np [12:22] hi [12:22] who is here ? [12:26] i'm here. lifeless, isn't the meeting in 35 minutes though? [12:28] 1100UTC [12:28] meh, yes [12:29] meeting in 30 [12:32] hi [12:33] mpt: you're still around? === mpt_ [n=mpt@219-89-142-251.jetstart.xtra.co.nz] has joined #launchpad [12:33] mpt_: you're still around? [12:33] you should think about getting a shell account somewhere, and using irssi [12:33] so you don't drop off irc so much [12:34] screen + irssi [12:36] like chinstrap [12:36] ;) === sivang [n=sivang@piware.de] has joined #launchpad [12:38] SteveA, yep [12:39] mpt_: skype call? [12:39] 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 === 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 [12:39] at least one of them being solved would be nice [12:39] SteveA, sure === SnkBite [n=SnkBite@212.25.63.82] has joined #launchpad [12:59] ok [12:59] meeting time in 1 [01:02] ok, whose here now ? [01:03] i'm here [01:03] jamesh ? [01:03] SteveA: ? [01:03] kiko ? [01:03] mpt_: ? [01:03] Meeting now? [01:03] what for? [01:03] review team [01:04] which you are partof for the ui reviews ;0 [01:04] Another evening I have to stay up late? [01:04] yayfor [01:05] nah [01:05] if you are here, I appreciate your attendance [01:05] if you aren't, its fine. its not a must-come-every week meeting [01:05] ok [01:05] partly because the reviewers are all fairly self guided [01:06] so next meeting, may 1st, same bat-time, same bat-channel ? [01:06] may 1st is a holiday in some countries [01:07] mayday ? [01:07] hey mpt [01:07] (no need to say more :) [01:07] BjornT: is it a holiday for you ? [01:07] lifeless: yeah [01:08] ok, well you get a day off then :) [01:08] I think its varied enough to not worried, just note your absence after this meeting on the agenda for the next [01:09] will do [01:09] queue status [01:09] I have to get to ddaa's branch-scanner for a re-review [01:09] and the small-fixies branch in jamesh' queue is looking a little ripe [01:09] other than that, the needs-review section is looking good. [01:10] 37 spiv salgado/launchpad/shipit-for-dapper 3173 merge 7345 14:15 [01:10] 31 BjornT spiv/launchpad/unicode-simple-sendmail 3284 merge (1) 149 17:05 [01:10] those two are in needs reply. [01:10] spiv is on leave.. [01:10] BjornT: what about your branch - is it likely to land soon ? [01:10] meh. my bad [01:10] salgado is the branch owner, hes still asleep [01:11] merge-conditional seems to be the killer region though [01:11] davids baz2bzr branch is at 54 days [01:11] which has to be some sort of records [01:12] 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] BjornT: cool [01:13] any comments, issues with reviews at the moment ? [01:14] jamesh: the pending reviews page is not showing the branches in the ui queue - they are also in other peoples queues. [01:14] 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. === ddaa is not sure exactly what baz2bzr is blocked on nowadays [01:15] 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] ddaa: on you from the look of it [01:15] possibly on the sourcecode/ merge fixes [01:16] in which case make a note of that on the wiki :0 [01:16] Mh... I think it was related to some new test failure, related to to tarball fixtures or somesuch [01:17] Let me take moment to say - tarballs fixtures are really bad news. [01:17] 99% of the time. This may be that 1% where they make sense, but I don't believe so. [01:19] can we talk about that now, or am I disrupting the reviewer meeting? [01:19] BjornT: so, no comments/issues on reviews? [01:19] no, no comments from me [01:19] mpt_: how are you handling the ui review load? [01:19] mpt_: are there things the reviewers can watch out for ? [01:20] ddaa: also, please action the bzr-documentation branch, you have mail from me about that. [01:20] ddaa: tarballs, we can talk in a few minutes. [01:22] doc-bazaar, date of the mail? I don't see anything new [01:22] (oops, sorry for disrupting meeting) [01:22] ok, I'll take that as meeting-closed time. [01:22] thanks for coming [01:22] (unless there is other business [01:22] ) [01:23] ok, meeting-over [01:25] lifeless: doc-bazaar is already acted on [01:25] that's why I set it up to needs-review again [01:26] lifeless, my load is about 1 branch every 3 months, but currently I have 2 very large one [01:26] s [01:26] sabdfl's one is 800 K [01:26] ddaa: I didn't get a reply to my mail [01:26] mpt_: it might be a good idea to put those branches in the wiki page [01:28] ddaa: ok, lets talk tarballs [01:29] so, the use case there was: take a baz archives produced by cscvs, and feed it to baz_import [01:29] three options: [01:30] 0. all in test: create cvs repo, run cscvs [01:30] 1. harcoded in test: create baz archive with hardcoded log messages [01:31] 2. tarball [01:31] 0 is ridiculously overcomplex for the case [01:32] 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] 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] at the rate it's going, it will be obsolete before being merged [01:33] lifeless: do you consider that's a fair assessment? [01:35] mmm [01:35] our converted archives are around now [01:35] what are you specifically testing here ? [01:35] baz2bzr is the stuff that does the incremental conversion in importd [01:36] it's testing end-to-end functionality of the conversion to bzr, both initially (new imports!) and incrementally (daily syncs). [01:36] I think based on that that 2 is not a valid test [01:37] then neither would be 1 [01:37] because its avoiding being an end to end test [01:37] and doing 0 would just be crazy [01:38] 1 is valid because it is testing that things created /now/ by the current code also import with the current code [01:38] duh? [01:39] 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] it's not buying anything functionaly. I understand 1 is more readable than 2, but that's all. [01:40] and the "end-to-end" I was initially referring to was "both end of the baz2bzr script" [01:40] lifeless, done [01:40] ddaa: are you testing invocation of baz2bzr? or baz2bzr internals ? [01:41] ddaa: speaking of baz2bzr, there is a pybaz urgent-bugfix-for-baz2bzr in your mailbox. === stub [n=stub@ppp-58.8.4.140.revip2.asianet.co.th] has joined #launchpad [01:42] 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] lifeless: testing both [01:43] the baz_import behaviour is tested by running the baz2bzr script [01:43] so, invocation of baz2bzr by importd ? [01:43] no, invocation of baz2bzr by the test case... hu... [01:43] using the same CLI used by importd [01:44] so, I'm confused. [01:44] because baz2bzr already has unit tests for the cscvs headers, blackbox tests for its use as a command, etc. [01:44] sure [01:44] surely the only thing we need to be adding tests for is invocation by importd ? [01:45] and cscvs-specific headers are really irrelevant to this. [01:45] but the tests here checks that the _right_ bzrtools is being used === cprov [n=cprov@201-43-145-81.dsl.telesp.net.br] has joined #launchpad [01:45] integration testing [01:45] what do you mean [01:45] by 'right' [01:46] 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] errors happen [01:46] good morning [01:47] ddaa: you know the hierarchy of testing? Many unit tests, some ui tests, very few end to end tests ? === bradb [n=bradb@modemcable092.66-130-66.mc.videotron.ca] has joined #launchpad [01:47] in particular, that test check things like "just the right revprops are there" (i.e. no branch-nick) [01:47] ddaa: what I am hearing from you sounds like a schizophrenic test [01:47] which, we have seen, is useful to check redundantly [01:49] you have said it is testing: [01:49] end to end baz2bzr [01:49] invocation of baz2bzr by importd [01:49] nope [01:49] baz2bzr internals [cscvs-revision properties] [01:49] I do not think I said that. [01:50] 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] right [01:50] 21:43 < ddaa> no, invocation of baz2bzr by the test case... hu... [01:50] 21:43 < ddaa> using the same CLI used by importd [01:50] and doing that, checks proper handling of cscvs metadata in the output of baz2bzr [01:50] the interface to baz2bzr used is the CLI, importd uses the CLI too [01:51] a good test tests one thing [01:51] it tests one thing [01:51] it makes tests faster, easier to debug, more robust. [01:51] if it testeed one thing, you could have told me that at the beginning. [01:52] it test "baz2bzr, run from the CLI, convert a baz branch produced by cscvs into the proper bzr data" [01:52] ddaa: and it tests that your custom ui factory is used [01:52] "ddaa: so, the use case there was: take a baz archives produced by cscvs, and feed it to baz_import" [01:53] mh... right, I was being unclear [01:53] I think the test is unclear too. [01:53] for instance. [01:53] lifeless: as as matter of fact, the test for the UI factory is distinct from the test for the bzr output [01:54] ddaa, Wednesday-ish for your review [01:54] 'test that baz2bzr can be run from the cli by importd' [01:54] no "by importd" [01:54] ddaa: its already tested that it can be run from the cli. No need to write a new test for that. [01:54] this is a test for baz2bzr, no importd stuff here, no Job [01:54] ddaa: think about this in TDD terms, we want to write a test that will FAIL today. [01:55] all that code was written in TDD [01:55] ddaa: so your tests should be testing stuff that isn't already tested and working - by definition. [01:56] 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] 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] I do not have fun. I think this conversion is wearing me down as much as it is wearing you down. === jinty [n=jinty@84.Red-83-55-199.dynamicIP.rima-tde.net] has joined #launchpad [01:59] so, lets break this down into those bits [01:59] what was wrong in the bzr output you wanted to fix ? [01:59] 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] But I do not, because baz_import belong to a different tree, and may therefore not be the right version. [02:00] ddaa: I would write a single smoke test for the end to end behaviour desired. [02:00] ddaa: as a smoke test, I'd seriously do cvs<-....>bzr [02:01] because its a single test, meant to be incredibly sensitive to changes, not fine grained unit tests [02:01] I agree that's the Right Way of doing it. [02:01] but in general we dont test across-trees in launchpad [02:02] we don't test that we have the right zope, the right cscvs, the right pybaz [02:02] in production thats the responsibility of the person doing the rollout [02:02] 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] as we dont run the test suite on the production servers, for good reasons, it *cannot* be caught by tests. [02:04] 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] * meant to catch [02:05] 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] 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] can turn that into an arch archive created by hand if you are concerned about readability. [02:05] by hand = by the test case [02:06] I'm worried about several things [02:06] bzr is bad on binary files at the moment [02:06] really bad [02:06] 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] okay, will waste the tarball and create the archive in the test suite [02:07] and clarity here - in a complex code base - is extremely important. [02:08] 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] thank you [02:08] can we chat about 2 other things quickly ? [02:08] lifeless: I think the coverage of baz2bzr is more than adequate [02:08] go on [02:09] pybaz - I have sent you a patch log mangling patch [02:09] this may fix some of the blacklist imports [02:09] can you please as a priority give me a review for it? Its testless for a number of reasons. [02:10] what was the other thing... oh yeah [02:10] 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] also, I do not understand what can produce the problem. [02:10] I want to update rocketfuel to baz2bzr and bzr 0.8 rc2 this week [02:10] ddaa: tla produced the problem ;0 [02:11] what input to tla [02:11] it took a commit message from a user than had a pseudo header [02:11] summary: blah [02:11] keyworkds: more blah [02:11] this is not an rfc2822 header: foo bar [02:11] [02:11] more content here [02:12] would "applied patch not a header" override "applied-patches"? [02:12] the 'this is not'... line should have been put in the body of the message [02:12] ddaa: applied-patches isn't a tla internal header, and no, IIRC last header wins [02:13] BTW, your mail does not appear to include a patch [02:13] 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] so it's difficult for me to apply it :) [02:14] done [02:14] okay I think I understand [02:14] we ended up with non-RFC822 data [02:14] yup [02:15] and the stdlib that we use to parse the log message barfed [02:15] and the email python module starts the body *at that line*. [02:15] thus ignoring all the arch-added headers. [02:15] esp. New-patches: [02:16] -> KeyError when baz_import tries to access that [02:16] 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] ddaa: exactly. [02:16] ddaa: also 'None' type has no attribute split [02:17] lifeless: I can understand how you can be offended by Tom ranting about baz design decisions. [02:17] 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] hahha [02:17] guess I'm being over sensitive. [02:18] anyway, moving along .. [02:18] if he were trying, he would actually realise that we were heading roughly towards arch2... [02:18] yup [02:18] and _that_ would distress him terribly [02:18] I want to update the bzr and bzrtools in rocketfuel [02:18] do you have any concerns about that ? [02:18] not enough hours in the week [02:19] major changes: revision-history is normalised, and knits are defaults. [02:19] 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] ok, I will try it and if it baulks, I will email you a FYI [02:19] I dont have time to do the integration myself if its non-trivial. [02:20] 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] ok [02:20] lets quickly do it now [02:20] I'm not in condition [02:20] ok [02:20] I'm being mildly sick too [02:20] gnight then === 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 [02:51] hello there [02:53]