[00:00] <wgz> apache's windows port is reasonable... though I wouldn't run an sshd on windows myself
[00:02] <wgz> If you want to go that route, I can help you get bzr working over http
[00:02] <wgz> otherwise you're probably best posting to the mailing list for advice
[00:02] <Noldorin> wgz, sshwidnows (openssh for win) isn't very good?
[00:02] <Noldorin> right
[00:02] <Noldorin> i see
[00:05] <wgz> feel free to try it, but I'd personally be very nervous about allowing that kind of access to my box
[00:05] <Noldorin> wgz, just because you think windows ssh servers don't have very well-tested security?
[00:07] <wgz> it's a big surface area, and not widely used, yes.
[00:14] <Noldorin> wgz, it's a big surface area on unix too :P
[00:14] <Noldorin> just better tested
[00:18] <Noldorin> wgz, are there any guides out there for setting up bzr+ssh (openssh) on unix at least?
[00:24] <jelmer> Noldorin: there is no setup required, just a ssh server (and having bzr installed) is sufficient
[00:24] <Noldorin> jelmer, oh yes? bzr client knows exactly what to do itself when it encounters an ssh server?
[00:25] <Noldorin> jelmer, recommend any windows ssh server btw?
[00:26] <jelmer> Noldorin: right, it just asks the remote server to run "bzr serve", and that's sufficient
[00:35] <wgz> Noldorin: an ssh client can get the server to run arbitrary commands, so it just asks the server run bzr
[00:42] <jelmer> Noldorin: I don't have any experience with SSH servers on Windows, sorry
[00:42] <Noldorin> jelmer, no prob. thanks for the tip anyway :-)
[00:43] <Noldorin> wgz, sure, as long as bzr is set up to deal with the quirks of being on an ssh transport. which i guess it is :-)
[08:12] <Amis> Hello o/
[08:14] <Amis> Soo... I'm searching all over the net but not finding an answer for this (seems to be very common) question: how can I make my Bazaar remember FTP passwords? I'm using 2.3.1 Bazaar with 0.6.1 T. Bazaar
[08:16] <Amis> I might also add I use Window
[08:16] <Amis> s
[08:35] <Amis> Uhh, net split
[08:36] <Amis> So, I found this thing called "authentication.conf" that does what I need BUT it does not work with SFTP connections and I can't really wrap my head around it
[08:37] <Amis> "password ignored in section [projectnamehere], use an ssh agent instead" is what it says. What's the point of ignoring the password in the conf then promting for it? I don't really get it.
[08:52] <fullermd> I don't know the Windows side.  But with a lot of ssh programs, bzr _can't_ pass the password to ssh.
[08:53] <fullermd> In that case, bzr isn't prompting for the password; ssh is.
[08:53] <fullermd> But whether that's what's happening for you, I don't know.
[08:54] <Amis> So there's an SSH client being used (since it can connect) but it bzr can't pass the password to that client?
[08:54] <vila> hey guys !
[09:02] <Amis> Okkey, I managed to set it up but it was hell of a struggle for someone without a linux machine at hand :/
[09:04] <mgz> morning all
[09:04] <vila> morning mgz
[09:33] <mgz> vila: on the get_message_encoding branch,
[09:33] <mgz> I'm a little torn on whether to add 'system' or not.
[09:34] <vila> for someone unaware of the context, 'message' is ambiguous
[09:34] <mgz> what we care about is system messages,
[09:34] <mgz> but gettext looks at LC_MESSAGES as well sorta
[09:35] <vila> right, but LC_ gives a hint there
[09:35] <mgz> and on win, FormatMessage is a generic api too (though generally just used to interpret errnos)
[09:36] <vila> what makes you remove the 'system' part ?
[09:36] <mgz> because it's the encoding for any messages really, it's just we happen to only care about the system ones
[09:37] <vila> what are the other kinds ?
[09:37] <vila> of message that is
[09:38] <vila> error messages as in: produced by the application as opposed to the underlying system ?
[09:38] <mgz> the c locale is a global setting
[09:38] <mgz> anything can look at it and use it.
[09:39] <vila> right,
[09:39] <vila> I think the trigger for my remark was the docstring mentioning system but since it's in osutils...
[09:41] <vila> may be the context makes it clearer but your proposal doen't have any uses of the function (classical issue when splitting proposals to make them easier to review ;)
[09:42] <mgz> basically what we need it for is to know how to interpret the strings that get put in OSError, IOError, and so on
[09:43] <mgz> which is why 'system', but it doesn't preclude the use of the setting for other things
[09:46] <vila> yeah, that's the part I can't see from the proposal probably. So, just land it ;)
[09:48] <mgz> well, the one worry would be if plugin authors are tempted to use it for something not related to the C library at all
[09:48] <mgz> like encoding strings they want to show the user with it, rather than looking at the stream.encoding or something
[09:52] <vila> maybe you can better explain the intent in the docstring ?
[10:00] <vila> mgz: urgh, mixed eols in test_win32utils.py
[10:00] <vila> weirdly enough, lp didn't notice
[10:00] <mgz> ...how did we manage that?
[10:01] <vila> for we I don't know, for where it's only the recently added lines ;)
[10:03] <vila> what is this '_func' attribute ?
[10:05] <mgz> ^just added in my branch? can rewrite history to avoid that... but thought editor I used on win was smart enough not to do that...
[10:06] <vila> yup
[10:06] <mgz> _func is something I'm trying out as a way of writing ctypes code
[10:06] <vila> no need to rewrite history, just fix it ;)
[10:06] <mgz> there are bunch of annoying issues with ctypes wrappers, that make it close to impossible to write good code with them
[10:08] <mgz> firstly, if you don't define the params, you risk breaking on bad arguments in really bad ways
[10:09] <mgz> secondly, you need to lazily load functions if you want to import the module on a platform without that library
[10:10] <mgz> thirdly, the basic wrapper is a horrible class with a useless docstring
[10:10] <mgz> fourthly, to test your wrapper properly you need to cover the error cases, which isn't always easy to get from the underlying library
[10:11] <mgz> so, this way does the definition inside a normal function with a docstring, on an attribute that can be overriden for tests
[10:12] <mgz> it's similar to having a named global in the module that partners the function, but more systematic
[10:12] <mgz> works out at a lot of boilerplate though
[10:12] <vila> but you can define this attribute as a real method and get the same benefits AFAICS
[10:12] <mgz> how do you mean?
[10:13] <vila> _get_env_var_w = ctypes.WINFUNCTYPE(DWORD, LPCWSTR, LPWSTR, DWORD)(88	+ ("GetEnvironmentVariableW", ctypes.windll.kernel32))
[10:14] <vila> and still override that in tests
[10:14] <mgz> as a module global?
[10:14] <vila> yes
[10:14] <mgz> we can't do that - kernel32 doesn't exist on nix.
[10:14] <mgz> would prevent import win32utils working there.
[10:15] <vila> these tests requires win32 anyway
[10:15] <vila> ha
[10:15] <vila> this code is already protected by has_ctypes and plaftorm = win32 no ?
[10:15] <vila> well, winver != 98
[10:16] <mgz> nope, it could be, but that has downsides too.
[10:16] <vila> what nope ? it *is* covered by: if has_ctypes and winver != 'Windows 98':
[10:17] <mgz> with a lot of functions from different places, you end up loading many libraries at import type you may not need
[10:17] <vila> oh.
[10:17] <vila> (bit slow this morning)
[10:18]  * vila scratches head
[10:18] <mgz> >>> print sys.platform, win32utils.winver != 98
[10:18] <mgz> linux2 True
[10:18] <vila> I still don't get it, we've been able to import lazily without this trick
[10:18] <mgz> ^was the 'nope'
[10:18] <vila> let's start again :)
[10:19] <mgz> if you look at existing code of this kind in osutils and win32utils
[10:19] <vila> The attribute trick makes me frown, can we do without it ?
[10:19] <mgz> you'll see they use a wide range of different tricks
[10:19] <mgz> vila: I'm still looking for a way that doesn't suck :)
[10:20] <vila> hmm
[10:20] <mgz> a decorator that does the boilerplate here is one idea, but then that's doing more work at startup and is even more magical
[10:22] <mgz> you need function specific code, but most of the wrapper wants to be just like all the other wrappers
[10:23] <vila> yeah, so you have cache local to your function, why not have a shared one then (for the WINFUNCTYPE), you can still inject whatever you need for tests
[10:25] <vila> or may be just documenting *that* magic (caching in the function attributes) is good enough to start with ?
[10:25] <vila> But is it even worth caching when the others don't ?
[10:25] <mgz> many of the other functions only get called once
[10:26] <mgz> but having everything use the same idiom at some point would make life easier
[10:27] <vila> right, so some of the things you said here are worth documenting in the proposal ;-)
[10:27] <mgz> ^one option I haven't mentioned is ctypes allows an errcheck function attribute for the specific logic you need to add, but then the exposed object is still the generated class with the useless docstring
[10:27] <vila> caching because used more than once (but still, why on the function itself ;)
[10:28] <vila> if the docstring is the issue can't you just override it or provide a wrapper ?
[10:28] <mgz> there's a point with ctypes where you have so many wrappers you forget where one starts and the next begins :)
[10:28] <vila> bah, this discussion is becoming far longer than it should :-/
[10:29] <mgz> :D
[10:29] <mgz> you've given me some useful feedback.
[10:33] <vila> mgz: reviewed, do the tweaks you feel necessary
[10:51] <mgz> how would you feal about cfunc = <function_name>._c_function ...or can you think of a better naming scheme?
[12:04] <vila> mgz: sry, missed that,
[12:04] <vila> hmm, this sounds better
[13:06] <mgz> pants, forgot news.
[13:23] <mgz> lunch!
[14:16] <mgz> blom blom.
[14:20] <jelmer> mgz: hmm
[14:20] <jelmer> I think I'm going to need a dictionary for that one
[14:22] <mgz> just making funny noises :)
[18:13] <mgz> okay, I need  break
[18:13] <mgz> +a
[19:06]  * lamont boggles at non-monotonically increasing revnos
[19:06] <nyuszika7h> )
[19:06] <nyuszika7h> Oops, auto-attach again >_<
[19:06] <lamont> if a is at rev 10, b is based on rev 7 + a change + merge of a, and I bzr pull into a from b, then the revno of a becomes smaller... this does not seem sane to me
[19:12] <lifeless> lamont: you've created a shorter left-hand-path
[19:12] <lifeless> lamont: you may want to disable such pulls by setting the config option for that
[19:16] <lamont> lifeless: I believe that I do, yes.
[19:16] <lamont> Is that clear in the manpage?
[19:17] <lifeless> look for append_revisions_only in 'bzr help configuration'
[21:21] <Dov_Rine> what's the best way to install bazaar for use as a redmine repository?
[22:03] <lamalex> lifeless, is there a simple
[22:03] <lamalex> er whoops imeant to hit backspace not enter
[23:05] <Noldorin> hi jelmer
[23:06] <jelmer> hi Noldorin
[23:39] <Noldorin> jelmer, hey.
[23:40] <Noldorin> jelmer, so with regards to bzr+ssh, how is the url translated into a path on the SSH server?
[23:49] <jelmer> Noldorin: it's the path part of the URL
[23:49] <jelmer> Noldorin: bzr log bzr+ssh://foo.com/var/www/bla accesses /var/www/bla there
[23:51] <jelmer> Noldorin: it supports ~