[00:00] hello bialix [00:00] poolie: do you have any specific plans for 2.2.1? [00:01] I mean a more or less precise date [00:01] because I need to release qbzr 0.19.1 [00:05] let's see [00:06] the actual freeze date for 2.2.0 is over a month ago now [00:06] we could do it pretty soon [00:06] when do you want to do 0.19.1? sooner, or later? [00:07] 'morning poolie [00:07] hi there [00:08] i wonder what's in the 2.2 branch now? [00:08] poolie: I want to have 0.19.1 sooner or in time with 2.2, so GaryvdM can bundle it into installer [00:09] could you do it early next week and then we'll do 2.2.1 after that? [00:09] I'll do it this weekend then [00:09] my fixes for add are in there, plus some smaller fixes [00:09] and they had quite a few dupes and would be worth getting out= [00:11] ok [00:11] * bialix eods [00:12] bye [01:07] gz, bialix, i'll resubmit the setlocale patch [01:08] oh apparently jam sent it, and it's working through pqm [01:11] poolie: what would a fixture for thread leaking entail? for the moment I've kept it all as-is but moved it to the test result (...and then poked various other unrelated things nearby that I probably should have filed seperate bugs on but kept breaking stuff) [01:13] basically just moving everything in to a self contained object that's notified when the test starts and finishes [01:13] I think this is pretty low-overhead though, and having to enable it per-testcase will probably mean we miss tests that aren't obviously using threads [01:13] i don't know if that's enough [01:13] it could be confined to a fixture even if the base bzr testcase always starts it [01:13] ie you don't need to do it per case [01:14] I'll wham what I've done up in a mp as it might be easier to discuss there [01:16] bah, this is so going to conflict with my other branch, should have thought of that === mlh_ is now known as mlh [02:12] hi spiv [03:04] hi poolie [03:05] There's a regression in 2.2 I'm filing now that I'd like to have fixed in 2.2.1 [03:05] oh ok, thanks for filing it [03:06] bzr+ssh:// to pre-1.6 bzr smart servers fails :( === zyga-kids is now known as zyga [03:39] poolie: https://bugs.edge.launchpad.net/bzr/+bug/633745 is the bug, btw [03:39] Launchpad bug 633745 in Bazaar "bzr+ssh to pre-1.6 server fails with AttributeError: 'NoneType' object has no attribute 'close' in close_ssh_proc (affected: 1, heat: 6)" [Critical,Confirmed] [03:39] is that related to the spam we're getting from crontab I wonder? [03:39] thanks- [03:39] almost not critical, but worth fixing [03:40] It's pretty shallow, but it's disappointing that hpss to pre-1.6 servers was broken in 2.2, after we had a different bug breaking it in 2.1. [03:41] Oh, I forgot, I have a plugin users can install as a workaround (this bug originally came up IRC yesterday) [03:42] lifeless: yes, I expect my fix will assist with some noise from various scripts, not sure if it's the spam you're specifically thinking of... [03:42] something about ssh and NoneTypes ;P [03:43] Probably the same, then :) [03:45] please for the love of puppies fix it. [03:45] its driving crontab mail for lp nuts ;) [03:46] lifeless: it seems the love of puppies isn't enough to inspire a bug report, though? [03:48] spiv: pretty sure someone was doing one [03:48] spiv: I didn't file one myself because of that [03:49] lifeless: yeah, I thought there would be too, but a few searches didn't find any. [03:49] Exception AttributeError: "'NoneType' object has no attribute 'close'" in ignored [03:49] Exception AttributeError: "'NoneType' object has no attribute 'close'" in ignored [03:49] is what I see [03:49] that case is ec2land, but it looks very similar in cron mails [03:51] Yeah, that's the bug. Until this manifestation I didn't know it was more harmful than occasional noise on stderr. [04:33] * spiv -> lunch === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann [06:41] Is there an equivalent of git merge --squash? I.e. merging several subsequent commits from a different branch into one? [06:41] that's what merges _are_ :) [06:42] so yes, 'bzr merge' [06:45] Well, if you really want to act like --squash, I think you'd also need to do 'bzr revert --forget-merges' after 'bzr merge'. [06:45] But I may be skimming the git docs too hastily. [06:49] Wait, then how do I do a merge the way git merge works - preserving commit history from the other branch? [06:49] That's just 'bzr merge'. [06:53] IIRC, 'git merge' with no args is roughly like 'bzr merge --pull && bzr commit' [06:54] Or if you prefer, 'bzr merge' with no args is roughly like 'git merge --no-commit --no-ff'. [06:55] That's great :) [06:55] So far I've actually found bzr having fewer gotchas and obscure corner cases than git [06:55] and more intuitive overall [06:55] That's what we're aiming for :) [06:56] i think it's only confusing for people that deeply understand git, and can't see why anyone would want to do it differently [06:57] heh [06:57] Well, it has saner defaults [06:58] i really like bazaar's "a branch is a path" over the whole repository thing git has.. having two semanticly different things that you have to deal with confuses me a lot [06:58] that too [06:58] I actually miss parallel instantly switchable branches [06:58] i have that [06:59] it's not intuitive how to get it in bazaar though [07:00] you can have a path for your working folder be a checkout of a branch, and then bzr switch between branches [07:00] lucidfox: I'm sure someone in here can walk you through how to set that up in bzr; short description is 'have a lightweight checkout that you bzr switch between (treeless) branches' [07:01] and you can do things like bzr qlog \dev\branches\* [07:30] ok so after all that distraction i'm going back to prompting to break locks [07:49] hi all ! [07:51] Eek! ETOOMUCHENTHUSIASMINTHEMORNING [08:06] fullermd: lol, catch e: drink more coffee [08:06] enthusiasm is good, can't live without it. [08:06] sure you can :P [08:07] ^- not enthusiasm :) [08:07] well I can... but... [08:07] :> [08:07] Coffee doesn't add to enthusiasm. [08:07] the sky isn't always blue nor the sun shining, better rely on inside resources :) [08:07] vila how hard do you think it would be to write textuifactory tests against a scriptrunner? [08:08] fullermd: being awake helps finding it back :-P [08:08] Kinda the opposite, actually. It makes me more alert, so I better understand the !#&$*%@ my clients try to say, which makes me less enthusiastic about anything other than mass murder... [08:08] But then, you can't spell "slaughter" without "laughter", so I guess it's not entirely unrelated. [08:08] poolie: use '<' ? Oh no, you mean hooking a textuifactory into stdin ? [08:08] mm, hooking up the streams [08:09] probably not too hard? [08:09] yup, if it's not, that's a bug [08:11] fullermd: see ? Laughing is good, always. Do you think DEATH don't laugh at you ? [08:11] * vila shamefully recycles a Desproges's joke :) [08:11] err, shamelessly ? [08:11] yes [08:12] if I start typoing shamefully as a portementeau between shame and fullermd where will I end... [08:13] Mississippi, apparently. So try to avoid it :p [08:15] vila will it cope with input or output that's not a full line? [08:15] eg i want a script like [08:15] Break lock? [08:15] < y [08:16] poolie: no idea, but your input will likely includes a new line. But char-based input... is tricky [08:17] that's ok, i don't need sub-line input [08:17] just for it to cope somehow with an output bit with no trailing \n [08:17] i might try it [08:17] poolie: c.f. shelve input handling requires setup under emacs for example [08:17] poolie: but I don't think textuifactory *allows* char-based input [08:18] to tell emacs to send it single keystrokes not lines [08:18] shelve use a dedicated method for that (~90% sure) [08:18] poolie: no, fully different subprocess handling [08:19] I set it up once but it was... sub-optimal, so I'm back to 'shelve --all' only [08:20] :/ [08:20] iwbn for it to detect stdin couldn't do single characters, and then read lines [08:20] isn't there M-x terminal or something like that, that should send single chars? [08:20] oh maybe that's what you mean [08:21] don't remember the exact mode, but yes, one that doesn't consider stdin to be line-based like the venerable shell-mode [08:22] I think that's why I revert, not everything I needed was supported there or the interactions was too much different === spm changed the topic of #bzr to: Launchpad down/read-only from 0800-1100 UTC for a code update | Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | Release Manager: jam | bzr 2.2.0 is officially out [08:24] poolie: another way to fix the problem will be to have shelve use a uifactory that could be configured to requires that any input includes a [08:24] that's what i meant [08:24] oh, that would be really sweet ;) [08:24] if $TERM=emacs, or something a bit smarter [08:25] oh, again :/ === poolie changed the topic of #bzr to: Launchpad down/read-only from 0800-1100 UTC for a code update | Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | Release Manager: jam | bzr 2.2.0 is officially out | patches welcome: http://webapps.ubuntu.com/employment/canonical_BSE/ [08:46] vila what do you think of something like http://paste.ubuntu.com/490797/ [08:47] hey vila, poolie, and all all all [08:47] poolie: nice /topic update :) [08:48] thanks [08:48] vila: as you work on conflicts again, I would like to ask: is it worth to extend auto-resolve logic to check whether conflicted path still exists, especially when conflict about inability to delete some dir and if there is no such path anymore just mark conflict as resolved? [08:48] :) i think that's exactly what he was just oding [08:48] *doing [08:48] poolie: x and y or z hurts [08:48] bialix: yes [08:49] oh, true [08:49] I thought vila working on moving garbage to the trash can [08:49] "Launchpad will be going offline for maintenance in ten minutes." <--- nnnooooo! [08:49] i don't normally use it but in that context it's ok [08:49] (joke) [08:49] i know [08:49] bialix: that's related :) [08:49] ok, then [08:49] http://wiki.bazaar.canonical.com/VincentLadeuil/ConflictResolution for a broader view [08:50] bialix: moving unversioned files to bzr-orphans dir get rid of some conflicts so they don't even have to be resolved [08:50] I think my thought is related but has its own benefits [08:51] bialix: this also avoid requiring a disctinction between precious and junk files by *not* deleting them [08:51] bialix: see the wiki above, orphaning is a simpler first step [08:51] and may help to fix bug 628561 [08:51] Launchpad bug 628561 in Bazaar Explorer "delete should move files to the trash (affected: 2, heat: 16)" [Low,Confirmed] https://launchpad.net/bugs/628561 [08:52] * bialix looks [08:53] bialix: bug #628561 is yet another variation, the patch I'm working on requires the orphan dir to part of the working tree so far, [08:53] Launchpad bug 628561 in Bazaar Explorer "delete should move files to the trash (affected: 2, heat: 16)" [Low,Confirmed] https://launchpad.net/bugs/628561 [08:54] bialix: I have some ideas about how to allow it to be *outside* of the working tree but it requires more work (basically requiring it to be inside the wt guarantees that we rely on TreeTransform including rollbacks) [08:54] yes, because system trash can is very system dependent, I can use your orphan dir as poor man emulation [08:54] ok https://code.edge.launchpad.net/~mbp/bzr/ui-factory/+merge/34956 posted, with the same diff [08:56] poolie: isn't it a good place to start implemeting a simple fixture [08:56] interesting [08:56] bah, I should comment on the mp instead [08:56] * bialix waves at GaryvdM [08:56] for what? the test ui factory? [08:57] hi gary [08:57] ok, i'm off to take an umbrella to stephane at her office :) [08:57] Hi all [08:57] poolie: make_test_ui_factory [08:57] vila, it may be [08:57] poolie: you've seen my PM ??? [08:57] i don't know if it would add much when no cleanup is needed [08:58] * GaryvdM has been lurking... [08:59] poolie: well, it's even more interesting when no cleanup is needed since you don't tie the fixture to the test class [08:59] or something [09:00] and the other end, make_test_ui_factory not accepting parameters for stdout and stderr while not hinting about it in its name also itches a bit [09:00] well, it was only a tiny change [09:01] GaryvdM: any success with your own build host? [09:01] yeah, no problem, and they can be added later and using a test method also allows for simpler implementations, just mentioning [09:01] GaryvdM: tell us yes :) [09:02] poolie: I think my point is more: hey, this goes in the right direction for fixtures, way to go ! [09:02] * poolie feels better now :) [09:02] i think tearing bits of test base classes into fixtures would be nice too [09:03] bialix: I got stuck where it can't find htmlhelp. I've fix this before on the ec2 server, so this time I'll make sure to document what I did :-p [09:03] yup. defining such test methods is waaaay better than duplicating their content all over the place [09:03] GaryvdM: yep [09:03] I was very tired last night, so I did not try to hard. [09:03] GaryvdM: way to go (Did I just said that earlier ?) [09:16] Ok, I think I'm done for the day. See you tomorrow! [09:18] spiv: cu [09:18] ARGH, lp down... iwbn to be able to setup a bzr branch to fallback to a local mirror for ready-only ops... [09:19] like in being able to handle 'bzr diff -rsubmit:' without tweaking branch.conf [09:19] * vila goes filing a bug on .... idiot === bialix_ is now known as bialix [12:05] so I have a locations.conf in ~/.bzr [12:05] should that be ~/.bazaar? [12:13] voidspace: Yes [12:13] thanks [12:21] that makes two questions the same day that could be answered by 'bzr config' or something... [12:21] voidspace: the closest today is 'bzr version' which mentions 'Bazaar configuration' === Ursinha-afk is now known as Ursinha [12:34] vila: thanks [13:35] hey all. [13:35] Hi mgz [13:50] mgz: hey ! [13:53] mgz: reviewing lp:~gz/bzr/selftest_leaked_threads_measuring_633462 is high on my TODO list, many thanks for working on that, I wasn't finding the time myself and that was frustrating [13:54] I ended up touching more stuff than I intended to, and thought of a way of doing less moving around of code before I fell asleep last night [13:54] but as I'm on a selftest bent I thought I go through and try and knock off all the stuff that has been annoying me for a while [13:55] something like ~10 bugs... how fast can I squish 'me [13:55] *em [13:57] mgz: try using a loom for that so you can more easily make several submissions [13:58] I was using shelve, but the fix broke some unrelated tests that were doing slightly dodgy things, and can't submit a mp with failing tests... it spiralled a little just when I was trying to get to bed [14:04] I know the feeling :-/ [14:10] Is anyone out there running < lucid any more, who could volunteer to test bzr-svn in the proposed ppa/ [14:10] ? [14:41] Hi guys, is there any way to force a bzr+https URL to use urllib instead of pycurl? [14:41] The certificate is invalid on the server, but i know its fine. [14:42] try urllib+bzr+https [14:42] bzr+https+urllib ? [14:42] vila knows better [14:42] bialix: you were right, but order matters [14:42] ok [14:43] Glenjamin: are you sure you bzr+ in front ? (I don't remember if all combinations are registered) [14:43] Glenjamin: are you sure you need bzr+ in front ? (I don't remember if all combinations are registered) [14:43] Glenjamin: we probe for a smart server anyway so this shouldn't be required [14:43] it's a writable smart server over https [14:43] ah [14:43] Glenjamin: in fact there is a nosmart+ prefix to *disable* this probe [14:44] bzr: ERROR: Transport operation not possible: http does not support mkdir() [14:44] httpS [14:44] bzr push https+urllib://url [14:44] or is this error message generic ? Ha, seems so [14:45] ok, try bzr+https+urllib then [14:45] not registered [14:45] maxb: I have a hardy vm. But I'll only be able to look tommorrow. [14:46] is there any way to disable pycurl, or make SSL exceptions? I found a couple of bugs on LP, but they seem to be old [14:46] Glenjamin: there are several that relates to that, old, yes, lack of time :-/ [14:47] i'll just turn on http until i get the cert sorted i guess [14:47] Glenjamin: there is something weird in your server config that makes the probe fails maybe, to you have a .bzr.log handy ? [14:50] Glenjamin: I was 99% sure we didn't need to register bzr+https+urllib since urllib is already the default, let me check [14:50] Glenjamin: argh, yes, urllib is the default for http but pycurl is still the default for https [14:51] Glenjamin: the idea is that since some people relies on ssl certificate verifications we can't disable it by default [14:51] Glenjamin: there is more than one client involved right ? [14:54] there will be, yes [14:54] Glenjamin: the best I can offer then is plugin, but it should be installed on all clients... and uninstalled once you fix your certificate :-/ [14:55] yeah, i'm planning to put a plugin on anyway for a shortened url scheme [14:55] but normally i'd have the plugin in the repo and have users use the full URL once to get the plugin [14:57] Glenjamin: lp:~vila/+junk/defaultToUrllib a bit dusty, but still working without any updates for... OMG, I never committed it :) [14:57] Glenjamin: just a sec :) [14:58] last modification date is 2008-01-22 16:25... [14:58] i've just allowed bzr+http access for now [14:58] i think we've got a cert for this domain somewhere [14:59] Glenjamin: which means your passwords are in the clear then (if you use Basic) [15:00] its on the same subnet, it'll do for the next few days [15:00] Glenjamin: ok, np with me :) [15:01] Glenjamin: I didn't hear anything anyway, I wasn't even there [15:02] Glenjamin: ok, lp:~vila/+junk/defaultToUrllib is now up-to-date, feel free to copy/paste in your own plugin if you have some deployment policy for it [15:03] i'm now getting ('error', "'module' object has no attribute 'ElementTree' back from the server =/ [15:03] i'm fairly sure it was working before [15:03] Glenjamin: this rings a bell, 'bzr version' on the server ? [15:03] I'm pretty sure we've fixed something there quite recently, mgz ? [15:04] yeah, get the latest bzr-xmloutput plugin [15:04] or... is that the same error? no, something else. [15:04] 2.1.1 [15:05] can you get the full traceback from the .bzr.log on the server? [15:06] i can, once i figure out how to get the wsgi app to log :) [15:07] 2.1.1... meh, when did your related modification landed mgz ? [15:07] Glenjamin: and on the client ? === james_w` is now known as james_w [15:09] client: http://pastebin.com/MCXszMBS [15:11] hmm, bzr-xml-output shouldn't be involved there, this is happening in the server, we need its log :-/ [15:11] Glenjamin: well, we need the traceback, it should be in the log, but if you find it elsewhere, that's good enough :-/ [15:12] Glenjamin: and that's cetainly worth filing a bug [15:12] Glenjamin: ...unless you have some hooks installed on the server that could involve xmloutput ? === zyga is now known as zyga-afk [15:22] vila: the server doesn't even have xmloutput =/ [15:23] Glenjamin: good, one less possible cause [15:23] Glenjamin: the weird thing is, I'm pretty sure mgz related change occured only on trunk, not in 2.1 nor 2.2 [15:24] managed to get the server log [15:24] http://pastebin.com/3gT0Za2B [15:25] the wsgi make_app tries to access stdin/out which mod_wsgi doens't allow [15:29] ah, it seems to be exactly https://bugs.launchpad.net/bzr/+bug/254278 [15:29] Launchpad bug 254278 in Bazaar "module object has no attribute ElementTree (affected: 2, heat: 7)" [Low,In progress] [15:35] Glenjamin: https://code.edge.launchpad.net/~gz/bzr/remove_monkey_patched_elementtree_escaping_614522/+merge/34028 may be relevant too [15:37] is that in 2.2? [15:39] Glenjamin: I don't think so, checking... no [15:40] i'll monkeypatch the server then, ta [15:42] Glenjamin: can you comment on bug #254278 ? With your bzr version and the log, this probably will be just a backport of the above fix but I can't investigate precisely right now [15:42] Launchpad bug 254278 in Bazaar "module object has no attribute ElementTree (affected: 2, heat: 12)" [Low,Confirmed] https://launchpad.net/bugs/254278 [15:42] Glenjamin: oh, if you path your bzr on the server, say so in the bug then ! [15:43] Glenjamin: oh, if you apply the patch to bzr on your server, give some feedback in the bug too ! [15:47] done, thanks for the help :) [15:51] Glenjamin: perfect [15:52] Glenjamin: thanks to you, knowing that the fix works is a good part of the... work :) [15:53] ah, so I actually fixed his bug, rather than creating it? [15:53] woho! [15:54] mgz: yeah :) All you have to do now, is 1) fire an mp for backporting it to 2.1, 2) assign the bug to yourself..... 4) profit ! ;) [15:55] I'd better just check a profile under 2.1 as well to make sure it's not using the hack majorly either [15:55] :) [15:58] NOOOOO, ff lost my review :( [16:00] oh, out of interest - what workflow do you guys use for conflict resolution? [16:03] I like to use physical intimidation and loud profanity, myself. [16:06] * bialix is second here [16:13] okay, Toshio's post in that bug is the only thing that could make sense, but I can't repo the problem here so there might also be some wdgi import issue going on [16:14] Glenjamin: could you get your wsgi script to give you the module path to bzrlib.xml_serializer.elementtree please? [16:22] ...with conflicts I just generally search through for >>> and double check the diff after resolve, but don't take that as best way [16:24] smerge-mode in emacs is nice. [16:24] vimdiff is also nice [16:25] smerge-mode is emacs is nice [16:26] Glenjamin: but what do you mean by workflow here ? The way we resolve the conflicts (including the tree-shape ones) or something more high-level ? [16:27] Uhm, I got an error that I have no clue on: [16:27] bzr: ERROR: An inconsistent delta was supplied involving u'/COPYING', 'copying-20100507105513-ntbj8bqjbsjpuvq7-1' [16:27] reason: Attempt to add item at path already occupied by id 'copying-20100505091350-s6ph8iovvrnhwpp9-17' [16:28] Can someone translate that for me please? [16:28] bialix, Gary (offline :-/): where is qbzr today on this topic (conflict resolution) ? [16:28] tedg: -Derror will give a backtrace [16:29] vila, Okay. I have a backtrace, but that doesn't tell me much. [16:30] * vila fires qblame === zyga-afk is now known as zyga [16:31] tedg: that's from revno 4553 by lifeless, the comment says: Add checks for inventory deltas which try to ensure that [16:31] deltas that are not an exact fit are not applied. [16:32] vila, Okay, why are my deltas not an exact fit? [16:32] tedg: I don't fully parse that myself ;) [16:32] tedg: what was the bzr command ? [16:32] vila, merge-upstream [16:33] I was afraid you'd say something like that :-/ [16:33] tedg: file a bug [16:34] Sure, but I need to figure out how to get my work done as well :) [16:34] I don't think this can be answered without reproducing and some analysis :-/ [16:35] tedg: this smells like a parallel import problem though as I don't think COPYING is often renamed [16:36] tedg: and don't forget to tag the bug UDD [16:38] vila, Will do. Doing by hand now to see if I can get more info. [16:40] tedg: checking the COPYING file-id in both branches should confirm that they are the ones involved [16:40] james_w: does tedg problem above rings a bell ? [16:40] vila: conflict resolutions? qconflicts or qresolve command [16:40] grr, ring, no s [16:40] vila, How do I get the file ID of a file. [16:40] vila: yes [16:40] tedg: it's fixed in bzr-builddeb trunk [16:41] tedg: here you go :) [16:41] vila: if you're lucky enough you can launch external gui merge tool; then say which conflict is resolved [16:41] Glenjamin: ^ [16:42] bialix: thanks, that was for Glenjamin [16:42] Glenjamin: what is your question actually? [16:43] tedg: bzr inventory --show-ids | grep COPYING [16:43] james_w, Will that get in Maverick? [16:43] tedg: yes [16:43] mgz: it was xml.etree iirc [16:43] vila, Thanks! [16:44] james_w, Woot! If I do the merge-upstream by hand now do you expect that to work? [16:44] vila: thats pretty much what i mean - i've been thinking about writing a plugin so you can do "bzr resolve --this FILE" or "bzr resolve --other FILE", which basically does mv on .THIS or .OTHER and resolves [16:44] but can't decide if there's any point [16:45] tedg: by hand how? [16:45] Glenjamin: http://wiki.bazaar.canonical.com/VincentLadeuil/ConflictResolution [16:45] Glenjamin: thanks, is that first path through the import maze then. would you mind reverting the hack stripping diff, and try a one line addition higher up for me? [16:45] Glenjamin: that's a work in progress [16:46] mgz: sure [16:46] vila: thanks for the review, hope it won't upset you too much if I poke the branch a bit further [16:46] Glenjamin: after http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/annotate/head%3A/bzrlib/xml_serializer.py#L33 [16:47] oh hang on [16:47] add import xml.etree.ElementTree [16:47] what's a good way to revert [16:47] mgz: not at all, but put the mp to wip then [16:47] i literally edited the file in dist-packages [16:47] vila: not that big a poke [16:47] mgz: see http://babune.ladeuil.net:24842/job/selftest-windows/161/ and ping again for a refresh [16:48] Glenjamin: patch -R with same input? [16:48] james_w, bzr branch ubuntu -r upstream-0.0.9 work ; cd work ; tar -xvzf 0.0.10 ; bzr commit ; etc. [16:49] i was lazy and just hacked it out with nano D: [16:49] tedg: it's not great as it doesn't get the pristine-tar data in [16:49] tedg: and it's probably quicker to use a checkout of bzr-builddeb trunk to run that one command [16:49] james_w, yes, how do I add that? [16:49] tedg: you can't do it from the command line [16:50] okay, overwrite with http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/download/john%40arbash-meinel.com-20100217171116-h7t9223ystbnx5h8/xml.py-20050309040759-57d51586fdec365d/xml_serializer.py then [16:50] james_w, Heh, well, I'm at the final step -- so quicker isn't an issue at this point :) [16:50] (and make sure the perms don't get mangled) === beuno is now known as beuno-lunch [16:52] vila: had problems with using result.stream and subunit in the test collection branch, I might need some extra code to make it happy [16:53] ...I'll stick this in the mp [16:54] mgz: does it mean the babune run won't complete ? [16:54] mgz: no idea is an acceptable answer [16:55] I didn't get as far as working out why subunit was unhappy last time, and it was a good thing to remind me about [16:55] 'remind me about' ? Me ? When ? [16:55] you mentioned babune in the mp, and I thought "oh, er..." [16:56] ah, ok [16:56] mgz: that appears to fix the issue as well [16:56] this is a slightly different situation so may actually be fine [16:56] glenjamin: great, thanks. [16:57] is there some sort of weird lazy loading going on in etree? [16:57] our code is slightly dodgy and relying on what other people's modules happen to import [16:57] vila: I think I might put that one-liner up for 2.1 rather than the monkey-patching strip, it's a less scary diff === dorins_ is now known as dorins [16:58] jelmer: thanks very much for tracking down the KARL3 svn-import issue [16:59] TresEquis: np [16:59] heh, conflicts somewhat more complex than my use case :D [17:03] mgz: sure thing, will ease SRU [17:03] james_w: upstream bzr-builddeb does fix it. [17:04] great, thanks for testing tedg [17:04] it will be uploaded soon, there are just a couple more fixes that I want to include [17:04] Glenjamin: you mean you were referring to text conflicts only ? [17:05] i was referring specifically to the case where i just want to say "use this one" in a text conflict [17:06] with newish bzr you can do `bzr resolve --take-this` [17:06] or --take-other [17:06] ah, thats exactly what i was after [17:06] cheers for the help today guys, time to go :) [17:10] Glenjamin: eerk no, I'm pretty sure --take-{this|other} doesn't work for text conflicts (yet)! [17:10] argh, too late :( [17:22] mgz: for the record (and Glenjamin) see 'Provide additional actions for text conflicts' at http://wiki.bazaar.canonical.com/VincentLadeuil/ConflictResolution, Implementing --take-this and --take-other first sounds like a bad idea as people may confuse them with --prefer-this and --prefer-other. [17:23] it's bad for real conflicts, quite often people have versioned auto-generated things where you just want the stupid [17:26] mgz: yeah, we need either versioned properties and file-level config variables to set a default action for these specific files [17:43] mgz: job 161 finished, but no output related to the leaks, expected ? [17:43] yeah, see new comment in the mp [17:44] ha, let see [17:45] mgz: hehe, so... add comments :-P [17:46]