[00:23] <maxb> glyph: Hrm, that looks like a bug caused by subvertpy converting from python-central to python-suppor
[00:23] <maxb> glyph: the weird thing is, I tested the upgrade in a hardy chroot, and it did not experience the problem
[02:06] <glyph> maxb: well, thanks for testing, at least :)
[02:07] <glyph> maxb: I can give you SSH access to this machine, if can't reproduce on your own hardy box and you want to see what it looks like
[02:22] <Kamping_Kaiser> naw, i made dulwitch explode
[10:39] <MvG> Hi! I feel trac-bzr bug #675014 is actually a bzr bug. Do you agree that the following command should work?
[10:39] <MvG> env -i PATH=/bin:/usr/bin python -c 'from bzrlib import bzrdir, transport; print bzrdir.BzrDir.open_containing_from_transport(transport.get_transport(".").clone("./t%C3%A4st"))'
[10:42] <MvG> bzrlib.transport.local.LocalTransport.abspath has some comments about url escaping that probably affect this issue here.
[11:23] <maxb> glyph: Did you see the my comment on the bug? Unfortunately I'm not sure that SSH access to a machine would actually tell me how it got into that state.
[11:26] <maxb> MvG: Succeeds for me running bzr.dev
[11:28] <MvG> maxb: strange. How do you tell python to use bzr.dev? Does PYTHONPATH=. do the trick?
[11:28] <MvG> maxb: Still can reproduce here. This is on Gentoo Linux. What OS are you on?
[11:31] <maxb> ah, not actually bzr.dev, but 2.3b3 release as it turns out. Installed as a system packaged, on Ubuntu maverick.
[11:31] <maxb> though it also works with bzr.dev when I remember to set PYTHONPATH
[11:32] <MvG> Also fails with 2.3b3 for me.
[11:33]  * MvG scratches his head
[11:36] <MvG> Can reproduce on a different system, a 1.3.1-1ubuntu0.1 on Ubuntu hardy.
[11:37] <MvG> maxb: You sure you copied the "env -i" along with the rest?
[11:37] <maxb> *oh*
[11:38] <maxb> Now I get
[11:38] <maxb>     return osutils.open_file(path, 'rb')
[11:38] <maxb> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 16: ordinal not in range(128)
[11:38] <MvG> It seems important that bzrlib has no knowledge of your locale, and therefore relies on ascii as the only safe thing.
[11:38] <maxb> which I would describe as correct behaviour, if a little unfriendly
[11:40] <MvG> If this is correct behaviour, is there an equally correct way to determine the branch and location within the branch if all one has is a transport at the root of hierarchy with several branches, and if one does not know the location where the branch-location part of the url stops and the within-branch part starts?
[11:41] <MvG> Should I combine the URL myself and rely on open_containing instead of open_containing_from_transport?
[11:42] <maxb> erm, something feels wrong about this question
[11:42] <maxb> if all one has is what you said, you don't have anything specifying a single branch
[11:43] <maxb> and I don't see how using transport-based vs url-based APIs would affect things
[11:48] <maxb> MvG: Fundamentally, if you deprive bzr of locale information you make it impossible to map unicode strings onto filesystem objects outside the realm of ASCII
[11:48] <MvG> Scenario is this: trac-bzr has one base location configured for the whole setup. All paths are expected to be relative to that. There are usually branches under it, so when users ask for object branch/dir/file, then trac-bzr should open base/branch, because it is the nearest parent of base/branch/dir/file that does exist and contain a .bzr control dir. It should also return dir/file as the path within that branch, for further processing.
[11:49] <maxb> sounds like exactly what open_containing is for/
[11:49] <maxb> ?
[11:49] <MvG> Well, some operations use several branches, and base might be a remote URL. In that case, I assume that clone() might be a lot more efficient than creating a new transport from scratch for every such item.
[11:50] <MvG> I assume that was the original intent behind using clone there, although I didn't write that code.
[11:51] <MvG> The fact that open_containing_from_transport exists suggests that a transport might refer to stuff within a branch as well as the branch root. And having that part rely on locale feels bad.
[11:51] <maxb> If any of the branches are named with non-ASCII, trac-bzr will and should have proper locale information
[11:52] <maxb> Though it is unpleasant, only the locale defines the charset to be used in file/directory names, on common Linux filesystems, as far as I know
[11:52] <MvG> The branches are all ascii, it's files within them which cause trouble. Those aren't even present in the filesystem, as the branches aren't checked out.
[11:53] <maxb> OK, that is less nice
[11:53] <maxb> I expect that part of open_containing involves probing whether they do or don't exist, which means bzr still needs to figure out what they would be called on disk if they did exist
[11:54] <MvG> Probably.
[11:54] <spiv> MvG: well, open_containing takes an optional possible_transports kwarg
[11:54] <MvG> spiv: That does sound good!
[11:54] <spiv> MvG: so it too can avoid constructing transports from scratch
[11:55] <maxb> Incidentally, are the semantics of possible_transports documented anywhere?
[11:55] <MvG> spiv: possible_transports is a list?
[11:55] <spiv> Yes.
[11:56] <spiv> maxb: heh, almost
[11:56] <MvG> By the way, how can I ensure to jail all access to some root transport? I.e. forbid access to branches that aren't below that root?
[11:56] <spiv> maxb: see 'pydoc bzrlib.transport.get_transport', except it gives the param the wrong name...
[12:02] <vila> spiv: urgh, ugly, shoot the culprit ;)
[12:05] <vila> err, no , wait, I meant bb:approve ! :D
[12:32] <spiv> vila: if it weren't zzz-o'clock on a Saturday, I might even do it...
[12:34] <ambv> hi there. I found a bug in 2.2.1, could anyone confirm whether it's still there on the latest trunk?
[12:43] <maxb> WHat's the bug?
[12:45] <ambv> one of your favourite UnicodeDecodeError kind
[12:45] <ambv> 1. branch out with a name using some Unicode characters
[12:46] <ambv> 2. commits work, log works, merging works
[12:46] <ambv> 3. but version-info raises UnicodeDecodeError
[12:51] <spiv> ambv: with LANG=C and a UTF-8 branch name I get a UnicodeDecodeError traceback, yes.
[12:51] <spiv> ambv: please file a bug.
[12:52] <ambv> spiv: great, I can present you with a patch as well.
[12:52] <spiv> ambv: doubly good!
[12:52] <spiv> ambv: any traceback from the CLI is a bug
[12:52] <spiv> ambv: so don't be afraid to file them if you see them :)
[12:52] <ambv> spiv: yeah but I don't want just to file bugs
[12:53] <ambv> recently I have been closing CPython bugs that were there since like 2004 or so
[12:53] <ambv> painful job since some of them very fairly trivial
[12:53] <spiv> ambv: well, if you want to fix them too that's awesome :)
[12:53] <ambv> yeah, that would at least be of some utility
[12:54] <ambv> what kind of worries me though is that the number of UCDEs on the tracker is kind of high:
[12:54] <ambv> https://bugs.edge.launchpad.net/bzr/+bugs?field.searchtext=UnicodeDecodeError&orderby=-importance
[12:54] <spiv> Yeah.
[12:54] <ambv> (there's not mine there yet)
[12:54] <spiv> Some/many may turn out to have common causes, or even have been fixed already.
[12:55] <ambv> spiv: did you confirm the bug on the trunk though>
[12:55] <spiv> ambv: yes
[12:55] <ambv> great.
[12:55] <ambv> so you're a core bzr dev?
[12:55] <spiv> Yeah.
[12:55] <ambv> nice to meet you, the product is fantastic.
[12:55] <spiv> Also, I'm due to be asleep :)
[12:56] <spiv> Thanks!
[12:56] <ambv> so, sleep well spiv
[12:56] <spiv> I will now :)
[12:56] <ambv> it's 2 PM where I'm now
[12:56] <ambv> haha
[14:02] <vila> ambv: there are several people working on Unicode errors in the community so +1 on spiv's "file bugs"
[14:03] <vila> ambv: there are also patches ready to land that are related (from mgz)
[14:03] <vila> mgz: by the way, is there anything retaining you to land those branches ?
[14:04] <vila> mgz: there are still enough time before 2.3b4 for this kind of stuff (says the RM ;)
[15:32] <meeto> hi
[15:32] <meeto> is anyone interested in a small QA (Paid) to setup an IIS server with BZR?
[16:43]  * maxb ponders the need to set up a hardy VM to debug 677655
[16:56] <Guest90193> bug 677655 ?
 3. but version-info raises UnicodeDecodeError <- sounds like bug 518609 which should mangle the name rather than raise on trunk
