[00:38] morning [00:38] morning Ian. [00:38] request: could you look at https://code.launchpad.net/~simon-kersey/bzr-explorer/568728-fix/+merge/24306 at some point? [00:39] I did a drive-by comment on in a while back, and don't want the guy thinking I'm ignoring him (I just don't know if the code is right) === davidstrauss_ is now known as davidstrauss [00:41] mgz: it would be churlish of me to chime in on the subject of Launchpad as an OpenID consumer, wouldn't it? :-) [00:42] anyway, I'm given to understand that wheels are in motion to get a proper OpenID consumer in Launchpad, so that makes me optimistic. [00:43] mgz: I hope to get back to code reviews today [00:44] igc: glad to see you back in the saddle [00:44] thanks bignose! [00:44] great, thanks. [01:10] hi guys [01:10] anybody care to help a bit? [01:11] I just nuked my bzr repo [01:11] but I have a crapload of checkouts (not branches, checkouts) here and there - what would be the best way to get the newest revisions in the new repo? [01:12] 1. restore a backup (40 revisions back), and in checouts do bzr up; resolve conflicts, bzr ci? [01:12] 2. just ignore the backups and move a checkout as the new repo? [01:13] 3. do bzr pull IN the backup-restored repo FROM the checkout? [01:13] 3 sounds plausible to me [01:13] 4. bzr push the checkoput INTO the backup-restored repo [01:13] as long as you hav heavyweight checkouts, not lightweight (the default is heavy) [01:13] 3 and 4 are equivalent [01:14] heavy, heavy [01:14] okay, great [01:14] so, restore a backup, bzr push/pull [01:14] trying. === spiv_ is now known as spiv [01:22] spiv: hi [01:22] mwhudson: also ping [01:22] lifeless: hello [01:22] bzr smart server in lp [01:22] what diagnostics can I get on that ? [01:22] not terribly much easily :/ [01:23] also, is it still running as a subprocess; and what happens to its stdin/stdout - are they connected to twisted ? [01:23] i think unhandled exceptions should go into oops reports [01:23] yes and yes [01:23] trying to figure out why we only get 21KB/s from lp; gathering data as first step [01:23] it's running bzr lp-serve user-id --inet [01:23] shoving this under udd as 'slow checkouts hurt distro users' [01:23] ish ayway [01:26] ok [01:26] do we have statistics / info gathering on the twisted master [01:26] I'm particularly interested in socket windows (raw and ssh wrapped), packet delays and so on [01:26] lifeless: morning. [01:27] spiv: python-dev, antoine's message 'Summing up' may be of interest to us and the smart server in standalone mode [01:27] lifeless: not in any very structured way [01:27] mwhudson: is that yes if I ask nicely? or 'no, but I didn't want to say that' ? :) [01:28] lifeless: ta, will look [01:28] lifeless: it's 'conch dumps some crap into a log file about this sort of thing, but i doubt it's of any use' [01:29] * mwhudson sucks a 50 meg file off launchpad over bzr+ssh using hitchiker and watches the network in system monitor [01:29] it's quite surprising [01:30] do tell [01:30] lifeless: http://people.canonical.com/~mwh/sm.png [01:31] yes [01:31] there is something wrong ;) [01:31] it ramps up slowly to a decent rate, then drops right down and slowly ramps up again [01:32] it's a bit odd [01:32] I would expect this as a buffering interaction [01:33] if a pipe somewhere fills [01:33] process swaps/stops getting time slices [01:33] the tcp window may not open enough, and can take time to recover [01:34] http grab of the same file is also behaving a bit strangely, but very differently [01:36] http://people.canonical.com/~mwh/sm2.png [01:44] lifeless: worked like a charm, thanks [01:46] guys, maybe it would be a good idea to estimate, what's the average bandwidth in both situations? [01:47] I mean, the graphs show completely different behaviour, true, but maybe the overall average bandwidth at the end of the downloading is more or less the same? [01:47] Hey, does anyone know if there's already a bzr equivalent of the git-version-gen autoconf script? [01:48] I know I can adapt that to be for bzr, but I figured I'd see if someone had already done it [01:48] if so, maybe it would be a good idea to try wgtetting or whatever with a fixed max rate, just below that average [01:48] to see if anything strange happens, or not [01:55] lamalex: not that I know of [01:55] lamalex: I've done something similar for setup.py [01:55] lamalex: and drizzle does something similar too [01:56] mtaylor: ^ show lamalex the bzr version stuff for drizzle [01:56] lifeless: aroo? [01:56] mtaylor: so http peaks at 1mb [01:56] bah [01:56] lifeless: oh - gotcha [01:56] mwhudson: so http peaks at 1MB [01:56] and bzr+ssh at 512KB [01:57] lamalex: it's all in pandora-build ... (which you should use for your autoconf needs anyway) ... but specifically [01:58] lifeless: yeah, after the initial fast burst though http followed a vaguely similar pattern to bzr+ssh [01:58] lamalex: http://bazaar.launchpad.net/~mordred/pandora-build/devel/annotate/head:/m4/pandora_vc_build.m4 [01:58] lamalex: I've got to run at the moment - are you going to be around in 5 hours? [01:58] spm: whats that darn tool you swear by [01:58] less of a sawtooth i guess [01:58] lifeless: 'find' [01:58] spm: not swear at [01:58] * mwhudson was going for 'awk' [01:59] mtaylor, no probably not [01:59] but maybe [01:59] lifeless: a hammer? [01:59] context may help - what are you trying to do :-) [01:59] spm: for network window / efficiency / analysis [01:59] lamalex: ok. well, I can certainly help you out on this if you still need it when I get back or tomorrow [01:59] AHhhhhh! tcptrace + xplot [01:59] mtaylor, thanks [01:59] lamalex: sure! [02:00] yikes, m4. [02:00] isn't there a better templating solution that's dependably installed? [02:00] http://www.tcptrace.org/ and http://www.tcptrace.org/manual/node12_mn.html specifically. sheer gold. [02:01] mwhudson: what file were you testing with [02:01] bignose: well, not that's integrated with autoconf, no [02:01] s/better/more human-maintainable/ [02:01] lifeless: http://bazaar.launchpad.net/~vcs-imports/linux/trunk/.bzr/repository/packs/7590053cc142a5cb7ca8d0e33022ce2a.pack [02:03] lamalex: that particular macro encodes YYYY.MM.BZR-REVNO into the version ... as we're the only user of that particular function, I haven't generalized it yet. [02:03] ok. I'm off. have fun all [02:17] hi [02:17] how can I move everything in the root dir of my branch to a subdir? [02:17] like: [02:17] bzr mkdir src [02:18] bzr mv . src/myproject [02:18] which of couse does not work ;) [02:19] bzr mv $(ls | grep -v src) src/myproject [02:19] hmm....that will fail because of some files that aren't under version control [02:19] well, adjust appropriately [02:20] perhaps bzr ls --versioned [02:21] Need a bzr pivot_root... [02:21] fullermd: wouldn't address this case [02:21] fullermd: (and we have it) [02:21] lifeless, well, thx....that works ;) [02:21] only .bzignore shouldn't be moved I guess ;) [02:21] right [02:21] but I will simply bzr revert it [02:21] you'll want to mv that back :) [02:21] or that, sure [02:23] We do? Where? [02:24] tree transform [02:24] it can handle a merge that moves the root [02:24] we don't have a userspace command for it, yet. [02:24] Yeah, but that's not much of a UI ;) [02:27] mwhudson: what ISP do you have? [02:30] lifeless: vodafone [02:31] but my local connection is through a telecom 'cabinet' [02:31] for ADSL ? [02:31] yar [02:31] I'm peaking at ~ 128K [02:31] which is, frankly, sucky. [02:31] oof [02:31] what does your modem think you're synced at? [02:32] dunno, don't have the admin password for it [02:33] are you still in the short term rental place? [02:33] yes [02:33] 3 months 1 week to go [02:34] Not that he's counting down or anything. [02:34] i'm not too surprised that your internet sucks then [02:34] hah [02:34] its a private residence the owner is on sabbatical, as opposed to a serial rent environment [02:34] ah ok [02:34] we've taken over the phone account etc [02:34] I suspect a call to telecom is in order [02:35] maybe the owner was on an old, capped plan? [02:35] 128K is 1Mbit [02:35] noone seems to bother with that any more though [02:35] I changed the plan to the upsized one [02:35] one possibility is an adsl1 modem [02:35] another is bad wiring [02:36] distance to the exchange? [02:36] who knows [02:36] telecome knows [02:36] thats who knows [02:39] spm: is ParseOptions: packet 41290 TCPOPT_SACK option truncated, skipping other options [02:39] spm: a meaningful worry - just use a longer snaplen and repeat? [02:50] lifeless: not sure. I usually grab the entire snaplen - debugging http so you want to see the data. [02:50] * igc lunch [02:50] heh, in this case the data is just a pack so 'meh' [02:51] or ssh, so equally [02:51] though [02:51] we may want to write a ssh analyzer [02:51] if we can get the session key out of twisted ? [02:51] mwhudson: ^ [02:51] mwhudson: would that be a lot of work, do you think? [02:52] lifeless: no idea at all [02:52] it would be at least a moderate amount of work [02:52] mwhudson: try suggesting it's impossible perhaps? [02:52] spm: -s doesn't seem to give me a graph [02:53] lifeless: -S create time sequence graph[s] [02:54] wrong case. [02:55] the stock xplot via apt, *may* not be able to deal with the output generated tho. on just about every other system I've used, I've had to manually compile 'his' version to have it work. [02:55] also, for nuisance value, the microwave here is on the same freq as the ap [02:55] \o/ [02:55] so dinner time is no-internets-time [02:56] awesomely awesome! [02:56] I know my wireless mouse used to get horribly laggy when the wireless was busy. [02:56] hmm, it decided a2b was empty [02:56] but b2a has dome something [03:00] that sounds ... vaugely right. a2b would be likely just acks. [03:01] tcptrace -l, to get a view? [03:01] summary text view as in. [03:01] otp [03:01] err - not summary. whatever. :-) [03:36] turns out to be wifi fail [03:36] however, am now getting 800KB/s to melbourne [03:38] sweet [03:38] still a bit bursty [03:39] drops down to 200 every now and then [03:39] going to be interesting to debug on top of :P [03:42] verra noisy [03:43] I wonder if I'm going to need a local ping background measurement ;P [03:53] 700K to b.l.n [03:53] \o/ [03:54] 800 [03:54] 850... you can do it [03:54] 100 :( [03:54] sawtooth [03:56] lifeless: i guess doing a regular bzr+ssh transfer off say devpad would be an interesting comparison [03:57] does hitchhiker have a non interactive mode ? [03:58] echo 'get /~vcs-imports/linux/trunk/.bzr/repository/packs/7590053cc142a5cb7ca8d0e33022ce2a.pack' | hitchhiker bzr+ssh://bazaar.launchpad.net :P [03:59] boom [03:59] I saw the same massive dropoff you did [04:05] spm: take pity on me; give me a sample session with tcptrace + xplot [04:05] I hav a trace [04:05] tcptrace -l shows sensible things [04:05] :-) [04:05] sure. [04:06] have you the trace somewhere I can munge at the same data? [04:06] sure [04:06] let me shove it on devpad [04:06] ta [04:07] the files ssh and http on devpad:~robertc - copying now [04:09] done [04:09] or thereabouts [04:10] ta, grabbing [04:10] You don't have permission to access /~robertc on this server. haha [04:11] I don't? [04:11] I beg to differ [04:11] oh wait. nm. I was using http access. lemme just scp it. [04:11] yah, not in ~public_html [04:14] righto. so looking at http. tcptrace -l http ;; on a bigger more complex snarf, i'd start with -b (brief) to get an idea of which streams to look at, but here is easy. [04:14] so no supriose that all the data is coming from crowberry; a is just acking. [04:15] right, I tried to capture just one file [04:15] well, there is the initial request ;) [04:15] :-) [04:15] tcptrace -G http <== builds *all* the graphs [04:16] xplot -x b2a_tsg.xpl a2b_tsg.xpl & [04:16] the -x and specifying both will allow you to zoom in on 1, and see the same zoom on the other at the same time. way cool. [04:17] I find it useful to not touch the vertical adjust, but stretch the two graphs fully horizontally. ymmv. [04:17] bad flag argument -x [04:17] right. you need his version of xplot then. [04:17] grah [04:17] ok [04:17] has he considered getting his patches upstream ? [04:17] no idea :-) [04:18] gawd dammit. one day I will remember that right click exits. [04:19] I wonder if tim sheppard even knows about this patchset [04:19] possibly not [04:19] shep at xplot.org [04:19] ^ go, mail him. [04:19] will do [04:19] but first... :-) [04:20] hmm, C code needs a little love [04:20] * spm starts to play spot the yak ;-) [04:20] ok, much better [04:21] it could use a window bitmap cache [04:21] if you stretch horiz, you'll be able to better zoom. vert if really useful imho. [04:21] so flat bits are stalls ? [04:21] so here we're basically looking for 1 main thing; other maybes. is the tcp window full. which - apparently is sure as hell isn't. [04:21] slowdowsn of some sort, yeah [04:22] aroud 12:54:20 "something" happened [04:22] hah! it does tmiezones [04:23] oh wow. zoom on ~ 12:54:19 window full. [04:23] And around 13:22, lunch happened. [04:23] * spiv makes it so [04:23] :-) [04:23] 14:54:19 you mean :P [04:23] lifeless: whatever :-D [04:23] but note also the large numbers of '1's and '2's. [04:23] chatty [04:23] looks like a fail for acks to be received [04:24] how do you you zoom out [04:24] left click [04:24] zoom by selecting; then left click [04:24] so whats a 1 and a 2 - or should I e reading at this point [04:25] rtfm, resends, once, twice of the same packet istr. [04:25] so you're thinking massive packet loss ? [04:26] the yellow band is the window size, right ? [04:26] actually - 1/2 I think are duplictae acking. [04:26] the delta between the horizonatal lines is the window [04:26] yellow and green [04:26] 53:24.5 has a similar region [04:27] hah, is one green?! [04:27] yeah. a couple of window fulls, imho, isn't bad. not great, but not bad. keeping in mind this is *your* window (aiui), not crowberrys. [04:28] sorry, I'm unclar [04:28] if you zoom in on the start, you can see the scaling take off. [04:28] is the gap 'data in the window' or 'amount that can be in the window' [04:28] amount that can be in the window. [04:28] ok [04:29] and can we tell amount in flight/in the receiver buffer [04:29] each white cross, is in fact a line with 2 arrows, zoom right in on one. that's a data packet. [04:29] I see black lines with arrows [04:30] http://www.tcptrace.org/manual/node12_mn.html <== check the 2nd diagram by way of example [04:32] based on that - it *looks* to me like crowberry isn't hammering you as hard as it could; or your pipe is full. ?? [04:32] tho the backoff from ~ 3/5ths to end is... odd [04:33] * spm checks throughput... [04:34] hrm. ~ 500kps. not too shabby. [04:34] avg [04:34] peaked at 880 or so [04:34] so lots of room for improvement [04:35] which, assuming default tcpwindow sizings on crowberry is about max for london to AU given latency. [04:35] I'm in nz ;) [04:35] so slightly closer eh? ;-) [04:35] no, sadly, no [04:35] can/should we tweak the window settings up ? [04:36] 350ms 64 bytes from crowberry.canonical.com (91.189.90.11): icmp_seq=5 ttl=42 time=328 ms [04:36] we can, trivially. I'd advise yes. but would want to cross check 1. what they actually are. [04:36] bah [04:36] 64 bytes from crowberry.canonical.com (91.189.90.11): icmp_seq=5 ttl=42 time=328 ms [04:36] and ask why the defaults aren't large enough to handle the earth. [04:36] 2. watch carefully JIC of funkies (I doubt we'd see any) [04:36] nfi. that's the default that linux kernels come with aiui. [04:36] yeah [04:37] the aarnet mirror admin [04:37] ho, Bazaar folk. what is the preferred pastebin? [04:37] swears that everyone should up their window settings [04:37] yeah. that supersize macca's theirs [04:37] they* [04:37] nod [04:37] bignose: one that works. And not pastie. [04:37] me, I use pastebinit [04:37] spm: thanks for this; I think there is more to nut out here [04:37] my favourite, , has been responding 500 errors for weeks. [04:38] spm: I need to do a couple of 'new country' chores before shops close. [04:38] lifeless: np. i suspect there is, but it's all clues. [04:38] I'll try that one, lifeless [04:38] shoo [04:38] spm: but I might grab a little more of your time to look at the ssh trace after, if thats ok with you [04:38] surely [04:38] lifeless: what URL? [04:38] its been .... some time, since I did this sort of analysis myself [04:38] bignose: apt-get install pastebinit [04:38] eek. crowberry is the, small, default. [04:39] spm: I can has RT ticket for 'we run servers please' ? [04:39] ooh! naughty Ubuntu worker, everyone knows ‘aptitude’ is the command to recommend :-) [04:39] spm: I mean, should I file an RT saying all our servers facing the net might need stuff ? [04:39] if you create said RT, I don't see why not ;-) [04:39] lifeless: sure. it'll help us track it at least. [04:44] fwiw. the *best* way to do these is get two sniffs at the same time. in this case, one on your machine, and one on crowberry. and display the sender from crowberry (b2a) and receiver at yours. you get a better view of the packet flows with times and whats missing etc. [04:50] I've had a crash on ‘bzr shelve’, with a “MalformedTransform” exception [04:50] there appear to be some bug reports with that same error, but different use cases [04:51] Launchpad is not displaying bug reports properly for me. can someone check whether the crash I'm getting is already reported, and/or submit that traceback to the report? [04:52] it's reproducible (I've pasted the version where I used ‘--no-plugins’), and I can make the repository available if it would help diagnosis. [04:55] spm: that would be awesome. I can has packet capture privs on crowberry ? :) [04:55] hahaha. no. *I* wouldn't even ask for that. :-) [05:00] mwhudson: how do I get that linux pack onto the staging bazaar.launchpad.net ? [05:01] mwhudson: /win 67 [05:03] spm: um, no quick idea, i guess you can sftp it up... [05:04] it seems to be because the shelve involves undoing a rename [05:04] but meanwhile the original filename is occupied by a new file, that isn't versioned. [05:04] so I'm not sure what I expect ‘shelve’ to do in that case. no crash, of course, but I don't know the right behaviour. [05:05] what bzr version? [05:06] also is there a bug about the rendering for you ? [05:06] [05:06] no, I don't have a Launchpad account and it's not working well for me in any case :-) [05:06] Bazaar version 2.1.1 [05:31] bignose: ok, we'll need to open a bug for you for that [05:31] bignose: you say there isn't a bug open about launchpad rendering badly? [05:32] bignose: could you put an email together, to me, with screen shots and so on that shows lp behaving badly, and I'll make a bug report out of it [06:01] any upload anything to sourceforge using bzr? [06:02] should I create a seperate trunk and branches directory (I am more familiar with doing this in svn) or just push it all up to SF? [06:14] PainBank: I haven't uses sf in a long time but bzr doesn't require specific directories like trunk and branches. You can probably push it all up as long as the project devs agree to treat dir x as trunk / mainline. [06:16] * fullermd eep!'s at broken dirstate code :( [06:20] PainBank: this article seems to be doing what you want http://sina.salek.ws/content/migrating-subversion-bazaar-including-special-guide-sourceforge-projects [06:57] fullermd: ? [06:59] lifeless: https://bugs.launchpad.net/bugs/582656 :( [06:59] Launchpad bug 582656 in Bazaar "Compiled _dirstate_helpers causes crash with specified file commands (affected: 1, heat: 6)" [Critical,Confirmed] [07:41] lifeless: shelve crash reported in Debian BTS now, [07:41] lifeless: the Launchpad rendering problems seem to be a strange interaction between Iceweasel and my proxy; change either of those and it's alright. [07:42] lifeless: shelve crash reported in Debian BTS now, (fixed the URL) [07:45] bignose: what proxy are you using ? [07:45] launchpad is on https generally, so I wouldn't expect anything in it except -perhaps- css files to hit your proxy [07:45] nevertheless, there is a problem :) [07:55] hi all [07:55] vila_: Sorry for using your nick, I'll leave === vila_ is now known as vila [07:59] tsk tsk [08:05] vila: hi [08:07] vila: i noticed you have claimed the reivew https://code.launchpad.net/~parthm/bzr/538868-message-for-heavy-checkout/+merge/25336 ... i could land it if it looks ok it you [08:07] parthm: hi ! [08:07] vila: or if i can get another reviewer :) [08:08] parthm: I didn't claim it, I suspect jam assigned me instead, I plan to review it soon [08:08] Maybe vila_ claimed it for you. [08:08] vila: ah. ok :) .. no hurry. was just wondering. [08:08] fullermd: ha :) [08:08] annoying squatter this vila_ ... [08:10] lifeless: I can't trivially run selftest, lacking testtools :| [08:10] lifeless: Won't have time the next few days to try and fudge it into place; got a week of stuff to do before I leave town Friday. [08:14] fullermd, lifeless : babune has a freebsd8 slave, can I help ? [08:14] Mmm. Building the bzr-2.1.1 tag in my 2.1 branch seems to die too, though the installed 2.1.1 doesn't [08:15] It was rebuilt since my last OS/python upgrade though, so it's not that... [08:15] Holy crow it takes a long time to branch bzr.dev on local disk. [08:18] die ? How ? [08:19] gnight [08:19] Hm. It seems to work on my server, which is fbsd8/i386/py2.6.4. Failing on my workstation, fbsd-current/amd64/py2.6.5. So, if everything's different, the result is different :p [08:19] Oh, pyrex 0.9.8.6 vs 0.9.9 too. Hm. [08:20] Maybe I can test that switch quick-like... [08:20] That could explain why the system-wide 2.1.1 works, but hand-building it doesn't; the system-wide has the generated files from the tarball. [08:20] In fact... [08:21] * vila holds his breath and hopes fullermd will finish his sentence soon enough [08:22] Yes, if I build from the 2.1.1 tarball, it works. If I build from the bzr-2.1.1 tag it blows chunks. diff shows only the generated .c/.h files as different between the trees. [08:22] So it sounds like pyrex 0.9.9. [08:24] hmm, pyrex 0.9.9 here, but maybe the .c files has not been modified since I upgraded.... [08:24] err, the .pyx files of course [08:24] one more hole in babune setup.... [08:24] a lucky one this time\ [08:25] Oh, that should be quick to test with that repro script (or manually) [08:25] Actually, don't even need a modified file in the tree. [08:25]