[00:00] <Peng> Nice, I think that push is stuck again.
[01:11] <ubotu> New bug: #175207 in bzr "Fix Makefile rules for doc generation" [Medium,In progress] https://launchpad.net/bugs/175207
[02:52]  * igc lunch
[08:48] <zerok> morning :)
[09:01] <Peng> Indeed it is.
[09:01] <Peng> Except for you weirdos in the Pacific ocean.
[09:01] <Peng> :P
[09:04] <zerok> ^_^
[12:37] <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:38] <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:39] <vila> And even with that we manage to get a *short* read...
[12:40] <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:41] <spiv> s/shortv/short readv/
[12:42] <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:43] <spiv> Well, I can't reproduce the ShortReadvError anymore, so that particular bug is fixed.  (Thanks!)
[12:44] <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:46] <spiv> I'm testing with your fix for 173010
[12:47] <vila> spiv: ha, good
[12:48] <spiv> I thought trying to reproduce 172701 might be a good stress test to make sure your patch really didn't break anything :)
[12:56] <spiv> vila: heh
[12:57] <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:59] <vila> lol, did you noticed that mac distro related bug waws leeeeet too ? :)
[13:00] <vila> spiv: so that squid bug is really bad for us or you can tune the range_offset_limit ?
[13:03] <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:14] <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:15] <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:16] <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:17] <vila> happy to help jam's(TM)
[13:18] <vila> yet 16m for an update... is that a bound branch ?
[13:19] <spiv> vila: nope
[13:20] <spiv> vila: just "bzr branch -r 2977 bzr.dev /tmp/foo; cd /tmp/foo; bzr pull http://bazaar-vcs.org/bzr/bzr.dev/"
[13:28] <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:29] <spiv> I'm going to try tweaking range_offset_limit
[13:30] <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:33] <vila> hmm, try setting it to 250 (our max is 200)
[13:34] <vila> we  issue several range requests on the same file, squid may have some problem with that
[13:37] <vila> ouch forget that, range_offset_limit is not a number of ranges it's a true offset possible value
[13:55] <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:57] <vila> dato: you can't... yet ;-)
[13:58] <dato> vila: ok, thanks. (not even with pycurl, I guess, right?)
[13:59] <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
[14:00] <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:10] <vila> dato: yes
[14:11] <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:13] <vila> oh, I see, being unsure about the meaning of <weasel> I thought it applied to the question not the originator ;-0
[14:51] <dato> phanatic: out of interest, why bzr-gtk 0.93 instead of 1.0?
[14:52] <phanatic> dato: see the release announcement Q&A :)
[14:52] <dato> phanatic: d'oh, sorry!
[14:52] <dato> very well
[14:53] <dato> phanatic: but
[14:54] <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:55] <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:56] <jelmer> bzr-gtk uses some of the most common API's exported by bzr
[14:57] <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
[15:00] <radix> so there's no need for the restrictive dependency in the .deb?
[15:06] <jelmer> not imho
[15:06] <dato> let's drop it then
[15:09] <radix> that would be fantastic
[15:10] <radix> I haven't been able to use bzr-gtk in quite a while because of it
[15:10] <dato> why?
[15:13] <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:14] <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:15] <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:16] <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:17] <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:20] <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:21] <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:23] <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
[16:50] <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:51] <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:52] <radix> sweet! with fixed dependencies and everything! you're my hero :-)
[17:22] <dennda> hi
[17:23] <dennda> what's wrong here? http://pastebin.ca/811148
[17:23] <dennda> and how do I fix it?
[17:24] <dato> dennda: you made a checkout of a read-only transport
[17:25] <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:28] <dennda> takes looong
[17:28] <dennda> ok, works. thank you
[17:28] <dato> you're welcome
[17:29] <dennda> :)
[18:06] <ubotu> New bug: #175337 in bzr "bzr bind should not check for divergence" [Medium,Triaged] https://launchpad.net/bugs/175337
[18:30] <sabdfl> hi folks
[18:30] <sabdfl> are there deb's for 1.0rcx?
[18:31] <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:32] <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:34] <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> [18:34] <fbond> bzr: ERROR: No such file: u'/home/fab/work/debs/pytagsfs/pytagsfs/debian/dirs'
[18:35] <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:36] <fbond> Just "rm debian/dirs"
[18:36] <jam> I see "[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:37] <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:38] <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:39] <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:40] <jam> fbond: it does
[18:40] <jam> So it looks to be fixed for 1.0rc23
[18:41] <jam> So it looks to be fixed for 1.0rc2
[18:44] <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:45] <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:47] <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:48] <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:49] <fbond> It's really nice.
[18:50] <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 :)
[19:35] <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.
[20:05] <ubotu> New bug: #175373 in bzr "Cannot merge -r 0..-1 in an empty branch" [Undecided,New] https://launchpad.net/bugs/175373
[20:50] <ubotu> New bug: #175390 in bzr "SSL Client Cert support in the auth ring" [Undecided,New] https://launchpad.net/bugs/175390
[22:00] <poolie> jam, statik, hi
[22:01] <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:03] <poolie> wait for jam?
[22:03] <statik> poolie: sure thing, I'll be around for a bit
[22:11] <poolie> statik, i'll ping him
[22:16] <jam> hi
[22:58] <igc> morning
[22:59] <abentley> Hey gang.
[22:59] <phanatic> morning guys
[23:00] <jam> morning igc
[23:05] <thumper> morning people
[23:06] <abentley> thumper: morning.
[23:19] <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:20] <spiv> jam: sure, a couple of hours is fine
[23:20] <jam> k
[23:20]  * jam => family time
[23:25] <mwhudson> jam: it seems https://code.edge.launchpad.net/~jameinel/bzr/extra-range-collapse-165061 mirrored at long last