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