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:02 |
poolie | uh | 00:03 |
poolie | maybe you turned on ssh connection auto-master? | 00:03 |
poolie | try turning that off | 00:03 |
cjalmeida | presto! it was mtu. | 00:04 |
cjalmeida | set it to 576 and everthing worked | 00:04 |
cjalmeida | I had a hunch about it when firefox started dropping conns, but set it to 1400, still too large | 00:05 |
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:06 |
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:08 |
=== zyga is now known as zyga-afk | ||
cjalmeida | poolie, for some reason, my /proc/sys/net/ipv4/tcp_mtu_probing was set to 0. | 00:30 |
poolie | mine too | 00:34 |
poolie | perhaps there is some tradeoff about having it on | 00:41 |
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:30 |
bob2 | yes | 01:31 |
bob2 | alack | 01:31 |
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:32 |
poolie | i wonder if it might not be possible to do some kind of heuristic detection | 01:46 |
lifeless | fullermd: PTMUd can handle blackholes... just faster without them | 02:00 |
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:02 |
lifeless | I speculate it is disabled due to newness; pehraps we should default it on | 02:03 |
lifeless | fullermd: 4821 doesn't need ICMP according to that wiki page | 02:04 |
poolie | lifeless, yes i thought perhaps there was another one | 02:07 |
fullermd | Ah. | 02:10 |
cjalmeida | poolie, lifeless, fullermd the tcp_mtu_probing setting to 1 seems to have fixed mos issues. | 02:18 |
cjalmeida | #openerp | 03:16 |
lifeless | poolie: btw - http://www.erlang.org/doc/man/dialyzer.html | 03:30 |
poolie | thanks | 03:30 |
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:00 |
BlindWolf8 | Anyone? | 05:23 |
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:58 |
BlindWolf8 | but then clients would need to change their paths, right? | 05:59 |
BlindWolf8 | for bound branches? | 05:59 |
lifeless | uhm, yes | 05:59 |
BlindWolf8 | i figured | 06:00 |
BlindWolf8 | right now it's bzr+ssh://<user>@<ip>:<port>/.bzr/branches/trunk/ | 06:00 |
vila | hi all | 07:06 |
* fullermd wavels. | 07:07 | |
vila | poolie: 'Requests' looks very good indeed, dependencies may be an issue there though | 07:07 |
vila | poolie: in short, too late for 2.5, worth considering for 2.6 | 07:08 |
poolie | hi | 07:10 |
poolie | yeah | 07:10 |
jelmer | 'morning | 07:49 |
mgz | morning all! | 07:55 |
jelmer | hey mgz | 07:58 |
jelmer | are we hanging out? | 08:01 |
mgz | I need to head downstairs if so | 08:02 |
jelmer | mgz: are you up for that journey? | 08:03 |
mgz | if that's where we'll all be :) | 08:03 |
jelmer | vila, poolie: ^ | 08:05 |
vila | morning guys ! | 08:05 |
vila | oh, right ! | 08:05 |
poolie | hi jelmer, mgz, | 08:06 |
poolie | yes let's try it | 08:06 |
wgz | hm, where is the thingy? | 08:14 |
jelmer | wgz: it's on http://plus.google.com/ | 08:14 |
* wgz reloads | 08:15 | |
jelmer | wgz: the top item should be an invite from poolie for the hangout | 08:15 |
vila | can't see it | 08:16 |
jelmer | mgz: no can hear you | 08:17 |
jelmer | vila: hmm, that's odd.. should be the first item in the stream | 08:17 |
vila | poolie is the first in the stream but I can't see any ref to an ongoing hangout :-( | 08:21 |
jelmer | vila: there should be a join button | 08:26 |
vila | yeah, that's what I remember but there is none | 08:26 |
vila | ha ! | 08:27 |
tvoss | Hi all | 08:39 |
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:40 |
tvoss | build log is here: https://launchpadlibrarian.net/90240218/buildlog.txt.gz | 08:43 |
jelmer | tvoss: for now, please use the 0.3 version of recipes | 08:50 |
tvoss | jelmer, thx, adjusted my recipe and requested a build | 08:53 |
mgz | okay. enough fun | 09:07 |
vila | mgz: regarding the seg fault, here is the only trace I found in kernel.log: http://paste.ubuntu.com/807177/ | 09:13 |
mgz | not very informative indeed | 09:16 |
vila | yeah, if I wasn't searching for it I've probably missed it | 09:17 |
vila | I had probably ? | 09:18 |
tvoss | jelmer, 0.3 version of the recipes work fine | 09:25 |
=== zyga-afk is now known as zyga | ||
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:51 |
jelmer | vila: thanks | 09:54 |
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:04 |
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:05 |
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:06 |
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:07 |
vila | yeah | 10:08 |
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:09 |
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:10 |
vila | fine | 10:11 |
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:12 |
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:13 |
vila | I don't mind but I just said you didn't need it ;) | 10:14 |
jelmer | well, that way we have the review record right.. I don't like reviewing my own stuff :) | 10:15 |
vila | jelmer: done, one last time: check news entry ;) | 10:19 |
jelmer | vila: huh, wha ? :-P | 10:23 |
* jelmer RUNS | 10:23 | |
vila | I knew, trap activated as planned | 10:23 |
vila | jelmer: jokes aside, if you still encounter news merge issues on pqm, let me know ;) | 10:36 |
jelmer | vila: will do | 10:38 |
zyga | hi | 11:35 |
zyga | is the author of lp:bzr-interactive around? | 11:35 |
=== tchan1 is now known as tchan | ||
=== zyga is now known as zyga-food | ||
mgz | oo larstiq magic | 15:11 |
LarstiQ | mgz: oh oh, I hoped it wasn't too magical :) | 15:12 |
mgz | approved, but you probably want to do some shuffling to get it on 2.5 which branched yesterday | 15:17 |
mgz | may just be able to branch lp:bzr/2.5, merge your change into that (and --fixes) then add news and repropose | 15:18 |
* LarstiQ looks for a corresponding bug | 15:19 | |
mgz | bug 881142 | 15:19 |
ubot5 | Launchpad bug 881142 in Bazaar "AssertionError: unversioned parent while creating working tree using pypy" [Medium,In progress] https://launchpad.net/bugs/881142 | 15:19 |
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:20 |
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:21 |
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:22 |
jelmer | LarstiQ: so most likely this is a hanging test, rather than anything to do with the signal handler | 15:23 |
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:24 | |
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:25 |
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:26 |
LarstiQ | vila: heya :) | 15:27 |
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:28 |
LarstiQ | vila: who is supposed to handle that signal, bzr or the shell? | 15:29 |
vila | err... dunno :) | 15:30 |
mgz | see <https://code.launchpad.net/~mbp/bzr/test-timeout/+merge/83559> | 15:31 |
vila | I think we just arm a timer | 15:31 |
vila | so yeah, we never try to catch it | 15:32 |
LarstiQ | ok, so then the only question is why it times out | 15:32 |
vila | LarstiQ: you run with -v ? | 15:34 |
vila | LarstiQ: said otherwise: are you sure the hanging tests is TestBadStatusServer ? | 15:34 |
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:35 | |
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:36 |
mgz | that's true, breaking in poking thread states can be useful | 15:37 |
mgz | +and | 15:37 |
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:38 |
LarstiQ | http://paste.debian.net/152579/ | 15:44 |
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:48 |
vila | ./bzr selftest -s bt.test_http.TestBadStatus -v would be simpler to start with | 15:49 |
* LarstiQ has to run now | 15:50 | |
LarstiQ | I'll be back tomorrow | 15:50 |
mgz | thanks LarstiQ! | 15:50 |
vila | k | 15:50 |
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:51 | |
mgz | actually, could just merge to 2.5 and add news for LarstiQ, will do that later unless pp gets there first | 15:55 |
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 | 15:56 |
vila | mgz: I did | 16:05 |
=== zyga-food is now known as zyga | ||
mgz | vila: ta! | 16:25 |
=== deryck is now known as deryck[lunch] | ||
=== deryck[lunch] is now known as deryck | ||
mgz | ha, okay, fixed eucatools proxying signature checking | 18:58 |
mgz | ...and that was the wrong channel this time. | 19:00 |
jelmer | mgz! | 19:01 |
BlindWolf8 | Hello. Is bzr_path_limiter able to traverse soft links? I'm getting a "not a repo" error | 19:42 |
BlindWolf8 | Actually, it's "No repository present" | 19:44 |
BlindWolf8 | Is it because I'm pointing it towards a branch and not a repo? | 19:53 |
jelmer | BlindWolf8: yeah, it won't be able to browse down towards the repo in that case | 19:54 |
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:02 |
jelmer | BlindWolf8: huh, why would you need symlinks to that? | 20:03 |
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:06 |
beuno | so, couldn't you register a shortcut like lp: has? | 20:08 |
BlindWolf8 | the project isn't on lp | 20:08 |
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:09 |
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:10 |
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:11 |
BlindWolf8 | at least on the server | 20:12 |
BlindWolf8 | I think the Windows installer version of bzr comes with that though | 20:12 |
jelmer | BlindWolf8: you should be able to just push to your desired location of bzr+ssh://<user>@<ip>:<port>/<project_name>/trunk | 20:13 |
BlindWolf8 | want me to try and report back? | 20:16 |
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:18 |
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:20 |
BlindWolf8 | why? would that create it on the server? | 20:21 |
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:22 |
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:23 |
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:24 |
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:25 |
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:26 |
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:27 |
BlindWolf8 | gotcha...the new version sounds like it's even more friendly | 20:28 |
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:30 |
* jelmer has to head out, sorry | 20:31 | |
jelmer | back later tonight | 20:32 |
BlindWolf8 | see ya! thanks! | 20:32 |
poolie | hi all | 22:17 |
GRiD | hi poolie, how's it going | 23:10 |
poolie | hi grid, pretty good, how are you? | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!