| jelmer | vila: it doesn't really matter what bzr-svn is compatible with, but what subvertpy is compatible with | 01:15 |
|---|---|---|
| jelmer | 1.4 is almost certainly too old though | 01:16 |
| _kbulgrien | hmm... bzr+ssh doesn't load user environment on far end? I get prompt for password then get `bash: bzr: command not found | 03:16 |
| _kbulgrien | bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.` | 03:16 |
| _kbulgrien | Hmm... BZR_REMOTE_PATH... | 03:21 |
| _kbulgrien | ok, that helps, but doesn't get by needing PYTHONPATH set to point to where bzrlib is on the remote. | 03:36 |
| _kbulgrien | I had to load bzr and bzrlib in my home directory on a web host. Now I can't seem to get bzr+ssh to work there because the remote bzr can't find its bzrlib because PYTHONPATH in .bash_profile on the remote isn't loaded. Is there a way to work around this other than, for example, putting the repo in an ftp space and avoiding the smart server? | 03:42 |
| _kbulgrien | sftp:// works. | 03:59 |
| _kbulgrien | ls | 03:59 |
| vila | jelmer: right, so next question is: if SamB_MacG5 can find a subvertpy version old enough to support svn 1.4, will bzr-svn.trunk be still compatible ? | 09:29 |
| vila | _kbulgrien, too bad you left. The trick to address your issues is to use a local wrapper so you can set anything you want. | 09:32 |
| vila | _kbulgrien: After that bzr_remote_path in locations.conf (so you can set it differently for different hosts) and you're done | 09:36 |
| vila | _kbulgrien: the wrapper I use is: '#!/bin/sh \n python /path/to/bzr $*' | 09:38 |
| vila | _kbulgrien: In locations.conf I have: '[bzr+ssh://myhost.local] \n bzr_remote_path = /path/on.myhost.local/to/wrapper | 09:39 |
| fullermd | Or fix his shell config. | 10:12 |
| fullermd | vila: and you want "$@" not $* | 10:15 |
| fullermd | (well, and 'exec' for cleanliness, but...) | 10:16 |
| vila | fullermd: ha, thanks for the tips. (shell is one of those languages I never took the time to master (I know make even better than shell...)). | 12:32 |
| vila | fullermd: so, even reading the doc didn't give me the feeling that one is better than the other in practice. Any caveat to be aware of ? "$@" is always safer than "$*" ? | 12:33 |
| fullermd | $@ keeps the borders between the arguments. $* resplits. | 12:41 |
| fullermd | Rather "$@" does. Both unquoted end up resplitting, but * quoted is a single. | 12:43 |
| fullermd | vila: e.g.: http://pastebin.com/42tNmcBi | 12:45 |
| fullermd | Upshot being that the $* will fail to DTRT any time there are single args with spaces in them. Filenames, paths, a `-m "log message"`, etc. | 12:46 |
| vila | fullermd: right, so to be on the safe side, the rule is to always use "$@" then right ? | 12:54 |
| vila | argh, mgz effect, sentence too long with the same word at the beginning and the end ;) | 12:54 |
| fullermd | If the goal is "pass args through as if we were aliasing to this other command", yeah. | 12:55 |
| vila | yup, which is the case I care the most about | 12:56 |
| vila | I think I always missed to read the right part in bash help as $@ == make target | 12:57 |
| vila | in my mind and I just couldn't use that in shell | 12:58 |
| fullermd | Let's not go there. It'll bring up memories of the awk scripts I wrote to handle bmake vs gmake... | 12:58 |
| vila | urgh, suffering already :) | 12:58 |
| fullermd | Someday, I'll get the time to finish my make replacement, and I won't have to deal with any of that crap again. | 12:59 |
| vila | ha, the adage (haha) about the small and beautiful language hidden in the monster applies to make IMHO | 13:01 |
| fullermd | I dunno. Hidden inside the monster of make, there's a language that's small, beautiful, and completely incompetent. | 13:02 |
| vila | the fact that it allowed creating such awful results should be used against it | 13:02 |
| fullermd | ... as opposed to the whole, which is large, terrifying, and still pretty incompetent... | 13:02 |
| vila | nah, there are some drawbacks (like in any other) but there are also sane ways to use it right | 13:02 |
| vila | but I reckon I rarely saw clean and light makefiles :-/ | 13:03 |
| vila | err, not reckon, | 13:03 |
| vila | recognize ? confess ? concede ? yeah, probably concede | 13:03 |
| fullermd | Spend some time in the bowels of the ports system sometime; that'll teach you how many clean light makefiles there are out there ;p | 13:03 |
| fullermd | 'reckon' would work too. Especially down here. | 13:04 |
| vila | exactly my point then | 13:04 |
| vila | for example, how many makefiles truly support -j ? | 13:04 |
| fullermd | All of the ones I write, and most of the ones I deal with ;p | 13:05 |
| vila | oh, that wasn't ironic ? | 13:05 |
| fullermd | Life is too short to wait for serial compiles... | 13:06 |
| vila | You really mean the ports makefiles are correct ? Worth having a look one day then. But you're not talking about the makefiles provided by the packages then right ? | 13:06 |
| vila | (Which are the ones I have the most exposure too) | 13:06 |
| fullermd | Well, the compilation is [almost] never part of ports itself; that would come from the upstreams. And I know a fair number of those are broken stupidity (even before we consider they came from automake). But I don't so much deal with those, as just tolerate them temporarily untarred on my system during the build. | 13:07 |
| vila | (yeah, let's exclude automake, that's clearly outside of this discussion ;) | 13:09 |
| vila | ok, so we seem to agree now that the context is a bit clearer ;) | 13:10 |
| fullermd | But ports itself is an excellent object lesson in the terrors and horrors that away in an almost-competent language. By the time you realize how wrong a choice it is, it's far too late to change and you have to bull ahead anyway. | 13:10 |
| fullermd | s/that away/that await/ | 13:10 |
| vila | ha, 'far too late to change'... the weight of compatibility... 'be ready to throw it, you will' or whatever he said ;) | 13:11 |
| fullermd | In practice, anything nontrivial in "make" winds up really just being a framework for calling a giant pile of unrelated obfuscated inline sh(1), with demonic contortions to get the data from A to B. | 13:17 |
| vila | right, don't do that in make then is my attempt to answer | 13:17 |
| fullermd | Which is why doing anything in ports involves calling fork() about a thousand times. | 13:17 |
| fullermd | Right. But *way* too late for that ;p | 13:17 |
| vila | I mean, make manages dependencies, it has limited support for complex actions | 13:18 |
| vila | indeed | 13:18 |
| vila | or not | 13:18 |
| vila | that's the point, it's an organizational choice not something the tool is really blamable for | 13:18 |
| vila | (and I'm not saying I have the magic bullet either...) | 13:19 |
| fullermd | Yeah, but the tool being almost-competent ensures that it will continue to be chosen and then the organization is left to force the last 10% by hook or crook. | 13:19 |
| fullermd | The "solution" is to have tools that are fully competent and tools that are so weak as to be almost worthless. Which is stupid too. | 13:19 |
| fullermd | So the end of life-as-we-know-it is really the best solution, as I've said all along. No software problem is so intractable it can't be solved by a good supernova. | 13:20 |
| vila | yeah, it's a well known fact that things are always simpler when you cool down a bit | 13:21 |
| vila | so when you coll down a lot, they have to be even simpler | 13:22 |
| vila | cool | 13:22 |
| vila | spurious tyop, joke alert | 13:22 |
| fullermd | It don't get much cooler than 2.725 Kelvin ;p | 13:22 |
| vila | hehe | 13:23 |
| fullermd | Some day I'll write up and submit a patch to make(1) to allow it to read email. Just to see if I can get it accepted. | 13:25 |
| vila | hehe, BCc me ;) | 13:26 |
| vila | <vila> _kbulgrien, too bad you left. The trick to address your issues is to use a local wrapper so you can set anything you want. | 14:39 |
| vila | <vila> _kbulgrien: After that bzr_remote_path in locations.conf (so you can set it differently for different hosts) and you're done | 14:39 |
| vila | <vila> _kbulgrien: the wrapper I use is: '#!/bin/sh \n exec python /path/to/bzr "$@"' | 14:39 |
| vila | <vila> _kbulgrien: In locations.conf I have: '[bzr+ssh://myhost.local] \n bzr_remote_path = /path/on.myhost.local/to/wrapper | 14:39 |
| === yofel_ is now known as yofel | ||
| _kbulgrien | Oh, ok... that makes sense... almost feels like a doh moment... | 14:42 |
| _kbulgrien | I did figure out the locations.conf part. | 14:43 |
| _kbulgrien | hmm. I'll have to dink with it. My first few attempts to add PYTHONPATH aren't working, but then I've not used fancy hashbangs like that before. | 15:01 |
| _kbulgrien | doh. | 15:06 |
| _kbulgrien | I read \n as literal but then with a little grey matter applied... that didn't make sense. | 15:09 |
| _kbulgrien | I got it working. Thanks vila | 15:10 |
| vila | _kbulgrien: PYTHONPATH shouldn't be needed, the bzr script arranges to call its associated bzrlib | 15:14 |
| _kbulgrien | it doesn't actually... PYTHONPATH is required in this situation as bzr barfs up with bzrlib not found without it ( http://pastebin.com/pYrVQNjw ) | 15:31 |
| _kbulgrien | Adding "export PYTHONPATH=${PYTHONPATH}:${HOME}/lib64/python" to the wrapper fixes that error. | 15:32 |
| vila | hmm, weird, I haven't needed that but then the various .rc involved when you connect this way and that left me... discouraged | 15:39 |
| _kbulgrien | of course the webhost only has 2.3.4 because of the old version of python, so maybe this was improved in a later version? | 15:40 |
| _kbulgrien | I had to manually install bzr in my home directory since it was not pre-installed. | 15:41 |
| vila | urgh, stuck with python 2.4 ? | 15:48 |
| SamB_MacG5 | vila: oh, I've got an old enough version of subvertpy | 15:56 |
| SamB_MacG5 | 6.533 bzr-svn: using Subversion 1.4.4 (), subvertpy 0.8.1 | 15:57 |
| vila | SamB_MacG5: with bzr-svn trunk ? | 15:58 |
| SamB_MacG5 | vila: no, doesn't work with trunk | 15:58 |
| vila | SamB_MacG5: which version then ? | 15:58 |
| SamB_MacG5 | 1.1.0, but the test code is broken ... | 15:59 |
| vila | ha too bad :-/ | 15:59 |
| SamB_MacG5 | maybe I should try and fix subvertpy | 15:59 |
| vila | SamB_MacG5: check with jelmer for details there, I'm not sure the tests have been thoroughly and regularly run on osx | 16:00 |
| SamB_MacG5 | vila: I meant *besides* the breakage due to missed URL escaping wrt TMPDIR | 16:01 |
| vila | but there ought to be a combination of bzr-svn/subertpy that works for your case (config.py in the installers may be a good start too (sorry I didn't mention that earlier)) | 16:01 |
| vila | ^_o | 16:01 |
| vila | TMPDIR URL escaping ? | 16:02 |
| SamB_MacG5 | iMac:pyprof2calltree user$ printenv TMPDIR | 16:02 |
| SamB_MacG5 | /var/folders/4b/4b+Qm+OQFj8f23emq17tBU+++TM/-Tmp-/ | 16:02 |
| SamB_MacG5 | I get a bunch of "tests tried to escape" complaints | 16:03 |
| vila | ha crap | 16:03 |
| SamB_MacG5 | due to the plus signs | 16:03 |
| vila | I did a fix for that in bzrlib involving using realpath or something | 16:04 |
| vila | I'm not sure it's caused by the plus signs, I'd rather bet on some symlink being resolved or not when needed | 16:04 |
| vila | It took quite a long time and several shots to get them all, not sure all of them are in 2.3 | 16:05 |
| vila | grepping for osx in bzrlib/tests should get you there | 16:05 |
| * SamB_MacG5 checks for sure | 16:06 | |
| SamB_MacG5 | https://gist.github.com/a4eff1160a82eb92602d | 16:07 |
| * SamB_MacG5 blames his IRC client this time | 16:07 | |
| * SamB_MacG5 wonders how his IRC client knew how to authenticate itself as him with github, anyway | 16:09 | |
| SamB_MacG5 | vila: okay, it's also possible that the URL got fully escaped, but was then unescaped before being checked against the list ... | 16:10 |
| vila | I don't think so, I'm pretty sure the isolation stuff is encoding neutralassume it receives the urls in the right encoding | 16:11 |
| vila | I don't think so, I'm pretty sure the isolation stuff is encoding neutral | 16:11 |
| vila | gree | 16:11 |
| vila | grrrrrRR | 16:11 |
| vila | there may a way to temporarily disable the isolation check too | 16:12 |
| vila | *may be | 16:13 |
| SamB_MacG5 | well, it's easier to just add "TMPDIR=/tmp" at the beginning of the commandline | 16:13 |
| vila | oh yeah, far easier ! :) | 16:14 |
| vila | perfect work-around, you can pretty safely ignore the isolation errors, the check is here to guarantee we don't introduce new leaks | 16:15 |
| vila | but all existing tests have passed that check countless times now | 16:15 |
| SamB_MacG5 | actually, there seems to be more code that doesn't quite work ... | 16:15 |
| SamB_MacG5 | outside the test harness | 16:15 |
| vila | ha, less good, you really need jelmer there then | 16:15 |
| SamB_MacG5 | so obviously fixing up subvertpy is better ... | 16:16 |
| vila | or search launchpad for later fixes | 16:16 |
| vila | probably | 16:16 |
| vila | SamB_MacG5: did you try a more recent python version by the way ? (just curious) | 16:17 |
| SamB_MacG5 | oh, no, not yet ... | 16:17 |
| vila | ok, let me know about the end result if/when you do | 16:17 |
| SamB_MacG5 | but that probably wouldn't help a whole lot with bzr-svn? | 16:17 |
| vila | I can't answer that, sorry | 16:18 |
| vila | in theory, it could be better as well as worse, so the theory isn't really helpful there, you need the expert's specific knowledge ;) | 16:19 |
| SamB_MacG5 | well, subvertpy trunk will still need fixing to make it build with SVN 1.4... | 16:19 |
| vila | SamB_MacG5: and you really need bzr-svn *there* ? (As opposed to another host where you could use recent stuff and publish with bzr+ssh) | 16:20 |
| SamB_MacG5 | oh, and about config.py, I know it's supposed to have all the right versions listed, but it had issues even *before* I merged from lp:bzr-mac-installlers | 16:21 |
| SamB_MacG5 | I'm still trying to sort out the right versions of everything to make things mostly work | 16:22 |
| vila | eerk, don't ever merge from lp:b-m-i, you should only work on top of lp:b-m-i/2.3 | 16:22 |
| SamB_MacG5 | it had some nice-looking infrastructure improvements | 16:22 |
| vila | hmm | 16:23 |
| vila | there are two things here | 16:23 |
| vila | one is config.py, use only the lp:/2.3, | 16:23 |
| vila | the other is everything else probably which should be safe to use but has never been tried so may have introduced regressions ? | 16:24 |
| vila | but config.py, wow, be extra conservative there or you'll run into an endless maze of compat issues | 16:24 |
| SamB_MacG5 | it's kind of annoying that launchpad download URLs include the series ... | 16:25 |
| vila | why ? | 16:25 |
| SamB_MacG5 | then it would be simple to build the URL from a template and the version number | 16:27 |
| SamB_MacG5 | I mean, if they didn't | 16:27 |
| SamB_MacG5 | anyway ... yeah, I knew I would have to revert a lot of the version numbers in config.py when I did the merge | 16:28 |
| vila | err, you mean 'bzr lp:<project. -rtag:<version>' vs 'lp:<project>/<series>' ? | 16:28 |
| SamB_MacG5 | vila: no, I meant the tarball URLs | 16:28 |
| vila | Well, I thought config,py used a format and some params and build the URL from that no ? | 16:29 |
| SamB_MacG5 | it seems to just run % on all of the strings with the dict as right-hand argument | 16:30 |
| vila | the series is often part of the version | 16:30 |
| SamB_MacG5 | yes, but sometimes the series has varying length ... | 16:31 |
| vila | so if you have 'series' and 'version' as parameters or 'minor_version' stuff like that | 16:31 |
| SamB_MacG5 | well, I suppose that could be done, yes | 16:31 |
| SamB_MacG5 | though some of these projects are actually rather irregular in their series usage | 16:32 |
| SamB_MacG5 | so you basically have to just look up the URL anyway... | 16:32 |
| * SamB_MacG5 thinks he's thinking of bzrtools | 16:32 | |
| vila | yeah, so tweaking config.py at release time was generally light enough to never itch enough ;) | 16:32 |
| SamB_MacG5 | anyhow, yeah, I know about config.py and am, in fact, trying to prepare it for a release ;-) | 16:33 |
| * SamB_MacG5 wonders how to disable lazy imports | 16:35 | |
| vila | yeah, so the rules when doing releases (up to you to follow them or not) was to push for plugins trunks for beta releases, freeze at 2.x.0 time, update only to dedicated series for plugins providing them otherwise stay frozen | 16:35 |
| vila | which is another way to say: if you want to do a 2.3.n+1 release, stick with whatever was in 2.3.n *unless* plugins like qbzr released 2.3 targeted point releases | 16:37 |
| vila | looking at the history of config.py should give you the most precise view of it, including divergences from these rules ;) | 16:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!