[17:59] <mgz> it's a problem with how version-info is specified.
[17:59] <mgz> (or rather the default 'rio' format)
[18:00] <ambv> mgz: yes.
[18:00] <ambv> rio.
[18:01] <ambv> this is why I asked if it's still the case on trunk.
[18:01] <ambv> spiv told me it is.
[18:01] <ambv> mgz: can you confirm or deny this? :)
[18:02] <mgz> it should be 'fixed' on trunk, where fixed means it doesn't throw an exception any more but mangles the text instead.
[18:02] <ambv> mgz: why would it mange?
[18:02] <ambv> *mangle
[18:03] <ambv> I mean, I know why --format python would
[18:03] <ambv> but the text format?
[18:03] <ambv> bzr log works
[18:03] <mgz> well, read the bug, but basically because the claim is rio is a binary format that happens to be utf-8, not text
[18:04] <mgz> this is a dumb design, but means printing to a non-utf8 terminal results in unreadable output
[18:04] <ambv> mgz: then again, I do have an UTF-8 term.
[18:05] <mgz> then I'm suprised it ever raised an error for you, what's your LANG setting? or are you on a mac?
[18:05] <ambv> Mac
[18:05] <mgz> okay, that'd be it.
[18:05] <ambv> why?
[18:06] <ambv> default encoding?
[18:07] <mgz> locale works slightly differently there. anyway, the trunk fix should be fine for you.
[18:10] <ambv> great.
[18:12] <mgz> do file any other non-ascii bugs you find, just keep in mind bug 172383 which will probably cover many of them.
[18:13] <ambv> mgz: I will. it is to be expected that Linux will be the main platform here. I mean Canonical, etc. and this being a GNU project. so I will try to test the hell out of it on the Mac.
[19:02] <lvh> Hi!
[19:02] <lvh> Is there a guide for serving bzr with access control?
[19:02] <lvh> I basically want private access only (both for reading and writing).
[19:03] <lifeless> install bzr on the server, use bzr+ssh urls.
[19:03] <lifeless> done :)
[19:26] <lvh> lifeless: Aha, okay, so just make plain user accounts for everyone
[19:26] <lvh> lifeless: Thanks
[19:27] <lvh> lifeless: Is there some kind of convention for storing stuff? /var? I assume everyone needs write access.
[19:29] <lvh> (Although I'll just use the bookmarks plugin to make that a non-issue)
[19:30] <fullermd> I imagine that's more site-ish than bzr-ish...
[19:31] <fullermd> Our 'central' stuff at work is under /home/cvs/ for instance.
[19:32] <lvh> fullermd: I was thinking of an analogy with /var/ww
[19:32] <lvh> w
[19:32] <fullermd> (originally for consistency with our CVS stuff; now to keep people on their toes ;)