=== elmo_ is now known as Guest53104 [02:04] hi all [02:07] ola [02:16] lifeless, what new laptop disk did you buy? [02:17] poolie: the intel 320?300? GB one [02:18] '520 series' or something? [02:18] yeah [02:19] poolie: SSDSA2CW30 [02:19] k thanks [02:19] * poolie deletes stuff instead [02:20] http://www.betterit.com.au/scripts/prodview.asp?idproduct=265748 === poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jelmer [06:31] vila, hi? [07:08] hi all ! [08:26] jelmer, wgz, hi? [08:27] i might make mgz be pilot this week as it's mostly jelmer that needs reviews [08:38] i'll let you settle it [08:39] vila, maybe you could just send a note about the ppas and other releases [08:39] *srus [08:39] mm [08:42] hmm, yeah, our ppas need some love, maxb ? [09:00] hello mgz ! [09:00] morning all [12:02] jelmer: do you want to swap pp this week? [12:02] the alternative is we just do a morning or something reviewing your branches [12:31] mgz: I think that might be better [12:31] mgz: though I'd also be happy to swap this week if you prefer ? [12:32] nope, just swapping a morning seems fine to me [12:35] ok, let's do that then [13:30] oi, jelmer, vila, why am I talking in /query to both of you... [13:30] jelmer -> in here [13:30] mgz: ohai [13:31] I knew you were all talking about me behind my back :( [13:31] so, this is LANG=C with bzr-svn bascially? [13:32] fullermd: just look the other side :) [13:32] mgz: yeah [13:32] mgz: UnicodeFilenameFeature is present, but libsvn fails to actually encode non-ascii filenames [13:33] if there's an obvious worked-before and fails-now, might be best to just file a bug and subscribe me. [13:34] mgz: will do [13:34] for now, I'll just set LC_ALL=en_US.UTF8 while running the bzr-svn testsuite.. [13:35] the clearest issues will be with stuff that used to fail early, but now works till it tries outputting something [13:35] which is pretty easy to get around with paths, as can convert to urls [13:39] mgz: for the record, I looked a bit at the server tests failing on osx [13:39] the change where the failures started on babune is a red herring, if I try again with an older revision, it fails too [13:40] so either I changed some setup on the osx slave (can't imagine what) or I installed some os update which broke something (no help from google there either) [13:40] hm. [13:41] the code where it breaks has been introduced to support ipv6 years ago and seem to closely match the example in the python docs... [13:53] jelmer: aha, I understand from bug 920444 description [13:53] Launchpad bug 920444 in Bazaar "locale.getlocale() returns ascii locale even though UnicodeFilenameFeature is present" [High,Confirmed] https://launchpad.net/bugs/920444 [13:55] there bzr-svn tests relying on out process svn for things I take it [13:55] or... just bypassing python I guess is the point [13:55] changing the feature is the obvious way forward [14:05] mgz: it's all in the same process, but indeed bypassing python [14:06] I'm unsure if a different feature making the current one stricter would be best [14:07] without running the tests that need unicode filenames under LANG=C we then only rely on explict subprocess tests [14:08] hmm [14:08] but it's annoying for you to have to work out which tests need a full locale set on nix [14:08] mgz: these tests are multiplied [14:09] and possibly worse than that for parametrised tets [14:09] +s [14:09] mgz: against some implementations they need setlocale(), against others they don't [14:09] right. [14:10] well, it's not that they need setlocale so much as they need a unicode locale. [14:10] in-process libsvn as a locale set, it's just not one that can be used for non-ascii names. [14:10] (in this case) [14:11] out of process things potentially break if a unicode locale is given, but they don't call setlocale() [14:12] mgz: right, I mean they need a call to setlocale() to set it to a non-ascii encoding [14:13] but you can't go changing the locale as a library [14:17] jelmer: quick questions about udd: 1) can I upgrade jubany to builddeb trunk (jubany has revno 650, trunk has revno 708) 2) pristine-tar fix for suse bzip2 seems to be in 1.17 (or 1.16 but some later commits seem to be related so 1.17 seems safer) jubany currently uses 1.11ubuntu1~0.IS.8.04 what is needed ? === Guest53104 is now known as elmo [14:19] I get a "conflicting tags" error, and I'm trying to understand how to debug it. [14:19] jelmer: i.e. in an ideal world, I can update bzr-builddeb to trunk, someone in the know package pristine-tar 1.17 for lucid-cat and no additional package import failures are introduced :-D [14:22] mgz: right, but we can from the bzr script (which is also whats runs the testsuite) [14:22] mgz: another alternative is for subvertpy to override the locale before each libsvn call [14:23] mgz: though that might have too much overhead, I'm not sure [14:26] vila: I think upgrading pristine-tar i safe [14:28] I think so too, but who did packaged it for -cat ? [14:28] vila: I don't think it's packaged for -cat yet, I can do that [14:29] jelmer: we can ignore the user's configuration sure, but it's better to not do that, even for just the testsuite [14:29] we use 1.11.*IS.* on jubany but lucid package only 1.00 so I suspect someone packaged it in the past (imbw) [14:30] jelmer: and about bzr-builddeb ? Are there fallouts to be expected or is it safe to upgrade ? [14:30] jelmer: and that would be great if you package 1.17 for -cat ! [14:31] 1.17 is already in sid and wheezy, it's weird it's not in precise yet... [14:34] vila: I think it's safe to upgrade [14:34] vila: lamont did the backport last time, so I think getitng a new pristine-tar should just be a matter of filing an RT [14:34] jelmer: cool, I'll do that then [14:34] jelmer: exellent, I'll file one [14:48] rt filed === yofel_ is now known as yofel [15:12] vila: BTW, did you get whatever you needed out of that pycurl Q the other day? [15:13] fullermd: well, the underlying question was: does freebsd have a known place to store/share root ssl certs, so far I found... let me find it back [15:14] /usr/local/share/certs/ca-root-nss.crt [15:14] fullermd: can you confirm that ? [15:14] That's part of ca_root_nss. [15:14] There is (intentionally) no CA list in the base system. [15:15] ok, let me rephrase/expand the question: [15:15] we now implement ssl cert validation in the http urllib implementation, do achieve that, we need a list of cas [15:16] curl (with default build options) pulls in the NSS root list, though that can be disabled. [15:16] python doesn't provide one so we need some platform specific defaults === ISK_ is now known as ISK [15:16] I filed bug #920455 by the way [15:16] Launchpad bug 920455 in Bazaar "ssl cert verification needs better defaults for all supported platforms" [High,Confirmed] https://launchpad.net/bugs/920455 [15:18] fullermd: so, bzr should pulls this list too ? [15:18] Right. There isn't one. Now, probabilistically most desktops probably have ca_root_nss installed, considering how many things wind up pulling it in, and curl default does. But a flip in OPTIONS, and the latter doesn't. [15:20] You could just use it if it's there, and not if it's not. [15:20] fullermd: so, if bzr was using /usr/local/share/certs/ca-root-nss.crt as the default value *and* does the needed magic in the packaging for pulling the NSS root list, the world would be a better place ? [15:21] err, if it's not there we can't use it and we can't verify certs either, that's supported by setting ssl.cert_reqs=none though [15:22] is it an issue to add that as a packaging dep ? [15:22] i.e. the idea is that we relied on pycurl before the fix but that not verifying certs with urllib is still a security issue [15:23] now we can verify (controlled by 2 options: ssl.ca_certs=, ssl.cert_reqs=) the certs but of course we need the right roots for that [15:24] Mmm. Lemme think about that. [15:24] It does pull in perl... [15:25] Of course, all the smart people already have that on their system, so it doesn't much matter. [15:25] I think I'd want to make it OPTIONal, since there's that contingent of security nuts who won't accept installing it. [15:26] perfect [15:26] security nuts will setup their own ssl.ca_certs *anyway* [15:26] I'll mull it a bit. Gotta conference call I have to go try now to gnaw off my own limbs to escape... [15:27] fullermd: no hurry, that's for 2.5.0 anyway [15:28] fullermd: on the other hand, the security nuts were probably using pycurl before that ;) [15:29] Well, or monotone :p [15:30] Right. Let see how well I can avoid talking in this stupid call... [15:30] * fullermd wanders off. [15:30] :) [17:11] if I undelete I file just by pulling it out of a previous version with bzr cat, then of course it's a fresh file with no history. [17:11] if I pull it out with bzr revert -rVERSION is that the same? [17:11] or does it regain its history then? [17:23] quicksilver, that will regain the history [17:23] james_w: good news, thank you! [17:24] james_w: so that is the 'right' way to undelete, I guess. How could I simply "prove" to myself that it has regained history. Is "bzr log filename" a good way? [17:24] quicksilver, I think that should work [17:25] thanks again [17:27] quicksilver: 'bzr st --show-ids' cannot lie :) [17:28] vila: hmm but what to compare to? a checkout of an old version I make? [17:29] quicksilver: that or a 'bzr st -c --show-ids' where is a revision where this file was changed [17:30] I didn't know about the -c argument [17:30] i've only been using bzr for 6.5 years [17:30] thanks vila [17:30] quicksilver: hehe [18:29] jelmer, I have a fix for a bzr-gtk issue I saw this morning. https://code.launchpad.net/~sinzui/bzr-gtk/precise-diff-0/+merge/89759 [18:35] sinzui: thanks, I'll have a look [18:37] sinzui: bug 914363 is no longer private [18:37] Launchpad bug 914363 in bzr (Ubuntu) "bzr crashed with TypeError in __new__(): object of type 'NoneType' has no len()" [Undecided,Confirmed] https://launchpad.net/bugs/914363 [18:38] fab [18:39] I am not sure I fixed that. [18:39] * sinzui checks [18:40] Well maybe I did. [18:42] jelmer, yes I did fix that bug. There is a lot of warnings on stderr though about invalid matrix (not invertible) [18:45] sinzui: cool [18:45] sinzui: I have to run out for a bit, will do a review when I get back [18:47] thanks [19:44] bzr 2.4.2, 13 minutes to check out a branch, http://buildbot.twistedmatrix.com/builders/winxp32-py2.6/builds/1867/steps/bzr/logs/stdio [19:51] exarkun: that looks like 4 minutes, have you got the .bzr.log instead? [19:53] at least the checkout step says 'elapsedTime=257.125000' so something else must have been going on for the rest of it. [19:53] could be. it's not clear which timestamps to trust. [19:54] it definitely took a long time though. [19:54] making your script do BZR_LOG=/some/file/builder/can/attach would be grand [19:54] The .bzr.log might be available, I'll let you know. [19:54] I don't think that's possible. [19:57] that's a shame. I thought buildbot was pretty fancy. [19:57] ha. [20:02] * jelmer wonders if there is a particular reason buildbot uses checkout vs say, export [20:05] I expect some bzr experts could greatly improve buildbot's bzr support code. buildbot supports half a dozen or more version control systems, mostly with... creative solutions, constructed by people who are more knowledgeable about buildbot than about the particular version control system. [20:23] exarkun: yeah, looking at the source code it seems like just "bzr export" should be sufficient [20:23] unfortunately I don't think that bzr/buildbot integration improvements will make it onto my top 10 any time soon [20:24] even paying attention to this terrible performance is actually a terrible diversion from my actual priorities right now... [20:29] wgz: I fixed some pypy failures -> Ran 27060 tests in 2322.926s ; FAILED (failures=42, errors=69, known_failure_count=53) [20:29] here's the end of the log, paste.debian.net/153385 [20:30] an improvement on FAILED (failures=55, errors=8397, known_failure_count=28) [20:30] I don't know if it actually overlaps the build I linked to though [20:31] This kinda seems hopeless. I should probably give up and go back to work. [20:34] LarstiQ: good work, was that mostly changes to test cases themselves? [20:35] wgz: yes [20:36] hm, sadly exarkun's log doesn't seem to actually include the checkout... [20:36] it's just modifying an existing tree [21:25] hi LarstiQ, wgz [21:25] yawn [21:39] is it that early poolie? :) [21:40] wgz: 0840 for him [21:40] wgz: but jet lag :) [22:29] wgz, 0840 isn't early but waking up at 0430 is [22:29] :( === iBasic is now known as BasicOSX === wallyworld_ is now known as wallyworld