| igc | morning | 00:38 |
|---|---|---|
| mgz | morning Ian. | 00:38 |
| mgz | request: could you look at https://code.launchpad.net/~simon-kersey/bzr-explorer/568728-fix/+merge/24306 at some point? | 00:38 |
| mgz | 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) | 00:39 |
| === davidstrauss_ is now known as davidstrauss | ||
| bignose | mgz: it would be churlish of me to chime in on the subject of Launchpad as an OpenID consumer, wouldn't it? :-) | 00:41 |
| bignose | 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:42 |
| igc | mgz: I hope to get back to code reviews today | 00:43 |
| bignose | igc: glad to see you back in the saddle | 00:44 |
| igc | thanks bignose! | 00:44 |
| mgz | great, thanks. | 00:44 |
| rysiek|pl | hi guys | 01:10 |
| rysiek|pl | anybody care to help a bit? | 01:10 |
| rysiek|pl | I just nuked my bzr repo | 01:11 |
| rysiek|pl | 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:11 |
| rysiek|pl | 1. restore a backup (40 revisions back), and in checouts do bzr up; resolve conflicts, bzr ci? | 01:12 |
| rysiek|pl | 2. just ignore the backups and move a checkout as the new repo? | 01:12 |
| rysiek|pl | 3. do bzr pull IN the backup-restored repo FROM the checkout? | 01:13 |
| lifeless | 3 sounds plausible to me | 01:13 |
| rysiek|pl | 4. bzr push the checkoput INTO the backup-restored repo | 01:13 |
| lifeless | as long as you hav heavyweight checkouts, not lightweight (the default is heavy) | 01:13 |
| lifeless | 3 and 4 are equivalent | 01:13 |
| rysiek|pl | heavy, heavy | 01:14 |
| rysiek|pl | okay, great | 01:14 |
| rysiek|pl | so, restore a backup, bzr push/pull | 01:14 |
| rysiek|pl | trying. | 01:14 |
| === spiv_ is now known as spiv | ||
| lifeless | spiv: hi | 01:22 |
| lifeless | mwhudson: also ping | 01:22 |
| mwhudson | lifeless: hello | 01:22 |
| lifeless | bzr smart server in lp | 01:22 |
| lifeless | what diagnostics can I get on that ? | 01:22 |
| mwhudson | not terribly much easily :/ | 01:22 |
| lifeless | also, is it still running as a subprocess; and what happens to its stdin/stdout - are they connected to twisted ? | 01:23 |
| mwhudson | i think unhandled exceptions should go into oops reports | 01:23 |
| mwhudson | yes and yes | 01:23 |
| lifeless | trying to figure out why we only get 21KB/s from lp; gathering data as first step | 01:23 |
| mwhudson | it's running bzr lp-serve user-id --inet | 01:23 |
| lifeless | shoving this under udd as 'slow checkouts hurt distro users' | 01:23 |
| mwhudson | ish ayway | 01:23 |
| lifeless | ok | 01:26 |
| lifeless | do we have statistics / info gathering on the twisted master | 01:26 |
| lifeless | I'm particularly interested in socket windows (raw and ssh wrapped), packet delays and so on | 01:26 |
| spiv | lifeless: morning. | 01:26 |
| lifeless | spiv: python-dev, antoine's message 'Summing up' may be of interest to us and the smart server in standalone mode | 01:27 |
| mwhudson | lifeless: not in any very structured way | 01:27 |
| lifeless | mwhudson: is that yes if I ask nicely? or 'no, but I didn't want to say that' ? :) | 01:27 |
| spiv | lifeless: ta, will look | 01:28 |
| mwhudson | 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:28 |
| * mwhudson sucks a 50 meg file off launchpad over bzr+ssh using hitchiker and watches the network in system monitor | 01:29 | |
| mwhudson | it's quite surprising | 01:29 |
| lifeless | do tell | 01:30 |
| mwhudson | lifeless: http://people.canonical.com/~mwh/sm.png | 01:30 |
| lifeless | yes | 01:31 |
| lifeless | there is something wrong ;) | 01:31 |
| mwhudson | it ramps up slowly to a decent rate, then drops right down and slowly ramps up again | 01:31 |
| mwhudson | it's a bit odd | 01:32 |
| lifeless | I would expect this as a buffering interaction | 01:32 |
| lifeless | if a pipe somewhere fills | 01:33 |
| lifeless | process swaps/stops getting time slices | 01:33 |
| lifeless | the tcp window may not open enough, and can take time to recover | 01:33 |
| mwhudson | http grab of the same file is also behaving a bit strangely, but very differently | 01:34 |
| mwhudson | http://people.canonical.com/~mwh/sm2.png | 01:36 |
| rysiek|pl | lifeless: worked like a charm, thanks | 01:44 |
| rysiek|pl | guys, maybe it would be a good idea to estimate, what's the average bandwidth in both situations? | 01:46 |
| rysiek|pl | 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 |
| lamalex | Hey, does anyone know if there's already a bzr equivalent of the git-version-gen autoconf script? | 01:47 |
| lamalex | I know I can adapt that to be for bzr, but I figured I'd see if someone had already done it | 01:48 |
| rysiek|pl | 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 |
| rysiek|pl | to see if anything strange happens, or not | 01:48 |
| lifeless | lamalex: not that I know of | 01:55 |
| lifeless | lamalex: I've done something similar for setup.py | 01:55 |
| lifeless | lamalex: and drizzle does something similar too | 01:55 |
| lifeless | mtaylor: ^ show lamalex the bzr version stuff for drizzle | 01:56 |
| mtaylor | lifeless: aroo? | 01:56 |
| lifeless | mtaylor: so http peaks at 1mb | 01:56 |
| lifeless | bah | 01:56 |
| mtaylor | lifeless: oh - gotcha | 01:56 |
| lifeless | mwhudson: so http peaks at 1MB | 01:56 |
| lifeless | and bzr+ssh at 512KB | 01:56 |
| mtaylor | lamalex: it's all in pandora-build ... (which you should use for your autoconf needs anyway) ... but specifically | 01:57 |
| mwhudson | lifeless: yeah, after the initial fast burst though http followed a vaguely similar pattern to bzr+ssh | 01:58 |
| mtaylor | lamalex: http://bazaar.launchpad.net/~mordred/pandora-build/devel/annotate/head:/m4/pandora_vc_build.m4 | 01:58 |
| mtaylor | lamalex: I've got to run at the moment - are you going to be around in 5 hours? | 01:58 |
| lifeless | spm: whats that darn tool you swear by | 01:58 |
| mwhudson | less of a sawtooth i guess | 01:58 |
| spm | lifeless: 'find' | 01:58 |
| lifeless | spm: not swear at | 01:58 |
| * mwhudson was going for 'awk' | 01:58 | |
| lamalex | mtaylor, no probably not | 01:59 |
| lamalex | but maybe | 01:59 |
| spm | lifeless: a hammer? | 01:59 |
| spm | context may help - what are you trying to do :-) | 01:59 |
| lifeless | spm: for network window / efficiency / analysis | 01:59 |
| mtaylor | lamalex: ok. well, I can certainly help you out on this if you still need it when I get back or tomorrow | 01:59 |
| spm | AHhhhhh! tcptrace + xplot | 01:59 |
| lamalex | mtaylor, thanks | 01:59 |
| mtaylor | lamalex: sure! | 01:59 |
| bignose | yikes, m4. | 02:00 |
| bignose | isn't there a better templating solution that's dependably installed? | 02:00 |
| spm | http://www.tcptrace.org/ and http://www.tcptrace.org/manual/node12_mn.html specifically. sheer gold. | 02:00 |
| lifeless | mwhudson: what file were you testing with | 02:01 |
| mtaylor | bignose: well, not that's integrated with autoconf, no | 02:01 |
| bignose | s/better/more human-maintainable/ | 02:01 |
| mwhudson | lifeless: http://bazaar.launchpad.net/~vcs-imports/linux/trunk/.bzr/repository/packs/7590053cc142a5cb7ca8d0e33022ce2a.pack | 02:01 |
| mtaylor | 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 |
| mtaylor | ok. I'm off. have fun all | 02:03 |
| joerg_ | hi | 02:17 |
| joerg_ | how can I move everything in the root dir of my branch to a subdir? | 02:17 |
| joerg_ | like: | 02:17 |
| joerg_ | bzr mkdir src | 02:17 |
| joerg_ | bzr mv . src/myproject | 02:18 |
| joerg_ | which of couse does not work ;) | 02:18 |
| lifeless | bzr mv $(ls | grep -v src) src/myproject | 02:19 |
| joerg_ | hmm....that will fail because of some files that aren't under version control | 02:19 |
| lifeless | well, adjust appropriately | 02:19 |
| lifeless | perhaps bzr ls --versioned | 02:20 |
| fullermd | Need a bzr pivot_root... | 02:21 |
| lifeless | fullermd: wouldn't address this case | 02:21 |
| lifeless | fullermd: (and we have it) | 02:21 |
| joerg_ | lifeless, well, thx....that works ;) | 02:21 |
| joerg_ | only .bzignore shouldn't be moved I guess ;) | 02:21 |
| lifeless | right | 02:21 |
| joerg_ | but I will simply bzr revert it | 02:21 |
| lifeless | you'll want to mv that back :) | 02:21 |
| lifeless | or that, sure | 02:21 |
| fullermd | We do? Where? | 02:23 |
| lifeless | tree transform | 02:24 |
| lifeless | it can handle a merge that moves the root | 02:24 |
| lifeless | we don't have a userspace command for it, yet. | 02:24 |
| fullermd | Yeah, but that's not much of a UI ;) | 02:24 |
| lifeless | mwhudson: what ISP do you have? | 02:27 |
| mwhudson | lifeless: vodafone | 02:30 |
| mwhudson | but my local connection is through a telecom 'cabinet' | 02:31 |
| lifeless | for ADSL ? | 02:31 |
| mwhudson | yar | 02:31 |
| lifeless | I'm peaking at ~ 128K | 02:31 |
| lifeless | which is, frankly, sucky. | 02:31 |
| mwhudson | oof | 02:31 |
| mwhudson | what does your modem think you're synced at? | 02:31 |
| lifeless | dunno, don't have the admin password for it | 02:32 |
| mwhudson | are you still in the short term rental place? | 02:33 |
| lifeless | yes | 02:33 |
| lifeless | 3 months 1 week to go | 02:33 |
| fullermd | Not that he's counting down or anything. | 02:34 |
| mwhudson | i'm not too surprised that your internet sucks then | 02:34 |
| lifeless | hah | 02:34 |
| lifeless | its a private residence the owner is on sabbatical, as opposed to a serial rent environment | 02:34 |
| mwhudson | ah ok | 02:34 |
| lifeless | we've taken over the phone account etc | 02:34 |
| lifeless | I suspect a call to telecom is in order | 02:34 |
| mwhudson | maybe the owner was on an old, capped plan? | 02:35 |
| lifeless | 128K is 1Mbit | 02:35 |
| mwhudson | noone seems to bother with that any more though | 02:35 |
| lifeless | I changed the plan to the upsized one | 02:35 |
| lifeless | one possibility is an adsl1 modem | 02:35 |
| lifeless | another is bad wiring | 02:35 |
| mwhudson | distance to the exchange? | 02:36 |
| lifeless | who knows | 02:36 |
| lifeless | telecome knows | 02:36 |
| lifeless | thats who knows | 02:36 |
| lifeless | spm: is ParseOptions: packet 41290 TCPOPT_SACK option truncated, skipping other options | 02:39 |
| lifeless | spm: a meaningful worry - just use a longer snaplen and repeat? | 02:39 |
| spm | lifeless: not sure. I usually grab the entire snaplen - debugging http so you want to see the data. | 02:50 |
| * igc lunch | 02:50 | |
| lifeless | heh, in this case the data is just a pack so 'meh' | 02:50 |
| lifeless | or ssh, so equally | 02:51 |
| lifeless | though | 02:51 |
| lifeless | we may want to write a ssh analyzer | 02:51 |
| lifeless | if we can get the session key out of twisted ? | 02:51 |
| lifeless | mwhudson: ^ | 02:51 |
| lifeless | mwhudson: would that be a lot of work, do you think? | 02:51 |
| mwhudson | lifeless: no idea at all | 02:52 |
| mwhudson | it would be at least a moderate amount of work | 02:52 |
| spm | mwhudson: try suggesting it's impossible perhaps? | 02:52 |
| lifeless | spm: -s doesn't seem to give me a graph | 02:52 |
| spm | lifeless: -S create time sequence graph[s] | 02:53 |
| spm | wrong case. | 02:54 |
| spm | 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 |
| lifeless | also, for nuisance value, the microwave here is on the same freq as the ap | 02:55 |
| spm | \o/ | 02:55 |
| lifeless | so dinner time is no-internets-time | 02:55 |
| spm | awesomely awesome! | 02:56 |
| spm | I know my wireless mouse used to get horribly laggy when the wireless was busy. | 02:56 |
| lifeless | hmm, it decided a2b was empty | 02:56 |
| lifeless | but b2a has dome something | 02:56 |
| spm | that sounds ... vaugely right. a2b would be likely just acks. | 03:00 |
| spm | tcptrace -l, to get a view? | 03:01 |
| spm | summary text view as in. | 03:01 |
| lifeless | otp | 03:01 |
| spm | err - not summary. whatever. :-) | 03:01 |
| lifeless | turns out to be wifi fail | 03:36 |
| lifeless | however, am now getting 800KB/s to melbourne | 03:36 |
| spm | sweet | 03:38 |
| lifeless | still a bit bursty | 03:38 |
| lifeless | drops down to 200 every now and then | 03:39 |
| lifeless | going to be interesting to debug on top of :P | 03:39 |
| lifeless | verra noisy | 03:42 |
| lifeless | I wonder if I'm going to need a local ping background measurement ;P | 03:43 |
| lifeless | 700K to b.l.n | 03:53 |
| lifeless | \o/ | 03:53 |
| lifeless | 800 | 03:54 |
| lifeless | 850... you can do it | 03:54 |
| lifeless | 100 :( | 03:54 |
| lifeless | sawtooth | 03:54 |
| mwhudson | lifeless: i guess doing a regular bzr+ssh transfer off say devpad would be an interesting comparison | 03:56 |
| lifeless | does hitchhiker have a non interactive mode ? | 03:57 |
| lifeless | echo 'get /~vcs-imports/linux/trunk/.bzr/repository/packs/7590053cc142a5cb7ca8d0e33022ce2a.pack' | hitchhiker bzr+ssh://bazaar.launchpad.net :P | 03:58 |
| lifeless | boom | 03:59 |
| lifeless | I saw the same massive dropoff you did | 03:59 |
| lifeless | spm: take pity on me; give me a sample session with tcptrace + xplot | 04:05 |
| lifeless | I hav a trace | 04:05 |
| lifeless | tcptrace -l shows sensible things | 04:05 |
| spm | :-) | 04:05 |
| spm | sure. | 04:05 |
| spm | have you the trace somewhere I can munge at the same data? | 04:06 |
| lifeless | sure | 04:06 |
| lifeless | let me shove it on devpad | 04:06 |
| spm | ta | 04:06 |
| lifeless | the files ssh and http on devpad:~robertc - copying now | 04:07 |
| lifeless | done | 04:09 |
| lifeless | or thereabouts | 04:09 |
| spm | ta, grabbing | 04:10 |
| spm | You don't have permission to access /~robertc on this server. haha | 04:10 |
| lifeless | I don't? | 04:11 |
| lifeless | I beg to differ | 04:11 |
| spm | oh wait. nm. I was using http access. lemme just scp it. | 04:11 |
| lifeless | yah, not in ~public_html | 04:11 |
| spm | 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 |
| spm | so no supriose that all the data is coming from crowberry; a is just acking. | 04:14 |
| lifeless | right, I tried to capture just one file | 04:15 |
| lifeless | well, there is the initial request ;) | 04:15 |
| spm | :-) | 04:15 |
| spm | tcptrace -G http <== builds *all* the graphs | 04:15 |
| spm | xplot -x b2a_tsg.xpl a2b_tsg.xpl & | 04:16 |
| spm | 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:16 |
| spm | I find it useful to not touch the vertical adjust, but stretch the two graphs fully horizontally. ymmv. | 04:17 |
| lifeless | bad flag argument -x | 04:17 |
| spm | right. you need his version of xplot then. | 04:17 |
| lifeless | grah | 04:17 |
| lifeless | ok | 04:17 |
| lifeless | has he considered getting his patches upstream ? | 04:17 |
| spm | no idea :-) | 04:17 |
| spm | gawd dammit. one day I will remember that right click exits. | 04:18 |
| lifeless | I wonder if tim sheppard even knows about this patchset | 04:19 |
| spm | possibly not | 04:19 |
| lifeless | shep at xplot.org | 04:19 |
| lifeless | ^ go, mail him. | 04:19 |
| spm | will do | 04:19 |
| spm | but first... :-) | 04:19 |
| lifeless | hmm, C code needs a little love | 04:20 |
| * spm starts to play spot the yak ;-) | 04:20 | |
| lifeless | ok, much better | 04:20 |
| lifeless | it could use a window bitmap cache | 04:21 |
| spm | if you stretch horiz, you'll be able to better zoom. vert if really useful imho. | 04:21 |
| lifeless | so flat bits are stalls ? | 04:21 |
| spm | 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 |
| spm | slowdowsn of some sort, yeah | 04:21 |
| spm | aroud 12:54:20 "something" happened | 04:22 |
| lifeless | hah! it does tmiezones | 04:22 |
| spm | oh wow. zoom on ~ 12:54:19 window full. | 04:23 |
| spiv | And around 13:22, lunch happened. | 04:23 |
| * spiv makes it so | 04:23 | |
| spm | :-) | 04:23 |
| lifeless | 14:54:19 you mean :P | 04:23 |
| spm | lifeless: whatever :-D | 04:23 |
| spm | but note also the large numbers of '1's and '2's. | 04:23 |
| lifeless | chatty | 04:23 |
| spm | looks like a fail for acks to be received | 04:23 |
| lifeless | how do you you zoom out | 04:24 |
| spm | left click | 04:24 |
| spm | zoom by selecting; then left click | 04:24 |
| lifeless | so whats a 1 and a 2 - or should I e reading at this point | 04:24 |
| spm | rtfm, resends, once, twice of the same packet istr. | 04:25 |
| lifeless | so you're thinking massive packet loss ? | 04:25 |
| lifeless | the yellow band is the window size, right ? | 04:26 |
| spm | actually - 1/2 I think are duplictae acking. | 04:26 |
| spm | the delta between the horizonatal lines is the window | 04:26 |
| spm | yellow and green | 04:26 |
| lifeless | 53:24.5 has a similar region | 04:26 |
| lifeless | hah, is one green?! | 04:27 |
| spm | 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:27 |
| lifeless | sorry, I'm unclar | 04:28 |
| spm | if you zoom in on the start, you can see the scaling take off. | 04:28 |
| lifeless | is the gap 'data in the window' or 'amount that can be in the window' | 04:28 |
| spm | amount that can be in the window. | 04:28 |
| lifeless | ok | 04:28 |
| lifeless | and can we tell amount in flight/in the receiver buffer | 04:29 |
| spm | each white cross, is in fact a line with 2 arrows, zoom right in on one. that's a data packet. | 04:29 |
| lifeless | I see black lines with arrows | 04:29 |
| spm | http://www.tcptrace.org/manual/node12_mn.html <== check the 2nd diagram by way of example | 04:30 |
| spm | 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 |
| spm | tho the backoff from ~ 3/5ths to end is... odd | 04:32 |
| * spm checks throughput... | 04:33 | |
| spm | hrm. ~ 500kps. not too shabby. | 04:34 |
| lifeless | avg | 04:34 |
| lifeless | peaked at 880 or so | 04:34 |
| lifeless | so lots of room for improvement | 04:34 |
| spm | which, assuming default tcpwindow sizings on crowberry is about max for london to AU given latency. | 04:35 |
| lifeless | I'm in nz ;) | 04:35 |
| spm | so slightly closer eh? ;-) | 04:35 |
| lifeless | no, sadly, no | 04:35 |
| lifeless | can/should we tweak the window settings up ? | 04:35 |
| lifeless | 350ms 64 bytes from crowberry.canonical.com (91.189.90.11): icmp_seq=5 ttl=42 time=328 ms | 04:36 |
| spm | we can, trivially. I'd advise yes. but would want to cross check 1. what they actually are. | 04:36 |
| lifeless | bah | 04:36 |
| lifeless | 64 bytes from crowberry.canonical.com (91.189.90.11): icmp_seq=5 ttl=42 time=328 ms | 04:36 |
| lifeless | and ask why the defaults aren't large enough to handle the earth. | 04:36 |
| spm | 2. watch carefully JIC of funkies (I doubt we'd see any) | 04:36 |
| spm | nfi. that's the default that linux kernels come with aiui. | 04:36 |
| lifeless | yeah | 04:36 |
| lifeless | the aarnet mirror admin | 04:37 |
| bignose | ho, Bazaar folk. what is the preferred pastebin? | 04:37 |
| lifeless | swears that everyone should up their window settings | 04:37 |
| spm | yeah. that supersize macca's theirs | 04:37 |
| spm | they* | 04:37 |
| spm | nod | 04:37 |
| lifeless | bignose: one that works. And not pastie. | 04:37 |
| lifeless | me, I use pastebinit | 04:37 |
| lifeless | spm: thanks for this; I think there is more to nut out here | 04:37 |
| bignose | my favourite, <URL:http://paste.ca/>, has been responding 500 errors for weeks. | 04:37 |
| lifeless | spm: I need to do a couple of 'new country' chores before shops close. | 04:38 |
| spm | lifeless: np. i suspect there is, but it's all clues. | 04:38 |
| bignose | I'll try that one, lifeless | 04:38 |
| spm | shoo | 04:38 |
| lifeless | 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 |
| spm | surely | 04:38 |
| bignose | lifeless: what URL? | 04:38 |
| lifeless | its been .... some time, since I did this sort of analysis myself | 04:38 |
| lifeless | bignose: apt-get install pastebinit | 04:38 |
| spm | eek. crowberry is the, small, default. | 04:38 |
| lifeless | spm: I can has RT ticket for 'we run servers please' ? | 04:39 |
| bignose | ooh! naughty Ubuntu worker, everyone knows ‘aptitude’ is the command to recommend :-) | 04:39 |
| lifeless | spm: I mean, should I file an RT saying all our servers facing the net might need stuff ? | 04:39 |
| spm | if you create said RT, I don't see why not ;-) | 04:39 |
| spm | lifeless: sure. it'll help us track it at least. | 04:39 |
| spm | 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:44 |
| bignose | I've had a crash on ‘bzr shelve’, with a “MalformedTransform” exception <URL:http://pastebin.com/yk6ziW8V> | 04:50 |
| bignose | there appear to be some bug reports with that same error, but different use cases | 04:50 |
| bignose | 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:51 |
| bignose | 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:52 |
| lifeless | spm: that would be awesome. I can has packet capture privs on crowberry ? :) | 04:55 |
| spm | hahaha. no. *I* wouldn't even ask for that. :-) | 04:55 |
| lifeless | mwhudson: how do I get that linux pack onto the staging bazaar.launchpad.net ? | 05:00 |
| lifeless | mwhudson: /win 67 | 05:01 |
| mwhudson | spm: um, no quick idea, i guess you can sftp it up... | 05:03 |
| bignose | it seems to be because the shelve involves undoing a rename | 05:04 |
| bignose | but meanwhile the original filename is occupied by a new file, that isn't versioned. | 05:04 |
| bignose | 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:04 |
| lifeless | what bzr version? | 05:05 |
| lifeless | also is there a bug about the rendering for you ? | 05:06 |
| bignose | <URL:http://pastebin.com/yk6ziW8V> | 05:06 |
| bignose | no, I don't have a Launchpad account and it's not working well for me in any case :-) | 05:06 |
| bignose | Bazaar version 2.1.1 | 05:06 |
| lifeless | bignose: ok, we'll need to open a bug for you for that | 05:31 |
| lifeless | bignose: you say there isn't a bug open about launchpad rendering badly? | 05:31 |
| lifeless | 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 | 05:32 |
| PainBank | any upload anything to sourceforge using bzr? | 06:01 |
| PainBank | 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:02 |
| parthm | 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:14 |
| * fullermd eep!'s at broken dirstate code :( | 06:16 | |
| parthm | PainBank: this article seems to be doing what you want http://sina.salek.ws/content/migrating-subversion-bazaar-including-special-guide-sourceforge-projects | 06:20 |
| lifeless | fullermd: ? | 06:57 |
| fullermd | lifeless: https://bugs.launchpad.net/bugs/582656 :( | 06:59 |
| ubot5 | Launchpad bug 582656 in Bazaar "Compiled _dirstate_helpers causes crash with specified file commands (affected: 1, heat: 6)" [Critical,Confirmed] | 06:59 |
| bignose | lifeless: shelve crash reported in Debian BTS now, <URL:http://bugs.debian.org/bug=582210> | 07:41 |
| bignose | 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:41 |
| bignose | lifeless: shelve crash reported in Debian BTS now, <URL:http://bugs.debian.org/582210> (fixed the URL) | 07:42 |
| lifeless | bignose: what proxy are you using ? | 07:45 |
| lifeless | launchpad is on https generally, so I wouldn't expect anything in it except -perhaps- css files to hit your proxy | 07:45 |
| lifeless | nevertheless, there is a problem :) | 07:45 |
| vila_ | hi all | 07:55 |
| vila | vila_: Sorry for using your nick, I'll leave | 07:55 |
| === vila_ is now known as vila | ||
| vila | tsk tsk | 07:59 |
| parthm | vila: hi | 08:05 |
| parthm | 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 |
| vila | parthm: hi ! | 08:07 |
| parthm | vila: or if i can get another reviewer :) | 08:07 |
| vila | parthm: I didn't claim it, I suspect jam assigned me instead, I plan to review it soon | 08:08 |
| fullermd | Maybe vila_ claimed it for you. | 08:08 |
| parthm | vila: ah. ok :) .. no hurry. was just wondering. | 08:08 |
| parthm | fullermd: ha :) | 08:08 |
| vila | annoying squatter this vila_ ... | 08:08 |
| fullermd | lifeless: I can't trivially run selftest, lacking testtools :| | 08:10 |
| fullermd | 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:10 |
| vila | fullermd, lifeless : babune has a freebsd8 slave, can I help ? | 08:14 |
| fullermd | 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:14 |
| fullermd | It was rebuilt since my last OS/python upgrade though, so it's not that... | 08:15 |
| fullermd | Holy crow it takes a long time to branch bzr.dev on local disk. | 08:15 |
| vila | die ? How ? | 08:18 |
| lifeless | gnight | 08:19 |
| fullermd | 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 |
| fullermd | Oh, pyrex 0.9.8.6 vs 0.9.9 too. Hm. | 08:19 |
| fullermd | Maybe I can test that switch quick-like... | 08:20 |
| fullermd | 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 |
| fullermd | In fact... | 08:20 |
| * vila holds his breath and hopes fullermd will finish his sentence soon enough | 08:21 | |
| fullermd | 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 |
| fullermd | So it sounds like pyrex 0.9.9. | 08:22 |
| vila | hmm, pyrex 0.9.9 here, but maybe the .c files has not been modified since I upgraded.... | 08:24 |
| vila | err, the .pyx files of course | 08:24 |
| vila | one more hole in babune setup.... | 08:24 |
| vila | a lucky one this time\ | 08:24 |
| fullermd | Oh, that should be quick to test with that repro script (or manually) | 08:25 |
| fullermd | Actually, don't even need a modified file in the tree. | 08:25 |
| fullermd | So just 'bzr stat bzrlib' in the bzr.dev tree should tell you. | 08:25 |
| vila | tell me what ? what repro script ? | 08:26 |
| fullermd | https://bugs.launchpad.net/bzr/+bug/582656 | 08:26 |
| ubot5 | Launchpad bug 582656 in Bazaar "Compiled _dirstate_helpers causes crash with specified file commands (affected: 1, heat: 6)" [Critical,Confirmed] | 08:26 |
| fullermd | Or just 'bzr stat bzrlib'; I get the crash (with 0.9.9-built stuff) there too. | 08:26 |
| * vila branching (don't ouch the babune working one !!!) | 08:27 | |
| vila | yeah, ouch, exactly, not a typo ! | 08:27 |
| fullermd | Pfft. Wimp. | 08:27 |
| vila | boom | 08:28 |
| vila | KeyError: '' | 08:28 |
| fullermd | Oh, good. I've successfully ruined your day; now I can go sleep in peace 8-} | 08:28 |
| vila | fullermd: hehe, I'll check which pyrex version were used to generate my files and add a comment | 08:31 |
| fullermd | (which I'm about 3 hours overdue for at the moment, so *bamf*) | 08:31 |
| fullermd | It leaves a comment right on the first line. Handy. | 08:31 |
| vila | I thought so | 08:31 |
| vila | Generated by Pyrex 0.9.8.6 on Thu Apr 1 17:19:38 2010 | 08:32 |
| vila | haha, so funny | 08:32 |
| vila | not | 08:32 |
| fullermd | Just confirms my long-held suspicion that dirstate is a conspiracy against me. | 08:32 |
| vila | 656 diffs... | 08:33 |
| fullermd | Between the generated files? | 08:33 |
| === mrevell__ is now known as mrevell | ||
| fullermd | Yeah, I think the diffs are big even between runs of the same version. Suckage :| | 08:34 |
| * vila searches the magic incantation to ignore the comment lines mentioning the source file | 08:34 | |
| fullermd | Well, at least we could build with cython instead... except [last time I tried] that yields stuff that doesn't work at ALL. | 08:35 |
| fullermd | But that would fix THIS bug. Sorta ;) | 08:35 |
| vila | urgh, you're right, bunch of moved around code or added "registers" .... go figure the problem :-/ | 08:36 |
| vila | wow __Pyx_AddTraceback call added 8-{ | 08:37 |
| vila | err, no, calls deleted in fact (/me switches the windows to a sane order) | 08:38 |
| vila | lucid is still using 0.9.8.5, yeah for responsible distro maintainers using well tested versions :-P | 08:39 |
| fullermd | Figures. CD I ordered last week showed up in my mailbox today, so obviously something UNpleasant had to happen to counterbalance and leave the day centered. | 08:40 |
| vila | ok, got the failure in the test suite, that should narrow down the problem | 08:43 |
| vila | bah of course it's a blackbox test :-/ | 08:44 |
| vila | 7 failing tests already | 08:44 |
| fullermd | Oh well. I'll still have the CD after the bug is fixed. Nya nya nya, Fate! | 08:44 |
| vila | lol | 08:45 |
| * fullermd quickly hides. | 08:45 | |
| * vila setup a dedicated babune job :) | 08:47 | |
| vila | 32^W41^W53 failures so far, one of them ought to be easier to debug than the others | 08:48 |
| fullermd | Actually, I'd WAG that tracking it would be easier by just dumping some debug printf's around where it crashes to see what unexpected structure (or lack thereof) the pyx is giving back, and dig down from that direction. | 08:49 |
| * vila goes back to fixing its keyboard layout before turning insane | 08:49 | |
| fullermd | ... of course, just using the phrase "debugging printf" probably shows I'm not qualified to deal with python in the first place :p | 08:50 |
| vila | fullermd: except a pdb.set_trace() with a simplified context may be even more handy, I'll look into it when the run finish | 08:50 |
| vila | fullermd: same concept, different tool ) | 08:50 |
| vila | :) | 08:50 |
| fullermd | Well, I require_feature(zzz), so I'll leave it in your hands for the next fartoofew hours. | 08:51 |
| vila | I would probably wait for jam to turn up anyway he knows pyrex far better than me | 08:51 |
| vila | fullermd: sleep well | 08:51 |
| vila | and thanks for the heads-up ! | 08:52 |
| * fullermd <--- canary in the bzr-mines. | 08:52 | |
| vila | hmm, I was about to joke about sending some gas and thought better :) | 08:52 |
| bialix | bonjour vila | 09:03 |
| vila | hello Sacha :) | 09:04 |
| bialix | my patch for backslashes landed to 2.1 last night, thanks jam | 09:04 |
| bialix | I think I should provide a patch for bzr.dev to merge it cleanly now? | 09:05 |
| bialix | because that was for 2.1 only | 09:05 |
| bialix | and 2.2 has different command-line parser | 09:05 |
| bialix | or the person who will do merge simply ignore my changes? | 09:05 |
| bialix | vila: ^ | 09:06 |
| spiv | bialix: a patch to merge it cleanly would be good, I think | 09:06 |
| bialix | that's my understanding as well | 09:06 |
| vila | bialix: it would be better if you merge 2.1 to trunk to ensure the conflicts are properly resolved | 09:06 |
| bialix | I'm just double checking | 09:07 |
| bialix | ok, so maybe I can adapt some my new tests | 09:07 |
| vila | but if you propose a patch including your 2.1 merge in its ancestry everything should be fine | 09:08 |
| vila | grr damn xmodmap bug ! | 09:09 |
| mgz | morning all. | 09:24 |
| mgz | vila: just posted thingy about leak experiements, basically what I said yesterday evening | 09:25 |
| vila | mgz: Hi ! I haven't checked my mail yet :-/ | 09:25 |
| mgz | am now going to try and do some actually-useful things. | 09:25 |
| mgz | I mean just, like, that second. | 09:26 |
| bialix | heya mgz | 10:13 |
| gour | igc: hello, is bug #541626 bzr or fastimport's stuff? | 11:58 |
| ubot5 | Launchpad bug 541626 in Bazaar Fast Import "'BTreeBuilder' object has no attribute '_find_ancestors' (affected: 2, heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/541626 | 11:58 |
| asabil | jelmer: ping ? | 12:01 |
| jelmer | asabil: hi | 12:01 |
| asabil | hey jelmer, I just wanted to know if you would have an idea about this assertion error failing: | 12:02 |
| asabil | File "/home/asabil/.local/lib/python2.6/site-packages/dulwich-0.5.1-py2.6-linux-i686.egg/dulwich/pack.py", line 926, in iterentries | 12:02 |
| asabil | assert isinstance(offset, int) | 12:02 |
| asabil | AssertionError | 12:02 |
| jelmer | asabil: not without context... | 12:03 |
| asabil | I am trying to clone an internal git repo, and it fails with that error | 12:03 |
| asabil | I can paste the crash file somewhere | 12:03 |
| jelmer | what versions of bzr-git/dulwich ? | 12:04 |
| asabil | from source | 12:06 |
| asabil | freshly installed | 12:06 |
| asabil | the crash trace is here: http://pastebin.com/SkbAkPeE | 12:07 |
| jelmer | asabil: from the tarballs, from bzr ? | 12:09 |
| asabil | from bzr | 12:10 |
| maxb | Is there any good reason why bzrtools releases are strictly bound to bzr releases? | 12:16 |
| jelmer | asabil: can you check what the type of offset is ? | 12:20 |
| asabil | yep, give me few minutes please | 12:26 |
| asabil | it takes a lot of time to clone a 6Gb repo | 12:26 |
| jelmer | oh, if it's a 6gb repo I suspect the type might be a long | 12:26 |
| jelmer | I don't think we support repositories that big yet | 12:27 |
| asabil | is there a way I can help fixing this ? | 12:30 |
| jam | maxb: by request of the author | 12:31 |
| maxb | ...? | 12:31 |
| jam | abentley prefers that the plugin aborts early rather than claims to work and fails late | 12:32 |
| jelmer | asabil: we'd need support for larger pack files in dulwich first I think | 12:32 |
| jelmer | asabil: do you have any pack files > 2Gb? | 12:32 |
| asabil | let me check | 12:32 |
| jam | vila: I'm awake, but not officially working yet | 12:33 |
| asabil | jelmer, yes I think there is a 6Gb pack file | 12:40 |
| jelmer | asabil: in that case, you'd really need to patch dulwich first | 12:41 |
| jelmer | at the moment it doesn't support index files for pack files larger than 2Gb | 12:41 |
| asabil | ok, I will start there then | 12:42 |
| jelmer | you might also want to check nobody else is working on that support yet, I think one of the Google folks was interested in it as well | 12:42 |
| asabil | jelmer, on the mailing list ? | 12:44 |
| jelmer | asabil: yep | 12:44 |
| asabil | ok I will, thanks | 12:44 |
| mok0 | I'd like to access the revno from inside a program running out of a bzr repo. Does anyone have a code snippet that can show me how to do that? | 13:13 |
| mok0 | I've been browsing bzrlib for a function, but not been lucky | 13:13 |
| bialix | branch.last_revision() | 13:16 |
| mok0 | bialix, what's the path to "branch" ? | 13:18 |
| bialix | branch is the instance of bzrlib.branch.Branch | 13:18 |
| bialix | e.g. br = bzrlib.branch.Branch.open('path') | 13:18 |
| bialix | print br.last_revision() | 13:19 |
| bialix | or maybe br.last_revision_info() | 13:19 |
| bialix | check the API | 13:19 |
| mok0 | bialix: got it working, thanks a bunch! | 13:20 |
| bialix | np | 13:20 |
| mok0 | Now I need to figure out how best to include that in my django site | 13:24 |
| bialix | http://wiki.bazaar.canonical.com/Integrating_with_Bazaar can be useful | 13:30 |
| === JFo-afk is now known as JFo | ||
| mok0 | bialix: indeed | 14:01 |
| vila | jam: ok, back from shopping (a *real* chair for my desk :) | 14:01 |
| === joerg_ is now known as joerg | ||
| === CardinalFang_ is now known as CardinalFang | ||
| parthm | jml: hi | 14:41 |
| parthm | jml: .. sorry. i meant to ping jam. | 14:43 |
| parthm | jam: hi | 14:54 |
| ovnicraft | hi folks, when i push in lp i give the message, pgrade the repositories to the same format for better performance. | 15:09 |
| ovnicraft | i found in the web this command: bzr upgrade --2a | 15:11 |
| ovnicraft | so i want confirm this before to do it | 15:11 |
| ovnicraft | its ok? | 15:11 |
| jelmer | ovnicraft: yep | 15:11 |
| ovnicraft | jelmer, thx | 15:12 |
| jelmer | ovnicraft: it might also be that the remote branch is out of date while the local one is newer | 15:12 |
| jelmer | ovnicraft: in that case you might want to upgrade the branch on lp | 15:12 |
| ovnicraft | in lp has format 7 | 15:13 |
| ovnicraft | jelmer, i get that is 2a | 15:13 |
| maxb | format 7 sounds like a branch format | 15:21 |
| maxb | Bazaar formats can get confusing, because there's a repository, a branch, and a working tree, all with independent formats | 15:21 |
| jelmer | it is, but I think it's probably the branch format that's part of 2a | 15:21 |
| jelmer | maxb: yeah | 15:21 |
| maxb | bzr info -v tells all | 15:21 |
| jelmer | launchpad displays the long names | 15:21 |
| ovnicraft | sorry, branch format 7, repo format 2a | 15:35 |
| jelmer | ovnicraft: did the upgrade help? | 15:36 |
| ovnicraft | that info from lp, i am upgrading the repo | 15:36 |
| === radoe_ is now known as radoe | ||
| fullermd | jam: Latest bug comment is as far as I can take it. | 16:50 |
| jam | fullermd: that's the "its a really big diff that is hard to understand" ? :) | 16:50 |
| jam | can you email me the output? | 16:51 |
| fullermd | No, just tracked to one line that's differing in whether it succeeds or not. | 16:51 |
| jam | ah, didn't get that one yet | 16:51 |
| fullermd | Hmph. I just rm'd the dir :p | 16:51 |
| jam | you still have 0.9.9 pyrex installed, right? | 16:51 |
| fullermd | Yah, regenning. | 16:52 |
| jam | thanks | 16:53 |
| === IslandUsurper is now known as IslandUsurperAFK | ||
| [1]reggie | jam (or anyone else) -- how would I setup bazaar.conf to use sendmail to send mail? | 16:54 |
| [1]reggie | I'm on windows but have a sendmail binary | 16:55 |
| [1]reggie | just setting the config line in bazaar.conf doesn't appear to do it | 16:55 |
| jam | [1]reggie: first off, "to send mail" | 16:55 |
| jam | Under what circumstances? | 16:55 |
| [1]reggie | bzr commit | 16:55 |
| fullermd | Mailed. | 16:55 |
| jam | fullermd: thx | 16:55 |
| jam | [1]reggie: I presume you are then using 'bzr-email' ? | 16:55 |
| [1]reggie | let me check | 16:55 |
| === beuno is now known as beuno-lunch | ||
| jam | fullermd: I think you mentioned that cython doesn't work for you. Can you give a bit more detail? (I use it here) | 17:06 |
| jam | and I've at least reproduced the failure with your test script. | 17:08 |
| jam | Interestingly you do have to pass a path, which may be a decent hint | 17:08 |
| [1]reggie | jam, we have a emailer.py that is in our mysql_plugins folder. if post_commit_mailer = smtplib then it tries to use that. otherwise it uses whatever post_commit_mailed is set to | 17:08 |
| [1]reggie | I have mine set to my sendmail instance | 17:08 |
| [1]reggie | I just ran a test commit and got no error and no error in .bzr.log but also no email | 17:08 |
| [1]reggie | very frustrating that smtplib doesn't support SSL 465 | 17:08 |
| jam | [1]reggie: k. I'd start by saying I don't have a copy of, nor access to the mysql plugin | 17:08 |
| jam | so there isn't a huge amount of support I can do on it | 17:09 |
| [1]reggie | I know | 17:09 |
| jam | I will point out that bzrlib.smtp_connection.SMTPConnection *can* take an optional "_smtp_factory" parameter (originally designed for the test framework). And you could pass SMTP_SSL in there instead. | 17:11 |
| === davidstrauss_ is now known as davidstrauss | ||
| jam | If mysql cribbed the email sending from bzr-email | 17:11 |
| jam | that also has a "_smtplib_implementation" attribute, which instantiates an SMTPConnection | 17:12 |
| jam | which would be another way to inject your own SMTP_SSL object | 17:12 |
| TresEquis | jelmer: re https://bugs.launchpad.net/bzr/+bug/480102, the only thing odd about the last-imported revision for lp:karl3 is that it includes a change to an svn:eol-type property | 17:12 |
| ubot5 | Launchpad bug 480102 in Launchpad Bazaar Integration "assert len(tview) == tview_len (affected: 5, heat: 48)" [High,Triaged] | 17:12 |
| jam | [1]reggie: another option is too look at how bzrlib/mail_client.py works | 17:14 |
| jam | which is where 'bzr send' hooks into sending notifications to your existing mail client | 17:14 |
| jam | so that you have an opportunity to write messages to it. | 17:14 |
| jam | probably not exactly what you want for the mysql post-commit effect, though | 17:15 |
| TresEquis | that change shows up here: svn diff -c 5140 http://osi.agendaless.com/bfgsvn | 17:15 |
| TresEquis | bug not here: bzr log -p --limit=1 lp:karl3 | 17:15 |
| jelmer | TresEquis: bzr-svn doesn't import changes to svn:eol-type properties | 17:15 |
| TresEquis | OK, but would that explain the checksum issues on the next revision? | 17:16 |
| TresEquis | it also added 'svn:keywords' property, with 'Id' as the value | 17:22 |
| TresEquis | that might cause SVN to believe something different about the content of the file than bzr, maybe? | 17:23 |
| fullermd | jam: Don't remember offhand, it was a couple months ago. But it just flat didn't work at all for anything. | 17:24 |
| fullermd | jam: Yes, need the path. Don't need changes though; I found I could just 'bzr stat bzrlib' in a pristine tree to bring it up. | 17:24 |
| jam | so my immediate guess is that pyrex is leaving an exception on the stack, and then accidentally checking the exception state as part of the "x == y" statement | 17:25 |
| fullermd | Mmm. The object comparison does that? | 17:26 |
| fullermd | My fiddling fingered that one specific line of the C. | 17:27 |
| TresEquis | jelmer: the next commit on the karl/trunk branch (the one which fails to import) is svn r5144, which touches (only) the file whose properties got changed in svn r5140 | 17:28 |
| jam | fullermd: adding a "PyErr_Clear()" just before that line makes everything just peachy | 17:28 |
| jam | *ugh* | 17:28 |
| fullermd | Wacky. | 17:28 |
| jam | Looking at: http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/CHANGES.txt | 17:29 |
| jam | - Exceptions caught by an except clause are no longer put into the thread state and cannot be retrieved using sys.exc_info(). To access the caught exception, it must be bound to a name in the except clause. A third name can be supplied to capture the traceback. | 17:29 |
| jam | So I have another thought, we'll see | 17:29 |
| jam | looks like I got it | 17:29 |
| jam | change the bare "except KeyError:" to "except KeyError, e:" | 17:30 |
| jam | and things are happy again | 17:30 |
| jam | can you try it on your system? (line 1241) | 17:30 |
| fullermd | Hm. Well, that makes 'bzr stat bzrlib' work. The test script still fails, though, as does stat bzrlib/_dirstate_helpers_pyx.pyx | 17:33 |
| fullermd | (it's 1239 in my bzr.dev) | 17:33 |
| jam | fullermd: my guess is that we just have to trap all of these bare exceptions, because pyrex is fubar without it | 17:33 |
| jam | we use it in a fair number of other places | 17:33 |
| jam | basically, look for "except[^,]*:" | 17:34 |
| fullermd | Changing the one at 1222 as well fixes it. | 17:34 |
| jam | a) This is definitely a bug in pyrex, and I'm trying to write a simple test case to show it | 17:34 |
| jam | b) we can probably work around it for now | 17:34 |
| fullermd | (well, fixes this incarnation of it anyway; who knows what evil lurks in the hearts and minds of any other except's in there) | 17:34 |
| jelmer | TresEquis: hmm | 17:35 |
| jelmer | TresEquis: *looking* | 17:35 |
| jam | fullermd: reproduced | 17:36 |
| jam | I'll file a bug on pyrex | 17:36 |
| fullermd | I guess this just shows how version control systems can help you find bugs :p | 17:37 |
| TresEquis | svn collapses the $Id: ...$ string in its internal representation when that svn:keyword is set, I think | 17:38 |
| TresEquis | a stupid CVS compatibility hack | 17:38 |
| jelmer | TresEquis: bzr doesn't touch that, it shouldn't really affect it | 17:38 |
| TresEquis | it wouldn't cause bzr and svn to have different ideas about the payload for that file? | 17:39 |
| jam | fullermd: as near as I can tell, dirstate_helpers is the only extension that uses exceptions without objects, I'll put up a patch | 17:55 |
| === IslandUsurperAFK is now known as IslandUsurper | ||
| === deryck is now known as deryck[lunch] | ||
| === beuno-lunch is now known as beuno | ||
| TresEquis | jelmer: I'm trying now to check out the karl/trunk stuff from a copy of 'bzr' with a pdb.set_trace() just before the call to main() | 18:06 |
| TresEquis | so that I can look at the stack when the exception happens | 18:06 |
| TresEquis | crap, bzrlib is bailing out without giving me a shot at the traceback / stack frame | 18:11 |
| jam | fullermd, vila, lifeless: https://code.edge.launchpad.net/~jameinel/bzr/pyrex_099_bug_582656/+merge/25625 | 18:11 |
| fullermd | Purdy. | 18:13 |
| * fullermd thanks jam. | 18:14 | |
| mgz | amusing pyrex bug, well tracked down jam. | 18:20 |
| fullermd | Oh, right, "amusing" was totally the first word that came to my mind last night :p | 18:22 |
| mgz | maybe it's one of those things that's only funny after the fact ;) | 18:22 |
| fullermd | It'll give us something to chuckle over in the rest home, anyway. | 18:24 |
| vila | jam: setting a run on babune | 18:26 |
| vila | jam, fullermd : http://babune.ladeuil.net:24842/job/debug-freebsd/2/ | 18:28 |
| * vila dinner, will check later | 18:29 | |
| vila | rhymes :) | 18:29 |
| lfaraone | I'm on a selow connection, and I want to only make changes to a branch then push them up somewhere on launchpad, how can I minimize the data transfer? (I don't really care about full history) | 18:29 |
| TresEquis | jelmer: sigh, the traceback is no help, as the caller (who has computed the window) is implemented in C | 18:29 |
| jam | vila: I'm not sure what in that sentence rhymed... but maybe in french? Anyway, thanks for the run. I'm pretty confident, having used pyrex 0.9.9 here. | 18:34 |
| vila | jam: dinner with later ? | 18:36 |
| jam | I've never pronounced "later" as "linner" but maybe you do :) | 18:36 |
| vila | damn, for once there was no typo :) | 18:37 |
| jam | Now if you said "date: will check late" | 18:37 |
| fullermd | That would doubly rhyme, since late dates cause strife with the wife. | 18:39 |
| vila | talking about wife.... see you later :-P | 18:40 |
| mgz | Hm, should I file a new bug for my three hashcache-related test failures, or should I piggyback on bug 70272 from 2006 | 18:44 |
| ubot5 | Launchpad bug 70272 in Bazaar "test failure (TestHashCache) (affected: 0, heat: 0)" [Medium,Confirmed] https://launchpad.net/bugs/70272 | 18:44 |
| mgz | changing the three tests not to sleep for four seconds each would be nice as well, can't they be utimed into the past? | 18:47 |
| mgz | ...think I'll file a new one, mine's certainly FAT related, just tried unsetting TMP and they pass | 18:51 |
| === deryck[lunch] is now known as deryck | ||
| cbz | what is eclipse doing constantly running bzr in the background? | 19:26 |
| jelmer | TresEquis: :-(I | 19:28 |
| cbz | because it keeps ending up running out of heapspace - and complains about Decorators | 19:29 |
| fullermd | Calculating missile trajectories for when it becomes self aware and takes over. | 19:29 |
| TresEquis | jelmer: the offending svn revision is actually 5147, not 5140 | 19:29 |
| TresEquis | and the oddity is that the 'tview' string looks like a real revision of the file | 19:30 |
| TresEquis | but it corresponds to neither the prior version (5146) nor the updated one (5147) | 19:30 |
| TresEquis | the tview_len value is the actual length of the file in r5147 | 19:31 |
| TresEquis | so I have no idea where the bogus version comes from | 19:31 |
| TresEquis | jelmer: OK, the 'view' string is *not* a valid revision: it contains a Python syntax error, at least | 19:40 |
| jelmer | TresEquis: it doesn't occur anywhere in history? | 19:58 |
| TresEquis | jelmer: nope | 19:58 |
| MTecknology | In bzr explorer, is there any way to run 'bzr pull' a lot of branches at once? | 19:59 |
| TresEquis | jelmer: it looks like a partial / intermediate change between the version of the file svn r4908 and the version in svn r5090 | 19:59 |
| TresEquis | but it also includes text which wasn't added until 5147 | 20:02 |
| TresEquis | the developer who committed 5147 maybe was using bzr-svn? | 20:03 |
| TresEquis | I don't know if there is any way to see "fingerprints" left by such a commit, assuming bzr-svn made it | 20:04 |
| ree | hi jelmer TresEquis | 20:04 |
| TresEquis | ah, ree is the developer I spoke of | 20:05 |
| ree | ze one who messed up things, right :) | 20:05 |
| TresEquis | ree: do you think you might have committed svn r5147 via bzr? | 20:06 |
| ree | not sure. | 20:06 |
| ree | or bzr, or merge from our imagedrawer branch... which was also bzr'd | 20:07 |
| ree | so this may well be the root of the problem but I don't know how to be sure | 20:07 |
| ree | merge from our imagedrawer branch = with pure svn, that is | 20:08 |
| TresEquis | I do see a bunch of bzr: properties on the svn r5090 dump | 20:10 |
| TresEquis | which is the one where you merged the imagedrawer branch | 20:10 |
| ree | yes. I am not even sure if that one was merged with bzr or with svn | 20:11 |
| TresEquis | bzr:revision-info, bzr:ancestry, bzr:file-ids, bzr:revision-id, bzr:text-parents, bzr:text-revisions | 20:11 |
| TresEquis | plus svn:mergeinfo and svk:merge ;( | 20:12 |
| ree | how nice | 20:12 |
| ree | the svk bit was someone else ;) | 20:12 |
| ree | TresEquis, in fact it is possible that I done that one with svn | 20:13 |
| ree | sorry, usage history longer then memory | 20:13 |
| ree | jelmer, would it not be possible, in theory, that bzr-svn just ignores the wrong info, and misses "something" but not the whole lot? | 20:15 |
| ree | 'cause it may have been my fault, but if I could do it others will do it I can guarantee | 20:15 |
| ree | so that's maybe something bzr-svn should be prepared of | 20:15 |
| ree | ^ | 20:15 |
| TresEquis | I think it may be possible to scrub out the bzr: revision properties | 20:21 |
| TresEquis | I will want to try on a scratch repo first | 20:21 |
| ree | TresEquis, that would solve it | 20:24 |
| TresEquis | ree: those bzr: properties are not "revision properties" (which are unversioned, and can be changed later), but "tree properties" | 20:38 |
| TresEquis | which are revisioned | 20:38 |
| ree | d'oh | 20:40 |
| ree | does this prove that it was me with svn? or it could have been bzr? | 20:41 |
| TresEquis | I don't see how svn would have been adding bzr: properties | 20:46 |
| TresEquis | but using svn to merge a branch to which those properties had been added earlier via bzr-svn would be plausible | 20:47 |
| TresEquis | I also have no evidence that those properties have anything to do with the error | 20:47 |
| TresEquis | none of those properties are on the affected file, or its parents | 20:49 |
| jelmer | TresEquis: but they mention the affected file perhaps? | 20:52 |
| jelmer | TresEquis: what version of bzr-svn are you testing with? | 20:52 |
| TresEquis | 2.1.1 | 20:52 |
| ree | jelmer TresEquis it was definitely the case, that the properties were on the branch being merged | 20:54 |
| jelmer | TresEquis: of bzr-svn I mean? | 20:54 |
| ree | but, what buggers me is that there is no evidence that those properties have anything to do with the error | 20:54 |
| TresEquis | jelmer: http://paste.ubuntu.com/436359/ | 20:55 |
| ree | jelmer, I have the issue with 1.0.2 | 20:55 |
| jelmer | ree: Have you tried bzr-svn trunk ? | 20:55 |
| ree | no, but I can | 20:55 |
| jelmer | please do | 20:56 |
| TresEquis | jelmer bzr plugins says 1.0.2 | 20:56 |
| jelmer | TresEquis: can you please also try with trunk ? | 20:56 |
| TresEquis | the file which blows up the checkout / import is karl/trunk/karl/content/views/blog.py | 20:56 |
| TresEquis | jelmer: like so? $ bzr co lp:bzr-svn ~/.bazaar/plugins/svn | 20:57 |
| jelmer | TresEquis: yep | 20:58 |
| hno | How do I temporarily go back to a specific revision? Neither update or switch seem to take revision specifiers. | 20:59 |
| ree | TresEquis, tx | 20:59 |
| hno | I can do a checkout, but that seems a bit overkill.. | 21:00 |
| TresEquis | hno: bzr up takes a -r / --revision arg | 21:01 |
| hno | TresEquis: Maybe by bzr on this box is too old then.. 1.18.1. | 21:02 |
| hno | long overdue for upgrade anyway. | 21:02 |
| TresEquis | hno: I really like the new "shared revisions" repo format | 21:03 |
| ree | jelmer, checkout of our project will take some time, cc 10 min | 21:03 |
| * ree doing with trunk | 21:03 | |
| * TresEquis as well | 21:04 | |
| TresEquis | and halfway there | 21:04 |
| hno | TresEquis: "shared revisions"? Is this part of the 2a format? | 21:05 |
| TresEquis | "Shared repository with trees" | 21:05 |
| TresEquis | right, 2a | 21:05 |
| TresEquis | I misremembered | 21:05 |
| lifeless | hno: no, we've supported shared repos since 1.0 | 21:06 |
| lifeless | (actually a bit older still, but meh) | 21:06 |
| ree | I just wish joining worked solidly with svn. (to overcome externals) | 21:06 |
| ree | we had a project (kss) that we could never switch to bzr for this reason, mainly | 21:07 |
| TresEquis | jelmer: I'm back at the pdb.set_trace I added in bzrlib | 21:07 |
| hno | lifeless: I know. | 21:07 |
| lifeless | jam: land that pyrex patch; its like coding on top of a sea | 21:07 |
| TresEquis | jelmer: same crash | 21:08 |
| jelmer | 'morning lifeless | 21:08 |
| TresEquis | same busted not-really-a-revision ;( | 21:08 |
| jelmer | TresEquis: :-( | 21:09 |
| * ree still just at 488/1089 | 21:09 | |
| lifeless | hi jelmer | 21:09 |
| TresEquis | jelmer: the 'window' tuple has the bits which cause the borked file version in the 'new_data' field | 21:10 |
| jelmer | TresEquis: I suspect the base text is invalid and that's causing the problems | 21:11 |
| TresEquis | is that the 'sview'? | 21:12 |
| lifeless | hno: yes, -r on update is new | 21:13 |
| lifeless | hno: or you can use revert -r | 21:13 |
| lifeless | which has been around for ages. | 21:13 |
| hno | lifeless: I do not want to revert, just switch to that revision.. | 21:15 |
| TresEquis | jelmer: the 'sview' has the same text as svn r4908 | 21:15 |
| ree | TresEquis, why was it so much faster for you? Working from a server or something? | 21:15 |
| TresEquis | ree: dunno -- I started earlier, maybe | 21:16 |
| ree | TresEquis, did you do a bzr get, or a bzr co? | 21:16 |
| ree | or that shouldn't matter. | 21:16 |
| TresEquis | so, it is trying to apply the patch from r5090 - r5147 against the base from r4908 | 21:17 |
| TresEquis | ree: I did 'bzr co' | 21:17 |
| lifeless | hno: yes, so using your version of bzr: bzr shelve --all; bzr revert -r X; bzr unshelve | 21:19 |
| lifeless | hno: will get you onto that revision the same as update -r | 21:20 |
| TresEquis | jelmer: the 'apply_txdelta_window' curried 'apply_window' has a value for 'sbuf' which is from the wrong source revision | 21:21 |
| TresEquis | but I can't see who called that code in the first place | 21:22 |
| jelmer | TresEquis: it's called from fetch.py | 21:23 |
| TresEquis | jelmer: does that mean that the checksum matched before the currried bit was returned? | 21:27 |
| jelmer | TresEquis: the base text is wrong | 21:27 |
| jelmer | TresEquis: so yes | 21:28 |
| jelmer | I mean no | 21:28 |
| jelmer | sorry :) | 21:28 |
| hno | lifeless: Think I prefer checkout -r then... | 21:28 |
| * hno starts a 60 seconds countdown of the remaining lifetime of this install. Time for a complete system update. | 21:29 | |
| lifeless | hno: why? | 21:30 |
| TresEquis | ugh | 21:32 |
| hno | lifeless: Because I like to? And the distro release used becomes end-of-life in some weeks.. | 21:33 |
| lifeless | hno: I meant 'why do you prefer checkout -r' | 21:33 |
| lifeless | I am very happy that you're upgrading :) | 21:33 |
| hno | Because I do not want to accidently commit that revert. | 21:34 |
| lifeless | k | 21:34 |
| TresEquis | hno: just figured out I knew you from Squid list | 21:35 |
| lifeless | :) | 21:35 |
| hno | TresEquis: Thanks | 21:35 |
| lifeless | free software is a small small world | 21:35 |
| hno | indeed. And hi lifeless ;-) | 21:35 |
| lifeless | :) | 21:36 |
| hno | Ok, countdown ended. Time for system update. See you later and meanwhile let #bzr return to normal high squid developers presence level. | 21:37 |
| lifeless | ciao | 21:38 |
| TresEquis | ack , curried functinos are a pain to debug | 21:39 |
| TresEquis | curried functions called by C code are even worse | 21:39 |
| jelmer | TresEquis: that's not really the problem here though, the issue is before the curried code | 21:40 |
| TresEquis | jelmer: yeah, but the curried code is the only place I can detect the problem ;( | 21:41 |
| jelmer | TresEquis: look at SvnEditor.apply_textdelta | 21:41 |
| TresEquis | the currying gives me no way to get back to the 'self' of the think which created it | 21:42 |
| jelmer | TresEquis: if you go up in pdb? | 21:42 |
| TresEquis | up lands in 'report_inventory_contents' | 21:46 |
| jelmer | TresEquis: but down from that there is apply_textdelta? | 21:50 |
| TresEquis | no | 21:52 |
| TresEquis | down from there is the curried 'apply_window' | 21:53 |
| jelmer | ah, right | 21:53 |
| jelmer | have you tried setting a breakpoint in apply_window when the problematic file is processed? | 21:53 |
| TresEquis | I have the breakpoint in the apply_txdelta_window function, right before the failing assert | 21:54 |
| TresEquis | that is the bottom of the traceback | 21:54 |
| jelmer | that's too late though | 21:56 |
| jelmer | you need the place where the base text is retrieved | 21:57 |
| TresEquis | yep | 21:59 |
| NightNord | Greeting, everyone. Is there any kind of UTF-8 to native encoding when commiting/pulling to/from remote repository in bazaar, as it is done in subversion? | 22:00 |
| jelmer | NightNord: for paths, commit messages, etc - yes | 22:00 |
| jelmer | NightNord: not for file contents (similar to subversion) | 22:00 |
| TresEquis | jelmer: I have added yet-another-layer-of-indirection in fetch.py | 22:02 |
| NightNord | Too bad, it seems that none of git,hg,bzr capable of this feature. Curious, that CRLF/LF conversion is done in bazaar... | 22:02 |
| NightNord | jelmer: thanks | 22:02 |
| TresEquis | currying the curry with a method, to get me access to self | 22:02 |
| lifeless | vila: around ? | 22:04 |
| lifeless | NightNord: what do you mean ? | 22:06 |
| NightNord | lifeless: any known for me DVCS incapabable for switching text-file encodings, despite of that eol conversion could be done without marking all converted files as 'changed'-ones | 22:08 |
| NightNord | In theory, same trick could be used for encoding conversion | 22:09 |
| MTecknology | where is .bazaar/plugins/ in windows? | 22:13 |
| lifeless | NightNord: sure, you could write a plugin to do that for bzr | 22:13 |
| lifeless | MTecknology: bzr --version should show you | 22:13 |
| MTecknology | lifeless: thanks | 22:13 |
| NightNord | lifeless: if plugin is something the same as for git are 'hooks', I suppose it's quite hacky operation... At least if not checking bzr code =) | 22:17 |
| guijemont | jelmer: how do you run bzr-gtk's unit tests? | 22:17 |
| jelmer | "bzr selftest bzrlib.plugins.gtk" | 22:17 |
| lifeless | guijemont: bzr selftest plugins.gtk | 22:18 |
| lifeless | NightNord: filters to do changes like that are a supported feature, not hacky at all. | 22:18 |
| NightNord | Hm... That's could done a trick. I'll dig in, thanks, lifeless | 22:19 |
| guijemont | aha, didn't know about that command | 22:19 |
| lifeless | NightNord: if you're new to python you'll probably find the learning curve a little steep; folk here or on the mailing list will be happy to help, I'm sure. | 22:19 |
| TresEquis | jelmer: ok, different stab: I'll make 'self.chunks' on the FileRevisionBuildEditor an instance of a class derived from list, but which holds onto a reference to the editor | 22:20 |
| guijemont | time to see how many tests I broke | 22:21 |
| TresEquis | Waiting 10 minutes between tries is not good for staying in the flow ;( | 22:21 |
| NightNord | lifeless: Actually, I'll need to run single very simple shell command (find -name '*.cpp' -exec enca -x KOI8-R '{}' \;), so, I hope, my knowledge in python and some working plugin as example are sufficient. But thanks for invite, anyway =) | 22:23 |
| lifeless | NightNord: you'll need to do the reverse as well, for the input filter | 22:25 |
| lifeless | otherwise you'll commit in your local encoding | 22:25 |
| NightNord | Yes, I know, I just simplified description to write less ;) | 22:26 |
| lifeless | ok | 22:27 |
| NightNord | I found checkeol plugin, I suppose it will serve as good base | 22:27 |
| TresEquis | jelmer: ok, that hack gets me to the editor instance | 22:27 |
| TresEquis | only I lost my pdb prompt, gotta run again ;( | 22:27 |
| ree | TresEquis, got to go, good luck! | 22:28 |
| ree | jelmer, thanks! | 22:29 |
| TresEquis | jelmer: what information is interesting from the editor? base_ie? | 22:33 |
| NightNord | lifeless: hah, looks like plugins are actually like git hooks. And I see no plugins that actually 'change' data without marking it as changed | 22:39 |
| lifeless | NightNord: The eol plugin | 22:40 |
| NightNord | Ah, you mean embedded one... | 22:41 |
| NightNord | Now I finally got your point. There is a special type of plug-ins, called 'filters', which are exactly what I need | 22:42 |
| lifeless | yes, we hope | 22:44 |
| TresEquis | jelmer: the base_ie shows that it bzr-svn does think that the parent revision for svn r5147 is svn r4908, instead of r5090 | 22:44 |
| lifeless | not widely used, but if it doesn't fit file a bug and we'll fix. | 22:44 |
| TresEquis | now trying to figure out why | 22:45 |
| jelmer | TresEquis: please note that this is the per-file base, not the per-revision base | 22:45 |
| jelmer | and it's the revision against which the diff is sent, that's also not necessarily the base | 22:45 |
| jelmer | s/the revision/the file revision/ | 22:46 |
| TresEquis | jelmer: (Pdb) parent.base_ie.revision | 22:46 |
| TresEquis | 'svn-v4:4f889dee-8c54-0410-98c1-98789d956ae4:karl/trunk:4908' | 22:46 |
| TresEquis | doesn't that mean that we think the base version of the file is from svn r4908? | 22:47 |
| NightNord | lifeless: simple hack over eol.py show that it fit well. It's even simplier then I thought initially. Thanks again. | 22:47 |
| TresEquis | because svn thinks that the base revision is 5090 | 22:47 |
| MTecknology | is there any installer package for tortoisebzr on windows? | 22:48 |
| jelmer | TresEquis: it only means we expect svn to send the delta against the base text in that revision | 22:48 |
| jelmer | TresEquis: how can you tell svn thinks the base revision is 5090? | 22:49 |
| jelmer | is that the base revision of the overall revision or of this particular file revision? | 22:49 |
| TresEquis | svnlog shows 4098, followed by 5090, followed by 5147 (the last is the one which blows up) | 22:49 |
| jelmer | is the file changed at all in r5090? | 22:50 |
| lifeless | NightNord: cool | 22:50 |
| === jelmer_ is now known as jelmer | ||
| NightNord | lifeless: Actually, quick googling "git content filter" told me, that git supports just the same feature as well. But I will probably stick with bzr on this project, as folks at #git didn't know an answer for same question =) | 22:52 |
| TresEquis | jelmer: svn log of this particular file | 22:53 |
| TresEquis | the diff is a diff against 5090 | 22:53 |
| TresEquis | 5090 was, however, a revision which involved merging a branch | 22:53 |
| TresEquis | so maybe we are deceived by the metadata about the merge? | 22:53 |
| TresEquis | yes | 22:53 |
| TresEquis | jelmer: I set a conditional pdb.set_trace() inside FileRevisionBuildEditor.__init__ | 22:54 |
| TresEquis | the first time it hits, it is being called from open_file with base_revnum=5089 | 22:55 |
| mwhudson | is there any way of doing what bzr replay does that works on paths rather than fileids? | 22:57 |
| TresEquis | jelmer: the second time, the base_revnum of the caller is 5146 | 22:58 |
| TresEquis | jelmer: interesting, the 'len' attribute of the base_ie object matches the len of the r5090 version of the file, but its revision is still 4098 | 23:04 |
| jelmer | so it looks like we're storing the wrong file under the r4098 revid | 23:07 |
| TresEquis | or mapping to it inappropriately? | 23:08 |
| TresEquis | the file's text matches the 4098 revid | 23:08 |
| TresEquis | but not its length | 23:08 |
| TresEquis | anything you's like me to look at about the editor? | 23:09 |
| TresEquis | its parent_trees are both tied to svn r5146 | 23:09 |
| TresEquis | as its base_tree | 23:09 |
| TresEquis | its revid is svn r5147 | 23:10 |
| TresEquis | in the call to _open_file, the file_id and base_file_id are the same | 23:13 |
| jelmer | TresEquis: sorry, don't have time to help debug this at the moment :-/ | 23:15 |
| TresEquis | jelmer: ok, thanks | 23:19 |
| mwhudson | hm | 23:20 |
| mwhudson | is there any way i can cherry pick changes to just one file? | 23:21 |
| lifeless | yes | 23:26 |
| lifeless | mwhudson: merge filename | 23:27 |
| mwhudson | lifeless: ah right | 23:29 |
| mwhudson | thanks | 23:29 |
| lifeless | jam: tsk, you skipped mentioning pyrex in your fix ;P | 23:35 |
| lifeless | in NEWS, I mean. | 23:35 |
| mgz | mentioning slash blaming? | 23:38 |
| lifeless | oh blaming, most definitely | 23:39 |
| lifeless | doing 2.0->2.1 | 23:39 |
| lifeless | to propogate the pyrex fix | 23:39 |
| lifeless | hmm, I want a health checker for our branches | 23:39 |
| poolie | hi all | 23:49 |
| mgz | hello! | 23:50 |
| poolie | martin? | 23:50 |
| mgz | yup, vila made me get a nick that doesn't take half an hour to type ;) | 23:50 |
| bignose | bah. let them eat tab completion. | 23:53 |
| TresEquis | jelmer: I tried to summarize my findings on the LP issue | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
