[02:04] <poolie> hi all
[02:07] <lifeless> ola
[02:16] <poolie> lifeless, what new laptop disk did you buy?
[02:17] <lifeless> poolie: the intel 320?300? GB one
[02:18] <poolie> '520 series' or something?
[02:18] <lifeless> yeah
[02:19] <lifeless> poolie: SSDSA2CW30
[02:19] <poolie> k thanks
[02:19]  * poolie deletes stuff instead
[02:20] <lifeless> http://www.betterit.com.au/scripts/prodview.asp?idproduct=265748
[06:31] <poolie> vila, hi?
[07:08] <vila> hi all !
[08:26] <poolie> jelmer, wgz, hi?
[08:27] <poolie> i might make mgz be pilot this week as it's mostly jelmer that needs reviews
[08:38] <poolie> i'll let you settle it
[08:39] <poolie> vila, maybe you could just send a note about the ppas and other releases
[08:39] <poolie> *srus
[08:39] <poolie> mm
[08:42] <vila> hmm, yeah, our ppas need some love, maxb ?
[09:00] <vila> hello mgz !
[09:00] <mgz> morning all
[12:02] <mgz> jelmer: do you want to swap pp this week?
[12:02] <mgz> the alternative is we just do a morning or something reviewing your branches
[12:31] <jelmer> mgz: I think that might be better
[12:31] <jelmer> mgz: though I'd also be happy to swap this week if you prefer ?
[12:32] <mgz> nope, just swapping a morning seems fine to me
[12:35] <jelmer> ok, let's do that then
[13:30] <mgz> oi, jelmer, vila, why am I talking in /query to both of you...
[13:30] <mgz> jelmer -> in here
[13:30] <jelmer> mgz: ohai
[13:31] <fullermd> I knew you were all talking about me behind my back   :(
[13:31] <mgz> so, this is LANG=C with bzr-svn bascially?
[13:32] <vila> fullermd: just look the other side :)
[13:32] <jelmer> mgz: yeah
[13:32] <jelmer> mgz: UnicodeFilenameFeature is present, but libsvn fails to actually encode non-ascii filenames
[13:33] <mgz> if there's an obvious worked-before and fails-now, might be best to just file a bug and subscribe me.
[13:34] <jelmer> mgz: will do
[13:34] <jelmer> for now, I'll just set LC_ALL=en_US.UTF8 while running the bzr-svn testsuite..
[13:35] <mgz> the clearest issues will be with stuff that used to fail early, but now works till it tries outputting something
[13:35] <mgz> which is pretty easy to get around with paths, as can convert to urls
[13:39] <vila> mgz: for the record, I looked a bit at the server tests failing on osx
[13:39] <vila> 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] <vila> 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] <mgz> hm.
[13:41] <vila> 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] <mgz> jelmer: aha, I understand from bug 920444 description
[13:55] <mgz> there bzr-svn tests relying on out process svn for things I take it
[13:55] <mgz> or... just bypassing python I guess is the point
[13:55] <mgz> changing the feature is the obvious way forward
[14:05] <jelmer> mgz: it's all in the same process, but indeed bypassing python
[14:06] <mgz> I'm unsure if a different feature making the current one stricter would be best
[14:07] <mgz> without running the tests that need unicode filenames under LANG=C we then only rely on explict subprocess tests
[14:08] <jelmer> hmm
[14:08] <mgz> but it's annoying for you to have to work out which tests need a full locale set on nix
[14:08] <jelmer> mgz: these tests are multiplied
[14:09] <mgz> and possibly worse than that for parametrised tets
[14:09] <mgz> +s
[14:09] <jelmer> mgz: against some implementations they need setlocale(), against others they don't
[14:09] <mgz> right.
[14:10] <mgz> well, it's not that they need setlocale so much as they need a unicode locale.
[14:10] <mgz> in-process libsvn as a locale set, it's just not one that can be used for non-ascii names.
[14:10] <mgz> (in this case)
[14:11] <mgz> out of process things potentially break if a unicode locale is given, but they don't call setlocale()
[14:12] <jelmer> mgz: right, I mean they need a call to setlocale() to set it to a non-ascii encoding
[14:13] <mgz> but you can't go changing the locale as a library
[14:17] <vila> 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 ?
[14:19] <jave_> I get a "conflicting tags" error, and I'm trying to understand how to debug it.
[14:19] <vila> 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] <jelmer> mgz: right, but we can from the bzr script (which is also whats runs the testsuite)
[14:22] <jelmer> mgz: another alternative is for subvertpy to override the locale before each libsvn call
[14:23] <jelmer> mgz: though that might have too much overhead, I'm not sure
[14:26] <jelmer> vila: I think upgrading pristine-tar i safe
[14:28] <vila> I think so too, but who did packaged it for -cat ?
[14:28] <jelmer> vila: I don't think it's packaged for -cat yet, I can do that
[14:29] <mgz> jelmer: we can ignore the user's configuration sure, but it's better to not do that, even for just the testsuite
[14:29] <vila> 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] <vila> jelmer: and about bzr-builddeb ? Are there fallouts to be expected or is it safe to upgrade ?
[14:30] <vila> jelmer: and that would be great if you package 1.17 for -cat !
[14:31] <vila> 1.17 is already in sid and wheezy, it's weird it's not in precise yet...
[14:34] <jelmer> vila: I think it's safe to upgrade
[14:34] <jelmer> 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] <vila> jelmer: cool, I'll do that then
[14:34] <vila> jelmer: exellent, I'll file one
[14:48] <vila> rt filed
[15:12] <fullermd> vila: BTW, did you get whatever you needed out of that pycurl Q the other day?
[15:13] <vila> 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] <vila> /usr/local/share/certs/ca-root-nss.crt
[15:14] <vila> fullermd: can you confirm that ?
[15:14] <fullermd> That's part of ca_root_nss.
[15:14] <fullermd> There is (intentionally) no CA list in the base system.
[15:15] <vila> ok, let me rephrase/expand the question:
[15:15] <vila> we now implement ssl cert validation in the http urllib implementation, do achieve that, we need a list of cas
[15:16] <fullermd> curl (with default build options) pulls in the NSS root list, though that can be disabled.
[15:16] <vila> python doesn't provide one so we need some platform specific defaults
[15:16] <vila> I filed bug #920455 by the way
[15:18] <vila> fullermd: so, bzr should pulls this list too ?
[15:18] <fullermd> 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] <fullermd> You could just use it if it's there, and not if it's not.
[15:20] <vila> 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] <vila> 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] <vila> is it an issue to add that as a packaging dep ?
[15:22] <vila> 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] <vila> now we can verify (controlled by 2 options: ssl.ca_certs=<path>, ssl.cert_reqs=<your choice>) the certs but of course we need the right roots for that
[15:24] <fullermd> Mmm.  Lemme think about that.
[15:24] <fullermd> It does pull in perl...
[15:25] <fullermd> Of course, all the smart people already have that on their system, so it doesn't much matter.
[15:25] <fullermd> 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] <vila> perfect
[15:26] <vila> security nuts will setup their own ssl.ca_certs *anyway*
[15:26] <fullermd> 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] <vila> fullermd: no hurry, that's for 2.5.0 anyway
[15:28] <vila> fullermd: on the other hand, the security nuts were probably using pycurl before that ;)
[15:29] <fullermd> Well, or monotone   :p
[15:30] <fullermd> Right.  Let see how well I can avoid talking in this stupid call...
[15:30]  * fullermd wanders off.
[15:30] <vila> :)
[17:11] <quicksilver> 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] <quicksilver> if I pull it out with bzr revert -rVERSION is that the same?
[17:11] <quicksilver> or does it regain its history then?
[17:23] <james_w> quicksilver, that will regain the history
[17:23] <quicksilver> james_w: good news, thank you!
[17:24] <quicksilver> 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] <james_w> quicksilver, I think that should work
[17:25] <quicksilver> thanks again
[17:27] <vila> quicksilver: 'bzr st --show-ids' cannot lie :)
[17:28] <quicksilver> vila: hmm but what to compare to? a checkout of an old version I make?
[17:29] <vila> quicksilver: that or a 'bzr st -c <old> --show-ids' where <old> is a revision where this file was changed
[17:30] <quicksilver> I didn't know about the -c argument
[17:30] <quicksilver> i've only been using bzr for 6.5 years
[17:30] <quicksilver> thanks vila
[17:30] <vila> quicksilver: hehe
[18:29] <sinzui> 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] <jelmer> sinzui: thanks, I'll have a look
[18:37] <jelmer> sinzui: bug 914363 is no longer private
[18:38] <sinzui> fab
[18:39] <sinzui> I am not sure I fixed that.
[18:39]  * sinzui checks
[18:40] <sinzui> Well maybe I did.
[18:42] <sinzui> jelmer, yes I did fix that bug. There is a lot of warnings on stderr though about invalid matrix (not invertible)
[18:45] <jelmer> sinzui: cool
[18:45] <jelmer> sinzui: I have to run out for a bit, will do a review when I get back
[18:47] <sinzui> thanks
[19:44] <exarkun> 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] <wgz> exarkun: that looks like 4 minutes, have you got the .bzr.log instead?
[19:53] <wgz> at least the checkout step says 'elapsedTime=257.125000' so something else must have been going on for the rest of it.
[19:53] <exarkun> could be.  it's not clear which timestamps to trust.
[19:54] <exarkun> it definitely took a long time though.
[19:54] <wgz> making your script do BZR_LOG=/some/file/builder/can/attach would be grand
[19:54] <exarkun> The .bzr.log might be available, I'll let you know.
[19:54] <exarkun> I don't think that's possible.
[19:57] <wgz> that's a shame. I thought buildbot was pretty fancy.
[19:57] <exarkun> ha.
[20:02]  * jelmer wonders if there is a particular reason buildbot uses checkout vs say, export
[20:05] <exarkun> 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] <jelmer> exarkun: yeah, looking at the source code it seems like just "bzr export" should be sufficient
[20:23] <exarkun> unfortunately I don't think that bzr/buildbot integration improvements will make it onto my top 10 any time soon
[20:24] <exarkun> even paying attention to this terrible performance is actually a terrible diversion from my actual priorities right now...
[20:29] <LarstiQ> wgz: I fixed some pypy failures ->  Ran 27060 tests in 2322.926s ; FAILED (failures=42, errors=69, known_failure_count=53)
[20:29] <exarkun> here's the end of the log, paste.debian.net/153385
[20:30] <LarstiQ> an improvement on FAILED (failures=55, errors=8397, known_failure_count=28)
[20:30] <exarkun> I don't know if it actually overlaps the build I linked to though
[20:31] <exarkun> This kinda seems hopeless.  I should probably give up and go back to work.
[20:34] <wgz> LarstiQ: good work, was that mostly changes to test cases themselves?
[20:35] <LarstiQ> wgz: yes
[20:36] <wgz> hm, sadly exarkun's log doesn't seem to actually include the checkout...
[20:36] <wgz> it's just modifying an existing tree
[21:25] <poolie> hi LarstiQ, wgz
[21:25] <poolie> yawn
[21:39] <wgz> is it that early poolie? :)
[21:40] <lifeless> wgz: 0840 for him
[21:40] <lifeless> wgz: but jet lag :)
[22:29] <poolie> wgz, 0840 isn't early but waking up at 0430 is
[22:29] <poolie> :(