[00:29] mtaylor: so, the failure that stops it extracting for me on lucid is the same problem that building has apparently, but instead of being an error it just silently carries on. I don't see how this ever worked though. [00:30] mtaylor: the way I see it, it calls tar with -k, which means "don't replace existing files when extracting" and so the updated file that is listed in include-binaries isn't written over the top of the file from upstream. === Ursinha-afk is now known as Ursinha [06:16] spiv: lifeless tells quite highly of your repo repair skills [06:16] jtv: was just reading backlog from the other channel [06:16] * jtv cheers him on [06:16] (btw got the Prague picture? Women here have a tendency to point at you and ask questions when I show them my pictures) [06:17] jtv: pastebin the contents of 'find . -type f .bzr/repository'? [06:17] jtv: I did, thanks :) [06:17] spiv: not sure what it is you want me to find—that's not correct "find" syntax. [06:17] Although I admit to being puzzled why you are showing my picture to various women ;) [06:17] Oh, thinko [06:17] spiv: it's just in the batch, I can't help it. Some quite good ones. [06:18] 'find .bzr/repository -type f' [06:18] Got a great one of elmo, like an ultra-modern version of a 17th-century Dutch painting. But he doesn't like being in pictures so I'm not sharing widely. :/ [06:20] spiv: http://paste.ubuntu.com/483798/ [06:20] And pastebin 'bzr dump-btree .bzr/repository/pack-names' [06:20] spiv: http://paste.ubuntu.com/483800/ [06:25] jtv: ok, that definitely looks like you hit a pack-names update race. The fix should be 'mv .bzr/repository/obsolete_packs/f16*.*ix .bzr/repository/indices/ && mv .bzr/repository/obsolete_packs/f16*.pack .bzr/repository/packs' [06:26] jtv: which version of bzr? [06:26] spiv: not going to roll forward ? or is there no .new file ? [06:27] lifeless: nope [06:27] spiv: 2.2.0 [06:27] jtv: drat, that should contain all the fixes jam has made in this area :/ [06:27] jtv: which filesystem? [06:28] ext4 [06:28] it goes bad from time to time… wgrant has reported the same [06:28] Can I just cp -r to back up my repo? [06:29] Yep [06:31] Well, that's done. [06:32] And it seems to be working! Yay! [06:32] Thanks spiv, thanks lifeless :-) [06:33] jtv: Now the only question is what caused it :/ [06:34] My candidates are: a recent filesystem corruption and a race condition (the problem struck when I was pulling multiple branches in the same repo) [06:48] jtv: It hasn't done that for a long time for me. [06:48] Since maybe May. [06:54] wgrant: that's roughly when jam's fixes landed, IIRC [06:55] this is about the fs corruption I think, not the repo trouble [06:55] FS corruption, yes. [06:56] Block device flakes out for a moment, kernel marks it read only, FS goes bye-bye... [06:56] For me they seemed to go away for a while when I switched from the proprietary nVidia driver to nouveau, but now they're back. [06:56] Oh, more trouble while running rocketfuel-update. :-( [06:56] Exception AttributeError: "'NoneType' object has no attribute 'close'" in ignored [06:56] Exception AttributeError: "'NoneType' object has no attribute 'close'" in ignored [06:57] sorry, rocketfuel-get. [06:57] Those are harmless warnings, there have been posts on the list about them. [06:57] ok [06:58] (Perhaps utilities/update-sourcecode needs to be updated to call bzrlib.initialize()?) [07:22] hi all ! [07:26] spiv: any chance you can review my looms tomorrow ? You did notice you are the pp this week :-D ? [07:35] mgz: pong [07:39] jtv, spiv: bigkevmcd also had a corrupted repo yesterday, also on ext4 :-/ I asked him to file a bug (to track the config details) but I don't see it so far [07:40] vila: yeah, I'll review [07:41] yeah ! [07:41] vila: interesting... I wonder if bigkevmcd had a crash as well? [07:41] spiv: yeah, a reboot [07:42] Hmm! [07:42] spiv: an empty .pack file but dirstate and last-revision where mentioning the missing revision [07:42] which can only be explained by a very very dirty fs flush... [07:42] vila: interesting, quite different to jtv's symptoms then [07:43] vila: which was pack-names referenced a pack that had been moved to obsolete_packs [07:43] spiv: I didn't follow jtv's crash, can you summzrize or point me to the right... ok [07:43] eeerk an impossible scenario too... [07:43] No temporary pack-names files lying around (although a couple of upload/*.autopack, not sure how recent) [07:44] hmm, unless a pack-names file creation wasn't flushed (including creation of the temp one and its renaming...) [07:44] twilight zonesque [07:44] vila: right [07:49] so concretely, the fs might guarantee that f = open('foo.new', 'w'); write(f, '...'); close(f); rename('foo.new', 'foo') is atomic in the face of a crash (as I believe ext3 and ext4 do by default now), but not guarantee anything about whether files created and renamed before that will actually hit disk before that. So the (small) pack-names file might have its update committed, but the larger pack file might not be. [07:50] ...or somehow related to a journalling problem... It's hard to believe that an out-of-order error can happen for the updates of a single process though... [07:51] hehe long mesgs tend to cross on the wire :) [07:51] Well, in the face of a system crash, I don't think any guarantee is made about the relative order that files are written. [07:52] but journalling is supposed to protect against such scenarios... [07:52] ext4 defaults to data=ordered, which strictly speaking only guarantees that the file *metadata* is journalled. [07:53] Search for "* ordered mode" in http://lxr.free-electrons.com/source/Documentation/filesystems/ext4.txt [07:53] i.e. dir content and that's exactly what failled...oh wait, *file* content vs *dir* content :-/ [07:55] eerk, ordered is the default :-/ not journal [07:55] * vila revises its beliefs :( [07:56] so the fs is not corrupted... I'm so glad :( [07:57] And even if data=journalled it's not clear to me if that implies that changes to multiple files are necessarily committed in the same order as a (single) process that issues them. That doc only clearly states than an individual file will be consistent. [07:59] spiv: if data=journal (and the journal is not lost somehow), then after a crash, the journal is replayed and all updates should be seen [07:59] that's the point of a journal or all bets are off [08:00] vila: right, but the most recent changes might not be "committed" and lost, so the question of ordering still matters. [08:00] once an update is committed on the main fs, the corresponding entries must be deleted from the journal or be defined in a way that allow them to become no-ops if they are re-played [08:01] vila: also, see the auto_da_alloc option described at that URL [08:03] spiv: and we don't use fsync right ? [08:05] It's a bit scary to be qualified 'broken' there, sounds like some fs optimizations are a bit user-hostile... [08:05] vila: right, because it practice it is a huge performance hit because it tends to cause a system-wide flushing of buffered writes :( [08:05] EISHOULDNTHAVETOCARE [08:06] vila: there have been some "entertaining" discussions on the topic of fsync/ext4/etc summarised on LWN in the last year or so [08:06] vila: google for o_ponies if you like ;) [08:06] hehe [08:11] All I want is my rug back ! === Leonidas is now known as Guest60304 === Leonidas_ is now known as Guest96662 [09:19] hi, I have question about repository layout/workflow, can anyone advise? [09:22] I have two projects which share common source files. What is the best way to keep it all versioned and make it easy to backport changes from one project to another? [09:27] CcxCZ: the easiest way today is to handle 3 separate projects: project A, project B and project common [09:27] CcxCZ: 'nested trees' is the planned feature you really want here [09:28] CcxCZ: with nested trees you will be able to "nest" project common in both projects and cleanly merge changes made by one project or the other [09:30] vila: isn't it supported by 2.2? [09:30] CcxCZ: no, at best it will be supported or alpha in 2.3 [09:31] :[ [09:31] vila: thanks for info [09:32] CcxCZ: depending on the volume of shared files and changes, there are some ways to address your need today but nothing trivial :-/ [09:34] Huh, for some reason --lsprof-file foo.callgrind has given me a callgrind file where most of the calls aren't connected to each other :( [09:35] spiv: stop doing things behind callgrind back ! [09:37] vila: I didn't think I was! [10:03] what's best tool to migrate from svn? [10:09] CcxCZ: bzr-svn allows you to work with bzr while still connecting to an svn server [10:10] I think in most cases, bzr-svn is also the best tool for a one-shot migration [10:15] I think it required some specific repository format which was bothersome [10:15] I'm going to try svn2bzr.py now [10:19] where can i find docs on compiling bazaar? [10:20] bzrlib/_static_tuple_c.c:35: fatal error: _simple_set_pyx_api.h: No such file or directory [10:21] CcxCZ, it only requires a specific repository format if you're using bzr < 2.0 [10:22] (which you probably should not anyway..) [10:25] knittl: just try 'make' in the source directory [10:25] knittl: you need pyrex and a C compiler [10:25] vila: make? i did setup.py install [10:26] i might be missing pyrex [10:26] what's the package's name in ubuntu? [10:27] knittl: why do you want to run setup.py if you're using Ubuntu ? There is a ppa with the latest stable versions and if you want to run from sources you shouldn't need setup.py [10:27] because setup.py is usually the right way for python apps [10:28] and i need to run from source [10:28] CcxCZ: svn2bzr.py? Hasn't that project been dead for three years? [10:28] knittl: then run from sources, using setup.py will only make your life harder [10:28] knittl: python-pyrex [10:30] what is setup.py used for then? [10:31] knittl: *installing* from a release tarball for platforms that doesn't provide binary packages :) If you encounter a problem using it, please file a bug so we can track it [10:32] knittl: but if you want to run from sources, you don't need it (or you will have to run it each time you modify the sources) [10:32] uhm ok. let's try make [10:32] Well, that's not entirely true. You only need to re-run it when you modify compiled bits [10:32] knittl: all you need to run from sources is to make the 'bzr' script appears in your PATH [10:32] And "make" is just a trivial wrapper around setup.py [10:32] well, run everytime sources change is normal routine for selfcompiled apps [10:33] maxb: I was talking about setup.py, not make [10:33] no target install [10:33] :-/ [10:33] knittl: 'make' not 'make install' [10:33] i did make. and then i wanted to install [10:34] knittl: ghaaa, sorry. 'make' will build the extensions in the *source* dir, you can then run from here, no need to install, [10:34] but i want to install it systemwide [10:35] knittl: if you really really want to install, then yes, run setup.py [10:35] there we go … [10:36] knittl: why not use the version provided by either Ubuntu or one of the ppas described at https://edge.launchpad.net/bzr ? Just curious... [10:37] knittl: some plugins requires that the dependencies are kept in sync and is not a trivial task (/me looks at maxb ;) [10:37] It's not that hard, either, though [10:37] running comparisons of different dvcs (latest version from source) [10:38] I can understand wanting to check out how difficult a self-build is, to not be beholden on packagers [10:39] knittl: then I'd strongly recommend using https://edge.launchpad.net/~bzr/+archive/ppa , it's recent enough to make no differences with bzr.trunk except that the later may drive you into dependencies problems that will be totally irrelevant to a dvcs comparison... [10:40] hmm [10:40] knittl: anyway, these are the options, use whatever you see fit [10:40] but it's only rc? [10:41] knittl: nope, see this channel topic, I'm pretty sure all installers are already up-to-date (minus the OSX one ?) [10:41] what's special about the channel topic? [10:41] knittl: so the official announcement will occur RSN but the sources have been frozen already [10:42] knittl: it says: bzr 2.2-final has gone gold [10:42] not rc nor beta anymore [10:42] yes. but current trunk is 2.3.0, isn't it? [10:42] knittl: no, it's trunk but will become 2.3 in ~6 months [10:44] yeah. but it's not 2.2 [10:44] whatever, i'll have a look at the ppa as well [10:48] knittl: indeed, it's not 2.2 and as such is not as stable as 2.2, my point is just to warn you about that. While bzr.dev have a few bug fixes/memory consumption optimizations, I don't think that's worth the risk for a comparison if this means you get a bad user experience (and hard to reproduce problems, trunks of bzr and plugins may change quickly especially just after a release) [10:49] knittl: on the other hand, I'm not aware *today* of any problem in this area... [10:49] i'm not comparing usability [10:51] knittl: ok, feel free to ask any questions anyway [10:51] i sure will. thx :) === Guest96662 is now known as Leonidas [11:06] how do I remove project from shared repository? [11:08] Do you mean branch, not project? [11:09] yes [11:30] CcxCZ: You can just delete the branch from disk. Unfortunately there's no way to make bzr purge the data in the repository which is now unreferenced === FryGuy_ is now known as FryGuy- [11:34] so, the best way to clean shared repository is to make new one and re-branch all branches from the original one [11:42] If you really need the diskspace, yes [11:56] quick bzr question if anyone knows. I mistyped a branch name, hence merged with a non-existent branch, this didn't time out, so I ctrl+z'ed it. Now I get errors about the dirstate lock not being available. Ideas? [11:57] hi guys [11:57] is there any way to tell the merge command to ignore certain files? [12:00] Glenjamin: you can use --interactive [12:04] i was hoping for a middleground. I've got a branch which is going to be hanging around with a few changes from trunk - and i'd like be able to merge fiex back upstream without messing around a lot [12:04] i guess merge -c is probably my best bet [13:08] hi! how can i add files that are outside the working tree? [13:12] guiQt: 'bzr add file' unless they are really *outside* of the working tree as in 'above the root of the wt' in which case, you can't [13:15] but using bazaar explorer, i can't even see files outside the working tree... :-( [13:15] that's the reason of my question [13:20] guiQt: Under the working tree section, there's a drop down box to the left of "Filter:" [13:20] what does it say? [13:21] Unignored [13:21] I think he really means outside the wt [13:22] select "All" [13:22] or "Unversioned" [13:22] i have several project directories and a shared folder. they're all siblings. how can i add files belonging to shared folder? [13:22] ah, i see [13:23] yes, shared is above the root of each project [13:23] then the previous answers were more accurate - you can't add files that are actually *outside* the working tree [13:23] but what is the best strategy for such a case? [13:24] i believe there's a feature called nested trees in development, that works in a broadly similar way to svn:externals - but i don't know how complete it is yet. [13:26] i'm new to versioning systems and i supposed this pattern was frequent: several projects sharing common libraries [13:27] yes, you'd normally version the common libraries separately [13:27] and essentially treat them as their own project - which the other projects depend on [13:27] so do i till now! [13:27] which language are you using? [13:28] c++ (qt) [13:28] ah, i'm not really familiar with handling dependencies for C++ [13:29] guiQt: what's the problem versioning it separately? [13:30] with* [13:31] when exporting the project [13:31] i'd like to have all my files togheter [13:32] not each project uses all shared files [13:33] not a problem at all, only a matter of redundancy [13:33] I'd write an export script for each project, exporting only necessary files [13:34] if you mean export as in bzr export (without history) [13:34] exactly [13:35] ok [13:35] thank you so much for the talk. see you again. ;-) [13:36] glad to help :-) === Noldorin_ is now known as Noldorin [14:02] mgz: pong [14:17] [Errno 11] Resource temporarily unavailable [14:18] http://paste.ubuntu.com/483956/ [14:18] Known issue with the new bzr from the PPA, or pebkac? [14:19] pebkac [14:20] So that error can mean 'disk full' [14:25] Freed disk and it is still stuck. [14:26] hulp [14:28] sorted. another window had a 'bzr diff|less' open. === JFo is now known as JFo-swap [15:52] how can i make bzr resolve by accepting all THIS files as valid? [15:53] chx, I think "bzr resolved --take-this" [15:54] weird, bzr help resolved didnt list that option [15:54] resolve/resolved [15:55] yeah that probably needs 2.2 [15:55] i only have 2.1 [15:55] i guess revert [15:55] revert . [15:55] without the dot it will forget you merged as well, which you don't want === zyga is now known as zyga-dinner === zyga-dinner is now known as zyga [17:01] vila: still around? [17:03] mgz: not for long [17:04] well, I'm yours till you need to be gone. [17:04] hehe [17:05] you pinged me .. yesterday ? [17:05] ah, yeah, two things about my current mp, probably should have just posted there [17:06] 1) can I have your output with 2000 complaining tests, because I don't get nearly that many (and don't think I skip that much either) [17:06] 2) how is bb.test_log fixable just with addCleanup? [17:06] hmm, I'll need to re-run that [17:07] also, if you need any of my results for your leak branch, I've got the full thing [17:07] I don't clearly see where the cycle is, but you should be able to break it in an addCleanup [17:08] if only by deleting the offending attribute [17:08] or setting it to None [17:08] right, that doesn't work, because it's on the closure over the instance [17:09] you can't do much with cell objects. [17:09] and they're not terribly easy to get hold of. [17:10] waitaminute [17:10] there might be some locals poking trick, but not one I know about. [17:10] rhaa, what's wrong with lp ? I had all sort of random font sizes problems :-/ [17:11] they've changed some css, I see [17:11] might have caused your browser confusion === beuno is now known as beuno-lunch [17:12] so, for log, isn't it enough to self.log_catcher = None ? [17:13] mgz: after reverting your patch of course [17:13] nope, and I tested that just to be sure. [17:13] or del it [17:13] (well, to be exact, [17:13] + self.addCleanup(setattr, self, "log_catcher", None) [17:13] ) [17:14] hmm, does the cleanup lambda keep a reference to self in that case ? === chx_ is now known as chx [17:16] I rather suspect that bug 249452 in ubuntu was resolved some time ago [17:16] Launchpad bug 249452 in bzr (Ubuntu) "bzr overrides the shell prompt settings (affected: 0, heat: 17)" [Undecided,Confirmed] https://launchpad.net/bugs/249452 [17:19] lamont, did you see poolie's last comment on that bug? [17:20] yeah, it's fix released in Bazaar, but still open in ubuntu, I'm guessing it never actually made it out as part of 1.6? [17:20] mostly I didn't want to track down what version it was fixed in for ubuntu [17:20] vila: because the cycle is between the cell and the instance [17:21] not the attribute. [17:21] mgz: ha, looking at the source instead of the mp... [17:21] what do you call the 'cell' ? [17:21] it's the little object python creates for closures to store the outer variables [17:21] * mgz is actually a little shaky on these internal details... [17:21] mgz: so you need to delete the closure [17:22] or step back and re-think the approach taken in def getme(branch) [17:22] okay, here's a minimal case, what's the right cleanup to add? [17:22] hack in hijacking == True :) [17:24] http://float.endofinternet.org/bazaar/simple/weakcycle/weakcycle.py [17:24] the refs and weakref stuff is just to see what's happening, all that's needed is the closure for the cycle. [17:25] del inner ? [17:25] try it and see :) [17:26] wait, did I screw that test up.. [17:26] * mgz tries being less lame [17:27] need the bzr TestSuite [17:28] with or without inner defined I get the same result [17:28] yeah, I minimised too much without checking the negative result [17:28] fixing... [17:31] mgz: I remember why I did that I think: I needed to get the right LogFormatter object but the registry is a factory so I had to define __new__ to capture the object creation [17:32] there may be alternatives that doesn't involve cycles, but I'm still unsure about the whole cycle elements [17:32] yeah, the way the test is written currently is explainable [17:33] okay, so, just deleting something *should* work [17:34] but... log_catcher isn't sufficent. [17:34] mgz: as long as it's part of the cycle, yes, that's the idea [17:34] so, what constitute this cycle [17:35] mgz: so may be del MyLogFormatter ? === Ursinha is now known as Ursinha-lunch [17:35] no, that's just the type, not involved [17:35] or MyLogFormatter.__new__ = None [17:35] * mgz unshelves his debugging function [17:35] well, __new__ reference self (the test instance) === deryck is now known as deryck[lunch] [17:39] mgz: I'll be passing around only for the next hours but will be available if needed around 21h00 my time (in ~3 hours), ack ? [17:40] yeah, I'll dig a little more, thanks for the help. [17:41] ok [17:48] okay, I understand now [17:49] it *is* the __new__ that's the issue, because it's (implicitly) a staticmethod === gorozco is now known as p4tux [18:01] mgz: that was my last suggestion, yes, so it should stay defined as long as the... test class is defined ? Ouch [18:02] there is still one bit I don't remember (or may be I didn't understand it either at the time): why defining __init__ isn't enough ? [18:04] mgz: maybe overriding b.log.LogFormatterRegistry.make_formatter can work around the problem... [18:04] * vila off again === beuno-lunch is now known as beuno === Ursinha-lunch is now known as Ursinha [18:18] bzrlib/_dirstate_helpers_pyx.c:9002: warning: dereferencing type-punned pointer will break strict-aliasing rules [18:18] nice. only not. === deryck[lunch] is now known as deryck [18:53] does bzr have such concept as "tag", how do i add tag to a project, say "2.3", and how do i check if such tag already exists? [18:54] glen: bzr tag [18:54] glen: and "bzr tags" to see existing ones. [18:54] thanks a bunch! [18:54] glen: You probably don't want to tag something just like "2.3" because tags merge across branches. [18:54] glen: So you probably want something like myproject-2.3 [18:55] i.e it can't start with a number? [18:55] glen: It *can*, I just wouldn't recommend it. [18:55] anyway, i see project already has tag set: "release-2.3-final 4132" [18:55] glen: Also, you could have a revision number "2.3", which means you'd have to explicitly do -r tag:2.3 instead of just being able to do -r 2.3 [18:56] glen: Okay. :-) [19:36] mgz: ping, are there any updates on your mps for testtools or bzr that I should pull before re-running for the 2000 ? [19:56] don't suppose any setuptools_bzr contributors hang out here? having a problem with setuptools_bzr 2.0 and bzr 2.0 [19:56] er... bzr 2.2.0 [20:13] vila: no, just as is would be great [20:16] hmpf, massive maverick update [20:16] 192 packages, 230MB will be downloaded :) [20:26] hmm, nice colored ascii screen, makes me feel younger :) I prefer the graphic version though, especially when running X... [20:27] at least a reboot fixed it :-/ [20:40] mgz: hmm, ran 4 tests... again ? See http://babune.ladeuil.net:24842/job/py27-test-cycles-maverick/3/console [20:40] * mgz looks [20:40] mgz: did I use the wrong branch ? [20:41] is that on 2.7 as per the name? [20:41] yup [20:42] it doesn't need to be... [20:42] also, I've not done anything to fix --parallel=fork [20:42] (yet) [20:43] doesn't need 2.7 ??? Where did I get this belief then ? [20:44] running without --parallel at http://babune.ladeuil.net:24842/job/py27-test-cycles-maverick/4 [20:44] it's probably based on the branch for fixing selftest on 2.7 as that changed a bunch of things that would conflict. [20:45] that's looking good, thanks vila [20:46] mgz: http://paste.ubuntu.com/484132/ doesn't look good to me :) [20:46] hmpf, that's still getting junk in the output [20:47] ...is that what your link is saying too? [20:47] for skipped tests [20:47] it's still 2.7... that needs tracking down, I'll file a bug already. [20:49] this is really only a 2.7 thing, right? doesn't appear on any of your other bots. [20:49] mgz: I've setup a dedicated job on babune (it should pull from the bzr branch but not the testtools one though), so it will be easier to re-run or tweak [20:49] great, thanks. [20:49] I've setup a maverick slave and add the adequate ppa so py27 is the default [20:50] but the ppa lacks pyrex so far [20:50] I think I'll file against subunit because I've failed at seeing anything wrong in bzr or testtools [20:50] can always get moved later. [20:50] mgz: if you read the begining of the log, I've added some commands to display what is used [20:54] mgz: I've created a new view to track this kind of jobs: http://babune.ladeuil.net:24842/view/debug/ [20:58] this skipped printing-of-random-details-member thing doesn't actually look fatal [20:58] so, it might be a seperate bug that's causing the xml parser to fail on the subunit output later [21:15] that run looks wedged. is that going to be my fault or a known issue? [21:19] mgz: no idea [21:19] mgz: rather, no known cause for hanging runs on mo.... no space left on device :-) [21:19] wait, now it's progressing [21:19] er... well [21:19] IOError: [Errno 28] No space left on device [21:20] * mgz bows to vila [21:20] and man that 2.7 logging change is obnoxious [21:21] meh, no idea what obnoxious means here ;) [21:21] the log ends with thousands of tracebacks from the logging module [21:21] looks like tmp is full [21:22] which isn't nice, or useful. [21:22] there is 1GB log file there [21:22] WARNING listening socket error: [Errno 24] Too many open files [21:22] mwahahahahaha [21:23] * vila bangs head on desk [21:23] also known as leaking tests fills up my OSX disk :-( [21:24] well, at least we're progressing on several fronts, even if it's a pain. [21:24] I don't want to start saying: I've told you.... [21:24] why does bzr launchpad-login try to fetch the +sshkeys page from launchpad for the user? [21:24] but I've been repeating for ages that the leaking tests could blow up at any time... [21:25] cody-somerville: to check that the user can login with one key registered on lp ? [21:25] vila: oh hai [21:25] and hi mgz [21:25] lifeless: hey ! [21:26] hey lifeless. [21:26] before I get back to filing this against subunit for lack of better ideas, do you have any smart thoughts on why 2.7 only babune gets skipped [some random details member] in the output? [21:27] see vila's pastebin ^up there for an example [21:27] mgz: so, either you fix --parallel or you wait for my leaking tests mp to land (or review it :-) [21:27] mgz: s/only/on/ ? [21:28] well, I mean that it happens on 2.7 but apparently not 2.6 [21:28] ^okay, I'll look at parallel, presume that I can just override osutils.---thingy---concurrency to test [21:28] BZR_CONCCURRENCY even [21:29] ah, I meant, as in, write a testcase, but yes [21:30] * vila EODing, have fun ! [21:30] bye vila! [21:31] well 2.7 added an official skip [21:31] which pastebin ? [21:32] sorry, wrong keyword, [21:32] mgz: http://paste.ubuntu.com/484132/ doesn't look good to me :) [21:33] those ones actually have the 'reason' detail, but others have the 'traceback' or 'log' [21:35] whats wrong with it ? [21:36] it's weird, and we're not sure if it's related to the other things that go wrong with 2.7 like, the xml output not being well-formed [21:36] it looks like parameterisation or something to me [21:37] the reason you'd get logs and stuff, is if the skip is done late [21:37] after test activity [21:37] like I say [21:37] 2.7 added skip support [21:37] so I suspect an interaction with that [21:38] sounds likely, so, where should I be filing this? bzr? testtools? subunit? [21:38] whereever the problem is ;) [21:38] ;_; [21:38] I doubt subunit [21:38] very very much [21:39]