[03:47] * SamB_MacG5 thinks the fact that bzr-svn and bzr-builddeb conspire to be compatible with svn-buildpackage should be advertized better ... [03:51] SamB_MacG5: you're hitting issues with it? [04:00] jelmer: issue was that I had no clue that it was supposed to work in the first place [04:00] ... except for a suspiciously named branch of bzr-svn ... === ReekenX|AFK is now known as ReekenX [04:32] * SamB_MacG5 posts http://naesten.blogspot.com/2012/11/on-bzr-svn-and-svn-buildpackage.html about it === 18VAACLAG is now known as wallyworld === wallyworld is now known as Guest12715 === spm` is now known as spm === yofel_ is now known as yofel [07:54] Good day. I've been trying to pull a large source via bzr 2.5.1 for about 20 hours, with various timeouts. I've just tried pulling what ought be an identical source tree from loggerhead tarball export in about 3 minutes. Is there any debug data I could produce that would generate a useful bug for this? [07:59] (or would this not be a bug because of the extra volume of history also being downloaded?) [08:02] could try pasting the bzr log [08:02] .bzr.log [08:11] Thanks for the pointer: it appears that I received ConnectionReset messages which would indicate a local issue. [08:11] what transport were you using? [08:11] or accessing the source from, sftp? bzr+ssh? ftp? [08:11] bzr+ssh [08:12] Command line was `bzr branch lp:launchpad` [08:13] did you login to launchpad? [08:13] you get throttled speed if you arn't logged in [08:13] How does one log in? [08:14] bzr lp-login i think [08:14] Would having launchpad_username set in .bazaar/bazaar.conf be sufficient? LP has my SSH key. [08:14] i think that means you are logged in [08:14] Or does it need to be done each session? [08:14] just once i think [08:14] mgrandi: you don't get throttled [08:14] In that case, I'm logged in. [08:14] mgrandi: you just g=don't get ssh [08:15] I thought login just changed transport from http to bzr+ssh [08:16] it does [08:16] ive heard the speeds are slower if you are not logged in [08:16] http has no smart server attached to ut [08:16] Probably because of traffic shaping and http buffers along the way [08:16] so its slower, but its not throttled [08:16] its because you're checking out over a VFS [08:19] ah [09:09] morning! === mmrazik is now known as mmrazik|lunch === mmrazik|lunch is now known as mmrazik|afk [13:17] I just filed LP#1075548 and am here for back-questions [13:17] in case someone has them [13:48] * jelmer waves to mira|AO, Noldorin, mgz [13:48] hey jelmer! [13:48] hi jelmer [13:49] mira|AO: I've reassigned the bug to bzr-svn, but I'm not sure if there is anybody actively looking at those bugs [13:50] also, expansion of %2F is dodgy [13:51] ok [13:52] maybe just an svn server configuration issue? [13:52] mgz, the %C3 also gets expanded (and then repr'd as \xc3) [13:52] I don't think so… the file is in a sub-sub-sub…directory of something I moved, and its name exists (with %) in both bzr and svn before [13:53] and I’m not the only one seeing such errors [13:53] right, expanding the non-ascii is find (and bzr seems to do it correctly) [13:53] *fine [13:53] no, it's not fine [13:53] the file literally has these percent signs in it [13:54] ...oh, wow [13:54] -rw-r--r-- 1 tglase Administrators 1502 Dec 9 2011 upstream/src/plugins/wiki/www/locale/fr/pgsrc/Aide%2FPluginCr%C3%A9erUnePage [13:54] yeah. [13:54] okay, that should get handled properly. [13:54] it's perverse but hey. [13:54] (it's french) [13:54] * mira|AO hides [13:54] french doesn't use percent escapes! [13:55] right [13:55] though I'd like to hear them pronounce that... [13:55] you don't… [13:55] I suffer when we do IRL meetings each time [13:55] I guess an issue could be that bzr-svn is unescaping filenames one time too many.. [13:55] probably [13:55] can I attach an interactive python or ipython to it and 'live-debug'? [13:56] IIRC there was something [13:56] mira|AO: you can set BZR_PDB=1 [13:56] ah, that was it [13:56] also possibly to blame is url/file guessing code [13:57] mgz: that shouldn't be relevant here, that only happens when opening transports AFAIK [14:07] it might only be triggered when there's non-ascii chars with percents in it [14:07] so that the one-decode-too-much is cushioned by a one-encode-too-much somewhere [14:08] which doesn't hit the \xc3 [14:09] mismatched decode and encode would do it too probably [14:13] (Pdb) print self._override_file_ids[u'.not-evolvis/wiki/fr/Cr%C3%A9erUnePage'] [14:13] 10242@9d84d37e-dcb1-4aad-b103-6f3d92f53bf6:trunk%2Fsrc%2Fplugins%2Fwiki%2Fwww%2Flocale%2Ffr%2Fpgsrc%2FCr%25C3%25A9erUnePage [14:13] this is interesting [14:13] because the key is _not_ the real filesystem path [14:14] tglase@tglase-nb:~/Evolvis/tarent-5.1 $ l .not-evolvis/wiki/www/locale/fr/pgsrc/Aide%2FPluginCr%C3%A9erUnePage [14:14] that one is the renamed-to name [14:14] pdb is... not too easy to use [14:20] ah wait [14:20] according to debug output, it seems to move the file along all directories [14:20] first up, then down in the new subtree [14:23] (Pdb) print editor [14:23] <_ra.Editor object at 0x2213b88> [14:23] where's the source for that? [14:23] can't find it in usr/share/... [14:24] mira|laptop: it comes from the subvertpy sourcecode, written in C [14:25] ah ok [14:33] ok, in dir_editor_send_changes() in commit.py it's still correct... [14:35] so it may be a _ra.DirEditor object, which I assume is also in C [14:35] urgh [14:36] sorry, this is beyond what I can do during worktime [14:37] anyway, in (for me) line 309 of commit.py ('changed = True'), the values of url_join_unescaped_path(base_url,base_tree.id2path(child_ie.file_id).encode("utf-8")) and full_new_child_path are correct (the '# copy if they existed at different location' elif branch) === mmrazik|afk is now known as mmrazik === mmrazik is now known as mmrazik|otp [15:56] jelmer: o/ [15:57] vila: \o === mmrazik|otp is now known as mmrazik [17:17] vila, jelmer: So sorry to see you've each lost an arm... [17:17] lucky us it's not the same ! [17:18] Yeah, we can graft your stumps together and still get something with an arm on each side. === deryck is now known as deryck[lunch] [17:59] vila: So, did the updated script/desc simplify anything in that bug, or just make it worse? [17:59] fullermd: haven't found the time to look at it :-/ (yet) [18:01] Oh, sure, a likely excuse. I know you're just making up other things to do, to get out of having to go insane watching log shift around and laugh at you. [18:01] fullermd: truth is, diving into log is... scary, so I procrastinate ;) [18:01] You gotta get some minions. Then you don't have to procrastinate, you just delegate. [18:02] nah, I think I prefer to procrastinate ;) [18:03] Is it a reasonable guess on my part that "log DIR" looks a lot like "log -v FILE" inside, that explaining the confluence of the two in showing the bug? [18:03] but so far, I just toyed with your script, next step is to turn it into a test to get access to all the needed internals/tools to better diagnose [18:03] inside ? [18:04] you mean in the log output ? [18:04] In the internals of how it chooses stuff. [18:04] Since "log DIR" shows the bug with/without -v, while "log FILE" only does it with -v (though the behavior without -v on FILE seems a little off too; that's another matter) [18:05] well, not sure from memory, but log -v is really different from the rest as it looks at the existing text revs [18:05] you may be triggering several bugs too [18:05] * fullermd flexes his bug-triggering muscles. [18:05] fullermd: you mean 'starts typing' ? ;) [18:06] Hey, I can't deny my inborn gifts! The gods want me to break software; who am I to demur? [18:06] indeed === carif1 is now known as carif-1-1 [20:55] [23:55] bzr does not really give good errors when ssh stuff goes wrong >.> [23:58] dunno if this is bzrs fault or paramiko [23:59] Well, most *nix places, paramiko won't be involved anyway. It's more "spawning ssh", which really limits what you can say about the results. [23:59] well was trying to dpush somewhere