| Noldorin | jelmer, ah ok... | 00:09 |
|---|---|---|
| Noldorin | so absolute path | 00:09 |
| Noldorin | fair enough | 00:09 |
| Pegasus_RPG | Hello. Quick question: if I bzr cp a file to another name, will future changes to the original be propagated to the copy? | 05:26 |
| vila | hi all ! | 07:32 |
| jelmer | hi vila | 07:50 |
| mgz | morning! | 08:01 |
| jelmer | mgz! | 08:01 |
| vila | jelmer: regarding bzr-upload, as mentioned in the review, I want to use dedicated series, not maintain compatibility at all costs on trunk | 08:01 |
| vila | hey mgz | 08:01 |
| vila | standup ? | 08:01 |
| jelmer | vila: the plugin's metadata suggests it still supports 2.4 | 08:01 |
| vila | because we didn't bump the internal API for 2.5... | 08:02 |
| vila | so apples and oranges | 08:02 |
| vila | and as mentioned in NEWS, the code is still compatible with 2.4 so far, only the tests requires 2.5 | 08:02 |
| vila | but one needs to start somewhere :) | 08:03 |
| vila | the intent is to have a 1.1.0 when bzr-2.5.0 is released | 08:03 |
| * jelmer looks for his headset.. | 08:05 | |
| jelmer | got it | 08:09 |
| jelmer | vila, mgz: mumble? | 08:09 |
| vila | jelmer: there we are ;) | 08:09 |
| vila | jelmer, mgz : can you have a look at https://code.launchpad.net/~bzr/bzr/doc/+merge/84069 ? Given my implication I can't review it anymore ;) | 10:54 |
| alansaul | Hey guys, how can I get previous versions of a file that I accidently deleted? | 10:54 |
| alansaul | I dont want to take everything back, just them, can i just do a revert x.rb | 10:55 |
| jelmer | vila: sure | 10:55 |
| mgz | ...it didn't seem from the comments I saw go past there were any issues with that mp vila | 10:55 |
| mgz | alansaul: yup. | 10:55 |
| vila | mgz: yup, no issues AFAICS, but voting on it myself seems a bit... bizarre | 10:55 |
| vila | oh crap a > 2.000 lines proposal :-/ Hmm, at least the submitter signed with his own blood that it's mechanical ;) | 11:00 |
| mgz | we can throw things at him if it breaks stuff :) | 11:00 |
| vila | Yeah, the most irritating part is to think that annotations will be broken one way or the other :--/ | 11:02 |
| jelmer | vila: +1ed | 11:02 |
| vila | jelmer: thanks | 11:02 |
| mgz | vila: on the annotations front, just think of it as jelmer accepting all blame from now on | 11:02 |
| vila | hehe | 11:03 |
| mgz | okay, made a teeny bit more work for the pilot, time for lunch | 13:04 |
| jelmer | vila: when you have a chance, a review of https://code.launchpad.net/~jelmer/bzr/hpss-call-counts-3/+merge/84494 would be great - it fixes the hpss call count for lightweight checkouts which is causing spurious failures | 13:30 |
| jam1 | jelmer, mgz: I'm getting a weird bug with latest bzr.dev | 14:00 |
| jam1 | It is trying to take a lock: "~jameinel/u1db/index-transformations/.bzr/branchlock" | 14:01 |
| jam1 | shouldn't that be: ~jameinel/u1db/index-transformations/.bzr/branch/lock | 14:01 |
| jam1 | ? | 14:01 |
| jam1 | It looks like a bad trailing-slash normalization bu | 14:01 |
| jam1 | bu | 14:01 |
| jam1 | bug | 14:01 |
| jelmer | hey jam1 | 14:01 |
| * jam1 goes to a speech therapist for stuttering :) | 14:01 | |
| jelmer | jam1: looks like you're also hitting a bad trailing-'g' normalization bug :-P | 14:01 |
| === jam1 is now known as jam | ||
| jelmer | it does seem like that could be related to the recent URL changes | 14:02 |
| mgz | what fun. | 14:02 |
| jelmer | jam: is this on Windows? | 14:02 |
| jam | currently, yes | 14:02 |
| mgz | jam: file a bug with the command to run, we can probably repo and fix. | 14:03 |
| jam | jelmer: http://paste.ubuntu.com/761635/ | 14:03 |
| jam | mgz: I'm just running 'bzr push' to launchpad :) | 14:03 |
| mgz | o_O | 14:04 |
| jam | k, weird, I also get it with bzr.dev -r-200 | 14:04 |
| mgz | r6079 is one known breaker | 14:04 |
| mgz | if r6078 works and that one doesn't, means there's an extra regression the test suite didn't catch | 14:05 |
| jam | well -200 is 6145 | 14:05 |
| jam | mgz: well, I generally keep up to date with bzr.dev, so 6078 seems a bit to old, but it does indeed work and 6345 does not | 14:06 |
| jam | too | 14:06 |
| jam | now I'm at "nothing to push", so I can't continue to validate it | 14:06 |
| mgz | quick, write more code! :) | 14:07 |
| wgz | okay, I don't get it just pushing to +junk so there must be something specific going on with the branch layout | 14:12 |
| jam | mgz: https://bugs.launchpad.net/bzr/+bug/900764 | 14:14 |
| ubot5 | Ubuntu bug 900764 in Bazaar "failure to push to Launchpad 'branchlock'" [Critical,Confirmed] | 14:14 |
| wgz | ...or with u1db | 14:14 |
| jam | Looks like I was using rev 6322 this morning, and I'm using 6345 when I noticed things were broken. | 14:14 |
| jam | wgz: you can't hide from me :) | 14:15 |
| jam | even weirder, I think I had successfully pushed a couple of times. Maybe it is a remote autopack issue? | 14:15 |
| jam | but that shouldn't trigger a bug locking the branch | 14:15 |
| wgz | oo... ooooo | 14:15 |
| wgz | repacking would be extra fun. | 14:15 |
| jam | well the failure is early on in bzrlib.push._show_push_branch | 14:16 |
| jam | during the first remote write lock call on the Branch. | 14:16 |
| jam | well, something is working now... | 14:19 |
| wgz | how do we get logs from the launchpad side? | 14:19 |
| jam | I wonder if it was a display bug, coupled with a temporary Launchpad failure. | 14:19 |
| wgz | hm. | 14:20 |
| wgz | that's an interesting thought, and testable. | 14:20 |
| jam | mgz/wgz: Interestingly, I have 4 emails in my inbox from Launchpad talking about failures to generate merge proposals. | 14:22 |
| jam | looks like something with the librarian there | 14:23 |
| jelmer | yeah, the librarian was down for a while becuase of hardware problems | 14:28 |
| wgz | I got a 503 from the librarian just before you posted. | 14:28 |
| jelmer | it's not involved in code hosting though, as far as I know | 14:29 |
| wgz | coming back and looking at the bug report again, I don't think it can be a bzr.dev regression | 14:42 |
| wgz | the LockDir url is constructed on the launchpad side and just being reported to the client | 14:43 |
| vila | jelmer: done | 15:00 |
| jelmer | vila: thanks | 15:03 |
| mgz | vila: for some reason, I'm not getting your mail sent to the bzr list | 15:06 |
| mgz | can read it in the html list archive, but neither of your last two "week in" emails got to my inbox | 15:07 |
| vila | o_O | 15:07 |
| vila | mail log confirms the one for this morning was sent | 15:08 |
| vila | not received but I'm pretty sure that's how I configured my subscription | 15:09 |
| vila | (i.e. don't send me my own mails, thanks) | 15:09 |
| mgz | it got as far as the list, but didn't then get back out to me | 15:13 |
| mgz | and your last week's one had the same issue, I only saw it existed because I got the reply-to-the-reply | 15:14 |
| vila | bah, vila, learn to read, he said the mail went to the list, not a problem on your side | 15:14 |
| vila | mgz: that leaves: 1) an issue at your provider (aggressive spam filtering), 2) a wrong filtering on your side ? | 15:15 |
| vila | mgz: they don't like French maybe ? ;-p | 15:15 |
| mgz | it's canonical then google, and didn't get spamified | 15:16 |
| vila | oh, on google ? | 15:16 |
| mgz | I was wondering if there was anything else odd about either message that might cause it to get dropped | 15:16 |
| vila | see ? They know far too much already :) | 15:16 |
| vila | hmm, I can't imagine what can be different, let me check again | 15:16 |
| vila | mgz: here is my local copy: http://paste.ubuntu.com/761701/ | 15:18 |
| vila | mgz: the only lines that you probably won't find in your copy are the 'X-Draft-From' and 'Xref' ones which are local | 15:19 |
| vila | you should have more Received: lines though | 15:19 |
| vila | in other news, consistent oops on https://code.launchpad.net/~gz/bzr/mv_removed_non_ascii_898541/+merge/84609 | 15:20 |
| vila | some one is trying to get between us, mgz, what a nefarious (but hopeless) conspiracy ! | 15:21 |
| vila | there is a suspicious "Warning: <type 'exceptions.KeyError'>: 'branch'" in the oops page... | 15:23 |
| vila | just after a: "Warning: Macro expansion failed" | 15:23 |
| vila | any recent bzr deployment on lp ? | 15:23 |
| mgz | don't think so, but given jam's earlier experience something is up with the launchpad codehosting | 15:25 |
| * vila nods | 15:25 | |
| vila | the librarian failure seem to have triggered a bunch of import failures.... and the importer caught them as lp down times and happily retried them, ending up with 0 additional failures \o/ | 15:28 |
| vila | it did flip-flop a lot (back/down/back/down) but still managed to retry all the right ones | 15:29 |
| mgz | what's one of your oops # vila? | 15:30 |
| vila | (Error ID: OOPS-cbc7444249203b34468eab8a253cf7f1) | 15:30 |
| mgz | ...actually it's so consistent I can also get my own on that mp | 15:31 |
| vila | there are several urls with %7Egz (I thought we settled on ~ being legal and as such never quoted anymore, may be not landed on lp ??) | 15:32 |
| mgz | ...the oops page is really not very browsable | 15:35 |
| vila | yup :) | 15:36 |
| jelmer | vila: yes, that's not on LP yet | 15:36 |
| vila | with 'that' being 'stop quoting ~' ? | 15:37 |
| mgz | alright, is librarian related, forgot they put the diffs there | 15:37 |
| vila | yeah, librarian related but librarian is back. Did you propose while it was down ? | 15:38 |
| mgz | (what jam was saying earlier about getting diff generation failure email should have twigged earlier) | 15:38 |
| vila | s//submit/ | 15:38 |
| mgz | it lost some files apparently, they need reuploading | 15:38 |
| mgz | anyway, they're on it, so won't bug 'em further | 15:39 |
| vila | jelmer: wow, that was confusing (the test rewrites), I got it now | 15:52 |
| mgz | vila: oh conflicts expert | 15:52 |
| mgz | how in the hell you you get to the state: | 15:53 |
| vila | 2.4.2 is still in -proposed ? | 15:54 |
| mgz | added: config.py / conflicts: Conflict adding file config.py. Moved existing file to config.py.moved. | 15:54 |
| vila | mgz: different file-ids for the same file | 15:54 |
| mgz | I can only get to a added: removed: conflicts: state. | 15:54 |
| mgz | not a modified one. | 15:54 |
| mgz | without the removed. | 15:55 |
| vila | what branches do you encounter that in ? | 15:55 |
| mgz | the repo of a bug in qbzr. | 15:55 |
| mgz | I have the guy's branch state, but not clear instructions on how he got there, so I'm not sure how to write the test. | 15:56 |
| vila | bzrlib.tests.test_conflicts | 15:56 |
| vila | ha, crap, you don't like the way these tests are written | 15:56 |
| vila | I had an idea about how to rewrite them but I've yet to do it ;) | 15:57 |
| vila | at least you'll get the bits you need | 15:57 |
| vila | also, you can have a look at po_merger tests which are script-based and easier to grasp, | 15:57 |
| vila | basically you create a branch with all the stuff you need and then branch from the "right" revisions | 15:58 |
| mgz | anyway, just creating two branches with the same file and merging doesn't do it. | 15:58 |
| mgz | as in, diverging from the same root | 15:58 |
| vila | mwhahaha, I want some of either 1) what you're smoking, 2) the tweaked bzr addressing the parallel import issues you're using ;) | 15:59 |
| vila | if merge doesn't conflict merging the same path with two different file-ids it's probably because both paths use the same file-id :) | 15:59 |
| mgz | it conflicts alright, but not the right way | 16:00 |
| vila | text conflict ? | 16:00 |
| mgz | I get added/removed, the example branch just has modified | 16:00 |
| mgz | but with the conflict saying .moved has been created | 16:00 |
| mgz | the diff is just a line in the file | 16:00 |
| mgz | my diff is two files, one added, one removed | 16:01 |
| vila | meh, I'm lost, can you paste your test ? | 16:01 |
| mgz | ...I should look at the history in qbzr | 16:01 |
| mgz | o_O there is only one revision | 16:02 |
| wgz | vila: zip attachment in bug 815822 | 16:03 |
| ubot5 | Launchpad bug 815822 in QBzr "AttributeError: 'NoneType' object has no attribute 'is_ignored'" [Undecided,Incomplete] https://launchpad.net/bugs/815822 | 16:03 |
| vila | jelmer: looking at https://code.launchpad.net/~bzr-core/ubuntu/oneiric/bzr/sru-2.4.2/+merge/81039 , shouldn't some sru team be subscribed there ? | 16:03 |
| wgz | edit testrepo-fb-checkout/.bzr/branch/location to point to the right abspath of where you unpack it, then inspect testrepo-fb-checkout | 16:04 |
| wgz | okay, I think I have an idea | 16:06 |
| vila | grrr, of course I read that after doing it :) | 16:06 |
| kirkland | jelmer: hey there! back to my line of bzr/git import questions | 16:06 |
| vila | wgrant: obviously the .moved file is not there anymore | 16:07 |
| kirkland | jelmer: so i did my 'bzr up' in each of a dozen or so of the dirs that I imported from git into bzr | 16:07 |
| vila | wgrant: sry, bad completion | 16:07 |
| vila | wgz: obviously the .moved file is not there anymore | 16:07 |
| kirkland | jelmer: now, it is customary to push each of those to its own branch in LP? | 16:07 |
| kirkland | jelmer: for history/tracking purposes? | 16:07 |
| mgz | vila: it's just an idea, I still want the expert opinion :) | 16:07 |
| kirkland | jelmer: or how do others handle that? | 16:07 |
| mgz | I think the way I was doing it was wrong, I have two child branches both create a file then merge one to the other | 16:08 |
| jelmer | hi kirkland | 16:08 |
| kirkland | jelmer: howdy :-) | 16:08 |
| mgz | perhaps what's needed is a child branch to create a new file, move it over the file in the parent branch, then merge child to parent | 16:08 |
| kirkland | jelmer: so there are a handful of tags (v1.5, v1.4.3, v1.7, etc) | 16:08 |
| jelmer | kirkland: tags will be stored in the branch as well ("bzr tags") | 16:09 |
| vila | mgz: or create a new file with the same path in branch A and B, then merge ../B | 16:09 |
| jelmer | kirkland: but branches from git are usually pushed as separate branches onto Launchpad | 16:09 |
| kirkland | jelmer: as I described? | 16:09 |
| mgz | vila: that gives me the conflict I had, which is added f, removed f | 16:09 |
| vila | mgz: but from a quick look, the stuff in error.zip is incomplete | 16:10 |
| mgz | rather than modified f | 16:10 |
| jelmer | vila: see poolie's comment on that MP | 16:10 |
| jelmer | kirkland: it depends on your situation a bit - most people register launchpad imports to track branches in git | 16:10 |
| jelmer | kirkland: what's the situation in which you're using bzr-git? | 16:11 |
| kirkland | jelmer: I'm helping my new company migrate from git to bzr/Launchpad | 16:11 |
| vila | jelmer: I followed the comment to bug #848064 and there he says (and I pretty much agree) that this is not specific to bzr (or at least we don't have evidence so far) | 16:11 |
| ubot5 | Launchpad bug 848064 in Ubuntu Distributed Development "Revision not present branching from udd-imported branches on lp" [Critical,Confirmed] https://launchpad.net/bugs/848064 | 16:11 |
| kirkland | jelmer: they have one project (private/proprietary in Launchpad) | 16:12 |
| jelmer | kirkland: ah, I see - in that case what you described indeed makes the most sense - push each separate branch import from git as a separate branch on Launchpad | 16:12 |
| kirkland | jelmer: great | 16:12 |
| jelmer | kirkland: the tags should come along | 16:12 |
| kirkland | jelmer: okay, I'll have a look | 16:12 |
| vila | mgz: ctrl-alt-del, looks like I misunderstood | 16:12 |
| jelmer | kirkland: (and new versions of bzr-git will in fact no longer create separate directories for tags) | 16:12 |
| kirkland | jelmer: oh, interesting | 16:13 |
| kirkland | jelmer: okay, thanks for your help, cheers! | 16:14 |
| vila | mgz: .moved is the THIS file (confusing) | 16:14 |
| vila | mgz: therefore, the added one should be the OTHER file | 16:15 |
| vila | mgz: bbiab | 16:16 |
| jelmer | vila: argh, Option didn't have a help argument in 2.4 :-( | 16:38 |
| === deryck is now known as deryck[lunch] | ||
| mgz | ha! got the repo | 16:57 |
| mgz | ...that was the most convoluted thing ever | 16:57 |
| vila | jelmer: and you encounter that in what context ? | 16:59 |
| vila | mgz: so, fresh from the bug, he did delete .moved file and AFAICS we don't have the branch he was merging from | 17:02 |
| vila | mgz: additionally, his dirstate file seem to miss the revid for the merge too :-/ | 17:02 |
| vila | mgz: on the other hand, he provided the .zip to reproduce a bug which is not related to conflicts. | 17:03 |
| vila | mgz: in a nutshell, the branch he provided may not be one you can re-create | 17:04 |
| mgz | vila: I don't have the exact dirstate he got, the 'modifed' thing is mystifying as the bug needs no file-id to repo | 17:07 |
| mgz | but I have a series of steps that gets that problem | 17:07 |
| vila | mgz: with bzr-2.3.4 ? | 17:08 |
| mgz | with current bzr, the logic error in qbzr is reasonably clear | 17:08 |
| mgz | it's just less obvious how to actually trigger it | 17:08 |
| mgz | I'll wave the test case in front of you | 17:09 |
| mgz | (shortly) | 17:09 |
| vila | k | 17:09 |
| jelmer | vila: current bzr-svn trunk is broken with bzr 2.4 | 17:13 |
| vila | ha, because of the new config support ? | 17:15 |
| vila | jelmer: I thought I mention the compatibility part not being addressed when I first submitted but then thought you had different series targeted at 2.4 and 2.5 and finally, I forgot about it :-/ | 17:15 |
| jelmer | vila: np, it's not too hard to work around | 17:16 |
| vila | jelmer: so, more than help should cause problems no ? | 17:17 |
| jelmer | vila: some other minor regressions, fixing them now | 17:20 |
| vila | jelmer: what kind ? | 17:20 |
| jelmer | vila: not related to config, but apart from that bzr-svn trunk is 2.4-compatible | 17:21 |
| vila | but not 2.3 ? Where do you draw the line ? | 17:21 |
| vila | jelmer: stable + trunk ? | 17:22 |
| jelmer | vila: 2.4 and bzr.dev at the moment | 17:22 |
| vila | k | 17:22 |
| jelmer | vila: it varies, I dropped 2.3 support a month or so ago | 17:22 |
| jelmer | vila: I usually aim for the latest stable series and bzr.dev, but it depends on how hard it is to stay compatible | 17:23 |
| vila | now that you mention it, you probably want to add a .id attribute in your store | 17:24 |
| jelmer | vila: anyway, I just noticed it as I was trying to actually switch over some code to use the new options stuff | 17:24 |
| vila | right, it's opt-in at the option level | 17:25 |
| vila | but even the new options can still be read/modified with the old implementation | 17:25 |
| jelmer | vila: right, but how well will 2.4 work? | 17:27 |
| vila | bzr-2.4 use the new config implementation for only one (or a few) options | 17:28 |
| vila | so it should work at it works before :) | 17:29 |
| vila | worked | 17:29 |
| vila | as far as bzr-svn is concerned, get_config_stack will not be called and since no branch option use get_config_stack in bzr-2.4 nothing has changed | 17:29 |
| vila | jelmer: unless you encounter a scenario I can't imagine ? | 17:30 |
| jelmer | vila: I'm wondering whether I should start using get_config_stack in bzr-svn, or if that will affect compatibility with bzr 2.4 | 17:38 |
| vila | that should even break with bzr-2.4, there is no get_config_stack there | 17:39 |
| jelmer | vila: there is on SvnBranch :-) | 17:39 |
| vila | ooooh, that | 17:40 |
| vila | hmm | 17:40 |
| vila | that's a tricky question :) | 17:40 |
| * vila looks at bzr diff -rbzr-2.4.2.. bzrlib/config.py | 17:41 | |
| vila | jelmer: registering options looks suspicious | 17:43 |
| vila | no cmdline overrides | 17:43 |
| jelmer | vila: that's actually something that seems to work | 17:43 |
| vila | k | 17:43 |
| jelmer | vila: did cmdline overrides work at all in 2.4? | 17:44 |
| vila | it didn't exist | 17:44 |
| vila | just listing | 17:44 |
| vila | ha, remote (smart) branches broken, no impact or bzr-svn ? | 17:44 |
| jelmer | vila: nope - remote branches can't access svn stuff anyway, not even in bzr.dev | 17:45 |
| vila | jelmer: and no expansion either, so overall I saw nothing likely to fail, the basic pieces were in place and if some internals have changed, they should already work in 2.4 | 17:46 |
| jelmer | vila: cool | 17:46 |
| vila | and given the current read/write scheme using both implementations should be ok | 17:47 |
| vila | once this model change (so bzr.dev only) it will become dangerous to access one option with both implementations | 17:47 |
| vila | but even there, that will require modifying the value, so unlikely to be encountered soon (except for GUIs may be) | 17:48 |
| === deryck[lunch] is now known as deryck | ||
| mgz | okay, have a test | 18:00 |
| mgz | don't really understand all this monkeying but hey | 18:00 |
| mgz | vila: do you have a sec to look at a diff and tell me ways to make it saner? | 18:07 |
| vila | mgz: shoot | 18:07 |
| mgz | vila: http://pastebin.ubuntu.com/761875/ | 18:10 |
| vila | the 'remove/add/rename_one' dance you mean ? | 18:12 |
| mgz | yeah, and any of the other branch creaty bits. | 18:13 |
| vila | well, the branch creation bits are not that bad (unless you can create a richer branch in make_branch_and_tree) | 18:13 |
| mgz | I guess remove/os.rename/add would work | 18:13 |
| vila | yup, was about to ask/suggest about using os. everywhere in tree nowhere | 18:14 |
| vila | as I understand it, error.zip was obtained after shell commands, with no bzr commands involved | 18:14 |
| vila | so qbzr may be confused because some files referenced in the dirstate are not there anymore and some other have totally different content | 18:15 |
| mgz | yeah, but I can't get into that state, though I can do this similar one. | 18:15 |
| vila | oh, misread, make_branch_and_tree is the basic bzr one | 18:17 |
| vila | so po_merger tests use branch_builder and scripts which can be more readable, but your tree setup being 10 lines long... that would be overkill | 18:18 |
| vila | you can also add assertLength(1, tree.conflicts()) to complement self.assertPathExists("parent/f.moved") | 18:22 |
| vila | EOD'ing | 18:23 |
| mgz | thanks vila. | 18:28 |
| vila | mgz: rhaa, my comments were confusing. One thing you should think about is that the bug may be caused by some difference between the dirstate content and what qbzr thinks about the wt. As it's written, your test may not reflect that as it uses an in-memory tree which *may* not trigger the same behavior | 18:31 |
| vila | test scripts running complete commands are less likely to suffer from that which is why I mentioned them as opposed to the bzr-upload ones | 18:32 |
| vila | there, that's should be clearer ;) | 18:32 |
| vila | hmm, almost, by in-memory, I mean a wt with its internal state as opposed to loaded from the dirstate | 18:35 |
| lamal666 | lifeless, is pyjunitxml already integrated in testtools somehow? | 18:50 |
| === lamal666 is now known as lamalex | ||
| jelmer | lamalex: it's a separate package | 18:55 |
| lamalex | i know, but im wondering if there's a simple integration path that i haven't figured out | 18:56 |
| lifeless | lamalex: in what sense integrated? | 19:02 |
| lifeless | if you mean 'report tests using it',most folk I know have been setting that up in their local test glue, or if they have non via subunit | 19:03 |
| lifeless | there is a merge proposal just waiting copyright signoff to add a junitxml.main as a convenience for folk too | 19:04 |
| lamalex | ah, i guess we dont really have any test glue we've just been doing python -m testtools.run discover | 19:04 |
| lamalex | which is probably why im having a hard time figuring out how to fit the two together :P | 19:04 |
| lifeless | right now the easiest thing will be | 19:04 |
| lifeless | python -m subunit.run discover | subunit2junitxml -o tests.xml | 19:05 |
| lifeless | (I think, thats from memory - use -h and season to taste) | 19:05 |
| lamalex | yah | 19:05 |
| lamalex | ok, thanks lifeless | 19:05 |
| lamalex | i honestly would have never figured that out | 19:05 |
| lifeless | heh | 19:07 |
| lamalex | lifeless, does testtools output subunit by default/ | 19:32 |
| lifeless | no, subunit.run does (which is testtools compatible) | 19:32 |
| lamalex | ahh | 19:35 |
| lamalex | woop dere it is | 19:36 |
| poolie | hi all | 21:23 |
| wgz | hey poolie | 21:43 |
| poolie | hi there wgz, how's it going? | 21:43 |
| wgz | good, a little bit of an interesting launchpad day. how was your weekend? | 21:46 |
| poolie | really nice | 21:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!