[00:02] poolie: by "relevant plugins" do you mean ones that do iter_changes on PreviewTrees, or ones that might do RevisionTree.is_executable, or...? [00:04] im' not sure if it will be easy to identify which ones could be affected [00:04] we could guess based on the apis [00:04] or just test the ones that are packaged [00:04] poolie: I don't think it will be easy. [00:05] poolie: Okay, I'll go find out what's packaged and make sure I've got it all installed, and then run the plugin tests. [00:06] do you think this is too laborious and we should just land it? [00:06] i think it would be worth at least just running them [00:06] if it turns out they're too noisy, then we could decide what to do [00:11] poolie: I think I can run them and delta the test failures against vanila 2.2. [00:11] that sounds good to me if that works for you [00:21] so to keep this under control as a contract [00:21] i think i should mark out what we want in each particular future release [00:21] would that work for youL [01:18] mkanat: actually just generally, feel free to request review from me, jam, spiv, or all of ~bzr [01:19] poolie: Okay. [01:34] mwhudson: If I make the change about the None, do you want me to re-request review or just go ahead and merge it after doing it? [01:35] mkanat: if you're confident in your change, just merge it [01:35] mwhudson: Okay. [01:36] mwhudson: I'm also wondering if there might be an off-by-one error in the contents array, so that it has an extra line that it shouldn't have. [01:38] seems a bit unlikely somehow [01:39] mwhudson: Well, I think that annotate_iter may not consider a final "\n" to be adding an extra line. [01:40] oh right maybe [01:41] So I suppose I could just have the generator create an infinite number of empty containers at the end. [01:41] Since we iterate over the contents array now instead. [01:41] that works i guess [01:41] I think it'd be the simplest solution, code-wise. [01:46] Well, launchpad outage stops me from doing any more development or merging. :-( [01:54] is there an issue with launchpad right now? [01:55] jdobrien: one of the data centres is offline [01:55] mwhudson, aha! that would answer it [01:56] mwhudson, I hope it was planned :o [02:01] mkanat: why would the lack of availability of a centralized web resource have anything to do with you being able to get work done with a distributed revision control system like Bazaar? [02:41] poolie: I've run all plugin tests, and none fail with is_executable that pass with 2.2. Actually, an extra fails with 2.2, so I assume it's a flaky test. [02:50] AfC: Because my code exists only on LP right now, I reverted my patch locally. [03:10] abentley: nice [03:11] poolie: shall I go ahead and land it on 2.2, then? [03:11] please do [03:14] poolie: btw, I looked up who committed this code that's causing me grief. It was me. [03:14] haha :) [03:14] thanks for persisting with fixing it [03:16] poolie: no worries. [05:02] mkanat: reading your patch now [05:20] poolie: Okay. [05:20] done! [05:20] good to go [05:20] poolie: Thanks! Good timing by me. :-) [05:27] poolie: BTW, I'm on the launchpad-devel mailing list still, so I do get the messages even if they're not CC'ed to me. (I usually just watch for subjects about loggerhead or codebrowse.) [05:27] poolie: There is a test framework in place, BTW. [05:28] k [05:28] ... but it's hard to use for this? [05:29] poolie: No, not that hard, I could do it. But I think it mostly already covers this, since annotate is already tested...I believe. [05:29] Yeah, annotate is already tested. [05:29] it seems like if you're changing the default view [05:29] and the tests don't fail [05:29] there must be a gap in coverage? [05:29] poolie: I haven't run the tests, because they're failing anyway. :-) [05:31] really, just generally? :/ [05:31] poolie: Well, they were last time I ran them. [05:35] to the extent that it's not worth adding a new one? [05:35] poolie: Ah, no, it could be worth adding a new one. Let me get the tests running on my new system (I just upgraded my OS and am missing some packages) and I'll see how much work it would be. [05:39] well, it could be worth a try [05:42] I'm not quite figuring out why the tests won't run on my machine. Maybe it's some python 2.7 thing. [05:44] what os do you use? [05:44] mkanat: hmm, IIRC bzr's tests are fine on 2.7 now. [05:44] poolie: Fedora [05:44] spiv: Yeah, but these are loggerhead's tests. [05:45] I seem to recall just being able to "nosetests" on python 2.6 and things would be fine. [05:48] jam, mwhudson: Do you know what it takes to get the loggerhead tests to run right? [05:48] mkanat: at one point I tried to integrate it with "bzr selftest -s bp.loggerhead" [05:49] jam: Ohh, right. Since then, I think the tests have been broken with nosetests. [05:49] jam: So I have to have it symlinked in as a plugin to do that, right? [05:49] something like that, yes [05:50] AttributeError: 'module' object has no attribute '_WritelnDecorator' [05:50] Are bzr's tests only working with python 2.7 on trunk? [05:51] I have 2.2.1 installed. [05:52] mkanat: probably yes [05:52] Okay. [05:52] there's no py26 in fedora 14(?) [05:53] poolie: Right. [05:56] I run bzr trunk's tests with 2.6 all the time. [05:56] Perhaps you need a newer testtools or something like that? [05:57] spiv: No, I just easy_install'ed it. [05:57] This is the traceback: http://pastie.org/1337546 [05:58] It's pretty apparent that it's just related to the unittest changes in 2.7. [06:00] mm [06:00] you might be able to cherrypick-back the changes from 2.3 to fix it? [06:00] or perhaps testing it against bzr 2.3 is still useful [06:01] Ah, well, I don't imagine LP runs 2.3. [06:02] I'll have to figure out how to make these tests work with nosetests again. [06:09] Wow, how is this SO FAST? Probably because of crazy custom Hg implementation. http://code.google.com/p/python-nose/source/list [06:15] that's what we should aim for [06:16] Yeah. [06:16] might need more than little slices of time though :/ [06:16] I think we'd have to actually cache the rendered HTML to get that fast. [06:16] But maybe not. [06:16] perhaps an intermediate representation is cached [06:16] they're probably not touching a magnetic disk to have it consistently that fast [06:17] that sort of speed is what cassandra is aimed at [06:17] - its a bigtable backend for hg [06:17] poolie: Well, if it's anything like their Svn implementation, it's a mapreduce thing with, yeah, bigtable. [06:19] First off we'd have to figure out what and how to cache things. [06:19] Although if you had a cassandra backend for bzr, we may not even have to cache them, I don't know for sure. [06:20] you'd denormalise things like revnos [06:21] in a sense such a thing is a cache [06:21] Right, we already have a revno cache in loggerhead. [06:22] if we can finish the 'does not need vfs for regular use' work, we could seriously consider a cassandra impl [06:22] failing that we could push (thus limiting the operations that take place) into a ro cassandra mirror [06:22] using hpss to talk to a process that talks to cassandra? [06:23] oh nm, yes [06:23] yes, exactly. [06:25] jam: Do you know why your changes would have caused this (when trying to run the loggerhead tests via nosetests)? http://pastie.org/1337584 [06:26] mkanat: not specifically, but I know that loggerhead doesn't know whether it is a plugin or a main script, and does some ugly hacks with the python import path to try and work both ways [06:26] jam: Ah, yeah. [06:30] poolie: It's probably going to take me quite some time to get the test suite working again, just as far as figuring out what's wrong and making things work right again. Do you still want me to add a test for the new controller? [06:31] mkanat: I'm not poolie, but I think investing in the test suite will pay off [06:31] spiv: I fully and completely agree with you; this is more of a "how does Canonical want me to spend my hours" sort of a deal. :-) [06:32] mkanat: let's not block this merge on that, but i do think it would be worth spending some canonical time on it [06:32] poolie: Okay. [06:32] Sounds good. [06:32] it seems like it will help do other work in future [06:33] poolie: Okay, agreed. [06:34] it would be good to switch it to using testtools.run rather than nosetests [06:34] which will give it easy hudson integration via subunit.run [06:34] lifeless: It can already run under bzr selftest, I just can't run bzr selftest using my version of bzr and my version of Python. [06:35] mkanat: why not? actually scratch that question. Different one: perhaps fixing that is more important. [06:35] lifeless: Supposedly that's been fixed on trunk, just not in 2.2.x. [06:35] lifeless: (This is with python 2.7.) [07:36] So, TAL is not a very good template language. :-( [07:38] the chameleon implementation is nicer [07:38] gives you $foo for when you're feeling lazy [07:40] Yeah, it's not so much the convenience of not of the language, as much as it is that it's just very difficult to work out how to do certain things. [07:40] Particularly if you can't wrap an element in another element, or don't want to. [07:41] I really liked Mako last time I used it, that's probably what I'd prefer, although I have no idea if there are any serious problems with it in production (or if it's still actively maintained). [07:46] hello all ! [07:46] full red babune [07:47] I upgraded to testtools trunk yesterday, direct link, url: http://babune.ladeuil.net:24842/job/selftest-maverick/lastFailedBuild/ [07:48] Nice tests as only reading their names strongly suggests a shallow problem [07:56] I could do template inheritance with my patch that I'm working on right now, too, if I was using Mako instead. :-/ [08:05] lifeless, jml: bug #683505 rings a bell regarding a recent change in testtools ? [08:05] Launchpad bug 683505 in Bazaar "bzrlib.tests.test_selftest.TestSubunitLogDetails failures with testtools trunk (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/683505 [08:06] mgz: may also be related to a too aggressive cleanup of the test details ? ^ [09:39] jml, lifeless: ping [09:41] testtools introduced a change in revno 142 (regarding the return value of running a test suite with failing or erroring test), [09:41] I'd like to guard against that by testing the testtools version [09:42] I can use 0.9.8 for that except if you expect to change the behavior again before releasing 0.9.8 [09:43] jml, lifeless: when do you expect to release 0.9.8 ? [09:45] vila: its going to be backed out, see the bug [09:47] lifeless: rats, too bad I missed that one, this sounded like a nice change though [09:48] only part of the patch is buggy [09:48] only that bit will be backed out [09:48] it breaks subunit too [09:49] Ok, I'll subscribe to the bug to see how it goes then [09:50] meh, lp already subscribed me :) [09:50] I'll revert my babune testtools in the mean time [13:06] dOxxx: Hey ! [13:07] vila: hey :) [13:07] vila: everything go okay with the release? [13:07] dOxxx: Thanks for the reviews and merges ! I haven't looked at the s/update/pull/ bit you mentioned, do you plan to: 1) fix it, 2) revert to use checkouts 3) something else ? [13:07] vila: fixed it when I merged your changes. [13:08] dOxxx: AFAIK, yes, there are a couple of people having troubles with svn on OSX for reasons unclear to me, I was wondering if you knew more about that (they used 2.2.1 if that's relevant) [13:08] dOxxx: Cool! [13:08] vila: Which version of OSX? [13:09] were there bugs filed? [13:09] wow, that was ambigous, re-try: yes, the 2.2.2 release seems okay. Then some people with 2.2.1/10.5 have reported svn related problems [13:09] ok [13:09] dOxxx: I think there were bugs, but linked to/from answers [13:10] dOxxx: at least one of them has installed macports and had related problems but didn't confirm that uninstalling macports addressed them [13:11] dOxxx: the other(s?) didn't mention macports [13:11] if you could point me to the bug reports, I'll take a look [13:11] ok, let me find them [13:12] but... just wondering, was it for 2.3bn that svn/subertpy tip was needed ? [13:13] checking [13:14] No, I think it was for all branches [13:14] But it's a compilation problem not a runtime thing [13:15] I needed r2219+ to actually get subvertpy to compile on 10.5 [13:15] dOxxx: oh? [13:16] bug #681285 [13:16] Launchpad bug 681285 in Bazaar "Can't push my changes in Bazaar" [Undecided,Incomplete] https://launchpad.net/bugs/681285 [13:16] jelmer: ^ you may know better from the error message in the last comment [13:16] jelmer: yep, as I recall you made the changes for me [13:16] well, the *2* error messages even [13:17] dOxxx: can you fetch without problems from that location? [13:18] sorry still reading bug [13:19] dOxxx: ahh, ok. That was a while ago though. [13:19] jelmer: yeah, so I don't think that's the problem here. [13:20] dOxxx: right, the other is harder to find back: bug #682904 and https://answers.launchpad.net/bzr/+question/135989, read the question before the bug may be [13:20] Launchpad bug 682904 in Bazaar "Can't push my changes in Bazaar--need to update libsvn?" [Undecided,Invalid] https://launchpad.net/bugs/682904 [13:20] vila: could you check what version of svn you have on your 10.5 build machine? [13:20] how ? [13:20] I *have* svn ?? [13:21] of course, how do you think the installers build? :) [13:21] OS X comes with svn stock [13:21] no idea, I've just pushing buttons ;) [13:21] s/I've/I'm/ [13:21] hah [13:21] dOxxx: Ahh, you're Gordon! [13:21] jelmer: yers ;) [13:22] jelmer: meet dOxxx aka Gordon [13:22] sorry, shoulda introduced myself :) [13:22] dOxxx: meet Jelmer :) [13:22] svn --version reports: 1.4.4 (r25188) [13:22] dOxxx: np, I know who you are.. but I hadn't connected you with your nick name :-) [13:23] hmm.... [13:23] dOxxx: is this as bad as I think ? :-/ [13:23] jelmer: would compiling subvertpy against libsvn 1.4 cause a problem like described in these questions? [13:23] dOxxx: yeah [13:24] i.e. is bzr-svn compatible with svn 1.4.4 ? [13:24] it is compatible but certain functionality won't be available [13:24] and performance will be impacted [13:25] I don't want to include new svn libraries with the OSX bzr installer [13:25] dOxxx: why not? [13:25] jelmer: 1) I'm not sure how to do it correctly, 2) that's touching system files, which is kinda icky [13:26] jelmer: I don't think the OSX installer can use private binaries/libraries easily so they are installed sys... what he said :) [13:26] vila: urgh :-( [13:26] I guess it makes to use whatever the system is providing [13:27] it is ! [13:27] the OSX installer puts all the bzr stuff into the system python's site-packages and stuff like the Qt framework in the system location too [13:27] but the fix here may be to just tell people to upgrade their svn if needed [13:27] so it's already potentially overwriting Qt libraries [13:27] but that's different than pushing a newer one [13:27] but those aren't installed stock with OSX so I didn't feel so bad about that [13:28] but even if they upgrade their system svn, it seems that since subvertpy is compiled against 1.4, it will still cause problems? [13:28] yes [13:28] oh my [13:29] right, so we'd need to compile subvertpy against svn 1.5 at least and tell users that they must install svn 1.5 first [13:29] no, wait, I don't get it [13:29] vila: subvertpy build against svn 1.4 on our build machine will make it behave like a svn 1.4 client even if there are newer svn libraries installed on the user's machine [13:29] are you both implying that 2.2.0 was ok, but 2.2.1 is not anymore because of subvertpy ? [13:30] vila: I don't think this is related to the bzr version [13:30] I was referring to the installer version [13:31] so the set of whatever we package there, including bzr, plugins and their dependencies [13:32] urgh [13:32] if we can't provide an all-in-one installer including bzr-svn, it means (IMHO) that we should have specific packages for svn-1.4, 1.5 and/or whatever other versions are available and install only the relevant ones ? [13:32] s/ones/one/ [13:33] but back to my question: bzr-svn was working with the 2.2.0 installer right ? [13:34] like I said, I don't think this is a problem that was introduced in a particular version of the installer, it may have always existed [13:34] dOxxx: or did you use a 10.5 host with an upgrade svn to 1.5 ? [13:34] ha, ok :-/ So these are the first reports that bzr-svn doesn't work on OSX ? [13:35] vila: honestly, I can't remember what version of svn it had installed. I know that it was a fresh install of OS X 10.5, so I'm assuming that it was svn 1.4 like yours [13:35] jelmer: did you get feedback from osx 10.5 users ? [13:35] vila: as far as I know, I don't seem to get emails for bug reports on bzr-svn [13:35] dOxxx: honest ignorance is better than silence :D [13:35] vila: please note that these bug reports are not an indication that bzr-svn doesn [13:35] 't work at all, it's just certain kinds of pushes [13:36] oh [13:37] right :) [13:37] I was shaking the tree to see which fruits will fall :) [13:37] Wasn't meant to be negative [13:38] meh, especially when the report starts with: "For a while, Bazaar was working fine, but now when I push, I get" [13:40] dOxxx, jelmer : how does one check which svn and which subvertpy is used by bzr (or is subvertpy the only relevant part) ? [13:43] vila: newer versions of bzr-svn will mutter that information to .bzr.log [13:43] Said otherwise: how can one install an upgraded svn/subvertpy to make bzr happy ? [13:43] hmm, or may be s/how can one/is it possible to/ [13:43] If you just install svn 1.5.x and reinstall subvertpy, things should be happy [13:44] jelmer: the bzr 2.2.2 OSX installer uses r2219 of subvertpy, has there been an official release since then? [13:45] looks like 0.7.4 and 0.7.5? [13:46] dOxxx: yep [13:46] ok, I should update the installer configs to use 0.7.5 then I think [13:46] vila: do you think we should rebuild the OSX installers for 2.2.2 to use a newer subvertpy? [13:47] the version its currently using is from July and about 2 releases out of date [13:48] hmm [13:48] I don't know if it will solve George's problem but it seems like a generally good idea [13:48] since it looks like there have been some svn 1.4 compatiblity fixes [13:49] 2.2 is stable, if we broke it we should fix it, but upgrading too many things may break it even more [13:49] dOxxx: yeah, it wouldn't solve George's problem [13:49] jelmer: would subvertpy 0.7.5 still be compatible with bzr-svn 1.0.3 or should we use a newer version of that? [13:49] dOxxx: there's no need for a newer bzr-svn [13:49] ok thanks [13:59] so, testing 2.2.1, 2.2.2, 2.3b3 locally with 'bzr info http://svn.apache.org/repos/asf/subversion/trunk' succeeds [13:59] does it mean I need another svn server to test against ? [13:59] to reproduce George's problem ? [13:59] vila: have you tried the URL George is using? [13:59] not yet, I though it required some auth, let me try [14:00] jelmer: Did you deliberately turn the bzr-pqm-daily recipe on again for karmic? [14:00] * maxb turns it off again [14:01] dOxxx: indeed, it asks for a suer/password and when I enter none, fails with a 500 server error [14:01] darn [14:02] what I don't understand is why, if George upgraded his svn to 1.6.9 and subvertpy to 0.7.4, why is still not working? It gives a different error though. [14:03] dOxxx: did he recompile his subvertpy against svn 1.6 ? [14:03] he doesn't say. [14:03] maxb: I didn't realize it was intentionally disabled. I enabled the natty builds yesterday evening. [14:04] The recipe description field could do with being more prominant, and supporting line-breaks [14:06] vila, jelmer: I've updated https://answers.launchpad.net/bzr/+question/135989, asking George for specifics on how he upgraded svn and subvertpy [14:07] I need to go do my actual day job now unfortunately. :P [14:07] jelmer: he says (in bug #682904) : "Note that I am running svn 1.6.9 and subvertpy 0.7.4." [14:07] jelmer: Oh, whilst I think about the recipes, I had a question: Why are the bzr daily recipes using version numbers like 1.4.0~bzr{revno}~ppa{revno:packaging}+{revno:debian} ? The ordering of {revno:packaging} and {revno:debian} is inverted to what feels natural to me? [14:07] Launchpad bug 682904 in Bazaar "Can't push my changes in Bazaar--need to update libsvn?" [Undecided,Invalid] https://launchpad.net/bugs/682904 [14:07] dOxxx: no worries, thanks for the help ! [14:08] jelmer: he didn't say *where* he installed them though [14:08] vila: but that doesn't say against which version of the libsvn API his subvertpy was compiled against though [14:08] yeah that's what I'm wondering [14:08] considering he was using MacPorts before [14:08] dOxxx: not sure that's the same guy [14:08] they seem to be the same George [14:09] ha, good, well done to file different bugs then :-/ [14:09] yeah and two Questions with the same content :) [14:09] ha, now we need duplicates for questions too... [14:10] vila, dOxx: If he has svn 1.6.9 installed but compiled his subvertpy against svn 1.4 then it still won't work. [14:10] ha no, poolie turned the bug into a question, oh my [14:10] maxb: Something can be said for either [14:10] dammit, I'm not getting notified of bugs filed on bzr-mac-installers [14:10] jelmer: /me nods [14:11] jelmer: ok :-) I'd like to understand what can be said for this way? [14:11] ok... set myself as the bug supervisor maybe that will do it [14:12] vila: I don't understand the testtools from the log or Robert's bug entry [14:12] +issue [14:13] mgz: just a sec, let me push my wip branch, that should be clearer there [14:13] the three failing tests look wrong to me, but why were two of them passing before? [14:14] three/two ? [14:14] Three were passing three are now failing [14:14] we don't seem to use a custom wasSuccessful method, and the default one should return False if there's a failure [14:14] unexpected success flipped, but the other two should be the same [14:15] mgz: in a nutshell, the bug I filed is a duplicate, more fixes should be done in testtools [14:15] I'm guessing from the bug entry Robert knows what's going on, I just can't divine what the fix should be from what he's written [14:16] hmm, he said the change doesn't take into account decorated was_successful or something, including subunit [14:16] ah, maybe it's a subunit only thing. [14:17] i'm not sure this is bzr or launchpad question. [14:17] mgz: now, I don't understand the specifics, I've only been looking at making the tests more precise about whether running a test suite should succeed or not depending on which tests were provided [14:17] argh [14:17] but this used to work: bzr branch lp:~ubuntu-on-ec2/vmbuilder/automated-ec2-builds [14:17] but now gives bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~ubuntu-virt/vmbuilder/0.12/". [14:17] vila: looks like we need to do a new 2.2.2 installer build anyway to update bzr-svn to 1.0.4 [14:17] bug 621446 [14:17] Launchpad bug 621446 in Bazaar Mac Installers "AttributeError: paths when trying to svn-import" [Undecided,New] https://launchpad.net/bugs/621446 [14:17] smoser: that's a #launchpad question really. You have a branch stacked on another branch that no longer exists. [14:18] https://code.launchpad.net/~ubuntu-virt shows no 0.12 branch there anymore. I'm guessing someone deleted that, and my branch shared data [14:18] jelmer, yeah. [14:18] jelmer, thanks. [14:18] smoser: Soren had the same issue the other day. [14:18] dOxxx: unless this is already fixed in 2.3b3 (or b4 which will be released tomorrow) [14:19] vila: no it's an installer issue. the installer is configured to use bzr-svn 1.0.3. [14:19] jelmer, funny, soren is probably who deleted my branch :) [14:19] maxb: if somebody fixes something in the packaging branch then that change should sort before any fixes in the debian branch. [14:19] nothing to do with bzr version per se [14:19] smoser: I didn't delete your branch. I moved mine to ~ubuntu-virt. [14:19] just that 2.2 is current stable branch so I should make sure it works ;) [14:19] dOxxx: if 1.0.4 is not specifically targeted at bzr-2.2, we shouldn't include it in 2.2.[23] [14:19] well, one its gone from where it was, so move or delete, ... potAto potato [14:20] maxb: ~bzr has write access to the packaging branch but not the debian branch so the packaging branch can always merge in the debian branch if necessary, never the other way around. [14:20] dOxxx: otherwise we end up packaging the same thing in 2.3 and 2.2 and this will break the stability guarantee [14:20] soren, do you happen to know, then what i need to do to make that function again ? [14:21] dOxxx: that's the rule, does it apply in this case ? [14:21] vila: not sure I understand your previous comment [14:22] mgz: lp:~vila/bzr/683505-test-no-log, wip, doesn't work yet [14:22] jelmer: but, every build will always take the latest revno of the debian branch anyway, so I'm not seeing where this ordering issue would arise [14:22] dOxxx: let me look at the bug [14:22] maxb: Imagine somebody made a commit in the debian branch [14:23] maxb: or, in fact, did a merge in the debian branch (changing the revno's) [14:24] but... that would be a silly thing to do! :-) [14:24] thanks vila. [14:24] dOxxx: dang ! Same here, I never got gplyph answer ! [14:25] so, I think the conditions are backwards in those three tests, but it's subunit being funny. [14:25] so again, probably wants something changing in all three projects. [14:26] smoser: I'd talk to mvo. I think he sorted it out. [14:27] okay really going to work now [14:27] seeya [14:27] mgz: since babune was very update, I've reverted to testtools-0.9.7 waiting for a consensus to emerge :) [14:28] mgz: what is backwards ? [14:28] mgz: that subunit says all is well even when running a single failing test ? [14:29] dOxxx: argh, no one more second ! [14:29] ? [14:30] dOxxx: my comment was: if bzr-svn doesn't say: this release is compatible with bzr-2.2 and 2.2 users are expected to upgrade, we should include it in 2.2.2, otherwise we should not [14:30] dOxxx: i.e.: the plugin authors should be explicit, like qbzr maintaining a specific series target at 2.2 and another targeted at 2.3 [14:30] that would be nice [14:31] jelmer can confirm that bzr-svn is targeted at 2.2 and 2.3, so in this case, yes, we should rebuild the 2.2.2 installers [14:31] bzr-svn 1.0.4 [14:31] meh, bzr-svn-1.0.4 yeah, thanks :D [14:32] argh [14:32] dOxxx, vila: The supported versions for a bzr-svn branch should be available in info.py [14:32] George says he "replaced the system-installed svn with the new version using MacPorts" [14:32] jelmer: by the way, the 1.1 and 2.0 series for bzr-svn are not that clear to me ;D [14:32] /facepalm [14:32] dOxxx: be sure to check the dates ? [14:33] this is a new comment on the question [14:33] posted 15 min ago [14:33] https://answers.launchpad.net/bzr/+question/135989 [14:33] as far as I know MacPorts installs into /opt so it wouldn't replace the system svn [14:34] vila: Yeah, I haven't really gotten to those. I have Plans, though :-) [14:34] jelmer: hehe great ! [14:34] so, bzr-svn 1.0.5 is targeted at 2.x for x in [0,1,2,3] :) [14:35] bzr-svn 1.0.3 is targeted at 2.x for x in [0,1,2] [14:36] and of course I don't have bzr-svn-1.0.4 available here ;D [14:36] anyway so I think his svn is not properly upgraded and his subvertpy not compiled against the right version. [14:36] and now I really must go to work, already 30 min late. [14:36] dOxxx: right, happy work day ! Thanks again ! [14:36] bye! [14:56] jelmer: one more thing: bzr-svn is aimed at being compatible with svn-1.[456] right ? (relying on subvertpy compiled against the right library ?) [14:57] vila: yep, and 1.7 [14:59] hmm, so the issue with OSX installers is to be able to build various subvertpy packages on a host with the right(s) svn installed :-/ [14:59] and provide some way to select the right one :-( === zyga is now known as zyga-food === Meths_ is now known as Meths === zyga-food is now known as zyga [16:06] vila: yes, that's my understanding of the subunit aspect. [16:07] . o O (Oh my god, what does he mean with this 'yes'....) [16:07] :D [16:07] mgz: what is backwards ? [16:07] mgz: that subunit says all is well even when running a single failing test ? [16:07] :P [16:07] ha, ok === deryck is now known as deryck[lunch] [16:08] I wonder if he does this manually in order to carry some subliminal messages [16:08]