| Peng | Nice, I think that push is stuck again. | 00:00 |
|---|---|---|
| ubotu | New bug: #175207 in bzr "Fix Makefile rules for doc generation" [Medium,In progress] https://launchpad.net/bugs/175207 | 01:11 |
| === me_too is now known as too_short | ||
| === too_short is now known as me_too | ||
| === me_too is now known as too_short | ||
| === too_short is now known as me_too | ||
| === me_too is now known as too_short | ||
| === too_short is now known as me_too | ||
| * igc lunch | 02:52 | |
| === me_too is now known as turbo0O | ||
| === turbo0O is now known as me_too | ||
| === asak_ is now known as asak | ||
| === doko__ is now known as doko | ||
| zerok | morning :) | 08:48 |
| Peng | Indeed it is. | 09:01 |
| Peng | Except for you weirdos in the Pacific ocean. | 09:01 |
| Peng | :P | 09:01 |
| zerok | ^_^ | 09:04 |
| spiv | vila: I've partially diagnosed my squid problem (bug 172701) | 12:37 |
| ubotu | Launchpad bug 172701 in bzr "Large readv requests can fail if there is a squid proxy" [High,Fix released] https://launchpad.net/bugs/172701 | 12:37 |
| vila | spiv: I'm all ears | 12:38 |
| spiv | vila: the extreme slowness appears to be because squid will sometimes fetch entire files even if the client asks for just a range -- even if the client also sets Pragma: no-cache & Cache-control: max-age=0. | 12:38 |
| vila | And even with that we manage to get a *short* read... | 12:39 |
| vila | you're sure it's not triggered by bzr issuing a new request after a short read instead ? | 12:40 |
| spiv | vila: So the client sends requests to fetch a small amount of a large pack file, and squid fetches the whole thing and then forgets it. Then the client asks for a different part of the same file, and squid fetches the whole thing over again, etc. | 12:40 |
| spiv | vila: So I haven't reproduced the shortv since you claimed to have fixed it | 12:40 |
| spiv | vila: but this explains why it's ridiculously slow :) | 12:40 |
| spiv | s/shortv/short readv/ | 12:41 |
| vila | the way I fixed it is to issue a larger request (single range encompassing all the offsets or if that fails too the whole file) when a short read is encountered | 12:42 |
| vila | if you still can reproduce it try with -Dhttp, that will log all the requests and mention the retries | 12:42 |
| spiv | Well, I can't reproduce the ShortReadvError anymore, so that particular bug is fixed. (Thanks!) | 12:43 |
| spiv | But I thought you'd be interested to know about some of the other strange behaviour (extreme slowness) I saw while experiencing that bug :) | 12:44 |
| vila | my fix for 173010 has landed, it will produce still another behavior (pycurl will not emit requests bigger than 4M) so be sure to check what version you're using | 12:44 |
| spiv | I'm testing with your fix for 173010 | 12:46 |
| vila | spiv: ha, good | 12:47 |
| spiv | I thought trying to reproduce 172701 might be a good stress test to make sure your patch really didn't break anything :) | 12:48 |
| spiv | vila: heh | 12:56 |
| spiv | vila: it's bug 1337 in squid's bug tracker :) | 12:57 |
| ubotu | Launchpad bug 1337 in malone "Distro release tasks should include name of distro" [Low,Invalid] https://launchpad.net/bugs/1337 | 12:57 |
| spiv | ubotu: no, http://www.squid-cache.org/bugs/show_bug.cgi?id=1337 :P | 12:57 |
| vila | lol, did you noticed that mac distro related bug waws leeeeet too ? :) | 12:59 |
| vila | spiv: so that squid bug is really bad for us or you can tune the range_offset_limit ? | 13:00 |
| vila | hmmm, thinking more about it, at the time of 172701 we were issuing far too much ranges , so maybe this bug has been fixed in two different ways | 13:03 |
| === cfbolz_ is now known as cfbolz | ||
| spiv | vila: well, when using http+urllib I still see "http readv of a3069b4df97462558e8666ff0cc72386.pack offsets => 705 collapsed 161 | 13:14 |
| spiv | " | 13:14 |
| spiv | vila: the fetch completes though. | 13:14 |
| spiv | vila: it takes about 16m now (with both urllib or pycurl) to do the pull in 172701 through my squid proxy. | 13:15 |
| vila | spiv: it may still occurs for valid reasons (fragmented repo), before the patch more ranges can be emitted for not so valid reasons | 13:15 |
| spiv | vila: which is better than in 172701 (where it was failing, and taking longer to do so!) | 13:16 |
| spiv | So I'm pretty happy. | 13:16 |
| vila | happy to help jam's(TM) | 13:17 |
| vila | yet 16m for an update... is that a bound branch ? | 13:18 |
| spiv | vila: nope | 13:19 |
| spiv | vila: just "bzr branch -r 2977 bzr.dev /tmp/foo; cd /tmp/foo; bzr pull http://bazaar-vcs.org/bzr/bzr.dev/" | 13:20 |
| spiv | vila: if I bypass my squid proxy, it takes 9m 43s to do the same pull. | 13:28 |
| spiv | vila: (versus 16m 5s with squid) | 13:28 |
| vila | hmm, bad proxy :-/ | 13:28 |
| spiv | vila: yup :( | 13:28 |
| spiv | I'm going to try tweaking range_offset_limit | 13:29 |
| vila | ha, let me know, if you succeeds that will be worth mentioning it in bug #172701 at least | 13:30 |
| ubotu | Launchpad bug 172701 in bzr "Large readv requests can fail if there is a squid proxy" [High,Fix released] https://launchpad.net/bugs/172701 | 13:30 |
| spiv | vila: curiously, my squid.conf claims that range_offset_limit is already 0 (i.e. never fetch more than client requested). | 13:30 |
| vila | hmm, try setting it to 250 (our max is 200) | 13:33 |
| vila | we issue several range requests on the same file, squid may have some problem with that | 13:34 |
| vila | ouch forget that, range_offset_limit is not a number of ranges it's a true offset possible value | 13:37 |
| dato | vila: <weasel> how do I tell bzr to use a different ca-certificates file (for https), or tell it to accept cert with fingerprint $fpr for a host? | 13:55 |
| dato | vila: I guess you're the right person to ask that to :) | 13:55 |
| vila | dato: you can't... yet ;-) | 13:57 |
| dato | vila: ok, thanks. (not even with pycurl, I guess, right?) | 13:58 |
| vila | dato: oops, checking code, it seems you can use CURL_CA_BUNDLE to indicate a different ca-certificates file (I thought only win32 can do that) but I never tested it myself | 13:59 |
| vila | I'm currently working on a https test server, once that's done, I plan to add these capabilities to urllib and be in position to deprecate pycurl | 14:00 |
| dato | aha. CURL_CA_BUNDLE, environment variable? | 14:00 |
| vila | dato: yes | 14:10 |
| dato | thanks | 14:11 |
| vila | dato: if you test it let me know | 14:11 |
| dato | certainly not me, maybe weasel .9 | 14:11 |
| dato | er, :) | 14:11 |
| vila | bialix added it for win32 so I don't know that code very well | 14:11 |
| vila | oh, I see, being unsure about the meaning of <weasel> I thought it applied to the question not the originator ;-0 | 14:13 |
| === cprov is now known as cprov-lunch | ||
| dato | phanatic: out of interest, why bzr-gtk 0.93 instead of 1.0? | 14:51 |
| phanatic | dato: see the release announcement Q&A :) | 14:52 |
| dato | phanatic: d'oh, sorry! | 14:52 |
| dato | very well | 14:52 |
| dato | phanatic: but | 14:53 |
| dato | phanatic: should I still enforce at packaging level that 0.93 needs 1.0, and can't work with e.g. 1.1? | 14:54 |
| phanatic | dato: i suppose the bzrlib API should be backwards compatible throughout the whole 1.x series... | 14:54 |
| radix | I sure hope so, maybe I will actually be able to use bzr-gtk if the bzrlib API stabilizes :) | 14:55 |
| dato | I haven't seen any mention that API changes will be handled any different in 1.x than they were in 0.x | 14:55 |
| dato | but alas, I don't read every post in the list :) | 14:55 |
| jelmer | bzr-gtk uses some of the most common API's exported by bzr | 14:56 |
| jelmer | I bet 0.93 is compatible with even 0.18 | 14:57 |
| jelmer | some of the other plugins like bzrtools and bzr-svn use more obscure API's that are more prone to changes | 14:57 |
| radix | so there's no need for the restrictive dependency in the .deb? | 15:00 |
| jelmer | not imho | 15:06 |
| dato | let's drop it then | 15:06 |
| radix | that would be fantastic | 15:09 |
| radix | I haven't been able to use bzr-gtk in quite a while because of it | 15:10 |
| dato | why? | 15:10 |
| radix | dato: because I keep track of the bazaar repository and every time I try to install bzr-gtk I don't have an old enough version of bzr | 15:13 |
| radix | unless this has recently changed, I don't think bzr-gtk is updated at the same time as bzr | 15:13 |
| jelmer | that's still the case | 15:13 |
| jelmer | bzr-gtk releass some time after bzr releases a rc usually | 15:14 |
| dato | radix: what repository? bazaar-vcs.org/releases/debs ? | 15:14 |
| jelmer | dato: Debian Sid as well | 15:14 |
| radix | the bazaar-vcs.org repository, yeah, wherever it is | 15:14 |
| jelmer | dato: simply because upstream is behind and hasn't released a compatible version yet | 15:15 |
| dato | yes, but... he should be able to install bzr-gtk in a couple days (or, ok, a week) | 15:15 |
| dato | jelmer: yes, I know that. only, that I'm very surprised to hear radix say that he hasn't been able to use bzr-gtk for a long while because of that | 15:15 |
| radix | dato: bzr releases pretty regularly | 15:15 |
| jelmer | well, 1.0rc1 is two weeks or so old now? | 15:15 |
| radix | as I'm sure you're aware | 15:16 |
| jelmer | not sure what qualifies as "a long while" in radix' opinion :-) | 15:16 |
| radix | so maybe there are some windows in which I could install bzr-gtk | 15:16 |
| radix | jelmer: 6 months maybe? | 15:16 |
| radix | every time I try I seem to either get a dependency error, or it's soon uninstalled the next time I upgrade bzr | 15:16 |
| dato | anyway, I just think that if you care about bzr-gtk, you shouldn't dist-upgrade bzr until both become available | 15:17 |
| dato | if you're blingly dist-upgrading, otoh... | 15:17 |
| radix | I use stable Ubuntu releases, augmented with the bazaar-vcs.org repository. | 15:20 |
| radix | I'm not tracking debian unstable or something like that | 15:20 |
| dato | well, bazaar-vcs.org has bzr-gtk 0.90 ... | 15:21 |
| dato | radix: without needing to track unstable, you could just grab bzr-gtk from there | 15:21 |
| dato | if you care enough, that is :) | 15:21 |
| radix | dato: right, and that version of bzr-gtk depends on bzr << 0.91~, but the version of bzr it has is 1.0~rc1-3bazaar1 | 15:23 |
| === cprov-lunch is now known as cprov | ||
| === siretart_ is now known as siretart | ||
| ndim | radix: That is bzr-gtk's and bzr's way of telling you to go take a 3 week vacation until the thing is sorted out. | 16:50 |
| radix | ndim: more like a 6 month vacation :) | 16:50 |
| radix | which I'd be happy to do ;-) | 16:50 |
| dato | radix: if you'd like, http://incoming.debian.org/bzr-gtk_0.93.0-1_all.deb ought to install with your current bzr | 16:51 |
| radix | sweet! with fixed dependencies and everything! you're my hero :-) | 16:52 |
| dennda | hi | 17:22 |
| dennda | what's wrong here? http://pastebin.ca/811148 | 17:23 |
| dennda | and how do I fix it? | 17:23 |
| dato | dennda: you made a checkout of a read-only transport | 17:24 |
| dato | dennda: if you run `bzr checkout`, you should use a sftp:// url, instead of an http:// one | 17:25 |
| dato | dennda: try this: | 17:25 |
| dato | bzr unbind | 17:25 |
| dato | bzr bind sftp://bazaar.launchpad.net/~dennda/memaker/motor | 17:25 |
| dato | dennda: and commit again | 17:25 |
| dennda | takes looong | 17:28 |
| dennda | ok, works. thank you | 17:28 |
| dato | you're welcome | 17:28 |
| dennda | :) | 17:29 |
| ubotu | New bug: #175337 in bzr "bzr bind should not check for divergence" [Medium,Triaged] https://launchpad.net/bugs/175337 | 18:06 |
| sabdfl | hi folks | 18:30 |
| sabdfl | are there deb's for 1.0rcx? | 18:30 |
| jam | sabdfl: I see debs for 1.0rc1 available in http://bazaar-vcs.org/releases/debs/gutsy/ | 18:31 |
| jam | I don't see 1.0rc2 yet | 18:31 |
| dato | hardy also has them, via sid | 18:31 |
| jam | dato: What about for debian itself? | 18:31 |
| dato | and sid has rc2 | 18:31 |
| dato | (but hardy does not have rc2 yet) | 18:32 |
| dato | jam: ^ | 18:32 |
| jam | dato: well, I also don't see a "hardy" in http://bazaar-vcs.org/releases/debs/ | 18:32 |
| dato | jam: I mean proper hardy, as in packages.ubuntu.com | 18:32 |
| jam | we should probably update that, unless we are just using 'sid' for that. | 18:32 |
| jam | ah | 18:32 |
| fbond | Hey, is this a known issue? I removed a file, and now bzr diff halts with "no such file or directory" | 18:34 |
| fbond | === removed file 'debian/dirs' | 18:34 |
| fbond | bzr: ERROR: No such file: u'/home/fab/work/debs/pytagsfs/pytagsfs/debian/dirs' | 18:34 |
| fbond | This is new behavior, from what I can tell, on 1.0.0 rc1, using dirstate-tags. | 18:35 |
| jam | fbond: I don't see that here, did you use "bzr rm debian/dirs" or just plain "rm debian/dirs" ? | 18:35 |
| fbond | Just "rm debian/dirs" | 18:36 |
| jam | I see "=== removed file 'generate_docs.py'" | 18:36 |
| fbond | That used to work. Does it no longer? | 18:36 |
| jam | and then a patch | 18:36 |
| jam | with everything in the "removed" field | 18:36 |
| jam | fbond: if you can reproduce it, I'll try to debug | 18:36 |
| jam | but my simple test here just works | 18:36 |
| fbond | It is happening consistently for me. | 18:36 |
| jam | fbond: can you reproduce it in a test script? | 18:37 |
| jam | or alternatively, is the stuff something that you could tar up and send to me? | 18:37 |
| fbond | Probably. | 18:37 |
| fbond | Well, it's actually on LP, anyway. | 18:37 |
| jam | hmm... I think I reproduced it with 1.0rc1 | 18:37 |
| jam | it doesn't reproduce in bzr.dev | 18:37 |
| fbond | Yeah, I'd never seen it before. | 18:38 |
| fbond | I actually blamed it on bzr-builddeb. | 18:38 |
| jam | I think I remember Aaron doing something with .kind() for diff | 18:38 |
| jam | let me see if it is in 1.0rc2 | 18:38 |
| fbond | Okay. | 18:38 |
| jam | fbond: bzr.dev revno 3088: Diff handles missing files correctly, with no tracebacks | 18:39 |
| jam | I'm getting 1.0rc2 now to see if it has that fix | 18:39 |
| jam | fbond: it does | 18:40 |
| jam | So it looks to be fixed for 1.0rc23 | 18:40 |
| jam | So it looks to be fixed for 1.0rc2 | 18:41 |
| fbond | jam: Okay, so I just need to upgrade. | 18:44 |
| fbond | Which brings us back to ... | 18:44 |
| fbond | .debs for rc2 ! | 18:44 |
| fbond | :) | 18:44 |
| jam | lifeless was the one making .debs, but I know he is on vacation for the rest of the month, I'm not sure, but I think poolie was going to take over | 18:45 |
| jam | I'll ask him when he comes online later tonight | 18:45 |
| jam | In the mean-time you probably can "bzr rm filename" and have it stop failing | 18:45 |
| fbond | Wow, nice vacation. Okay, no big deal. | 18:45 |
| fbond | jam: Thanks! | 18:47 |
| jam | Yeah, lifeless tends to not take any vacation during the whole year | 18:47 |
| jam | we always take the last week off anyway, so it is just 2-weeks just before the last week off | 18:47 |
| fbond | Gotcha. | 18:48 |
| fbond | No need to justify to me. If he can swing it, good for him! | 18:48 |
| fbond | With PPA in place now, you guys should think about just building on LP. | 18:48 |
| fbond | It's really nice. | 18:49 |
| fbond | Using bzr-builddeb, upgrading to a new upstream version is little more than a 30 second operation. | 18:50 |
| fbond | But I guess I'll stop evangelizing :) | 18:50 |
| === cprov is now known as cprov-out | ||
| hexmode | does anyone have an easy-to-follow pqm setup manual? | 19:35 |
| hexmode | I'd like to use it but it looks like I'd need to learn a lot before I attack it. | 19:35 |
| ubotu | New bug: #175373 in bzr "Cannot merge -r 0..-1 in an empty branch" [Undecided,New] https://launchpad.net/bugs/175373 | 20:05 |
| ubotu | New bug: #175390 in bzr "SSL Client Cert support in the auth ring" [Undecided,New] https://launchpad.net/bugs/175390 | 20:50 |
| poolie | jam, statik, hi | 22:00 |
| poolie | yes, i was going to make debs | 22:01 |
| statik | poolie: hi! | 22:01 |
| poolie | shall we talk | 22:01 |
| statik | talking would be fabluous | 22:01 |
| poolie | wait for jam? | 22:03 |
| statik | poolie: sure thing, I'll be around for a bit | 22:03 |
| === Mez is now known as Mez|OnAir | ||
| poolie | statik, i'll ping him | 22:11 |
| jam | hi | 22:16 |
| igc | morning | 22:58 |
| abentley | Hey gang. | 22:59 |
| phanatic | morning guys | 22:59 |
| jam | morning igc | 23:00 |
| thumper | morning people | 23:05 |
| abentley | thumper: morning. | 23:06 |
| spiv | jam: when do you want to talk about the set memory consumption strangeness? | 23:19 |
| jam | spiv: would it be fine after a couple hours? | 23:19 |
| jam | (I assume you are just starting your day) | 23:19 |
| jam | basically, the sets are consuming more memory than I thought they would | 23:19 |
| spiv | jam: sure, a couple of hours is fine | 23:20 |
| jam | k | 23:20 |
| * jam => family time | 23:20 | |
| mwhudson | jam: it seems https://code.edge.launchpad.net/~jameinel/bzr/extra-range-collapse-165061 mirrored at long last | 23:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!