[00:02] <cjalmeida> poolie, I tried the 2.5b2 from ppa and same issue. I'll try to check mtu. BTW, nautilus ssh connection also stopped working. however, dolphin and large scp transfers are OK.
[00:02] <cjalmeida> weird...
[00:03] <poolie> uh
[00:03] <poolie> maybe you turned on ssh connection auto-master?
[00:03] <poolie> try turning that off
[00:04] <cjalmeida> presto! it was mtu.
[00:04] <cjalmeida> set it to 576 and everthing worked
[00:05] <cjalmeida> I had a hunch about it when firefox started dropping conns, but set it to 1400, still too large
[00:06] <cjalmeida> even nautilus is working fine now
[00:06] <cjalmeida> poolie, I'll see if i can find a good mtu. Canonical should put a post connect test to determine best value.
[00:08] <poolie> what, in network-manager or something?
[00:08] <poolie> hm
[00:08] <poolie> path mtu discovery does already exist
[00:08] <poolie> i don't recall why it doesn't work in some cases
[00:30] <cjalmeida> poolie, for some reason, my /proc/sys/net/ipv4/tcp_mtu_probing was set to 0.
[00:34] <poolie> mine too
[00:41] <poolie> perhaps there is some tradeoff about having it on
[01:30] <fullermd> Path MTU discover _does_ require that you not have any networks in the path run by flaming idiots who think "Oh, hey, let's block all ICMP; that way we're more secure!"
[01:31] <bob2> yes
[01:31] <bob2> alack
[01:32] <fullermd> (I dunno if that's less of a problem now than it was a decade ago.  My cynical side says 'no'...)
[01:32] <bob2> there are still people who think icmp is how teh hackers get in, but they mostly seem to be sysadmins rather than netadmins
[01:32] <fullermd> Luckily, I'm buoyed up by my native optimism and happy outlook.
[01:46] <poolie> i wonder if it might not be possible to do some kind of heuristic detection
[02:00] <lifeless> fullermd: PTMUd can handle blackholes... just faster without them
[02:02] <lifeless> cjalmeida: poolie: that sysctl is for RFC 4821 checking, which is new (2007) vs RFC 1191 checking, which is what most folk expect/need
[02:02] <lifeless> cjalmeida: poolie: http://kb.pert.geant.net/PERTKB/PathMTU covers both
[02:03] <lifeless> I speculate it is disabled due to newness; pehraps we should default it on
[02:04] <lifeless> fullermd: 4821 doesn't need ICMP according to that wiki page
[02:07] <poolie> lifeless, yes i thought perhaps there was another one
[02:10] <fullermd> Ah.
[02:18] <cjalmeida> poolie, lifeless, fullermd the tcp_mtu_probing setting to 1 seems to have fixed mos issues.
[03:16] <cjalmeida> #openerp
[03:30] <lifeless> poolie: btw - http://www.erlang.org/doc/man/dialyzer.html
[03:30] <poolie> thanks
[05:00] <BlindWolf8> Hey all. I have a Bazaar server where clients use ssh_path_limiter to access a repo. Am I able to pass multiple paths in my authorized_keys file?
[05:00] <BlindWolf8> I want to do this so a single person doesn't need to generate a key per project
[05:00] <BlindWolf8> I am using Shared repos
[05:23] <BlindWolf8> Anyone?
[05:58] <lifeless> BlindWolf8: just put all the repos under a common root
[05:58] <lifeless> /srv/repos/A /srv/repos/B and make /srv/repos the permitted path
[05:59] <BlindWolf8> but then clients would need to change their paths, right?
[05:59] <BlindWolf8> for bound branches?
[05:59] <lifeless> uhm, yes
[06:00] <BlindWolf8> i figured
[06:00] <BlindWolf8> right now it's bzr+ssh://<user>@<ip>:<port>/.bzr/branches/trunk/
[07:06] <vila> hi all
[07:07]  * fullermd wavels.
[07:07] <vila> poolie: 'Requests' looks very good indeed, dependencies may be an issue there though
[07:08] <vila> poolie: in short, too late for 2.5, worth considering for 2.6
[07:10] <poolie> hi
[07:10] <poolie> yeah
[07:49] <jelmer> 'morning
[07:55] <mgz> morning all!
[07:58] <jelmer> hey mgz
[08:01] <jelmer> are we hanging out?
[08:02] <mgz> I need to head downstairs if so
[08:03] <jelmer> mgz: are you up for that journey?
[08:03] <mgz> if that's where we'll all be :)
[08:05] <jelmer> vila, poolie: ^
[08:05] <vila> morning guys !
[08:05] <vila> oh, right !
[08:06] <poolie> hi jelmer, mgz,
[08:06] <poolie> yes let's try it
[08:14] <wgz> hm, where is the thingy?
[08:14] <jelmer> wgz: it's on http://plus.google.com/
[08:15]  * wgz reloads
[08:15] <jelmer> wgz: the top item should be an invite from poolie for the hangout
[08:16] <vila> can't see it
[08:17] <jelmer> mgz: no can hear you
[08:17] <jelmer> vila: hmm, that's odd.. should be the first item in the stream
[08:21] <vila> poolie is the first in the stream but I can't see any ref to an ongoing hangout :-(
[08:26] <jelmer> vila: there should be a join button
[08:26] <vila> yeah, that's what I remember but there is none
[08:27] <vila> ha !
[08:39] <tvoss> Hi all
[08:40] <tvoss> I'm trying to setup a packaging recipe and hitting a problem with bzr-builder
[08:40] <tvoss> apparently missing a launchpad id
[08:43] <tvoss> build log is here: https://launchpadlibrarian.net/90240218/buildlog.txt.gz
[08:50] <jelmer> tvoss: for now, please use the 0.3 version of recipes
[08:53] <tvoss> jelmer, thx, adjusted my recipe and requested a build
[09:07] <mgz> okay. enough fun
[09:13] <vila> mgz: regarding the seg fault, here is the only trace I found in kernel.log: http://paste.ubuntu.com/807177/
[09:16] <mgz> not very informative indeed
[09:17] <vila> yeah, if I wasn't searching for it I've probably missed it
[09:18] <vila> I had probably ?
[09:25] <tvoss> jelmer, 0.3 version of the recipes work fine
[09:51] <vila> jelmer: colocated-names reviewed, mostly questions for now but the change looks ok, I need answers to understand the impact but it seems low risk  enough to be ok
[09:54] <jelmer> vila: thanks
[10:04] <jelmer> vila: replied
[10:04] <vila> jelmer: already reading and replying ;)
[10:04] <vila> one question
[10:04] <jelmer> vila: thanks for the quick followups :)
[10:04] <vila> self.name = name in __init__ makes it an instance variable right ?
[10:05] <vila> BzrBranch.__init__ that is
[10:05] <vila> and great answer by the way, I smelled a bug but couldn't put my finger on it
[10:06] <jelmer> vila: ah, sorry
[10:06] <jelmer> vila: I missed that that code was in Branch, I was only reading the diff
[10:06] <jelmer> yeah, I can see why documenting it as an instance variable makes sense
[10:07] <vila> unless the line should be deleted, I see no use of it from a quick grep...
[10:07] <jelmer> vila: which line, assigning to self.name ?
[10:08] <vila> yeah
[10:09] <vila> well, annotations say you added it so you should know ;)
[10:09] <vila> damn, there *is* doc for it
[10:09] <vila> sry
[10:10] <vila> why did I miss it in the first place....
[10:10] <jelmer> vila: it is meant to be used by things that need to display colocated branch names
[10:11] <vila> fine
[10:12] <vila> jelmer: approved, but watch for lp:bzr/2.5 as a target
[10:12] <jelmer> vila: thanks
[10:12] <jelmer> vila: I guess I should probably resubmit against 2.5?
[10:13] <vila> jelmer: depends on how you submit to pqm, don't wait for another review if you resubmit on lp though ;)
[10:13] <jelmer> vila: resubmitting against 2.5, would you mind re-reviewing?
[10:13] <jelmer> *resubmitted
[10:14] <vila> I don't mind but I just said you didn't need it ;)
[10:15] <jelmer> well, that way we have the review record right.. I don't like reviewing my own stuff :)
[10:19] <vila> jelmer: done, one last time: check news entry ;)
[10:23] <jelmer> vila: huh, wha ? :-P
[10:23]  * jelmer RUNS
[10:23] <vila> I knew, trap activated as planned
[10:36] <vila> jelmer: jokes aside, if you still encounter news merge issues on pqm, let me know ;)
[10:38] <jelmer> vila: will do
[11:35] <zyga> hi
[11:35] <zyga> is the author of lp:bzr-interactive around?
[15:11] <mgz> oo larstiq magic
[15:12] <LarstiQ> mgz: oh oh, I hoped it wasn't too magical :)
[15:17] <mgz> approved, but you probably want to do some shuffling to get it on 2.5 which branched yesterday
[15:18] <mgz> may just be able to branch lp:bzr/2.5, merge your change into that (and --fixes) then add news and repropose
[15:19]  * LarstiQ looks for a corresponding bug
[15:19] <mgz> bug 881142
[15:20] <mgz> really good job tracking that down, gets us down to a sensible number of failures on pypy I take it?
[15:20] <LarstiQ> mgz: not entirely sure
[15:20] <mgz> I'll do a run later this evening and report back.
[15:21] <LarstiQ> mgz: while running test_http.TestBadStatusServer.test_http_get bzr hangs for a long time and then: zsh: alarm      ../pypy-1.7/bin/pypy ./bzr selftest
[15:22] <LarstiQ> reading around that can happen when a signal handler isn't properly set when the signal arrives
[15:22] <LarstiQ> but looking at the code I couldn't figure it out
[15:22] <jelmer> LarstiQ: we register an alarm handler to kill hanging tests
[15:22]  * LarstiQ nods
[15:22] <LarstiQ> jelmer: "something" goes wrong there :)
[15:23] <jelmer> LarstiQ: so most likely this is a hanging test, rather than anything to do with the signal handler
[15:24] <LarstiQ> jelmer: my understanding is that the signal handler doesn't run and it passes down to zsh
[15:24]  * LarstiQ might be wrong
[15:25] <jelmer> LarstiQ: I don't think we register a signal handler at all, (intentionally?)
[15:25] <LarstiQ> jelmer: possibly, I didn't quite follow the code. One _exists_ at least.
[15:25] <LarstiQ> vila might know more
[15:25] <jelmer> LarstIQ: At least, if I have hanging tests on cpython it dies the same way
[15:26] <LarstiQ> jelmer: ah ok
[15:26] <jelmer> so it might be that the signal handler isn't being called, but at least it's consistent across the various python implementations :)
[15:26] <vila> LarstiQ: hey !
[15:27] <LarstiQ> vila: heya :)
[15:28] <vila> AFAIK, we don't use signals in tests *expect* SIGALRM to kill hanging tests (based on selftests.timeout defaulting to... 60s I think)
[15:28] <vila> except not expect
[15:29] <LarstiQ> vila: who is supposed to handle that signal, bzr or the shell?
[15:30] <vila> err... dunno :)
[15:31] <mgz> see <https://code.launchpad.net/~mbp/bzr/test-timeout/+merge/83559>
[15:31] <vila> I think we just arm a timer
[15:32] <vila> so yeah, we never try to catch it
[15:32] <LarstiQ> ok, so then the only question is why it times out
[15:34] <vila> LarstiQ: you run with -v ?
[15:34] <vila> LarstiQ: said otherwise: are you sure the hanging tests is TestBadStatusServer ?
[15:35] <mgz> it tracking it down to one test that hangs (semi) reliably would be a good start
[15:35] <LarstiQ> vila: good point
[15:35]  * LarstiQ tries a run with just that test
[15:36] <mgz> can set that conf value to less than 60 for less patient alarm timeout while trying test subsets
[15:36] <vila> ... or to more than 60 if you need to debug ;)
[15:37] <mgz> that's true, breaking in poking thread states can be useful
[15:37] <mgz> +and
[15:38] <LarstiQ> after which point would the alarm kick in? It's not giving any progress info (while with -v) for more than a minute already
[15:38] <mgz> it should just be 60s after test start
[15:38] <mgz> otherwise try ctrl+\ and see where you land
[15:44] <LarstiQ> http://paste.debian.net/152579/
[15:48] <mgz> TestBadStatusServer.test_http_has it is.
[15:48] <LarstiQ> the following completes in 21 seconds: ../pypy-1.7/bin/pypy ./bzr selftest -v -s bt.test_http -x test_http.TestBadStatusServer.test_http_has -x test_http.TestBadStatusServer.test_http_get -x test_http.TestPost.test_post_body_is_received -x test_http.TestRecordingServer.test_send_receive_bytes
[15:49] <vila> ./bzr selftest -s bt.test_http.TestBadStatus -v would be simpler to start with
[15:50]  * LarstiQ has to run now
[15:50] <LarstiQ> I'll be back tomorrow
[15:50] <mgz> thanks LarstiQ!
[15:50] <vila> k
[15:51] <vila> thanks for digging  !
[15:51] <LarstiQ> mgz: then I'll also have some questions about proper NEWS entry writing
[15:51]  * LarstiQ off
[15:55] <mgz> actually, could just merge to 2.5 and add news for LarstiQ, will do that later unless pp gets there first
[15:56] <vila> LarstiQ: in case your read the log, I suspect you're re-trying a request that failed, we want the first failure as the server is not supposed to receive more than one request which is probably why it's hanging
[15:56] <vila> mgz: I'll do
[16:05] <vila> mgz: I did
[16:25] <mgz> vila: ta!
[18:58] <mgz> ha, okay, fixed eucatools proxying signature checking
[19:00] <mgz> ...and that was the wrong channel this time.
[19:01] <jelmer> mgz!
[19:42] <BlindWolf8> Hello. Is bzr_path_limiter able to traverse soft links? I'm getting a "not a repo" error
[19:44] <BlindWolf8> Actually, it's "No repository present"
[19:53] <BlindWolf8> Is it because I'm pointing it towards a branch and not a repo?
[19:54] <jelmer> BlindWolf8: yeah, it won't be able to browse down towards the repo in that case
[20:02] <BlindWolf8> Is tehre a way to remove the ugly "/.bzr/branches/trunk/" from URLs without making symlinks or is that just the way it's going to be?
[20:03] <jelmer> BlindWolf8: huh, why would you need symlinks to that?
[20:06] <BlindWolf8> Just was trying to make my URLs for team members easier to pop in/look less ugly, but Iif they have to look like bzr+ssh://<user>@<ip>:<port>/<project_name>/.bzr/branches/trunk/ then that's the way it's going to be
[20:08] <beuno> so, couldn't you register a shortcut like lp: has?
[20:08] <BlindWolf8> the project isn't on lp
[20:09] <beuno> no, I mean "lp:" is probably registered in the launchpad plugin
[20:09] <beuno> maybe you could have a plugin to register "something:"
[20:09] <jelmer> BlindWolf8: why not just bzr+ssh://<user>@<ip>:<port>/<project_name>/trunk ?
[20:10] <mgedmin> there's a bookmarks plugin, iirc
[20:10] <mgedmin> http://doc.bazaar.canonical.com/plugins/en/bookmarks-plugin.html
[20:10] <BlindWolf8> I don't think bzr+ssh://<user>@<ip>:<port>/<project_name>/trunk works. That would be the ideal solution, I think
[20:11] <BlindWolf8> I'm using colocated branches...the project only really needs a trunk
[20:11] <jelmer> BlindWolf8: ah
[20:11] <jelmer> BlindWolf8: so this is very specific to bzr-colo
[20:11] <BlindWolf8> I'm not using that plugin
[20:12] <BlindWolf8> at least on the server
[20:12] <BlindWolf8> I think the Windows installer version of bzr comes with that though
[20:13] <jelmer> BlindWolf8: you should be able to just push to your desired location of bzr+ssh://<user>@<ip>:<port>/<project_name>/trunk
[20:16] <BlindWolf8> want me to try and report back?
[20:18] <BlindWolf8> Fails with "not a branch" error
[20:18] <glyph> I notice that there's no 'qmissing' in bzr
[20:18] <glyph> erm qbzr
[20:18] <glyph> is there a thing that's similar?
[20:18] <jelmer> BlindWolf8: when you're pushing?
[20:20] <BlindWolf8> when I'm pulling
[20:20] <jelmer> BlindWolf8: you'd have to push to that location first (and ditch the .bzr/branches/ bit from bzr-colo)
[20:21] <BlindWolf8> why? would that create it on the server?
[20:22] <BlindWolf8> just an FYI: everyone's using colo'd bound branches...no checkouts or master branch
[20:22] <jelmer> BlindWolf8: yes, that should create it on the server
[20:22] <BlindWolf8> just a single branch, nothing fancy
[20:22] <jelmer> BlindWolf8: you're complaining about colocated branches on the server
[20:23] <BlindWolf8> server doesn't have any fiels on it...every else has those files though
[20:23] <BlindWolf8> only dir on the server is the .bzr dir
[20:23] <jelmer> BlindWolf8: right, that's fine - the server just has to have the branch, not the working tree
[20:24] <BlindWolf8> but isn't the branch technically in the .bzr dir already...?
[20:24] <jelmer> BlindWolf8: it is, but it lives in a special location which is a bit of a hack used by bzr-colo
[20:24] <jelmer> BlindWolf8: that's why you have to specify /.bzr/branches/foo rather than just /foo
[20:25] <BlindWolf8> I'm assuming it's going to be awhile until that's fixed :-)
[20:25] <jelmer> BlindWolf8: bzr 2.5 will have proper colocated branch support, different from bzr-colo
[20:26] <BlindWolf8> what's the ETA on that?
[20:26] <jelmer> BlindWolf8: 2.5.0 is due out in a month I think
[20:26] <BlindWolf8> what's the upgrade path for old repos with the old colo format?
[20:27] <jelmer> BlindWolf8: no idea; I think Neil (the author of bzr-colo) had some ideas but I've only been involved with the colo support in the core
[20:28] <BlindWolf8> gotcha...the new version sounds like it's even more friendly
[20:30] <BlindWolf8> just thought about my folder layout and I think I'm goign to need to make symlinks on a per user basis for security reasosns
[20:30] <BlindWolf8> so epeople can't get into other projects
[20:30] <BlindWolf8> since I can only pass one directory with ssh_path_limiter
[20:31]  * jelmer has to head out, sorry
[20:32] <jelmer> back later tonight
[20:32] <BlindWolf8> see ya! thanks!
[22:17] <poolie> hi all
[23:10] <GRiD> hi poolie, how's it going
[23:54] <poolie> hi grid, pretty good, how are you?