[00:01] jam: It's a LP bug. It's failed to publish a build-dep on lpia [00:03] nooo, new bzr-git failure on hardy === zyga is now known as zyga-afk === Meths_ is now known as Meths [03:50] How can I merge changes HEAD-2 and HEAD-3 in the history? === Ursinha is now known as Ursinha-afk [07:02] hi. if i use --hardlink but then edit a file ... how can i make sure my editor breaks the hardlink? [07:03] depends on the editor [07:03] i see. can nano do it? can a file system configured to do it, in general ? [07:03] no [07:03] to (b) [07:04] dunno if nano can/does by default [07:37] there is an ldpreload hack to break them [07:50] lifeless: FL-COW? [07:53] Urp. Bookmarks is broken with .dev :( === zyga-afk is now known as zyga === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [12:39] hi. i have a weird problem which only happens when i use vc-bzr in emacs, but maybe someone here can help me anyways? [12:40] when i do "C-x v =" on a file in emacs (bzr diff equivalent) i get: bzr: ERROR: [Error 2] The system cannot find the file specified [12:40] however, when i do "bzr diff that/file.el" in cmd.exe it works just fine [12:41] any ideas? [12:44] can you find out what actual filename emacs is using? [12:44] i.e. is it just trying to do `bzr diff file.el` [12:45] i've tried to look in the source code, reluctant to modify it, but what the hell, what's the worst thing that can happen... let me check [12:46] well, if it logs someplace or something... [12:46] it doesn't [12:46] * Tak not familiar with emacs nor vc-bzr [12:52] i noticed just now that if the file has no changes, everything works as expected saying "no changes found" or similar [12:52] so it's something that happens when it determines that there are changes [13:01] okay, i think i've found the problem and it must be on emacs's side [13:01] "Running bzr diff --diff-options -c vc-bzr.el in background... done" [13:01] i don't think the working directory is correct [13:01] therefore it can't find vc-bzr.el [13:06] actually, i guess that's not the problem, since it works right when there are no changes [13:17] okay, running the same command that emacs uses in cmd.exe gives me the same error abut a file not being found [13:17] i'm guessing that this file is "diff" === Ursinha is now known as Ursinha-lunch === tchan1 is now known as tchan [14:09] damd: sounds pretty weird [14:09] damd: --diff-options without options for a given diff is suspicious [14:10] vila: i wrote a patch for vc-bzr-diff which takes care of it [14:10] damd: bzr has an internal diff, so I suspect having --diff-options triggers using an external 'diff' which it doesn't find [14:10] exactly [14:10] ha good [14:10] damd: the fact that you're using windows may make the bug more obvious too [14:10] i would have pushed the patch immediately if i had the time/ability to test it properly [14:11] damd: are you running emacs from source or from a official release ? [14:11] from weekly windows builds [14:11] I see [14:12] * vila should really switch to vc and stop using dvc if only for test purposes [14:12] vc is really nice when you get the hang of it [14:12] I haven't use it for years [14:15] why do all things emacs have so ugly logos? [14:16] the emacs logo itself, the gnu logo, and now the DVC logo, christ that's bad [14:16] http://download.gna.org/dvc/dvc.png [14:18] aw, come on there are not that bad :) [14:18] the DVC logo is probably one of the worst logo's i've seen :| [14:18] actually the dvc is a nice variation of the emacs one (when you like the later ;) [14:18] they've literally _forced_ it to look like it says DVC on that gnu head [14:19] actually, that's what they did with the emacs logo as well... forced it to look like a gnu and now it looks like neither a gnu nor emacs [14:19] well, the oldest logo I can remember for emacs was a kitchen sink :) [14:19] yeah, i've seen that, but at least that wasn't official :P [14:20] hmm, as official as it can be as this time: http://www.emacswiki.org/emacs/EmacsIcons [14:22] I think even Lucid Emacs was using the kitchen sink icon, at least I was using lucid in these times so that's probably where I remember the icon from [14:23] i thought only some "funny" distros shipped emacs with that icon [14:23] this is the emacs icon that is the default in windows: http://www.emacswiki.org/pics/static/CarbonEmacsPackageIcon.png [14:25] yeah, this one has been around for ehat... ~ 10 years ? [14:25] ha no, the pencil was added at some point [14:25] no idea, i only started using emacs about five years ago [14:25] honestly, if i were to create an emacs logo, i wouldn't know where to start, but i _would_ know where to _not_ start and that is with the current gnu thing [14:26] hehe [14:26] enough senseless ranting for now! [14:27] mwahaha, best wallpaper ever : http://i.imgur.com/RxlwP.png [14:28] see, even the wallpapers are ugly :( [14:28] lol [14:28] scratch this itch ! [14:28] yeah [14:30] http://paste.ubuntu.com/558550/ <- that's a lot of PointlesslyBreakThings lines. [14:31] do I need to add a tests for all of the ones that get fixed, or just trust people not to write broken code in future... [14:32] mgz: hellllo ! [14:33] hey vila! [14:33] mgz: what's the context ? [14:33] bug 707954 [14:33] Launchpad bug 707954 in Bazaar "bzr mv cause ERROR: exceptions.UnicodeEncodeError" [Low,In progress] https://launchpad.net/bugs/707954 === Ursinha-lunch is now known as Ursinha [14:33] str(xx) considered harmless ? [14:33] harmful I meant [14:34] http://paste.ubuntu.com/558552/ <- example test. [14:34] str(any_path) is harmful, yup. bzr uses unicode for paths. [14:34] ha ! yeah, so my last memories was running away crying from the rename exceptions [14:35] adding tests to ensure we cover all code paths there will be ideal [14:36] second to that would be to get rid of the str() harmful calls, but finding them and fixing them without tests may be tricky [14:37] so to come back to your initial question, if you can add a test for every call your fix: perfect [14:37] trying to avoid future errors... no idea on how to do that (the tests should be a good defense anyhow) [14:37] I'm guessing not to blackbox though. [14:38] depends which layer you want to test [14:39] well, ideally lower if I'm covering all those. [14:41] yup, my memory tells me the relevant code is indeed lower [14:41] it's WorkingTree.move ._determine_mv_mode .rename_one [14:41] have a look at the related exceptions too, that's where I started crying [14:42] yeah, they're a bit of a mess. [14:42] at one point I got lost because exceptions were raised when trying to format an exception [14:42] as is the general code for displaying errors about paths, eg bug 388437 [14:42] Launchpad bug 388437 in Bazaar "notbrancherror doesn't show non-ascii paths correctly" [Medium,In progress] https://launchpad.net/bugs/388437 [14:43] related to that, [14:43] ^I need to fix some of this in another branch anyway [14:43] the unicode exceptions have an attribute with the faulty string but it's not displayed by default [14:43] yeah, that'll be worth doing on top. [14:44] I was wondering if we could catch them in the bzr script (or wherever the exceptions are caught).. you see the point [14:44] yup. [14:44] I'm still awfully jet lagged so you type too fast for me ;) [14:44] so... where are WorkingTree methods tested? [14:45] did you see the bash_completion failures on windows ? [14:45] per_tree ? [14:45] bt.per_tree, bt.per_workingtree [14:45] ah, yeah. [14:45] or may be these ones aren't :-/ [14:46] I'd so love to add a 'raise' somewhere that would make all the relevant tests fail... [14:46] ^nope. [14:46] -s bp.bash_completion -> 4 failures [14:47] can you reproduce that ? [14:47] it's not really worth testing at all on windows though, and I thought wasn't. [14:47] "Missing feature 'bash executable' skipped 12 tests." [14:47] so, unlikely to get them. [14:48] well, I thought that too, but babune was happy with them before... [14:48] hmm [14:48] jam: around ? [14:48] testing a cygwin bash under the windows python isn't very worthwhile. [14:48] hi vila [14:48] jam: hello ! [14:49] I'm currently on windows, but I ran the test and it gave "missing bash executable" [14:49] can you run -s bp.bash_completion in your windows setup... damn [14:49] I'll try and check into it a bit [14:49] I run the win32 python under cygwin [14:49] so I would have thought path would be correct [14:51] rats, babune has no log about the features and skipped tests :( [14:52] 2.7 logs skips sensibly now, but the win slave is on 2.6 right? [14:54] strange [14:54] running python manually, I see cygwin in the path [14:54] and running "p = subprocess.Popen('bash -c "echo hello"', shell=True)" works [14:55] ah, it's the probe [14:55] it specifically probes for the exact name "bash" in the path [14:56] so it won't find "bash.exe" [14:56] haaaa ! doxxx fix ! [14:56] so why is it finding it for vila [14:56] in its mergetools proposal gordon tweaked osutils.find_executable_on_path, with weird bits for windows I didn't fully understand [14:57] so my guess is that it makes it find exes that weren't found previously [14:58] using a trick that is *not* used when calling the exe, so the probe succeeds now (it was failing before) and the tests now failed (they were skipped before) [14:58] vila: yep [14:58] vila: well, I wouldn't be surprised if the tests fail because it isn't compatible [14:58] which means babune reports skipped tests as successful ones... :-/ [14:58] more than just because it can't find it [14:58] true [14:58] vila: right, the code in test_bashcomp.py looks to be using the exact path to 'bash' [14:59] and not using shell=True [14:59] hmm, not using shell=True is harmless on unices ? [15:00] * vila never uses shell=True [15:03] hm, I don't know how to hit some of these branches. [15:06] mgz: scary ;) [15:10] ...the test just above where I'm adding these looks totally bogus too [15:10] self.assertRaises((errors.InvalidNormalization, UnicodeEncodeError), [15:10] tree.rename_one, 'a', u'ba\u030arry') [15:11] what the hell kind of check is that? it will *always* be raising the second exception, which If A Real User Did It, would print a big ugly traceback. [15:11] Do the latest versions of bzr-svn support any form of setting SVN properties (specifically, svn:eol-style and svn:mime-type)? [15:11] mgz: this makes sense [15:11] mgz: that's what the bug you're fixing is about [15:12] wash: No, there is no way to explcitly edit user svn properties through bzr-svn [15:12] mgz: except that we now know that it's a bug and not an expected behavior [15:14] maxb: *nods* Thanks [15:17] mgz: check the annotate on that file. I probably wrote that code about 3-4 years ago [15:18] back when I was working on supporting normalization inside bzr [15:18] I know it pre-dated dirstate [15:18] which was what, 0.15 ? [15:18] yeah, it's old, and I'm not even sure why the UnicodeEncodeError is checked for from the history [15:18] jam: are you sure it hasn't been modified when the rename exceptions have been introduced ? [15:19] possibly for when unicode paths aren't supported at all? it's unclear. [15:19] my gut feeling is that UnicodeEncodeError has been added at this point in time [15:19] vila: could have been. I wouldn't be surprised if the test was saying "must raise InvalidNormalization" and someone decided to be lazy and have it raize Unicode [15:19] mgz: you may want to check the InvalidNormalization one [15:19] jam: yup, that's my feeling [15:20] mgz: also note, I personally have stopped trying to fight that fight since getting normalization during status is pretty difficult to make it perform well [15:21] and I ran into people on Windows not having normalized filenames [15:21] because Japanese windows wanted to use all wide characters in the filename [15:21] NF(K)* is pretty deadly, but that's the K. [15:22] messes up kana as well as ＦＵＬＬＷＩＤＴＨ characters [15:22] wow, nicely displayed here :) [15:22] something still needs to be sorted jam, because macs seem stuck in limbo wrt unicode at the moment in bzr [15:23] NFK* is evil madness [15:23] mgz: Oh the system is pretty hosed at the moment. NFC is better than NFK, (AIUI) though I didn't know it back in the day [15:24] however, *I personally* have stopped trying to fight for it. I'd be happy to review stuff [15:24] i have a bzr question for anyone who can help [15:24] leonardr, no one can at the moment as you haven't asked your question ;) [15:25] cody: ah, that's the problem. i never asked my question [15:25] i'll explain it in abstract terms but here's the merge proposal of the branch: https://code.launchpad.net/~leonardr/lazr.restful/encode-xhtml-field/+merge/47536 [15:26] leonardr: I believe the standard line is: "Just ask the question, don't ask to ask", but honestly it is pretty ingrained in us that a polite interruption is the rigth thing to do... [15:26] i do not want to get side tracked on this discussion, but to set the record straight, my first utterance was an introduction and i immediately proceeded to start writing the question [15:26] I suppose in IRC you want short communication because everyone has to type? Not sure why that became standard [15:27] the last release of this package was at revision 164 [15:27] we're now at revision 166, and i need to do a point release based on revision 164 [15:28] i can just do a release off my branch [15:28] but i'd like to merge it in to the mainline so that it will be easy to find later [15:29] That all sounds correct.... where's the question? :-) [15:29] my current plan is to revert to revision 164, commit, merge my branch, commit, do the point release, and then re-merge the code from revisions 155 and 156 [15:29] is there a better way, or is that it? [15:29] eek [15:29] leonardr: reverting is probably not what you want [15:29] just branch from -r 164 [15:29] leonardr: just create a branch at... [15:30] lp:~leonardr/lazr.restful/encode-xhtml-field is a branch from -r 164 [15:30] leonardr: -r 164, do your release stuff (including commitS) [15:30] leonardr: then merge your point release on top of your trunk resolving conflicts [15:31] leonardr: this will reflect the exact history of what you did, pretty clean IMHO [15:31] vila: my problem with that is that there will be no revision in trunk that corresponds to the release [15:31] There will be no *mainline* revision in trunk which corresponds to the release [15:31] leonardr: it will and you can tag it [15:32] vila: ok, what do i tag? [15:32] leonardr: the tip in your release branch *before* merging it to trunk [15:32] vila: thanks, that was the missing piece [15:33] leonardr: if you look at bzr history, you'll see that the tags are never on the mainline, always on a dotted revno [15:33] .... in a PQM-managed project, which this is not [15:33] maxb: right, but this shouldn't be a problem either [15:34] Not a problem, but it does make the statement that tags are never on mainline not applicable here [15:34] ho ! [15:34] right, my remark applied to bzr history *ONLY* [15:34] maxb, vila: well *some* tags are on the mainline, for people like me that didn't like having to pre-tag before sending it to pqm, but we changed away from that because it was a real PITA to maintain. :) [15:34] Ah, the bzr history of bzr [15:35] maxb: ouch, right, I missed the ambiguity there :-/ [15:35] leonardr: So, is this making sense? :-) [15:35] maxb: not at all :) [15:35] but yes, leonardr, I would tag your release branch, and then merge it, and not try to tag the trunk mainline [15:35] ok, i'll do that and let you know how it goes [15:35] jam: as can be seen in bzr-0.{7,8,11,13,14,15,16,17,18,90} ? :-D [15:36] vila: did you just run bzr log to find that ? [15:36] bzr tags [15:36] or 'bzr tags' [15:37] vila: some of those are "?" tags [15:37] all of them [15:37] so those were before we merged release branches back into trunk [15:37] but I still wanted to track them once we finally got tags [15:38] vila: actually, only bzr-0.0.5 is a mainline revno. [15:38] I think I did the work to have the tag on the release branch mainline [15:38] yup, and plan0merge-dev >_< [15:39] vs my local branch that got merged into the release branch, which was then eventually merged on the mainline [15:39] vila: I don't have plan0merge-dev tag [15:39] so that must have been one of yours [15:39] plan-merge-dev [15:39] I do have "plan-merge-dev" and "plan-merge-ab" [15:39] leonardr: short version: bzr branch -r 164 lp:lazr.restful lazr.restful-0.15.x; cd lazr.restful-0.15.x; bzr merge lp:~leonardr/lazr.restful/encode-xhtml-field; bzr commit; ; cd ....../branch-or-checkout-of-trunk; bzr merge ....../lazr-restful-0.15.x; bzr commit; bzr push [15:40] vila: interesting that plan-merge-dev is a (vila) commit [15:40] :) [15:40] I don't think so [15:40] maxb: ok, i'll let you know if i get unexpected results, but if the bzr tag works it should be fine [15:41] jam: it's from pqm and plan-merge-ab from aaron [15:41] leonardr: One specific point to note - to ensure trunk's history is not confusing, it's important to merge the release branch into trunk, and not vice versa [15:42] jam: both from 200712 [15:42] vila: it *is* a pqm revision, but it was a (vila) requested one :) I honestly don't know what the idea is [15:42] maxb: sure. that's what i do usually, so it's no problem [15:42] nor do I *really* care [15:42] (except it's usually not a release branch) [15:42] though it would be nice to be able to prune/hide tags [15:42] 100 tags is getting a bit big, the 1000s of tags in an emacs branch is pretty overwhelming [15:43] hrm. bzr help does not tell you what the options are for tags --sort=??? [15:44] jam: weird... I never used tags until being RM... [15:44] maxb: probably a bug in the help system. If you don't specify that an option can be supplied without the prefix, then it doesn't document the values [15:44] Hey, I'm getting a really odd Bazaar error: "ValueError: could not convert string to float: /bfa.ko" [15:44] vila: "bzr.dev" is now properly failing the bash_completion tests [15:45] Any clue on how to get back to a running state from that? [15:45] tedg: Do you have a traceback with that? [15:45] tedg: doesn't look like a float to me :) [15:45] can you give more of a traceback [15:45] Traceback (most recent call last): [15:45] File "/usr/bin/bzr", line 139, in [15:45] exit_val = bzrlib.commands.main() [15:45] File "/usr/lib/pymodules/python2.7/bzrlib/commands.py", line 1203, in main [15:45] _register_builtin_commands() [15:45] File "/usr/lib/pymodules/python2.7/bzrlib/commands.py", line 182, in _register_builtin_commands [15:45] import bzrlib.builtins [15:45] Not much... [15:45] !paste [15:45] For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. [15:46] bug 708063 [15:46] Launchpad bug 708063 in bzr (Ubuntu) "bzr crashed with ValueError in _register_builtin_commands(): could not convert string to float: /bfa.ko" [Undecided,New] https://launchpad.net/bugs/708063 [15:47] tedg: ouch, sounds like a .pyc corruption no ? [15:47] tedg: does 'bzr version' works ? [15:47] tedg: or 'bzr info' [15:47] vila, No, neither of those work. [15:48] tedg: right, so your install is... damaged ? [15:48] vila, Which pyc should I delete? [15:48] I can just remove the package and reinstall? [15:48] tedg: well, yes [15:49] tedg: but you may have a deeper issue there, .pyc files don't get corrupted randomly on well-behave machines ;) [15:50] tedg: python-2.7 on lucid ?? [15:51] vila, Yeah, it's odd. But none the less, it works after the reinstall. [15:51] tedg, No on Natty [15:51] vila, ^ :) [15:51] tedg: so InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429) is misleading ? [15:52] vila, It's correct. That is what I used to install, then I upgraded. [15:52] bah, of course, DistroRelease: Ubuntu 11.04 is the one I should have looked at [15:52] tedg: anyway, good to know you're out of trouble [15:52] I'll mark this bug invalid [15:52] Yes, thank you vila. I already marked it so. [15:53] tedg: you rock, lp-cant-refresh sucks ;) [15:53] vila, It's not really a LP specific problem. The web in general sucks :) [15:58] tedg: shooting the messenger :) [16:34] okay, get this baby reviewd time. [16:37] mgz: :) [16:37] jam: do you know a way to look at the pending jobs for the package importer ? [16:37] vila: define "look at" [16:38] http://package-import.ubuntu.com/status/ tells you what is pending [16:38] and what is currently running, etc. [16:38] it currently says 0 but tail -f progress_log shows it keeps adding some [16:39] so I guess my question is: what's the difference between outstanding jobs and pending jobs [16:39] vila: when the package importer doesn't have explicit packages to import, it then spins checking random packages for consistency [16:39] ha, I haven't seen that code yet then [16:40] so "Outstanding" means it has seen new .deb files that need to be imported [16:40] I'm working on mass_import.py [16:40] otherwise it is just poking around doing sanity checks [16:40] right, and it never stops doing that [16:41] so I think I will stop poking at this code and start looking at testing it before deploying... [16:46] hm, have a feeling there was something else I was going to say in the mp but can't remember it. [16:46] vila: your mail host is blocking emails from me [16:47] vila: Remote host said: 550 Too many spams from your IP (98.139.52.70), please visit http://postmaster.free.fr/ [RCPT_TO] [16:47] and the page they link me to is in French, so I really don't know what to do [16:47] (well, click the English button...) [16:47] to put their spam filters were the sun doesn't shine ? [16:48] it looks like they are blocking all email from some of the mail.*.yahoo.com servers [16:48] at least, the IP they give resolves to: nm6-vm0.bullet.mail.ac4.yahoo.com [16:49] which is a bit hard for me to workaround. [16:49] I can send mail directly from my IP, but that is usually blacklisted because it is a comcast account [16:49] (or whatever the rules are. It is a "home" account, which is often blanket blocked) [16:54] heh :-/ So apparently bzr-git/hardy has *never* worked [16:54] * maxb wonders whether it's still worth doing hardy in ~bzr PPAs [16:54] jam: try using my canonical address ? === leonardr is now known as leonardr-afk [16:56] maxb: I believe hardy is still in its support window [16:56] Yes, but that's not *quite* the same question :-) [16:57] vila: I'm just resending to make sure it works, but it was a note about the bash completion failures from sometime last night [16:57] oh, just a moment [16:58] Did hardy default to apt installing recommends? [16:58] maxb: that's not the highest priority, if people are happy with hardy (instead of lucid), they are probably happy with whatever bzr version they have [16:58] jelmer needs more imaginative branch names. [17:00] he's submitted like, five different things called lazy something this month. [17:05] vila: I'm going to have to put up a 2.3 branch that just messes with imports as I've not had time to work on the transport hook and 2.3 is past beta [17:07] mgz: for your Unicode changes, isn't it just moving when the error occurs? I thought the exception formatter still treats everything via str() [17:08] I cheated. [17:09] in this case, it gets safely upcast to unicode, then BzrError.__str__ encodes it to utf-8 [17:09] I've got some other work that makes unicode things happen sensibly all the way down to bzrlib.trace [17:12] so, mojibake not UnicodeError [17:12] I'll add a note about this to the mp. [17:12] well, its an improvement [17:18] does bzr have a native grep function? [17:18] (preferably in the CLI) [17:18] catphish: there is a 'bzr-grep' plugin [17:19] mgz: meh, why don't you just target 2.4 ? [17:19] jam: thanks, hopefully that'll do what i want :) [17:19] because I left a horrible hack in the code! [17:21] mgz: with my blessing, send any complaint my way :) [17:25] hm, doesn't look like too many hits. [17:28] mgz: you're referring to transport hook hack right ? [17:30] right. === mnepton is now known as mneptok [17:39] mgz: so nothing worth backporting to 2.3, target 2.4 :) [17:40] I'll put a mp up with some import changes and we'll see. [17:41] ...I actually intended that last mp to go to 2.3 as well, given it didn't change any interfaces, but perhaps 2.4 is safer. === bigjools-afk is now known as bigjools [17:43] mgz: yup [17:44] EODing, bye all [17:44] bye! [18:12] What is the name of the format defining the :param foo: constructs in bzr docstrings? === Meths_ is now known as Meths [18:23] maxb: epydoc restful ? [18:23] thanks === leonardr-afk is now known as leonardr [19:13] * jelmer waves [19:14] hi jelmer [19:14] are you at LCA? [19:14] hi james [19:14] no, I'm in Seattle [19:15] ah yeah [19:30] jelmer: Hi. I've now discovered that bzr-git has in fact never ever been compatible with hardy's ancient python-tdb. I'm thinking of uploading a bzr-git/hardy to the ~bzr PPA with the Recommends: python-tdb dropped, and the default cache format hardcoded to sqlite even if python-tdb is installed. [19:32] maxb: sounds reasonable [19:33] maxb: I wonder how useful it would be to have bzr-git on hardy if it's never been packaged for hardy though [19:33] great. This bzr-git/dulwich update has been an epic :-/ [19:34] maxb: is it really an update? have we ever hard bzr-git/dulwich available for hardy? [19:34] Well, we had previous versions in the PPA for hardy [19:47] maxb, jelmer: Note that until fairly recently we still had production machines in LP on Hardy. However, they've all been transitioned to lucid, AFAIK [19:48] I think LP itself went to lucid nov/dec last year [19:48] and there was much rejoicing :-) [19:48] In Sept, there was "Don't use 2.6-isms because we are still running hardy" [19:48] Oct 13th was the transition, it looks like [19:49] anyway, that makes supporting Hardy much less interesting from at least Launchpad's standpoint [19:50] maxb: that function in dulwich was never unit tested earlier [19:51] maxb: (and bzr-git does its own patching of urlparse) [19:52] mgz: do you need me to submit your non_ascii patch? [19:53] jam: I can do it. you have any opinion on whether it should have NEWS? [19:53] it should have news [19:53] I don't know that it merits whatsne [19:53] whatsnew [19:54] will do that and push. [19:54] Possibly, since it is a user-visible change, but definitely NEWS [19:54] mgz: for your get_transport() change, this is all mechanical, right? You are just changing "from bzrlib.transport import get_transport" to "from bzrlib import transport" [19:55] it is. [19:55] diff in email is a little wrong because I suck, but I repushed the branch with a less screwed up first revision [19:57] mgz: that one looks fine to me as well [20:15] pushed the first one. I'll let vila look at the other in the morning if he likes before pushing. [20:38] I am interested in getting https://bugs.launchpad.net/bzr-gtk/+bug/707482 fixed. Is anyone minding bzr-gtk about [20:39] hi mgz, sinzui [20:40] sinzui, it seems like you're most of the way there [20:40] I can make this fix if someone agrees I am on the right path [20:40] * poolie looks [20:41] so which value is wrong? [20:42] i guess line_no? [20:42] poolie: ganonnate's line_no and revno I think. UI is pretty simple, so changing the column types to int is probably right. Since gtktreeview reuses columns for layout when making a tree, casting to str() may be required [20:42] hi poolie [20:43] sinzui, it's strange it's not failing before [20:43] i wonder if maverick's pygtk automatically casts or something? [20:43] i didn't think it did that [20:44]