| RenatoSilva | where should I look for 1.16.1 source? here in https://code.launchpad.net/~bzr/bzr/1.16, or in trunk? | 00:13 |
|---|---|---|
| LarstiQ | RenatoSilva: I'd download the 1.16.1 tarball? | 00:13 |
| LarstiQ | maybe I don't get what you're after | 00:14 |
| mzz | there's a "download" button on bazaar-vcs.org, the source tarball is not far from there | 00:14 |
| RenatoSilva | LarstiQ: 1.16.1 in in 1.16 or trunk? | 00:14 |
| RenatoSilva | mzz: oh you're here too | 00:14 |
| mzz | or do you mean you want a bzr branch? | 00:14 |
| RenatoSilva | mzz: I want to browse with loggerhead | 00:15 |
| * LarstiQ blinks | 00:15 | |
| LarstiQ | okay | 00:15 |
| RenatoSilva | someoneme must know which next version is in trunk | 00:15 |
| LarstiQ | RenatoSilva: then the url you pasted sounds like the choice, bzr.dev/trunk has moved quite a bit since 1.16 | 00:15 |
| RenatoSilva | if 1.17 or 1.16.2 | 00:15 |
| LarstiQ | RenatoSilva: never 1.16.2 | 00:15 |
| mzz | this'd be easier if launchpad loaded | 00:15 |
| LarstiQ | RenatoSilva: 1.16.2 will be made from the 1.16 branch, not the development focus | 00:16 |
| * LarstiQ still doesn't get what the goal is | 00:16 | |
| RenatoSilva | LarstiQ: so anything under 1.16 will be in the 1.16 branch right? | 00:16 |
| mzz | RenatoSilva: yes, that's what the 1.16 branch is for | 00:17 |
| RenatoSilva | LarstiQ: the goal is browsing 1.1.6.1 source code in launchpad, that simple | 00:17 |
| RenatoSilva | ok thanks | 00:17 |
| * mzz wonders if loggerhead does tags | 00:17 | |
| LarstiQ | RenatoSilva: well, the 1.16 branch might have moved a little from 1.16.1, but it's the closest | 00:17 |
| mzz | most recent commit there is "Tweak NEWS file for 1.16.1 release." | 00:18 |
| mzz | so probably not | 00:18 |
| RenatoSilva | LarstiQ: humm, so there's not a "static" branch for 1.16.1... | 00:18 |
| mzz | RenatoSilva: there should be a tag, but I don't see any tags in loggerhead | 00:19 |
| RenatoSilva | mzz: when loggerhead implement tags we'll be able to do it | 00:19 |
| mzz | RenatoSilva: anyway, the head of the 1.16 branch should be it. Trying to confirm but it'll take a bit. | 00:20 |
| LarstiQ | RenatoSilva: I don't think it's really useful, but I'll look around to see if there is | 00:20 |
| RenatoSilva | LarstiQ: tags? there's not | 00:20 |
| LarstiQ | no, a 'static' 1.16.1 | 00:21 |
| RenatoSilva | ah ok | 00:21 |
| RenatoSilva | mzz: bug 246739 | 00:21 |
| ubottu | Launchpad bug 246739 in loggerhead "tags are not available" [Wishlist,Fix committed] https://launchpad.net/bugs/246739 | 00:21 |
| mzz | and "bzr tags -d lp:bzr/1.16" isn't working very well either | 00:22 |
| LarstiQ | mzz: what goes wrong with that? | 00:23 |
| mzz | LarstiQ: it takes forever | 00:23 |
| mzz | LarstiQ: well, it grabbed a few MiB worth of data if I can trust the progress indicator, then I aborted it | 00:23 |
| mzz | I'm just pulling the branch, but it'll take a while because of the slowness of the network partition I'm pulling it into | 00:23 |
| LarstiQ | RenatoSilva: https://edge.launchpad.net/bzr/1.16/1.16.1 just has the release files | 00:24 |
| * LarstiQ checks branches | 00:24 | |
| LarstiQ | but I'm pretty sure we don't do branches for point releases | 00:24 |
| RenatoSilva | LarstiQ: where did you find this link, it's not listed in 1.16 series | 00:25 |
| RenatoSilva | LarstiQ: ok got it, sorry | 00:25 |
| LarstiQ | RenatoSilva: launchpad.net/bzr, click on the 1.16.1 link in the series canvas thingy | 00:25 |
| * RenatoSilva is trying bzr tags -d lp:bzr/1.16, slow too | 00:27 | |
| RenatoSilva | is it downloading the branch or only the .bzr? | 00:27 |
| RenatoSilva | to where? | 00:27 |
| * mzz frowns | 00:28 | |
| LarstiQ | the branch is a subset of .bzr | 00:28 |
| mzz | either this repo is a lot further behind than I realised or I'm doing something stupid with repository type mismatches. | 00:28 |
| * LarstiQ looks at what cmd_tags does | 00:28 | |
| LarstiQ | a cursory glance looks like it really shouldn't be slow to get the tags | 00:32 |
| RenatoSilva | it is in 3082KB, no progress in bar | 00:33 |
| RenatoSilva | seems to be downloading a big stuff | 00:33 |
| mzz | my "bzr branch" is now at revision 800/6292, and looks like it'll take a while still. | 00:34 |
| * LarstiQ tacks on a -Dtransport | 00:34 | |
| mzz | I don't know how much of that is the bzr+ssh I'm downloading through and how much is the sshfs I'm downloading onto, but the latter is probably significant. | 00:34 |
| mzz | I really should switch that to something faster one of these days. | 00:34 |
| LarstiQ | mzz: why do you have things set up like this? | 00:35 |
| LarstiQ | oh boy | 00:37 |
| mzz | LarstiQ: I have my repositories sitting on a server on my lan. I should upgrade that to nfs instead of an sshfs though. | 00:37 |
| mzz | (they're treeless repositories, with lightweight checkouts sitting on my local drive) | 00:38 |
| * RenatoSilva just download the source, and found C code o.O | 00:39 | |
| LarstiQ | RenatoSilva: there are python fallbacks, so you can run in pure python | 00:39 |
| LarstiQ | RenatoSilva: but the C (generated from pyrex) is faster for a couple of bits | 00:40 |
| mzz | it runs well enough as pure python that it took people a bit of time before they realised the release tarballs were missing the c files (twice, iirc) :) | 00:41 |
| RenatoSilva | LarstiQ: pyrex? you mean all the C code is entirely generated from python code?? | 00:41 |
| LarstiQ | RenatoSilva: pyrex code is not exactly pure python code. But yeah, mostly. | 00:42 |
| LarstiQ | there used to be some pure C too though, not sure if we still have that | 00:42 |
| RenatoSilva | ok | 00:42 |
| LarstiQ | for the patience diff algorithm I think | 00:42 |
| LarstiQ | RenatoSilva: see the *.pyx files | 00:43 |
| mzz | mmm, so if I have a lightweight checkout and the thing it is bound to moves around, how do I re-bind it to the new location? | 00:43 |
| dash | bzr bind or bzr switch | 00:44 |
| mzz | "bzr bind newlocation" is giving me "bzr: ERROR: Not a branch: oldlocation/.bzr/branch" | 00:44 |
| mzz | as is "bzr switch" | 00:44 |
| dash | oh, lightweight. i'd be switch | 00:44 |
| dash | it'd | 00:44 |
| mzz | as is "bzr switch --force", and bind doesn't have a --force | 00:44 |
| RenatoSilva | LarstiQ: I see.. the generated C code is crazy | 00:44 |
| mzz | I can just edit .bzr/branch/location, but that's lame. | 00:44 |
| james_w | LarstiQ: thanks | 00:46 |
| RenatoSilva | mzz: I'm reading commands.py...it seems that the only encoding_type value supposed to cause an error is 'strict', but the xmloutput has no command set as 'strict' | 00:55 |
| mzz | RenatoSilva: iirc that's what my patch changed | 00:55 |
| LarstiQ | RenatoSilva, mzz: try tags with --show-ids | 00:56 |
| RenatoSilva | most of them are 'replace', which is supposed to replace with '?' the problematic chars, instead it was raising an error | 00:56 |
| * RenatoSilva just noticed the tags command finished | 00:56 | |
| LarstiQ | the slow part is the revno lookup | 00:57 |
| mzz | LarstiQ: duh | 00:57 |
| RenatoSilva | where does it put the downloaded files? | 00:57 |
| LarstiQ | RenatoSilva: where does what? | 00:58 |
| mzz | RenatoSilva: it *was* replacing them with ? when you were feeding it unicode (which was written in the wrong encoding) | 00:58 |
| * LarstiQ is falling asleep | 00:58 | |
| mzz | RenatoSilva: it only started erroring once you started explicitly feeding it utf-8 encoded bytes | 00:58 |
| LarstiQ | could one of you file a bug on tags doing that lookup stupidly, and assign it to me? | 00:58 |
| RenatoSilva | LarstiQ: it seems to download a lot of files | 00:58 |
| LarstiQ | RenatoSilva: yes but what | 00:58 |
| LarstiQ | RenatoSilva: `bzr tags` will not put anything anywhere | 00:59 |
| mzz | LarstiQ: later, I'm also kinda sleepy | 00:59 |
| RenatoSilva | mzz: yes, and 'replace' should try to decode from utf-8 and encode as cp850, and when it fails it should get the problematic chars and replace them with '?', not raise the error to the user, right? | 01:00 |
| RenatoSilva | LarstiQ: so what are those KB growing up | 01:00 |
| LarstiQ | RenatoSilva: as I said, naive revid → revno lookup | 01:01 |
| mzz | RenatoSilva: no. With "replace" it expects you to feed it unicode, which it'll encode as cp850. Feeding it utf-8 is unsupported and will blow up as soon as it's non-ascii. | 01:01 |
| mzz | which it did. | 01:01 |
| LarstiQ | RenatoSilva: try --show-ids to see the difference | 01:01 |
| * mzz is fairly certain he understands what the commands api wants you to do here now. | 01:01 | |
| mzz | well, mostly | 01:01 |
| RenatoSilva | LarstiQ: ok, but it seems files being downloaded, the message could be fetching revisions instead | 01:01 |
| mzz | RenatoSilva: exactly, which is what he wants a bug filed on | 01:01 |
| LarstiQ | RenatoSilva: fsvo files, nothing that would be in your working dir | 01:02 |
| RenatoSilva | mzz: "replace - put in a bogus character (typically '?')" | 01:03 |
| mzz | RenatoSilva: yep, *if* you're feeding it unicode. Once you start feeding it bytes it's free to blow up, that's not the intended use. | 01:03 |
| LarstiQ | not bogus, and always '?', on purpose | 01:03 |
| RenatoSilva | LarstiQ: fsvo? | 01:03 |
| LarstiQ | RenatoSilva: for some value of | 01:03 |
| * LarstiQ sleep now | 01:04 | |
| RenatoSilva | mzz: humm | 01:04 |
| mzz | RenatoSilva: up until you mentioned "bzr" yesterday I was assuming your "stdout" was sys.stdout. What a non-'strict'-mode bzr command gets isn't sys.stdout. | 01:05 |
| RenatoSilva | mzz: ? | 01:05 |
| RenatoSilva | mzz: when I don't use > file, isn't it using sys.tdout? | 01:06 |
| RenatoSilva | mzz: it's a file with encoding == cp850, which makes me think it's the terminal | 01:06 |
| mzz | RenatoSilva: it's using sys.stdout wrapped in an object from the codecs module that encodes unicode before handing it to the actual sys.stdout | 01:06 |
| RenatoSilva | mzz: it encodes to the encoding set in outf right? | 01:07 |
| RenatoSilva | mzz: in sys.stdout I mean | 01:07 |
| mzz | RenatoSilva: http://docs.python.org/dev/library/codecs.html#streamwriter-objects that is | 01:07 |
| mzz | RenatoSilva: logic for finding the encoding is in bzrlib.osutils.get_terminal_encoding, which does indeed look at sys.stdout.encoding | 01:09 |
| RenatoSilva | why do you say 'replace' expects to receive unicode objects? how can it know that certain unicode char is not supported by the target encoding? does it really know? does it really analyze each char and check against the target encoding? when I was not sending utf-8, sometimes it was sent raw cp850 to encode as cp850, and sometimes it was sending unicode (the dir path). In this last case, you mean ஠was a replacement caused by by encoding_type = 'repla | 01:17 |
| RenatoSilva | sorry for the typos | 01:17 |
| RenatoSilva | http://pastie.org/534468 --> this description is a bit confising | 01:20 |
| RenatoSilva | strict - abort if we cannot decode -- decode an unicode obj??? | 01:21 |
| RenatoSilva | exact - do not encode sys.stdout -- so who will encode? because unicode chars are not actual bytes | 01:22 |
| mzz | you weren't sending raw cp850, it would've failed the same way it did when you sent raw utf-8 | 01:22 |
| RenatoSilva | ok, always unicode | 01:23 |
| mzz | and I was confused, my patch used 'exact', right? | 01:23 |
| RenatoSilva | yes | 01:23 |
| mzz | patch used exact, so it got the actual unwrapped stdout, which it then wraps using codecs.getwriter (just like bzr would do for us) *but* using utf-8 as the encoding instead of using the terminal encoding. | 01:23 |
| RenatoSilva | I mean 'replace' should replace çã with ?? not ‡Æ | 01:24 |
| mzz | the problem was that the characters you were asking it to write *were* available in the terminal encoding (iirc cp850) but the bytes they were mapped to meant something else in whatever encoding whatever you used to view the result used. | 01:24 |
| RenatoSilva | hummm, because N++ does not supoport cp850 | 01:25 |
| RenatoSilva | and no editor I've ever seen ... | 01:25 |
| mzz | I don't know if it doesn't support it, but it wasn't using it when reading the file. | 01:25 |
| mzz | and even if it did the file would be lying: the contents of the file would mention the utf-8 encoding, which it isn't actually encoded in. | 01:26 |
| RenatoSilva | and when I send str objects when using 'replace' it will try to decode and encode again? | 01:27 |
| RenatoSilva | decode from get_encoding? | 01:27 |
| mzz | you read that "what every programmer must..." page you were linked to, right? | 01:27 |
| RenatoSilva | it seems that I didn't | 01:28 |
| mzz | that page wasn't python-specific, but it's a bit hard for me to explain this if you haven't at least skimmed that article, or are already familiar with what's described in it. | 01:28 |
| RenatoSilva | I was linked to? | 01:28 |
| mzz | I think you were, sec | 01:28 |
| mzz | http://www.joelonsoftware.com/articles/Unicode.html is the one I meant | 01:29 |
| RenatoSilva | oh I read this in the past | 01:29 |
| RenatoSilva | Joel is boring | 01:29 |
| RenatoSilva | but I want to read it again | 01:29 |
| mzz | basically what's passed around inside bzr is usually python unicode objects, which are sequences of unicode codepoints | 01:30 |
| RenatoSilva | I think my problem here is just to understand how encoding_type, unicode/str and write work together | 01:30 |
| RenatoSilva | mzz: I think I 've got what are u''s and ''s | 01:31 |
| RenatoSilva | mzz: and encode and decode | 01:31 |
| RenatoSilva | mzz: I just don't get how u''/'' and encoding_type and write work together | 01:31 |
| mzz | that article explains what code points are to some extent. Anyway, like most good bzr commands this one is passing around unicode objects, and they're *correct* (which I checked by having you print the repr of one) | 01:32 |
| RenatoSilva | I mean, for each encoding | 01:32 |
| RenatoSilva | sorry | 01:32 |
| RenatoSilva | for each encoding_type x for each in (unicode, str), what is the behavior of write? | 01:32 |
| mzz | the command layer then assumes that you're usually running commands interactively, and that most commands deal in unicode, not bytes (aka str) objects | 01:32 |
| mzz | so unless you use a nonstandard mode the "output" you get from the commands layer wants *unicode* objects which it *encodes* to bytes using the terminal encoding (which it gets off sys.stdout.encoding or some other place) | 01:34 |
| mzz | normally this works pretty well | 01:34 |
| mzz | this was all bzrlib stuff. There's also a general python rule to be aware of: if you pass something a str where a unicode is needed or vice versa python implicitly converts using the ascii encoding, which means it'll blow up unless there aren't any accented or other weird characters in there. | 01:35 |
| RenatoSilva | mzz: I think if I read the right code I will be anwered | 01:35 |
| mzz | so if you're using this mode of the command layer you *cannot* write in a different encoding: you can convert to bytes, but then python will go and decode those back to unicode when bzr tries to helpfully encode using the terminal encoding, which you don't even want! | 01:36 |
| RenatoSilva | if you pass something a str where a unicode is needed or vice versa python implicitly converts using the ascii encoding, which means it'll blow up unless there aren't any accented or other weird characters in there. ---> oh I didn't know that, I thought it was a bzrlib stuff!!! | 01:36 |
| mzz | no, that's a python thing | 01:36 |
| RenatoSilva | big news to me | 01:37 |
| mzz | what's happening is basically '\xc3\x88'.encode('cp850') (try that one in an interactive python prompt) | 01:38 |
| mzz | I forgot what character you were using, but let's assume it's u'\xc8' (which is an E with a ` on it). If you .encode('utf-8') that you get '\xc3\x88'. Your stdout then tried to .encode('cp850') that. | 01:40 |
| RenatoSilva | mzz: so when I was sending cp850 bytes, python was decoding from preferred encoding (cp850), and then bzrlib was encoding again as preferred encoding (cp850)? :D | 01:40 |
| mzz | but you can't encode '\xc3\x88': it's already a str. So python tries to convert it back to unicode using the ascii encoding. | 01:40 |
| mzz | that's what happened when you stuck that explicit .encode('utf-8') in there, and you started getting UnicodeDecodeErrors | 01:40 |
| mzz | what happened when you did get output, it just didn't look right in n++, was that n++ was guessing the encoding wrong | 01:41 |
| mzz | guessing encodings is very hard (except for a few of them) | 01:41 |
| mzz | and yes, bzr was decoding and encoding using the preferred *terminal* encoding (cp850) but you weren't actually looking at the file on the terminal. | 01:42 |
| mzz | it *should* have shown up correctly with the output to the terminal, not a file. | 01:42 |
| mzz | If that *also* failed python was getting the terminal encoding (sys.stdout.encoding) wrong. | 01:43 |
| RenatoSilva | "So python tries to convert it back to unicode using the ascii encoding." ---> Hummm!!!!!!! | 01:43 |
| mzz | all this works much better in python 3, where that implicit conversion was removed | 01:46 |
| * mzz wantssssss it | 01:46 | |
| RenatoSilva | mzz: n++ has ANSI, UCS and UTF8, there's no cp850, and notepad.exe does not have this either | 01:47 |
| RenatoSilva | mzz: I've heard all strings are unicode in py3k | 01:47 |
| mzz | unsurprisingly there's still a "bytes" type (similar to the py2 "str" type), and what's called the "str" type in py 3 is similar to the "unicode" type in py 2. There's no type called "unicode" in py 3. | 01:48 |
| mzz | more important than the name change is that those implicit conversions went away. The implicit conversions are annoying that you don't realise they're happening as long as your input is ascii (unaccented chars), and that's pretty common when you're coding in english. | 01:49 |
| RenatoSilva | mzz: If that *also* failed python was getting the terminal encoding (sys.stdout.encoding) wrong. --> by falied you mean wrong chars in _terminal_? | 01:51 |
| Pegasus_RPG | hello. How can I search a repo for the latest revision of a now-deleted file? | 01:52 |
| mzz | Pegasus_RPG: there's a "heads" command in bzrtools that may be of use | 01:52 |
| mzz | Pegasus_RPG: err, wait, I misread that | 01:52 |
| mzz | Pegasus_RPG: the file's gone but you just need to go backwards in history to get it back, right? | 01:52 |
| Pegasus_RPG | correct, I still want everything else to be current | 01:53 |
| mzz | RenatoSilva: yep | 01:53 |
| RenatoSilva | mzz: unsurprisingly there's still a "bytes" type (similar to the py2 "str" type), and what's called the "str" type in py 3 is similar to the "unicode" type in py 2. There's no type called "unicode" in py 3. ----> looks nice, someone cleaned the bedroom | 01:53 |
| mzz | RenatoSilva: note that (assuming an ntfs filesystem) the filenames on disk aren't actually cp850 :) | 01:53 |
| RenatoSilva | mzz: they're cp1252 | 01:54 |
| mzz | RenatoSilva: yep, that's what py3 is all about. py2 can't fix things like this because it tries to be backwards compatible. | 01:54 |
| RenatoSilva | I guess | 01:54 |
| mzz | RenatoSilva: they shouldn't be. | 01:54 |
| * mzz looks up the on-disk encoding name | 01:54 | |
| RenatoSilva | should be what? | 01:54 |
| Pegasus_RPG | mzz: correct, I still want everything else to be current | 01:54 |
| RenatoSilva | mzz: a python function returns cm** or so... but I thought it just meant cp1252 | 01:54 |
| mzz | RenatoSilva: hopefully utf-16 on disk, but you shouldn't have to care about that. Try sys.getfilesystemencoding() | 01:55 |
| mzz | Pegasus_RPG: mmm, I don't quite remember how to do that. Sec. | 01:56 |
| RenatoSilva | mzz: sys.getfilesystemencoding() == 'mbcs' | 01:56 |
| Pegasus_RPG | mzz: to add another wrinkle, I'm working on a branch. the file was deleted back in trunk awhile ago | 01:56 |
| RenatoSilva | mzz: should be some MS UCS | 01:56 |
| Pegasus_RPG | (When trunk was in svn. :) ) | 01:56 |
| mzz | Pegasus_RPG: shouldn't really matter, I think, assuming this is a bzrsvnified branch | 01:57 |
| Pegasus_RPG | it is | 01:57 |
| mzz | bleh, is launchpad really slow or does it just not like me? | 01:59 |
| mzz | ah, I have an idea | 02:00 |
| mzz | or rather the help does | 02:00 |
| RenatoSilva | mzz: lp has been slow to me too these days | 02:00 |
| mzz | Pegasus_RPG: can you find a revision that file existed at? | 02:00 |
| Pegasus_RPG | I was hoping bzr could tell me :) | 02:00 |
| mzz | Pegasus_RPG: if you do you should be able to "bzr log -rthatrevision.. -p thefile.txt" | 02:00 |
| mzz | Pegasus_RPG: from "bzr help log": "To log a deleted file, specify a revision range so that the file existed at the end or start of the range." | 02:01 |
| Pegasus_RPG | ok | 02:01 |
| Pegasus_RPG | I could just give it an insane range | 02:01 |
| mzz | yeah, exactly | 02:02 |
| Pegasus_RPG | ok thanks | 02:02 |
| mzz | if you give an open-ended range with one end at a spot where it exists I'd expect it to pick it up | 02:02 |
| RenatoSilva | mzz: thank you for helping | 02:02 |
| mzz | Pegasus_RPG: there's also a bzr-undelete thing, but launchpad won't divulge further information to me | 02:02 |
| Pegasus_RPG | RenatoSilva: sorry for interrupting | 02:02 |
| mzz | Pegasus_RPG: lp:bzr-undelete, not sure if it's useful or works. | 02:03 |
| Pegasus_RPG | ok bzr log found it thanks! | 02:05 |
| Pegasus_RPG | oop, now I need to get that file without messing up my existing checkout | 02:09 |
| Pegasus_RPG | do I just bzr cat it to a new file? | 02:10 |
| Pegasus_RPG | or can I preserve the history some other way? | 02:10 |
| mzz | I don't remember if "bzr revert -rblah old/rev/filename" works, but I'd expect it to. | 02:11 |
| mzz | "bzr help revert" says it should work. | 02:11 |
| Pegasus_RPG | sweet it did. thanks! | 02:13 |
| RenatoSilva | Pegasus_RPG: you did not | 02:16 |
| RenatoSilva | Pegasus_RPG: interrupt | 02:16 |
| * RenatoSilva 'll brb | 02:19 | |
| RenatoSilva | how to apply a single patch? it's being rejected... | 04:25 |
| * RenatoSilva used raw patch tool | 04:26 | |
| RenatoSilva | Created new stacked branch referring to /~verterok/bzr-xmloutput/trunk. | 04:39 |
| RenatoSilva | what's this? | 04:39 |
| AfC | Wow. bzr 1.16 feels a lot ... slower. So I tried Robert's strace trick, and saw Bazaar spending ~0.3s trying to unlink .pyc files. | 04:54 |
| AfC | Yeah. time bzr-1.15.1 status = 0.19s. time bzr-1.16.1 status = 0.89s. Bloody hell. | 04:58 |
| spiv | D'oh, missed AfC. That's almost certainly an issue with stale .pyc files, which would be a packaging/installer bug. | 08:56 |
| Glenjamin | is there a seprate channel for bzr-svn issues? | 09:46 |
| Glenjamin | aha | 09:58 |
| Glenjamin | nailed the bug: | 09:58 |
| Glenjamin | request.auth is an empty dict if a URL redirects | 09:58 |
| Glenjamin | ok, reproducible as well | 10:06 |
| Glenjamin | bzr info http://glenjamin.co.uk/other/bzr/menudjen/ | 10:06 |
| Glenjamin | this redirects to a page which is protected by http auth, which then throws a keyerror | 10:07 |
| === mario_ is now known as pygi | ||
| === sdboyer_ is now known as sdboyer | ||
| Youssef | Hi GUYS!!!! | 16:38 |
| Youssef | i come to report a bug! | 16:38 |
| Peng_ | ...... | 16:43 |
| === eaumontab is now known as abeaumont | ||
| gioele | suppose I change a single byte in a text file with very long lines (100k bytes per line). Will bzr save a one-byte difference or will it save the whole line? | 18:07 |
| Peng_ | gioele: Unless you're using the development6-rich-root or 2a disk formats, with C extensions compiled, deltas will be line-based. | 18:09 |
| SamB | Peng: ... why doesn't the Python implementation do line-based deltas? | 18:12 |
| SamB | er. I mean, why does it? | 18:12 |
| Peng_ | SamB: Simplicity, I imagine, and maybe performance. | 18:24 |
| Peng_ | I'm pretty sure I'm right, but I'd kinda like to verify it. | 18:25 |
| SamB | I thought the Python code was supposed to always have the same results as the C code :-( | 18:26 |
| Peng_ | SamB: It is compatible, just not as small. | 18:28 |
| SamB | that seems like it could be a serious issue :-( | 18:29 |
| Peng_ | SamB: In what way? | 19:19 |
| === Noya_ is now known as Noya | ||
| RenatoSilva | bzrlib/transport/__init__.py lines 1535 - 1557 | 21:56 |
| RenatoSilva | could you help me to understand this code? I'm trying to fix a bug | 21:56 |
| thumper | abentley: I don't suppose you are working on a take-changes for pipelines ATM are you? | 22:00 |
| thumper | abentley: did you see my blog post about pipelines? wrote it last night | 22:00 |
| RenatoSilva | Is any xmoutput folk here? | 22:01 |
| LarstiQ | RenatoSilva: starting with the _urlRE regex? | 22:02 |
| thumper | grr | 22:05 |
| thumper | somehow bzr 1.16.1 package trumped the daily ppa build | 22:05 |
| RenatoSilva | LarstiQ: line 1569: base = base.encode('ascii') | 22:05 |
| thumper | now I have bzrtools requiring bzr 1.17 and an "old" bzr | 22:05 |
| RenatoSilva | LarstiQ: isn't it dangerous? | 22:05 |
| RenatoSilva | LarstiQ: that's the cause, when you use non-ascii paths thios code causes an error | 22:06 |
| LarstiQ | thumper: hmm | 22:07 |
| LarstiQ | thumper: can you list the version numbers involved? | 22:07 |
| LarstiQ | RenatoSilva: no | 22:07 |
| thumper | LarstiQ: for the currently installed bzr? | 22:07 |
| thumper | Version: 1.16.1-1~bazaar1~jaunty1 | 22:08 |
| LarstiQ | RenatoSilva: the interface for get_transport is that you pass it an URL | 22:08 |
| LarstiQ | RenatoSilva: URLs _must_ be in ascii. This is a check that no one is passing unicode when they shouldn't | 22:08 |
| RenatoSilva | LarstiQ: :param base: either a URL or a directory name. | 22:08 |
| LarstiQ | thumper: and the daily package? | 22:08 |
| RenatoSilva | LarstiQ: # Only local paths can be Unicode | 22:08 |
| RenatoSilva | LarstiQ: and it is | 22:08 |
| LarstiQ | RenatoSilva: right, then it tries convert_path_to_url | 22:09 |
| RenatoSilva | LarstiQ: humm, it is passing a local Unicode URL... | 22:09 |
| thumper | LarstiQ: 1.16+4508+117 I think | 22:09 |
| LarstiQ | thumper: ok, so I think the version on that is bogus then | 22:10 |
| thumper | james_w: you are the only one in the changelog | 22:11 |
| RenatoSilva | LarstiQ: xmloutput is... how can I convert the non-ascii chars? it is already an URL, so will urlutils.local_path_to_url() work? | 22:11 |
| thumper | james_w: is your script doing this? | 22:11 |
| thumper | I know nothing about deb version numbers | 22:11 |
| thumper | except for that they sometimes go screwy | 22:11 |
| * thumper runs bzr from trunk until the package gets worked out | 22:13 | |
| eggy_ | Hello, when I locally clone a bzr repository, it works, but when I do it over bzr+ssh I get 'bzr: ERROR: Not a branch: ...' | 22:13 |
| RenatoSilva | eggy_: wrong address? | 22:13 |
| eggy_ | RenatoSilva: hmm, maybe. Doesn't it start at my home directory? | 22:14 |
| RenatoSilva | eggy_: you're cloning from lp? | 22:14 |
| eggy_ | RenatoSilva: from lp? I dunno, I did 'bzr clone bzr+ssh://myhost/relative/path/from/home/directory/to/repo' | 22:15 |
| eggy_ | But I now see that if I prepend home/user it works | 22:15 |
| LarstiQ | RenatoSilva: urls should not have unicode. See bzrlib.urlutils | 22:16 |
| eggy_ | To the relative path that is | 22:16 |
| LarstiQ | thumper: I think it's johnf not james_w? | 22:16 |
| LarstiQ | eggy_: it's an absolute path | 22:16 |
| LarstiQ | eggy_: /~/ and you get relative to your home directory, however the sftp server interprets that | 22:17 |
| eggy_ | LarstiQ: ah, ok, thanks | 22:17 |
| fullermd | Not on bzr+ssh it won't... | 22:20 |
| RenatoSilva | LarstiQ: I't trying to use urllib.quote | 22:20 |
| LarstiQ | fullermd: ah, didn't pay attention enough... | 22:21 |
| RenatoSilva | LarstiQ: bzrlib.urlutils.escape? | 22:21 |
| LarstiQ | RenatoSilva: bzrlib.urlutils.normalize_url might be more appropriate | 22:22 |
| RenatoSilva | LarstiQ: ok | 22:26 |
| mwhudson | jelmer: hi | 22:56 |
| mwhudson | bzr merge $svn-branch -r revid:revid-not-in-branch stack traces | 22:57 |
| mwhudson | jelmer: is this a known bug? | 22:57 |
| jelmer | mwhudson: depends on the stack trace :-) | 22:59 |
| mwhudson | jelmer: it's not very exciting, it shouldn't be an internal error i think | 23:04 |
| mwhudson | http://pastebin.ubuntu.com/210699/ | 23:04 |
| mwhudson | jelmer: ^ | 23:04 |
| mwhudson | (maybe it's a bzr bug) | 23:04 |
| mwhudson | jelmer: slightly clueless report of the same problem: https://bugs.edge.launchpad.net/bzr-svn/+bug/395906 | 23:08 |
| ubottu | Ubuntu bug 395906 in bzr-svn "bzr merge crashes on erroneous command line args: NoSuchRevision exception" [Undecided,New] | 23:08 |
| mwhudson | :) | 23:08 |
| jelmer | mwhudson: yeah, that's a bzr bug. it should be handling NoSuchRevision | 23:23 |
| mwhudson | jelmer: ok | 23:24 |
| lifeless | mmm | 23:25 |
| lifeless | npt sure I agree | 23:25 |
| lifeless | an error in fetch is fatal and bad | 23:26 |
| jelmer | lifeless: wrt the bug I mentioned? | 23:26 |
| jelmer | lifeless: "bzr merge -rrevid:foo" blows up in the same way | 23:26 |
| jelmer | lifeless: without bzr-svn involved anywhere | 23:26 |
| lifeless | yeah | 23:27 |
| lifeless | perhaps the revid: revspec should do validatio | 23:27 |
| lifeless | n | 23:27 |
| jelmer | yeah, that'd make sense. it would mean we didn't have to handle NoSuchRevision in various cmd_* classes in bzrlib.builtins | 23:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!