| poolie | hi all | 00:11 |
|---|---|---|
| jelmer | g'morning poolie! | 00:24 |
| jelmer | how were your holidays? | 00:24 |
| poolie | hi | 00:40 |
| poolie | pretty nice | 00:40 |
| poolie | wgz, hi? | 00:46 |
| wgz | hey poolie | 00:51 |
| poolie | hi | 00:52 |
| poolie | happy new year | 00:52 |
| poolie | i was just going to reply to terry from leo-editor | 00:52 |
| wgz | yeah, that was also on my todo for tomorrow | 00:52 |
| poolie | if he has a working branch i think he can just call that 'trunk | 00:52 |
| wgz | however he created the previous one still results in it being broken, apparently | 00:53 |
| wgz | I need somone who understands launchpad stacking to walk me through the relationship between the branches | 00:53 |
| AfC | Is there an environment variable (or?) that indicates to bzr which SSH key to use when connecting to a remote server? | 01:55 |
| poolie | afc, not in bzr, but you can configure that in .ssh/config | 01:55 |
| AfC | poolie: no, it's per command [ie bzr] not per target server that I need to change it | 01:56 |
| poolie | if you want to use a different one for bzr vs other access, create a different virtual host, with the HostName pointing to the real name | 01:56 |
| AfC | hm | 01:56 |
| poolie | hm | 01:56 |
| AfC | let me look, might work | 01:56 |
| poolie | i think you can set the ssh client command name and you could point to a script that adds that parameter | 01:56 |
| AfC | oh, | 01:56 |
| * AfC dummy | 01:56 | |
| AfC | I changed the name of they key file | 01:56 |
| AfC | already had an entry in .ssh/config | 01:56 |
| AfC | bah | 01:57 |
| AfC | humbug | 01:57 |
| AfC | sorry for noise. | 01:57 |
| AfC | poolie: thanks for help | 01:57 |
| AfC | [that was hard to debug!] | 01:58 |
| jelmer | moin | 07:51 |
| poolie | hi jelmer | 07:57 |
| poolie | welcome back | 07:57 |
| vila | hi all, | 08:00 |
| vila | happy new year poolie | 08:00 |
| poolie | hi there, thanks vila, hi mgz | 08:01 |
| mgz | morning all! | 08:01 |
| poolie | hey | 08:02 |
| === jameinel is now known as jam | ||
| jam | hi all, welcome back from the holidays | 08:14 |
| wgz | ....it's a random place in the UK | 09:59 |
| wgz | not even where my ISP is based | 09:59 |
| wgz | okay, enough battling with plusness | 09:59 |
| jelmer | it's probably just the closest thing to the cneter of the UK? | 09:59 |
| jelmer | I just got disconnected too | 09:59 |
| wgz | I'd expect more midlandsy for that, is suspiciously close to scotland | 10:00 |
| mgz | ha, again I'd plugged this laptop in without actually switching on the power | 10:27 |
| mgz | vila: so windows babune is still bust, I think this is still my fault and I've made a circular import despite trying not to | 11:30 |
| vila | dang it, almost forgot | 11:31 |
| vila | mgz: there are at least 2 issues | 11:31 |
| mgz | can you give me the traceback from the win32utils import? | 11:31 |
| mgz | if I can get away without completely restructuing the platform code to make it more sane, that would probably be best | 11:31 |
| vila | that one is trivial, just removing the line 2087 in osutils | 11:32 |
| vila | http://babune.ladeuil.net:24842/view/debug/job/debug-windows/lastFailedBuild/ | 11:32 |
| vila | http://babune.ladeuil.net:24842/view/debug/job/debug-windows/lastFailedBuild/testReport/junit/bzrlib.tests.per_intertree.test_compare/TestCompare/test_abc_content_to_empty_InterDirStateTree_C__/ is where I get lost | 11:32 |
| mgz | okay, looking, thanks | 11:33 |
| mgz | ack. | 11:33 |
| vila | mgz: so you can start from lp:~vila/bzr/for-babune/ | 11:34 |
| vila | if you want | 11:34 |
| mgz | probably also just an import ordering issue from me | 11:34 |
| mgz | otherwise, I'll blame jelmer's xml removing branch | 11:34 |
| mgz | will track it down. | 11:34 |
| vila | more likely ;) | 11:34 |
| vila | also, absolute import fallback came to mind | 11:35 |
| mgz | er... what were these test__btree_serializer ones about... | 11:36 |
| mgz | I thought I'd formed an opinion, but now can't remember it | 11:36 |
| vila | hmpf, yeah, not very readable output, but I suspect the same underlying issue so didn't ever bother | 11:37 |
| mgz | okay, your for-babune change is good, I'm going to send that to pqm | 11:43 |
| vila | jelmer: I'm not sure I understand your desire for unescape_for_display, care to clarify ? | 11:48 |
| mgz | can't a man have his desires? | 11:49 |
| vila | hehe | 11:49 |
| vila | sure, but understanding them help to address them ;) | 11:49 |
| jelmer | vila: Mostly, I just like to not have a lot of different ways of converting URLs to user touchable things and vice versa | 12:07 |
| mgz | URL.__unicode__ | 12:08 |
| jelmer | mgz: we do want to allow paths in locations.conf though | 12:08 |
| jelmer | in particular, I worry about things like readonly+file:/// | 12:08 |
| vila | yeah and windows paths too (or at least one bug asks for that) | 12:08 |
| jelmer | and escaping characters in URLs | 12:08 |
| vila | right, | 12:09 |
| jelmer | that's why I'm a bit skeptical - I'd rather just use normalized URLs internally and have user input converted to normalized URLs using something like location_to_url | 12:09 |
| mgz | passing strings around of various different types does lead to breakage | 12:10 |
| vila | so there are already several bugs filed for that and I agree with the goal and I'm not even sure I like allowing remote urls in config files given that server settings that can be overridden are... unclear | 12:10 |
| mgz | I don't think that means we need to use URLs for everything, but certainly we need to know what kind of path is being operated on when displaying it in an error message etc | 12:11 |
| mgz | rather than looking at it and guessing | 12:11 |
| jelmer | mgz: we do seem to need some guessing here, so I'd rather have it in one spot (location_to_url) than in multiple places | 12:11 |
| vila | so when I say out-of-scope, I don't mean I don't care, it's just that this proposal is not about this topic | 12:11 |
| vila | readonly+file is probably already a bug with locations.conf :-/ | 12:12 |
| jelmer | vila: I disagree, it adds more code that does this - and I think doing it properly is as much or perhaps less work than the current MP | 12:12 |
| mgz | well, we can guess (or rather have a clear process) when the url enters bzrlib from the user (command line, config file, etc) | 12:13 |
| mgz | s/url/path, url, or filename/ | 12:14 |
| jelmer | mgz: ah, yeah - I think we mean the same thing | 12:14 |
| mgz | but that's... an ideally, not what currently happens in many cases | 12:14 |
| mgz | yup, violent agreement | 12:14 |
| vila | jelmer: well, I tried changing it while migrating locations.conf to config stacks and... encountered some ugly cases (sorry I can't remember the details right now) but it wasn't that easy | 12:14 |
| mgz | hm, too many branches named "fix...." | 12:16 |
| vila | looking at the config bugs: bug #85479 #359320 #437009 | 12:16 |
| ubot5 | Launchpad bug 85479 in bzr (Ubuntu) "configuration location lookup does not take care of url encoding" [Medium,Confirmed] https://launchpad.net/bugs/85479 | 12:17 |
| vila | looking at the config bugs: bug #85479 bug #359320 bug #437009 | 12:17 |
| ubot5 | Launchpad bug 359320 in Bazaar "Paths with links, or relative paths, cannot be used in location.conf." [Medium,Confirmed] https://launchpad.net/bugs/359320 | 12:17 |
| ubot5 | Launchpad bug 437009 in Bazaar "locations.conf has problems with Windows paths with backslashes" [Medium,Confirmed] https://launchpad.net/bugs/437009 | 12:17 |
| mgz | nice set vila. | 12:18 |
| mgz | incremental cleanups are fine, I've not looked at your branch yet, will shortly | 12:18 |
| vila | yeah, right, as said above, it's not as if I don't care about the issue | 12:18 |
| vila | jelmer: I agree that I use the same pattern as locations.conf but I did on purpose so any fix in one should go into the other and hopefully even more code can be shared but I wanted a simple proposal | 12:19 |
| mgz | ow, builddeb makes a bt.test_selftest test fail | 12:20 |
| mgz | it's.... a relative import issue! :D | 12:21 |
| mgz | plugins/builddeb/util.py", line 32, in <module> from distro_info import DebianDistroInfo, UbuntuDistroInfo | 12:22 |
| mgz | already fixed? | 12:22 |
| jelmer | mgz: I don't think that's a relative import issue | 12:22 |
| jelmer | mgz: distro_info is a top-level package | 12:22 |
| mgz | ah, I just don't have it then. | 12:23 |
| vila | mgz: and yeah, urls enter bzrlib in different ways, config files are utf8 but provides unicode, btw https://code.launchpad.net/~vila/bzr/907279-override-from-env/+merge/86737 has landed but I'll still welcome your comments about 'env_encoding' | 12:24 |
| mgz | what's the lp: name for it? | 12:25 |
| mgz | vila: will do, can probably simplify the encoding side a little now with some of the other changes (rather than previous tack of having lots of different possible encodings for different things) | 12:25 |
| vila | mgz: yeah. your functions have the right stuff but the API doesn't quite fit what config is expecting, there is probably an easy middle ground though | 12:29 |
| vila | hmm | 12:29 |
| vila | more network issues on a different machine now :-/ | 12:29 |
| jelmer | :( | 12:33 |
| mgz | okay, that's made a bit of a dent in the review queue | 12:35 |
| jelmer | mgz: thanks | 12:35 |
| vila | transient DNS failure ? Do such things really still happen ? :-} | 12:39 |
| vila | jelmer: gha, look at smart/server.py line 360 :-( | 12:40 |
| vila | jelmer: on the bright side, grep returns ~50 hits for local_path_from_url so there is still hope | 12:41 |
| vila | jelmer: anyway, did I convince you I care about this stuff ? I already added a test with a location starting with file:/// (look at the last rev I pushed before my last comment), would you be fine with one more test showing that file:///foo is handled as /foo for section ids ? | 12:43 |
| vila | jelmer: and also (which may give you some more context), I'm whacking moles fixing bug #832042 already so chasing more moles today... is a bit too much ;) | 12:45 |
| ubot5 | Launchpad bug 832042 in Bazaar "config files are read for each option" [High,In progress] https://launchpad.net/bugs/832042 | 12:45 |
| mgz | okay, my issue with StartingPathMatcher vila, | 12:51 |
| mgz | is that I'm not sure if it's just trying to operate on local paths, or whether the if 'file://' check is intended to let other absolute urls through | 12:52 |
| vila | . o O (Amazing how apparently simple proposals can raise so many issues ;) | 12:52 |
| vila | mgz: same as locations.conf, | 12:52 |
| jelmer | vila: I think this is just a single issue with it - it keeps the brokenness that's present in the previous implementation | 12:53 |
| vila | mgz: the aim is (and was) to allow paths where internally we also deal with urls | 12:53 |
| jelmer | vila: I never questioned whether or not you cared :) | 12:53 |
| vila | hehe | 12:53 |
| mgz | which would be weird, because then the self.location could be either a url or a filesystem path when the slash handling goes on | 12:53 |
| vila | jelmer: but I can't fix all brokeness at once ;) | 12:53 |
| mgz | vila: the problem is the proposal isn't also deleting the old logic, so it's not clear you're not to blame :) | 12:54 |
| vila | mgz: yeah, not super pretty, I know, but that's what we have | 12:54 |
| vila | oh my deleting the old logic will have to wait for all plugins to stop using the old implementation.... | 12:54 |
| mgz | right :) | 12:55 |
| vila | well, for bzr itself to stop using it to start with | 12:55 |
| vila | I fired that one to *avoid* reusing locations.conf logic for new config files (the section ordering in this case) | 12:55 |
| vila | because I didn't want to have to deal with this brokeness in /etc/bazaar/defaults.conf or whatever we call it | 12:56 |
| vila | I'm not a big fan of using urls in config files either mainly because the smart server ignore many options coming from there | 12:56 |
| mgz | anyway, this is livable with, provided you define in the docstring what 'location' may be in practice, and add some XXX about making this saner | 12:57 |
| vila | yeah, there are 2 call sites: initial location conversion, section id conversion, we need a bunch of tests around these anyway (the bugs I mentioned above are also around these calls) | 12:58 |
| vila | .. and I haven't mentioned allowing relative paths there either ;) | 12:59 |
| mgz | just enumerating what doesn't work and listing bugs right there would help | 12:59 |
| vila | ... which open another can of worms: if these paths are inside a bzr tree, should we apply the renames too ? ;) | 13:00 |
| mgz | right now, the code has various assumptions and it's not clear what they are | 13:00 |
| jelmer | I think that would reduce some of my concerns about this code as well | 13:00 |
| vila | right, I'm slowly discovering pitfalls and trying to make them clearer | 13:00 |
| vila | \o/ | 13:00 |
| jelmer | I'm still not convinced that doing it right would actually be that much harder than what you have at the moment, but I'll defer to your judgement on that | 13:01 |
| vila | yeah, may be I resigned too soon last time or may be too many issues were making it harder to understand... | 13:02 |
| vila | I remember having to followup once or twice after my first attempt landed | 13:02 |
| vila | but I was focused on minimizing differences between the old and the new implementation | 13:03 |
| mgz | that's the kind of thing that is also useful to say in a docstring | 13:04 |
| vila | at least now, it's all contained in a single class | 13:04 |
| vila | 'that' ? | 13:04 |
| mgz | "logic intended to be compatible with previous implementation config.olf_function" | 13:05 |
| mgz | or similar. | 13:05 |
| mgz | olf? old. | 13:05 |
| mgz | I think the sky castle here is something like urlparse and poping from the tail to determine heirachy | 13:07 |
| mgz | after converting input string to url from relpath etc | 13:08 |
| vila | instead of just startswith ? | 13:08 |
| mgz | clearly just looking at the path section one segment at a time is enough for nearly all cases though | 13:08 |
| vila | not to mention globs :-/ | 13:09 |
| mgz | yeah, so you could say that http://example.com/bzr/branch?why=1/2 is in the same line as http://example.com/bzr/branch | 13:10 |
| vila | the former starts with the later | 13:11 |
| vila | oooh, jelmer, did you have some colo use case in mind ? | 13:12 |
| mgz | ah, I see, but then say that http://example.com/bzr/branch_X isn't in the same line | 13:13 |
| vila | yeah :-/ | 13:13 |
| vila | but is it really an issue ? | 13:13 |
| mgz | colo has kicked up a bunch of issues around this by wanting to stick stuff on the end of locations | 13:13 |
| vila | and potentially in the middle too | 13:13 |
| jelmer | mgz: colocated branch names don't have slashes in them though | 13:14 |
| mgz | you have a bug report requesting that :) | 13:14 |
| jelmer | mgz: slashes have to be urlencoded | 13:15 |
| mgz | say you wanted a location config for all your colo branches named 'trunk' | 13:16 |
| mgz | would you invision having a section like [file:,branch=trunk] with rules? | 13:16 |
| mgz | that's a relative path, not a glob | 13:17 |
| * mgz ponders | 13:17 | |
| vila | /path/asdfasdf/*/trunk | 13:17 |
| mgz | would you invision having a section like [file://*,branch=trunk] with rules? | 13:17 |
| jelmer | mgz: I think the latter makes most sense, probably | 13:17 |
| jelmer | mgz: I don't think colocated branches (or rather, path segment parameters) need special casing | 13:17 |
| vila | you have a branch.conf too, | 13:17 |
| vila | so the other conf files should not be abused (not to mention you can move your branch and keep your settings) | 13:18 |
| jelmer | as an example, I currently always have "email" in branches named "unstable" set to "Jelmer Vernooij <jelmer@debian.org>" | 13:18 |
| jelmer | independent of what project they're in | 13:18 |
| mgz | heh, I guess the glob would work with branches hidden in .bzr | 13:19 |
| vila | jelmer: and this works for colo branches right ? | 13:19 |
| jelmer | vila: I haven't tried it for colo branhces, but I don't see why it wouldn't | 13:19 |
| vila | me neither | 13:20 |
| vila | jelmer: errr, waitasec, what section name do you use for this ? | 13:21 |
| jelmer | IIRC [/home/jelmer/src/*/unstable] | 13:23 |
| vila | if I'm not mistaken it will fail for /home/jelmer/src/xxx/experimental/unstable | 13:23 |
| vila | i.e. locations.conf will match '*' with a *single* path component | 13:24 |
| jelmer | ah, I see. So I guess it won't work for colocated branches then | 13:24 |
| vila | to match on the colo branch name, no, but to apply to all colo branches yes | 13:25 |
| jelmer | anyway, I'm not really worried about that right now :) | 13:26 |
| vila | ...hmm, but StartingPathMatcher will match, damn, forgot to mention that... gee | 13:29 |
| jelmer | vila: are you sure? | 13:30 |
| jelmer | in that case it seems like file://foo/bar will also match file://foo/bars ? | 13:31 |
| jelmer | which would be Bad | 13:31 |
| vila | well, locations.conf split the path and then try to match each component and also sort on the number of components (my issue with it) | 13:31 |
| jelmer | vila: the components won't match for colocated branches | 13:31 |
| jelmer | file://bar/bar vs file://bar/bar,branch=foo | 13:32 |
| vila | sorry, components from split('/') | 13:32 |
| vila | after removing the final '/' if present | 13:32 |
| jelmer | right, so colocated branches won't match | 13:39 |
| vila | if you have a section named /foo/bar and a branch named file:///foo/bar,branch=baz the section will apply I think, by luck, but apply... | 13:41 |
| jelmer | vila: if that is the case, wouldn't file://foo/bars also match? | 13:48 |
| vila | if the section is named foo/bar ? It should match | 13:48 |
| vila | even /foo/bar/ :-/ | 13:48 |
| jelmer | urgh | 13:49 |
| vila | yeah | 13:49 |
| vila | note that nobody complained... yet :-/ | 13:49 |
| vila | s/yet/so far/ | 13:51 |
| vila | oh crap, smart server timing out while debugging :-( | 13:58 |
| vila | uuurgh, | 14:26 |
| vila | I found one cause of smart server calling get_config_file too much: | 14:26 |
| vila | in at least one case, both the remote branch and the real_branch will ask for it :-/ | 14:27 |
| jelmer | vila: we shouldn't be using the real branch anymore in a lot of cases | 14:27 |
| vila | I'm working on a branch based on bzr.dev@6404 | 14:28 |
| vila | the test is bzrlib.tests.per_branch.test_branch.TestStrict.test_strict_history(RemoteBranchFormat-v2) | 14:29 |
| vila | hmm | 14:30 |
| vila | jelmer: could it be that a failure in the smart server triggers a fallback to real_branch in the client ? I'm having a weird behavior right now: | 14:31 |
| vila | I encounter either LockNotHeld errors or SIGPIPE or... no errors but a use of real_branch | 14:31 |
| vila | AFAICS only pulls should be triggered, does that requires real_branch still ? | 14:32 |
| jelmer | vila: no, that shouldn't require real_branch | 14:32 |
| vila | jelmer: not sure if my description makes sense... ask for details if you need | 14:32 |
| vila | crap, so some error is swallowed :-( | 14:32 |
| jelmer | vila: I'm not sure that is the case, perhaps there's something oither than a pull here? | 14:33 |
| vila | the test do commits and pulls | 14:33 |
| vila | well, sprout, setting appen_revisions_only to start with too | 14:33 |
| vila | ha, and some merge_from_branch | 14:33 |
| vila | but all the trees should be local | 14:34 |
| vila | (but the branches should be remote) | 14:34 |
| vila | if I put breakpoints where LockNotHeld should raise, it stops raising... naughty | 14:35 |
| vila | oh, progress, I'm at the raising call site... | 14:37 |
| vila | weird, the real_branch is not None but still cannot be unlocked (so still some real_branch involved....) | 14:40 |
| vila | jelmer: any advice about debugging lock issues with the smart objects ? | 14:44 |
| jelmer | vila: not really, I'm not entirely sure what you're trying to debug | 14:45 |
| vila | well, I don't really know myself :-/ | 14:45 |
| vila | AFAICS I didn't touch any locking stuff | 14:46 |
| vila | hmm, or did I *remove* some ? | 14:46 |
| vila | hmm, so, I'm working on changing stack.set() to not call store.save() but instead wait until branch.unlock() to save the config file | 14:47 |
| vila | so far, I've fixed only a few places in the code and fixed the blackbox tests that were mixing config settings on branch objects and run_bzr() calls | 14:48 |
| vila | and I've got all blackbox tests passing, so presumably my fixes are not that bad | 14:49 |
| jelmer | vila: you probably need some magic in Branch._ensure_real | 14:49 |
| jelmer | vila: a write lock on RemoteBranch can be upgraded to a write lock on the real branch | 14:49 |
| vila | the trick is that I don't lock anything anymore (for config purposes) relying on ... damn it, let's try something | 14:50 |
| vila | nope | 14:51 |
| vila | so, relying on callers to always write lock branches when setting new values for options (which seems correct so far, except for the tests themselves) | 14:52 |
| jelmer | vila: if you do that, you probably want to also assert that the branch is locked when setting new options? | 14:52 |
| vila | hmm | 14:54 |
| vila | I didn't so far... | 14:54 |
| vila | .. fearing useless IOs ?? | 14:55 |
| vila | which is ridiculous, let's try that | 14:55 |
| jelmer | I don't think checking *we* have a write lock causes extra IO | 14:56 |
| vila | yup, but it means I need the .branch attribute for BranchStore which I was hoping to get rid of, nm | 14:57 |
| vila | hmm, no difference for the current test, but more blackbox failures to deal with | 15:03 |
| vila | pfew, 59 | 15:03 |
| vila | jelmer: any objection on making branch write-locking mandatory to set an option ? | 15:04 |
| jelmer | vila: sounds reasonable to me | 15:06 |
| vila | (previously we were taking one on the config file itself without involving the branch anyway...( | 15:06 |
| vila | )) | 15:06 |
| jelmer | mgz: any plans on landing your no_locale_hacks mp? | 15:12 |
| mgz | some, still a little concerned about the effect on random scripts using bzrlib directly | 15:14 |
| mgz | basically, on nix only, if they don't call setlocale, | 15:18 |
| mgz | currently they can do some things involving non-ascii characters, but not open non-ascii files or write non-ascii data to some streams | 15:19 |
| mgz | the branch means a few more things won't work unless setlocale is called. | 15:20 |
| jelmer | mgz: are you having seconds thoughts about it, or do you have anything in mind to address that? | 15:21 |
| mgz | well, could change the fallback value, but that probably does more harm than good for a corner case. | 15:23 |
| vila | ok, blackbox failures fixed, the diff is now >1400 lines and I've still to address the ~50 remaining failures :-/ | 15:42 |
| vila | and the previous test is still failing ;) | 15:43 |
| vila | jelmer: another nice suggestion like the previous one ? :-P | 15:44 |
| vila | kidding really | 15:44 |
| vila | I've found interesting cases with this one ;) | 15:44 |
| jelmer | vila: perhaps split out the change to require a write lock for config changes? | 15:44 |
| vila | oh, I will split out the change, there are already 4 or 5 mps in my wip | 15:45 |
| vila | and many controversial changes... like, | 15:45 |
| vila | if you have read-access only to a branch you cannot push it anymore...(well, unless you had write access when you set push_location) | 15:46 |
| vila | or the fact that we save some config settings even if the operation fails | 15:47 |
| vila | on the bright side, some hpss_calls went down ! | 15:47 |
| jelmer | :) | 15:52 |
| vila | O | 16:00 |
| vila | M | 16:00 |
| vila | G | 16:00 |
| vila | RemoteBranchStore you idiot ! | 16:00 |
| vila | ...and I stay polite | 16:01 |
| vila | I completely missed to do the same changes I did on BranchStore | 16:01 |
| vila | @only_raises is evil | 16:41 |
| jelmer | yep | 16:47 |
| mgz | ehehe, naughty jelmer | 16:49 |
| mgz | went with 'stronk' for the branch name :) | 16:50 |
| vila | that's where I lost the exceptions I was searching for... | 16:50 |
| jelmer | mgz: stronk is dutch for "branch" :) | 16:50 |
| jelmer | mgz: strong was the typo, not the other way around :) | 16:50 |
| mgz | ehehe | 16:51 |
| vila | of course, now that I know, calling store.save_changes() in unlock()... cannot fail with that ;) | 16:51 |
| mgz | hm, should probably just do this change, it's low impact | 16:58 |
| === vila is now known as bzr-RM | ||
| bzr-RM | jelmer: woohoo !!!! | 17:10 |
| === bzr-RM is now known as vila | ||
| vila | :) | 17:10 |
| jelmer | vila: hmm? | 17:11 |
| vila | noticed your what's new update ;) | 17:11 |
| jelmer | ah :) | 17:12 |
| glen | hi, how new bzr i need here to merge then? http://pastebin.com/hM6mWAs9 | 18:06 |
| glen | it says i need 1.16 or newer, i have 2.4.2 and it's not new enough still? | 18:07 |
| jelmer | glen: your repository locally is too old | 18:09 |
| jelmer | glen: you probably want to run "bzr upgrade" | 18:10 |
| glen | but i just checkouted it (branched it) | 18:10 |
| jelmer | glen: the remote repository that you cloned was probably also in an old format | 18:10 |
| === yofel_ is now known as yofel | ||
| glen | how do i upgrade remote repo? | 18:10 |
| jelmer | glen: "bzr upgrade <url>" | 18:11 |
| glen | "bzr upgrade lp:eventum" ? | 18:11 |
| jelmer | yep | 18:11 |
| glen | i need lots of bandwidth for that too? | 18:11 |
| jelmer | For launchpad branches I think there is also a link on the branch page that can do it for you | 18:11 |
| wgz | vila: I'm reasonably sure your odd babune debug-windows failures are pyx drift | 18:11 |
| glen | jelmer: but how fresh version it lp web updates to? i need 2.0.4 support | 18:12 |
| wgz | vila: tests pass here, failure makes no sense, and module path goes from "c:\cygwin\home\babune\babune\slaves\xp-32bits.local\workspace\debug-windows\bzrlib\workingtree_4.py" to "_dirstate_helpers_pyx.pyx" | 18:13 |
| wgz | which implies a dirty cwd, but the error is still weird | 18:13 |
| wgz | glen: the current format works with 2.0 clients still | 18:14 |
| glen | does bzr have concept of svn:eol-style ? | 18:15 |
| wgz | no, but you can set a similar thing globally for your local branches | 18:16 |
| wgz | see <http://doc.bazaar.canonical.com/beta/en/user-reference/eol-help.html> | 18:20 |
| wgz | vila: previous reference to these failures (thanks email search) <https://code.launchpad.net/~gz/bzr/url_unquote_unreserved_842223/+merge/82309/comments/177821> | 18:21 |
| wgz | hm, I see, it's building with cygwin's gcc, and pyrex not cython | 18:24 |
| wgz | so perhaps the failures relate to that, the debug-windows setup is not the same as the selftest-windows setup maybe? | 18:25 |
| wgz | hm, random poking isn't getting me anywhere, but does show that the .pyx file being used isn't the one from the build process I think | 18:44 |
| wgz | enough for today. | 18:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!