/srv/irclogs.ubuntu.com/2010/11/20/#bzr.txt

maxbglyph: Hrm, that looks like a bug caused by subvertpy converting from python-central to python-suppor00:23
maxbglyph: the weird thing is, I tested the upgrade in a hardy chroot, and it did not experience the problem00:23
glyphmaxb: well, thanks for testing, at least :)02:06
glyphmaxb: 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 like02:07
Kamping_Kaisernaw, i made dulwitch explode02:22
MvGHi! I feel trac-bzr bug #675014 is actually a bzr bug. Do you agree that the following command should work?10:39
MvGenv -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:39
ubot5Launchpad bug 675014 in Trac-Bzr "InvalidURL: URL was not a plain ASCII url (affected: 1, heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/67501410:39
MvGbzrlib.transport.local.LocalTransport.abspath has some comments about url escaping that probably affect this issue here.10:42
maxbglyph: 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:23
maxbMvG: Succeeds for me running bzr.dev11:26
MvGmaxb: strange. How do you tell python to use bzr.dev? Does PYTHONPATH=. do the trick?11:28
MvGmaxb: Still can reproduce here. This is on Gentoo Linux. What OS are you on?11:28
maxbah, not actually bzr.dev, but 2.3b3 release as it turns out. Installed as a system packaged, on Ubuntu maverick.11:31
maxbthough it also works with bzr.dev when I remember to set PYTHONPATH11:31
MvGAlso fails with 2.3b3 for me.11:32
* MvG scratches his head11:33
MvGCan reproduce on a different system, a 1.3.1-1ubuntu0.1 on Ubuntu hardy.11:36
MvGmaxb: You sure you copied the "env -i" along with the rest?11:37
maxb*oh*11:37
maxbNow I get11:38
maxb    return osutils.open_file(path, 'rb')11:38
maxbUnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 16: ordinal not in range(128)11:38
MvGIt seems important that bzrlib has no knowledge of your locale, and therefore relies on ascii as the only safe thing.11:38
maxbwhich I would describe as correct behaviour, if a little unfriendly11:38
MvGIf 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:40
MvGShould I combine the URL myself and rely on open_containing instead of open_containing_from_transport?11:41
maxberm, something feels wrong about this question11:42
maxbif all one has is what you said, you don't have anything specifying a single branch11:42
maxband I don't see how using transport-based vs url-based APIs would affect things11:43
maxbMvG: Fundamentally, if you deprive bzr of locale information you make it impossible to map unicode strings onto filesystem objects outside the realm of ASCII11:48
MvGScenario 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:48
maxbsounds like exactly what open_containing is for/11:49
maxb?11:49
MvGWell, 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:49
MvGI assume that was the original intent behind using clone there, although I didn't write that code.11:50
MvGThe 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
maxbIf any of the branches are named with non-ASCII, trac-bzr will and should have proper locale information11:51
maxbThough it is unpleasant, only the locale defines the charset to be used in file/directory names, on common Linux filesystems, as far as I know11:52
MvGThe 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:52
maxbOK, that is less nice11:53
maxbI 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 exist11:53
MvGProbably.11:54
spivMvG: well, open_containing takes an optional possible_transports kwarg11:54
MvGspiv: That does sound good!11:54
spivMvG: so it too can avoid constructing transports from scratch11:54
maxbIncidentally, are the semantics of possible_transports documented anywhere?11:55
MvGspiv: possible_transports is a list?11:55
spivYes.11:55
spivmaxb: heh, almost11:56
MvGBy 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
spivmaxb: see 'pydoc bzrlib.transport.get_transport', except it gives the param the wrong name...11:56
vilaspiv: urgh, ugly, shoot the culprit ;)12:02
vilaerr, no , wait, I meant bb:approve ! :D12:05
spivvila: if it weren't zzz-o'clock on a Saturday, I might even do it...12:32
ambvhi there. I found a bug in 2.2.1, could anyone confirm whether it's still there on the latest trunk?12:34
maxbWHat's the bug?12:43
ambvone of your favourite UnicodeDecodeError kind12:45
ambv1. branch out with a name using some Unicode characters12:45
ambv2. commits work, log works, merging works12:46
ambv3. but version-info raises UnicodeDecodeError12:46
spivambv: with LANG=C and a UTF-8 branch name I get a UnicodeDecodeError traceback, yes.12:51
spivambv: please file a bug.12:51
ambvspiv: great, I can present you with a patch as well.12:52
spivambv: doubly good!12:52
spivambv: any traceback from the CLI is a bug12:52
spivambv: so don't be afraid to file them if you see them :)12:52
ambvspiv: yeah but I don't want just to file bugs12:52
ambvrecently I have been closing CPython bugs that were there since like 2004 or so12:53
ambvpainful job since some of them very fairly trivial12:53
spivambv: well, if you want to fix them too that's awesome :)12:53
ambvyeah, that would at least be of some utility12:53
ambvwhat kind of worries me though is that the number of UCDEs on the tracker is kind of high:12:54
ambvhttps://bugs.edge.launchpad.net/bzr/+bugs?field.searchtext=UnicodeDecodeError&orderby=-importance12:54
spivYeah.12:54
ambv(there's not mine there yet)12:54
spivSome/many may turn out to have common causes, or even have been fixed already.12:54
ambvspiv: did you confirm the bug on the trunk though>12:55
spivambv: yes12:55
ambvgreat.12:55
ambvso you're a core bzr dev?12:55
spivYeah.12:55
ambvnice to meet you, the product is fantastic.12:55
spivAlso, I'm due to be asleep :)12:55
spivThanks!12:56
ambvso, sleep well spiv12:56
spivI will now :)12:56
ambvit's 2 PM where I'm now12:56
ambvhaha12:56
=== ambv_ is now known as ambv
vilaambv: there are several people working on Unicode errors in the community so +1 on spiv's "file bugs"14:02
vilaambv: there are also patches ready to land that are related (from mgz)14:03
vilamgz: by the way, is there anything retaining you to land those branches ?14:03
vilamgz: there are still enough time before 2.3b4 for this kind of stuff (says the RM ;)14:04
meetohi15:32
meetois anyone interested in a small QA (Paid) to setup an IIS server with BZR?15:32
* maxb ponders the need to set up a hardy VM to debug 67765516:43
Guest90193bug 677655 ?16:56
ubot5Launchpad bug 677655 in Bazaar "subvertpy traceback when using bzr from ppa on a hardy machine, even if I'm not invoking a bzr-svn command (affected: 2, heat: 12)" [Undecided,New] https://launchpad.net/bugs/67765516:56
mgz<ambv> 3. but version-info raises UnicodeDecodeError <- sounds like bug 518609 which should mangle the name rather than raise on trunk17:58
ubot5Launchpad bug 518609 in Bazaar "Unicode exception occurs by "version-info" (affected: 4, heat: 20)" [Medium,Fix released] https://launchpad.net/bugs/51860917:58
mgzit's a problem with how version-info is specified.17:59
mgz(or rather the default 'rio' format)17:59
ambvmgz: yes.18:00
ambvrio.18:00
ambvthis is why I asked if it's still the case on trunk.18:01
ambvspiv told me it is.18:01
ambvmgz: can you confirm or deny this? :)18:01
mgzit should be 'fixed' on trunk, where fixed means it doesn't throw an exception any more but mangles the text instead.18:02
ambvmgz: why would it mange?18:02
ambv*mangle18:02
ambvI mean, I know why --format python would18:03
ambvbut the text format?18:03
ambvbzr log works18:03
mgzwell, read the bug, but basically because the claim is rio is a binary format that happens to be utf-8, not text18:03
mgzthis is a dumb design, but means printing to a non-utf8 terminal results in unreadable output18:04
ambvmgz: then again, I do have an UTF-8 term.18:04
mgzthen I'm suprised it ever raised an error for you, what's your LANG setting? or are you on a mac?18:05
ambvMac18:05
mgzokay, that'd be it.18:05
ambvwhy?18:05
ambvdefault encoding?18:06
mgzlocale works slightly differently there. anyway, the trunk fix should be fine for you.18:07
ambvgreat.18:10
mgzdo file any other non-ascii bugs you find, just keep in mind bug 172383 which will probably cover many of them.18:12
ubot5Launchpad bug 172383 in Bazaar "[master] can't cope with NFD Unicode normalization on Mac OS X (affected: 11, heat: 100)" [Medium,Confirmed] https://launchpad.net/bugs/17238318:12
ambvmgz: 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.18:13
lvhHi!19:02
lvhIs there a guide for serving bzr with access control?19:02
lvhI basically want private access only (both for reading and writing).19:02
lifelessinstall bzr on the server, use bzr+ssh urls.19:03
lifelessdone :)19:03
lvhlifeless: Aha, okay, so just make plain user accounts for everyone19:26
lvhlifeless: Thanks19:26
lvhlifeless: Is there some kind of convention for storing stuff? /var? I assume everyone needs write access.19:27
lvh(Although I'll just use the bookmarks plugin to make that a non-issue)19:29
fullermdI imagine that's more site-ish than bzr-ish...19:30
fullermdOur 'central' stuff at work is under /home/cvs/ for instance.19:31
lvhfullermd: I was thinking of an analogy with /var/ww19:32
lvhw19:32
fullermd(originally for consistency with our CVS stuff; now to keep people on their toes ;)19:32
=== ambv_ is now known as ambv
=== frakturfreak|AKF is now known as frakturfreak
=== frakturfreak is now known as frakturfreak|AKF
=== frakturfreak|AKF is now known as frakturfreak
=== frakturfreak is now known as frakturfreak|AKF

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!