| lifeless | jelmer: poolie: fwiw dealing with tarmac failures is ~ the same opaqueness as pqm, from my observations of nontrivial projects that have migrated :) | 00:19 |
|---|---|---|
| poolie | :/ | 00:20 |
| poolie | don't know what you're smiling about | 00:21 |
| poolie | ;) | 00:21 |
| lifeless | habit | 00:23 |
| lifeless | or something | 00:23 |
| thumper | what does conflicting tags mean on 'bzr pull' ? | 01:17 |
| spiv | thumper: both sides have a tag named 'FOO', but they disagree on which revid FOO refers to. | 01:18 |
| thumper | spiv: so how can I say 'pull and use their tags' ? | 01:18 |
| spiv | --overwrite | 01:18 |
| thumper | hmm... | 01:19 |
| thumper | ok | 01:19 |
| jelmer | there is also bug 681792 | 01:19 |
| ubot5 | Launchpad bug 681792 in Bazaar "wishlist: bzr pull --overwrite-tags" [Medium,In progress] https://launchpad.net/bugs/681792 | 01:19 |
| spiv | (Or delete the offending tag(s) locally and pull again) | 01:19 |
| thumper | jelmer: thanks | 01:19 |
| thumper | jelmer: do you understand the package recipes? robert_ancell was asking me about them | 01:20 |
| robert_ancell | I'm trying again to get the logs of what goes wrong... | 01:20 |
| robert_ancell | simple question: does http://paste.ubuntu.com/752089/ look correct and are the branches in the correct format? | 01:21 |
| robert_ancell | I tried to use lp:ubuntu/simple-scan as a packaging branch initially but I don't think it has the correct relationship to lp:simple-scan to work (it had merge conflicts) | 01:22 |
| jelmer | robert_ancell: yes, though I don't think that version of bzr-builder can be entered on launchpad yet | 01:22 |
| robert_ancell | jelmer, yes, I subscribed to that bug | 01:22 |
| jelmer | robert_ancell: the version looks a bit odd, though with {date} as the debian revision | 01:23 |
| robert_ancell | Now it is failing with 'dpkg-buildpackage: error: version number does not start with digit' because it pulls out the wrong version number (I was using simple-scan-VERSION tags but I'm now using just VERSION). Any way to delete the old tags on the server? | 01:23 |
| jelmer | robert_ancell: it's fine if the branches aren't related, so long as they don't have overlapping files | 01:23 |
| jelmer | robert_ancell: bzr tag -d lp:simple-scan --delete TAGNAME | 01:24 |
| robert_ancell | jelmer, yes, been playing around with the version number, needs some work | 01:25 |
| robert_ancell | jelmer, I have to build with --allow-fallback-to-native - will that work on the server? | 01:27 |
| jelmer | robert_ancell: yes, launchpad has --allow-fallback-to-native enabled by default | 01:27 |
| jelmer | robert_ancell: alternatively, you could tag the upstream version with 'upstream-X.Y', and it would create an orig tarball for you | 01:28 |
| jelmer | or change the package to be native | 01:28 |
| robert_ancell | ok | 01:29 |
| robert_ancell | jelmer, any idea when 0.4 will work? Or is there another method of getting the version number in 0.3 I can use? | 01:31 |
| jelmer | robert_ancell: {debupstream-base} might do what you need to | 01:39 |
| jelmer | *too | 01:39 |
| robert_ancell | jelmer, the issue is that requires me to update debian/changelog right? | 01:40 |
| jelmer | robert_ancell: yes, but only for upstream releases | 01:41 |
| jelmer | robert_ancell: in bzr we e.g. use {debupstream-base}bzr{revno}~daily{revno:packaging} for most packages | 01:41 |
| robert_ancell | right. For most of the packages I want to do I am upstream and I want to set it up and then forget about it | 01:42 |
| jelmer | robert_ancell: that works for us too, because we end up updating the debian/changelog version when we do a release | 01:42 |
| jelmer | robert_ancell: and then do a matching upload to debian/ubuntu | 01:44 |
| robert_ancell | jelmer, I know I'll forget to do it :) | 01:44 |
| jelmer | robert_ancell: you're not uploading to ubuntu ? :-) | 01:44 |
| jelmer | (we use the same branch for ubuntu packaging as for the daily PPA) | 01:45 |
| robert_ancell | jelmer, no, these are daily builds to a PPA for upstream testers | 01:45 |
| robert_ancell | the Ubuntu packaging has some patches, merges from Debian and may not be running the latest version | 01:46 |
| jelmer | robert_ancell: in that case you'd probably indeed want to wait for the 0.4 support | 01:46 |
| robert_ancell | jelmer, thanks for the help | 02:03 |
| poolie | so apparently if you call accept from one thread and connect from another, python can sometimes deadlock in futex() | 04:54 |
| poolie | nice | 04:54 |
| lifeless | on different sockets? | 05:00 |
| poolie | on the two sides of the same socketpair | 05:08 |
| poolie | simulating a server in process | 05:08 |
| lifeless | interesting | 05:09 |
| poolie | ie this fixes it http://bazaar.launchpad.net/~mbp/bzr/2.5-client-reconnect-819604/revision/6209#bzrlib/tests/test_bundle.py | 05:09 |
| poolie | "fixes" | 05:09 |
| poolie | the loop doesn't fix it, only changing to a nonblocking select | 05:10 |
| lifeless | possibly accept isn't giving up the GIL ? | 05:10 |
| poolie | seems likely | 05:10 |
| poolie | i guess i should see if i can reproduce it and file a bug | 05:12 |
| poolie | it's kind of a stupid thing to do imo | 05:12 |
| spiv | It pretty clearly releases the GIL in 2.7.2: http://hg.python.org/cpython/file/8527427914a2/Modules/socketmodule.c#l1656 | 05:13 |
| poolie | hm | 05:14 |
| spiv | In the past all our sockets+threads deadlocks have turned out to be bugs in our logic, not cpython | 05:15 |
| poolie | :) | 05:15 |
| poolie | that does seem likely | 05:15 |
| poolie | but, strace shows one side in accept and one in futex | 05:15 |
| poolie | ... | 05:15 |
| spiv | (Although arguably perhaps because the APIs offered aren't as convenient/safe as one might hope?) | 05:16 |
| poolie | the futex not being released by getting eintr from accept | 05:16 |
| poolie | when i say it's stupid i mean i think running the server inprocess is a bit likely to fail | 05:16 |
| poolie | anyhwo | 05:16 |
| spiv | Well, that shows that one side is in accept, and the other side is stuck in a lock — quite possibly a lock owned by pure Python code (e.g. a threading.Mutex in a Queue.Queue) | 05:17 |
| poolie | that is possible | 05:17 |
| spiv | It would be extremely helpful if strace could magically distinguish between "Python VM internal lock" and "Lock exposed to Python application code" | 05:17 |
| lifeless | pytrace is pretty good at that | 05:18 |
| lifeless | (gdb + py* macros I mean) | 05:18 |
| poolie | i was excited for a second there | 05:18 |
| poolie | i'll try to hit it again and use gdb | 05:18 |
| poolie | it's inside lock_PyThread_acquire_lock | 05:38 |
| poolie | ah inside threading.join? | 05:40 |
| spiv | poolie: doesn't sound like a vm bug :P | 05:40 |
| poolie | :) | 05:41 |
| poolie | ah :) | 05:41 |
| poolie | apparently closing a socket does not interrupt threads that are accepting on that socket | 05:41 |
| poolie | so that explains why alternating selecting and accepting avoids the problem | 05:42 |
| spiv | That sounds familiar. | 05:44 |
| poolie | yeah | 05:44 |
| poolie | spiv, so basically the patch is reasonable but the explanation is wrong | 07:01 |
| vila | hi all ! | 07:31 |
| poolie | hi there vila | 07:31 |
| vila | poolie: hmm, what patch and explanation are you talking about ? | 07:31 |
| poolie | i think i understand why that was hanging | 07:31 |
| vila | great ! I'm all ears :) | 07:32 |
| poolie | https://code.launchpad.net/~mbp/bzr/2.5-client-reconnect-819604 | 07:33 |
| poolie | oops no mp | 07:33 |
| vila | I can review that locally, nw | 07:33 |
| poolie | no apparently that's not everything | 07:34 |
| vila | poolie: 'accept from one thread and connect from another' leading to hang rings a 'ipv6' bell | 07:38 |
| vila | where one side get an ipv4 socket but the other got an ipv6 one | 07:38 |
| vila | may not apply but encountered several times | 07:38 |
| poolie | pretty sure that's not it here | 07:39 |
| vila | also, 'not being released by getting eintr from accept', *only* the main thread get interrupts | 07:39 |
| vila | poolie: which test(s) is/are hanging ? | 07:44 |
| poolie | test_bundle test_smart_server_connection_reset | 07:45 |
| poolie | at least | 07:45 |
| vila | poolie: will it help to focus on getting an external smart server running first and only then look at those failures ? | 07:46 |
| poolie | mm | 07:47 |
| poolie | i think no, really | 07:47 |
| poolie | although i'm down on running the server in process, in this case the bug could have happened the same way externally | 07:47 |
| * vila get a weird 'table turned' feeling | 07:47 | |
| vila | genuine surprise, no smiley there | 07:47 |
| vila | poolie: I only get one failure with your branch and it looks genuine: bzrlib.tests.test_smart_request.TestSmartRequest.test_all_registered_requests_are_safety_qualified | 07:50 |
| poolie | we seem to have a regression that selftest does not exit 1 on failure | 07:51 |
| poolie | that might be a known bug | 07:51 |
| poolie | vila, right that seems genuinely out of date with jelmer's changes | 07:53 |
| poolie | vila, you ran everything and that was the only one? | 07:55 |
| vila | yes | 07:55 |
| vila | twice | 07:55 |
| vila | ha, spoke too soon, the second is hanging at 26507 in 4m50s, 1 failed (hanging test unknown though) | 07:56 |
| poolie | i wonder if we couldn't have a test fixture that sets an alarm | 07:56 |
| poolie | which one? | 07:57 |
| vila | ok, got it by lurking below /tmp: bzrlib.tests.test_bundle.TestReadMergeableFromUrl.test_smart_server_connection_reset | 07:58 |
| poolie | that's the one i'm fixing | 08:08 |
| poolie | that's the one i'm fixing | 08:13 |
| poolie | vila, i'm adding a config option for a timeout | 08:16 |
| vila | for the select ? | 08:18 |
| poolie | globally | 08:18 |
| poolie | :/ | 08:18 |
| poolie | how do i actually get a value from the command line? | 08:18 |
| vila | for the test ? | 08:18 |
| poolie | nm | 08:20 |
| vila | poolie: from a config stack ? conf.get('mytimeout') but remember those are reset for tests, we may want something like -E (used for debug flags) but for test options | 08:20 |
| poolie | i think a regular option is ok as long as it's read early enough | 08:21 |
| poolie | possibly we need a way inside tests to get the real config stack | 08:21 |
| vila | if you get the option before the test is started, you're fine | 08:23 |
| vila | s/started/create/ | 08:23 |
| vila | d | 08:23 |
| poolie | yep, it's ok now | 08:23 |
| poolie | i wonder if there should be a timeout by default | 08:23 |
| poolie | perhapsonly from make check | 08:23 |
| poolie | vila does babune run make check or just selftest directly? | 08:26 |
| vila | selftest directly | 08:26 |
| vila | why does the test name mentions smart server when no smart server is involved there ? (Or do I misread the test?) | 08:27 |
| vila | ha, silly, bzr: | 08:27 |
| poolie | i wonder if there should be a timeout by default | 08:28 |
| vila | a timeout for what ? All socket based requests from the clients ? | 08:28 |
| poolie | for tests | 08:29 |
| poolie | well https://code.launchpad.net/~mbp/bzr/test-timeout/+merge/83559 | 08:29 |
| vila | hmm, lp downtime | 08:33 |
| wgrant | Nearly back. | 08:34 |
| vila | back | 08:34 |
| wgrant | Nope. | 08:34 |
| vila | err, weird | 08:34 |
| sagaci | heh | 08:34 |
| wgrant | There we are. | 08:34 |
| vila | the importer said: down, down... back.. down, down... back | 08:36 |
| wgrant | vila: Ah, yeah. | 08:37 |
| wgrant | It went down for 35 seconds, came back because it failed, then we retried. | 08:37 |
| vila | ooh, thanks | 08:37 |
| wgrant | But it was down for the second time when you mentioned it here. | 08:38 |
| vila | yeah, I lag :) | 08:38 |
| vila | but the importer did cope well, not fallout failures | 08:39 |
| vila | poolie: reviewed, BB:tweak | 08:50 |
| poolie | thanks | 08:52 |
| poolie | got to go | 08:52 |
| poolie | back later maybe | 08:52 |
| mgz | morning all | 09:06 |
| vila | mgz: _o/ | 09:13 |
| * jelmer waves | 09:34 | |
| mgz | hey jelmer | 09:37 |
| m1sc | what's the right way to delete a branch? | 09:56 |
| mgz | m1sc: delete the directory. there's also `bzr rmbranch` | 09:59 |
| m1sc | mgz: ok. it's a shared repo - the data is garbage collected automatically? | 10:01 |
| mgz | nope, but it's generally insignificant. if not... I don't think we have a better way than making a new shared repo, mirroring all the branches you care about, then replacing the old repo. | 10:02 |
| m1sc | mgz: bzr rmbranch <mybranch> gives me "Not a branch.." oO special syntax required? | 10:03 |
| mgz | when `bzr info` on the same path tells you it's a branch? | 10:04 |
| * mgz just deletes the directories, with shared repos there's not much that can go wrong there. | 10:04 | |
| m1sc | mgz: nope, it doesn't. must be my fault, works for other branches.. thank you. | 10:05 |
| === zyga is now known as zyga-brb | ||
| jelmer | hmm, it seems that the hpss-call-count test for 'bzr verify-signatures' is spuriously failing | 11:07 |
| mgz | as in, some runs gives a different value and some runs doesn't? | 11:08 |
| mgz | rather than just the value being wrong, which wouldn't need much comment :) | 11:08 |
| vila | jelmer: yup, was about to mention it, could it be that some variations happens because readv groups differently depending on the compression results ? | 11:08 |
| vila | jelmer: in other words: if both 22 and 21 can occur, you may just relax the assertion there to accept both | 11:09 |
| jelmer | vila: yeah, indeed | 11:11 |
| vila | indeed as in related to readv grouping ? | 11:11 |
| jelmer | yes, and also indeed: we should just be accepting both | 11:13 |
| vila | hehe, double indeed then ;) | 11:13 |
| === zyga-brb is now known as zyga | ||
| vila | jelmer: yup, spurious, I got 2 failures out of 3 runs locally | 11:19 |
| jelmer | vil: https://code.launchpad.net/~jelmer/bzr/verify-signatures-spurious-hpss-call-counts/+merge/83583 | 11:20 |
| spiv | jelmer: yes, that sort of thing is another reason to remove VFS calls: to make the call counts more deterministic :) | 11:20 |
| deni | hello everyone | 11:21 |
| deni | am i mistaken (doing something very wrong) or does bzr ignore *.o files by default? | 11:21 |
| jelmer | hi deni | 11:22 |
| deni | and is there a way to disable that behavior? | 11:22 |
| jelmer | deni: it does, see ~/.bazaar/ignore | 11:22 |
| jelmer | spiv: :) | 11:22 |
| deni | jelmer: oh ok, tnx...didn't realize it | 11:25 |
| mgz | deni: versioning build artefacts is a very bad idea, what's the reason behind wanting to commit a .o file? | 11:27 |
| vila | jelmer: approved | 11:28 |
| jelmer | vila: thanks! | 11:29 |
| jelmer | vila: are you going to post a followup branch to 2.5-client-reconnect-819604 ? | 11:35 |
| * jelmer bumps his branch back to needs-review | 11:36 | |
| vila | dunno :-/ I see your vote *after* posting my 2 comments and refreshing the page | 11:36 |
| jelmer | vila: I posted that vote before you commented | 11:37 |
| vila | yup, I realizeD that | 11:37 |
| jelmer | vila: so, with your comments in mind, I think it would be nice to improve the branch | 11:37 |
| vila | ok, I'll submit one then | 11:38 |
| deni | mgz: i know i know....it's a whole tree of bad ideas that lead to this. :D anyway, deployment reasons | 11:48 |
| vila | jelmer: your branch still fails test_smart_request.TestSmartRequest.test_all_registered_requests_are_safety_qualified | 11:50 |
| vila | jelmer: with AssertionError: These requests were not categorized as safe/unsafe to retry: ['Repository.get_stream_1.19', 'Repository.insert_stream_1.19'] | 11:50 |
| vila | jelmer: which is weird as there were more of them earlier this morning (but I haven't precisely tracked which version I used vs what you fixed since then) | 11:51 |
| jelmer | vila: r6124 ? | 11:52 |
| jelmer | vila: err, r6214 ? | 11:52 |
| vila | 6215 | 11:52 |
| vila | but the last one is mine | 11:52 |
| jelmer | test_smart_request.TestSmartRequest.test_all_registered_requests_are_safety_qualified passes here | 11:52 |
| jelmer | and get_stream_1.19/insert_stream_1.19 do indeed have a categorizatin | 11:53 |
| vila | urgh, it just passed 8-/ | 11:53 |
| vila | trying again, that was woth --parallel=fork | 11:54 |
| vila | (the failure was for a full run with --parallel that is) | 11:55 |
| vila | jelmer: hmm, I've pushed my fix on lp:~vila/bzr/819604-fix-test-bundle | 11:56 |
| vila | it may be easier for all involved if you just merge it into your proposal rather than me using yours as a pre-requisite | 11:57 |
| vila | safety_qualified failed again | 11:57 |
| vila | isolation ? | 11:58 |
| vila | lazy loading ? | 11:58 |
| knielsen | I want the result of `bzr branch -rA t t_A; bzr branch -rB t t_B; cd t_A; bzr missing --include-merges ../t_B`. A is a parent of B. Can I do it without needing to create the two branches t_A and t_B? | 12:00 |
| knielsen | `bzr log -n0 -rA..B` does not work when A is not the primary (main-line) parent of B | 12:00 |
| knielsen | `bzr missing` has --my-revision and --revision arguments, but again it seems not to work for non-mainline parents (the docs seem unhelpful for this) | 12:00 |
| vila | knielsen: doesn't 'bzr log -n0 -rA..B --exclude-common-ancestry' work ? | 12:03 |
| jelmer | vila: with the same requests? | 12:03 |
| vila | jelmer: yes | 12:03 |
| * knielsen checking | 12:03 | |
| jelmer | vila: pulled into lp:~bzr/bzr/2.5-client-reconnect-819604 | 12:08 |
| knielsen | vila: no, it doesn't work. `bzr log -n0 -rA..B` is missing a changeset that `bzr missing` shows (and --exclude-common-ancestry does not help with this) | 12:08 |
| * vila curses complicated log implementation | 12:16 | |
| vila | knielsen: you know branch accepts a --no-tree parameter ? Branches are way cheaper to create this way if you have a big working tree | 12:16 |
| knielsen | the obvious answer would be `bzr missing --include-merges --my-revision=A --revision=B .`, but I could not get this to work, in fact I could not get --my-revision to do anything for some reason... | 12:17 |
| knielsen | vila: yes, probably will need to go with explicit branches and --no-tree | 12:17 |
| knielsen | should be ok, though I need to do this for a couple of 1000 revisions | 12:18 |
| vila | if '--revision A --revision B' is accepted, it should translate to '-rA..B' or nothing is really wrong | 12:18 |
| fullermd | knielsen: Don't overlook that you don't need to keep creating new branches for all those thousand. You can just create A and B branches once, and use 'pull' in 'em to reset their revs for each run. | 12:24 |
| knielsen | fullermd: right, interesting idea, might help | 12:24 |
| fullermd | (and with them in a shared repo with your source branch, all those resets will be cheap, since no data needs to be transferred) | 12:25 |
| vila | knielsen: 1.000 revisions... I can't imagine what you're trying to achieve... | 12:25 |
| knielsen | hehe. I'm trying to get an overview of a very complicated merge. I have a list of commits that were merged and pushed into a tree in sequence, and I want to for each one know how many revisions were merged in that push | 12:27 |
| knielsen | and I just wanted to try understand how `bzr log` worked with non-mainline revision ranges. But `bzr branch --no-tree` branches several trees per second, so I think that will be plenty sufficient for my needs | 12:28 |
| knielsen | tnx for the help | 12:28 |
| vila | knielsen: did you give 'bzr qlog' a shot ? It's pretty good at showing which revisions were merged into each mainline revision | 12:28 |
| * knielsen will try qlog also ... | 12:28 | |
| vila | It may be slow to start (for big & complex histories), but you'll start it only once | 12:29 |
| knielsen | vila: the main thing is that the mainline revisions do not correspond to the pushes into the tree, as there has been no discipline about in which order to merge before pushing | 12:29 |
| vila | You can also give several branches and it gives a pretty good view of what has been merged | 12:30 |
| vila | knielsen: argh, yeah, makes it hard to understand what is shared :-/ | 12:30 |
| knielsen | so I re-constructed a list of the commits that existed in the main tree during time. Many of these commits are not mainline revision, and many main-line revisions are not on the list | 12:30 |
| vila | knielsen: append_revisions_only is your friend to converge to such a workflow | 12:31 |
| knielsen | vila: yep :) | 12:31 |
| jelmer | vila: do you have any plugins loaded when running the testsuite? | 12:55 |
| vila | jelmer: I ran with BZR_PLUGIN_PATH=-site | 12:56 |
| jelmer | vila: found it - we override verbs in the testsuite, but don't cope with info= | 12:56 |
| vila | jelmer: where ? | 12:58 |
| jelmer | vila: override_verb() and disable_verb() | 12:59 |
| vila | ha, right, bad cleanup, I see | 13:00 |
| jelmer | vila: can you try again with my last commit to ~bzr/bzr/2.5-client-reconnect-819604 ? | 13:00 |
| vila | revno 6217 | 13:02 |
| vila | running | 13:02 |
| vila | jelmer: right fix, confirming isolation issue, note that the proper (and usual way) to do that is to overiddeAttr(request.request_handler) and populate it with a copy (out of scope for your branch) | 13:11 |
| vila | jelmer: run succeeded, the fix is good | 13:11 |
| === yofel_ is now known as yofel | ||
| vila | I got one spurious failure though: | 13:12 |
| vila | bzrlib.tests.per_interrepository.test_fetch.TestInterRepository.test_fetch_parent_inventories_at_stacking_boundary_smart_old(InterDifferingSerializer,RepositoryFormatKnitPack6RichRoot,RepositoryFormat2a) | 13:12 |
| vila | with a slightly different error for the client: ConnectionReset: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. | 13:12 |
| vila | so reconnecting doesn't help there (despite the hopes) | 13:12 |
| jelmer | yeah, me too | 13:12 |
| vila | jelmer: reliably ? | 13:16 |
| jelmer | vila: no, it seems to be spurious | 13:19 |
| vila | right, would have been too nice | 13:19 |
| mgz | ugh, the reconnection branch changes the way our current random failures fail? | 13:39 |
| * fullermd . o O ( If they're really random, you can't tell :p ) | 13:40 | |
| mgz | they have a limit axis of randomness fullermd :) | 13:40 |
| mgz | they either pass, or fail in a specific way. | 13:40 |
| mgz | they don't turn into elephants. | 13:40 |
| fullermd | Well, that sucks. No wonder nobody runs the test suite. | 13:41 |
| fullermd | Without a good payoff like that, it's so not worth it. | 13:41 |
| jelmer | mgz: ugh indeed | 13:49 |
| * jelmer thinks the value of elephants is widely overestimated | 13:50 | |
| fullermd | How else could we get revision info into pachyderm files? | 13:51 |
| jelmer | fullermd: zlib? | 14:12 |
| === treaves_ is now known as treaves | ||
| mgz | jelmer: are you nearly done passing all your hpss branches? :) | 15:48 |
| * mgz doesn't want to merge trunk for news till he's sure of getting a free slot | 15:51 | |
| jelmer | mgz: it's all in the queue now | 16:00 |
| mgz | cool | 16:03 |
| jelmer | mgz, vila: so, I wonder what we should do about the ~bzr/bzr/2.5-client-reconnect-819604 branch | 17:22 |
| mgz | cry? | 17:22 |
| jelmer | is the remaining spurious failure worse than what we have at the moment? | 17:22 |
| vila | the only way to know is to land it | 17:23 |
| vila | why should it be worse ? | 17:23 |
| jelmer | vila: for me, it *seems* to occur more often than the ones currently present, which I can't reproduce at all | 17:24 |
| jelmer | of course that's all totally unscientific, and I don't think we should hold that against it | 17:24 |
| jelmer | vila: but yeah, perhaps we should JFDI and rather than let it sit there for a couple more weeks | 17:25 |
| vila | as an experiment I'm running for i in {1..10000} ; do echo $i ; ./bzr selftest -s bzrlib.tests.per_interrepository.test_fetch.TestInterRepository.test_fetch_parent_inventories_at_stacking_boundary_smart_old -v InterDifferingSerializer -Ethreads ; done for bzr.dev revno 6311 | 17:26 |
| vila | I had 58 failures for 1837 runs so far | 17:26 |
| jelmer | vila: ah, interesting | 17:26 |
| vila | more failures when babune run jobs | 17:27 |
| vila | but at least it means there is a way to reproduce, slow, painful but reproducing nevertheless ;) | 17:27 |
| * jelmer does another merge of lp:bzr | 17:29 | |
| jelmer | vila, mgz: can either of you have another look at it again too? | 17:31 |
| jelmer | hmm | 17:32 |
| jelmer | vila: "merg hokk", is that Swedish for merge hook ? :P | 17:32 |
| vila | sry was afk (cooking), oook ? In the COVER or in the code ? | 17:37 |
| fullermd | Well, we wouldn't want to interrupt your cokking... | 17:38 |
| jelmer | vila: in the cover, so not really something that requires fixing | 17:38 |
| vila | arf, in the cover letter ;) Right, tyop, I thought hhtp was too last century ;) | 17:38 |
| jelmer | fullermd: vila is the Swedish chef? | 17:38 |
| fullermd | Dunno. Do you actually cook Swedes? I thought they were better just smoked... | 17:42 |
| vila | tagliatelles a la carbonara, more likely to be Italian | 17:43 |
| jelmer | vila: nice work on the po merge hook! submitted a review | 17:52 |
| jelmer | I wish writing these was easier.. | 18:02 |
| * jelmer calls it a day | 18:03 | |
| croepha | im making some build scripts, and I was wondering if there was a way to get a revison number for just a file or a directory and the files under it? or maybe just a way to tell if thoese files have changed since a specified revision? | 18:27 |
| lamalex | hey bzr, im trying to do bzr lp-propose-merge but it seems to be coughing since im using pipes and colo | 20:04 |
| lamalex | bzr: ERROR: file:///home/alex/Code/unity/.bzr/branches/rip-out-ap/trunk/ is not registered on Launchpad | 20:04 |
| lamalex | any ideas? | 20:04 |
| lamalex | do i just need to push my first pipe (which is just a clone of trunk) to lp? | 20:04 |
| Noldorin | hi poolie, jelmer | 21:10 |
| Noldorin | has Markdown support landed on LP yet? | 21:10 |
| jelmer | hi lamalex | 21:21 |
| jelmer | hi Noldorin | 21:21 |
| jelmer | Noldorin: this isn't really the right channel for that question | 21:21 |
| lamalex | hola jelmer | 21:22 |
| jelmer | noldorin: the lp folks are working on markdown support? | 21:22 |
| Noldorin | jelmer, true, but it's not that inappropiate either ;-) | 21:24 |
| Noldorin | jelmer, they are indeed. poolie for one | 21:24 |
| Noldorin | jelmer, how are you coming along on bzr-git anyway? i'm looking forward to the repo fix i want as a christmas present :-) | 21:25 |
| jelmer | Noldorin: sorry, lots of other more important stuff to fix first.. | 21:25 |
| Noldorin | :( :-( | 21:26 |
| Noldorin | jelmer, what's so much more important, i want to know? | 21:26 |
| Noldorin | this seems like a MAJOR bug...it prevents the most basic functionality of bzr git on some repositories | 21:26 |
| Noldorin | and not even very special repositories | 21:26 |
| Noldorin | for me, this would be #1 priority... i struggle to think of a more important one | 21:26 |
| Noldorin | sorry, i just find it hard to believe :-S | 21:27 |
| jelmer | Noldorin: push support in bzr-git is still experimental, the focus is on importing from git into bzr at the moment | 21:27 |
| Noldorin | jelmer, oh is that right? | 21:27 |
| jelmer | Noldorin: in addition, you're hitting a particular corner case | 21:27 |
| Noldorin | jelmer, sorry didn't know | 21:27 |
| Noldorin | jelmer, i'd dispute calling it a "corner case" (seems fairly simple), but i can accept that git -> bzr importing is more important :-) | 21:28 |
| jelmer | Noldorin: I use dpush on a regular basis and I've never hit that particular issue. | 21:36 |
| Noldorin | jelmer, oh well. maybe i'm jsut strange ;P | 21:36 |
| jelmer | Noldorin: I'm not trying to say the bug doesn't matter, but there's more things that deserve attention. This is just one. | 21:36 |
| Noldorin | jelmer, no no, i concede that. now that you've stated that git to bzr importing is your main goal | 21:40 |
| Noldorin | jelmer, i'm going to hope, but not expect, for new year :-P | 21:40 |
| fullermd | Noldorin: There's a good chance there'll be one in a month or so ;p | 21:49 |
| Noldorin | fullermd, oh yes? that's good to know :-P | 21:51 |
| Noldorin | fullermd, you work on bzr-git too huh? | 21:54 |
| fullermd | Never touched it. | 21:54 |
| Noldorin | oh | 21:55 |
| Noldorin | how do you knwo good chance ina month or so then? :-P | 21:55 |
| fullermd | 15:40 <Noldorin> i'm going to hope [...] for new year | 21:56 |
| fullermd | 'cuz I can read a calendar ;p | 21:56 |
| Noldorin | fullermd, yeah but that's making the bold assumption that my hope is a liklihood :-P | 21:56 |
| fullermd | Well, unless the world ends, it's going to be hard to NOT wind up with a new year in about 5 weeks. | 21:57 |
| fullermd | (I don't rule that out, to be sure. I just hope there's enough warning to make popcorn.) | 21:58 |
| Noldorin | fullermd, oh dear. you were making a cheesy joke by taking my sentence out of context. i just saw :-P | 22:00 |
| Noldorin | fullermd, makes sense now at least. | 22:00 |
| fullermd | It does? That should worry you... | 22:00 |
| Noldorin | heh | 22:03 |
| Noldorin | perhaps | 22:03 |
| Noldorin | but not too much | 22:03 |
| poolie | hi all | 22:15 |
| Noldorin | hi poolie | 22:17 |
| GRiD | hello | 22:19 |
| poolie | jelmer, the reconnect thing still has some logical conflicts with your new hpss verbs | 22:32 |
| poolie | i'll try to fix them up and send it | 22:32 |
| jelmer | 'evening poolie, GRiD | 22:43 |
| jelmer | poolie: the ~bzr -owned version? That merges lp:bzr fine here | 22:43 |
| lifeless | jelmer: logical, not textural | 22:46 |
| lifeless | texual | 22:46 |
| lifeless | bah | 22:46 |
| lifeless | textual. | 22:46 |
| jelmer | lifeless: oh, right.. logical and logical conflicts... | 22:47 |
| poolie | specifically some tests fail because your new verbs do not specify whether they can be safely retried | 22:49 |
| poolie | anyhow i will finish it today | 22:49 |
| jelmer | poolie: are you sure you have the last revision? vila and I had it pass the full testsuite today, including the HPSS stuff | 22:50 |
| poolie | jelmer, no i probably don't | 22:51 |
| poolie | i was just talking about my last result yesterday | 22:51 |
| poolie | if you guys fixed that, do land it | 22:51 |
| poolie | or perhaps you already did | 22:51 |
| jelmer | ah, cool | 22:51 |
| jelmer | poolie: actually, vila had some follow-up to your blocking-accept fixes, and I did some conflict resolution | 22:52 |
| jelmer | poolie: it should be ready to land, but if you'd like to have another look at the recent changes, that'd be great | 22:52 |
| poolie | ok i will | 22:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!