[12:03] <poolie> btw there's some docstring corrections in my pack-repo branch
[12:04] <lifeless> I'm thinking about this knit change
[12:04] <lifeless> heres what I plan:
[12:04] <lifeless>  - add a new subclass of knit that writes a different knit record but can read either
[12:04] <lifeless>  - add a new interknit to convert data from regular knits to this
[12:05] <lifeless> change packs to use the new knit
[12:05] <abentley> abadger1999: Thanks.  I've emailed the other contributors, to confirm it's okay with them (though I understand I'm not required to by law).
[12:05] <abadger1999> That's excellent.  Thanks for helping me clear that up.
 I am still getting the same error on windows : bzr: ERROR : ERROR 2 The system cannot find the file specified
[12:11] <kiko-afk> has anyone seen this error?
[12:11] <lifeless> no
[12:11] <lifeless> if you run with BZR_PDB=1 you can drop into pdb and poke around
[12:11] <lifeless> or check .bzr.log for a backtrace
[12:11] <kiko-afk> it's windows though
[12:12] <lifeless> ye
[12:12] <lifeless> s
[12:12] <lifeless> bzr version will show where the log file is
[12:12] <lifeless> (bzr --version)
[12:13] <abadger1999> abentley: BTW, I have a little patch that makes python setup.py sdist include the COPYING file
[12:13] <abadger1999>  http://toshio.fedorapeople.org/packages/trac+bzr-install.patch
[12:13] <kiko-afk> intriguing! thanks.
[12:15] <abentley> I don't understand your setup.py change.
[12:16] <abadger1999> I'm not sure why, but setuptools is deciding not to include COPYING in the tarball even though it is listed in data_files
[12:16] <abadger1999> moving it from data_files to MANIFEST.in makes setuptools more cooperative.
[12:17] <abentley> weird.
[12:17] <abadger1999> There's also some setuptools documentation that makes me think that data_files is for real data_files that the python module depends on at runtime
[12:18] <abadger1999> While MANIFEST.in can feed files into the tarball that aren't put into the installed module tree.
[12:18] <abentley> Okay, I'll take it on trust.
[12:19] <abadger1999> heh. Thanks :-)
[12:30] <abentley> lifeless: I don't know if the bzr.dev deb Recommends xdg-utils, but it should.  (The recent bzr send updates use xdg-email if possible)
[12:30] <lifeless> probably doesn't.
[12:30] <lifeless> I haven't started building dailies yet though
[12:30] <abentley> Okay.
[12:31] <abentley> Just thought of that, reading today's IRC log.
[12:31] <lifeless> thanks
[12:31] <lifeless> uhm, where to record this :)
[12:42] <beuno> does anyone know why someone would be getting these errors: http://paste.ubuntu-nl.org/35614/
[12:43] <poolie> it looks like it's trying to run putty and failing
[12:43] <igc> morning
[12:44] <beuno> poolie: I believe it's related to: https://bugs.launchpad.net/bzr/+bug/107155
[12:44] <ubotu> Launchpad bug 107155 in bzr "_get_vendor_by_inspection incorrectly determines "plink" to be the executable" [Medium,Confirmed] 
[12:48] <poolie> hi igc
[12:49] <beuno> it is  :D
[12:49] <poolie> beuno, yes, that looks like it
[12:49] <igc> morning poolie. Feeling better today?
[12:49] <poolie> suggest you try the workoround
[12:49] <beuno> it fixed it for him, thanks poolie
[12:49] <poolie> igc: no :)
[12:49] <poolie> beuno, could you try to write a patch for it that  changes the code that determines the ssh version ?
[12:51] <beuno> poolie: I can give it a try, yes   :D
[12:51] <beuno> I'll have to find a pc with windows around the office to test it, but I guess it shouldn't be too hard
[01:27] <Janzert> would anyone have a guesstimate for when win32 0.90 installers will be up?
[01:28] <poolie> Janzert, typically they come within a day or two of the release
[01:28] <lifeless> I'm not sure who is building them this time
[01:28] <poolie> alexander haro?
[01:29] <Janzert> ok, thanks
[01:32] <lifeless> yah
[01:32] <lifeless> might need a oing
[02:24] <lifeless> ok, should have our 0.90 debs up shortly, last build glitches for feisty gutsy sid seem fixed
[02:35] <tonyyarusso> btw, in case anyone cares I asked Apress and O'Reilly if they had any plans for a Bazaar book.  Both said no, not at this time, but were open to proposals.
[02:37] <kiko-afk> if they pay me a million dollars I will write two books on bzr
[03:34] <lifeless> spiv: hows that digit ?
[03:35] <spiv> lifeless: in motion ;)
[03:36] <poolie> digit?
[03:38] <spiv> I used a phrase like "I need to extract my digit" in a call yesterday when talking about getting the latest hpss fetch optimisation work up for review.
[03:44] <poolie> lifeless, there's an extension of look before you leap
[03:44] <poolie> which is about giving nice error messages if someone uses an api wrongly
[03:45] <poolie> for example if you give just a string rather than a tuple to an index as a key,
[03:45] <poolie> it just fails to match, or gives you a 'weird' error when trying to insert
[03:45] <poolie> i would have thought this was a bug, but it's probably not - checking everything takes time
[03:45] <poolie> and once i realize it's my bug it won't happen again
[03:46] <lifeless> right
[03:46] <poolie> you do pay the cost of developers being more mystified when they have bugs though
[03:47] <poolie> so possibly we should arrange to run with -O in normal use, but with assertions on in development
[03:47] <lifeless> so I'd be much happier if "asd"[0] [0]  errored
[03:47] <poolie> that sorta thing
[03:48] <lifeless> well in this case its a string blackhole
[03:48] <lifeless> (1,2)[0] [0]  errors
[03:48] <poolie> another thing like that was the patch from aaron i reviewed a while ago
[03:48] <poolie> things that are meant to yield a sequence of strings can silently return just a string instead, potentially making you do much more work
[03:48] <lifeless> yup
[03:49] <lifeless> my pet wish for python - have a byte data type. not *bytes*, *byte*.
[03:49] <poolie> mm
[03:53] <poolie> woot
[03:53] <lifeless> so gzipping is a net win
[03:53] <lifeless> we spend 4m20 seconds in IO if we don't gzip
[03:53] <lifeless> 1m40 if we do
[03:57] <lifeless> this is for a copy of mozilla, naturally
[04:15] <beuno> poolie, I'm finishing up the patch for bug #107155, should I just send it to the ML with [MERGE]  in the topic, or would you like to review it?
[04:15] <ubotu> Launchpad bug 107155 in bzr "_get_vendor_by_inspection incorrectly determines "plink" to be the executable" [Medium,Confirmed]  https://launchpad.net/bugs/107155
[04:16] <lifeless> beuno: just send to the lsit; things get reviewed there :)
[04:17] <beuno> lifeless, should of guessed, thanks.  I'm a bit nervous as this is actually changing code in bzr, I'm not that confident yet  :p
[04:20] <poolie> lifeless, do you want to talk about gzip some more?
[04:25] <lifeless> sorry, no browser:
[04:25] <lifeless> gzip each hunk
[04:25] <lifeless> real    5m53.774s
[04:25] <lifeless> user    4m7.047s
[04:25] <lifeless> sys     0m12.901s
[04:25] <lifeless> no gzip
[04:25] <lifeless> real    7m8.611s
[04:25] <lifeless> user    2m41.846s
[04:25] <lifeless> sys     0m16.821s
[04:25] <lifeless> gzip entire contents
[04:26] <lifeless> real    4m46.153s
[04:26] <lifeless> user    4m29.457s
[04:26] <lifeless> sys     0m11.961s
[04:26] <lifeless> so we spend nearly 50% of our user time doing gzip
[04:27] <lifeless> but overall time is IO bound for mozilla's tree if we don't gzip
[04:43] <beuno> lifeless, should of guessed, thanks.  I'm a bit nervous as this is actually changing code in bzr, I'm not that confident yet  :p
[04:43] <beuno> (sorry, wrong windows)
[04:43] <lifeless> :)
[04:44] <beuno> irssi still confuses me with the actual terminal sometimes, so up + enter is dangerous  :p
[05:06] <abentley> igc: ping
[05:07] <igc> hi abentley
[05:07] <abentley> Hi there.
[05:08] <abentley> I wanted to try and get a clearer idea of the distinction between "user guide" material and "user reference" material.
[05:08] <igc> the 'reference' should cover every detail ...
[05:08] <bheekling> Does bzr work from behind an http proxy?
[05:08] <bheekling> ie, if I set the http_proxy etc variables
[05:09] <abentley> 'cause the hook document was definitely meant as a how-to.
[05:09] <igc> but not bother explaining how to use those details
[05:09] <lifeless> bheekling: yes
[05:09] <igc> how-to is definitely 'User Guide' material
[05:09] <bheekling> it doesn't seem to be working for me, it says "bzr: ERROR: Transport error: Server refuses to fullfil the request"
[05:09] <igc> abentley: I'm pleased to see hooks added to the User Guide ...
[05:09] <lifeless> bheekling: interesting. You might try http+httplib
[05:10] <lifeless> rather htan just http
[05:10] <igc> The list of actual hooks though also lives in the Reference I feel
[05:10] <lifeless> and please file a bug with as much information as you have - what proxy server
[05:10] <abentley> igc: I think a certain amount of reference material is necessary to any how-to.
[05:11] <igc> yes. At least enough to explain things and give samples
[05:11] <bheekling> lifeless, what do you mean by http+httplib?
[05:12] <abentley> I guess I could ignore all the other hook types and just talk about the push hook.
[05:12] <igc> abentley: if and when we get lots of hooks, I don't think I want all of them in the Guide
[05:12] <abentley> And then link to a hook reference.
[05:13] <igc> That sounds good
[05:14] <lifeless> bheekling: 'bzr OPERATION http+urllib://server/path'
[05:14] <abentley> What is strange but true is I often 'bzr pull' my own patches off Bundle Buggy.  The hook docs were written at work, but I'll finish them at home.
[05:15] <igc> I download patches off BB all the time, even though their in my email somewhere
[05:16] <igc> s/their/they're/
[05:16] <abentley> igc: I download my own patches, though.
[05:16] <igc> ok, you win :-)
[05:17] <igc> can't beat that :-)
[05:20] <bheekling> lifeless, it works with that, thanks :)
[05:20] <lifeless> bheekling: can you please file a bug?
[05:20] <lifeless> bheekling: specify what proxy you have if you know
[05:21] <bheekling> lifeless, okay, I'll do that
[05:21] <lifeless> thanks
[05:29] <bheekling> lifeless, correction, it seems bzr works with my proxy just fine, that problem was a random fluctuation I think :)
[05:29] <bheekling> Its importing happily now
[05:42] <igc> poolie: any further thoughts re whether -D needs to stay a global option or not? I'm planning to make it a "standard option" instead of a global one unless I hear a reason not to
[05:43] <lifeless> it affects everythin
[05:43] <lifeless> so it should be global IMNSHO
[05:44] <igc> ok - so it *must* remain global?
[05:45] <poolie> igc, hi
[05:45] <lifeless> I think so, because we might do e.g. -Dcommand at some point, to track ui loading
[05:45] <lifeless> if we're happy not to do that, then having it standard is ok
[05:46] <igc> It seems to me that the limitations re global options are aceptable to -D
[05:47] <lifeless> profiling is the most boringest thing
[05:47] <poolie> igc, i agree it's ok to change it
[05:47] <poolie> is there a particular motivation for changing it?
[05:47] <igc> I can certainly see a case where parsing it before anything else would be required
[05:47] <igc> poolie: just following up your email
[05:48] <igc> ... where you thought out loud about 'maybe -D doesn't need to remain global'
[05:48] <igc> IIRC that is
[05:49] <lifeless> ok
[05:49] <lifeless> annotations cost us heaps
[05:49] <lifeless> $ rm -rf .bzr && bzr --no-plugins  init --experimental && bzr --no-plugins add > /dev/null && time ~/source/baz/repository/bzr --no-plugins  commit -m "Initial commit"  2>/dev/null
[05:49] <igc> so poolie, given the feedback from lifeless, I'll leave it global
[05:49] <lifeless> real    3m50.336s
[05:49] <lifeless> user    3m34.897s
[05:49] <lifeless> sys     0m10.941s
[05:49] <lifeless> thats a 30 second improvement
[05:49] <lifeless> on initial commit
[05:50] <lifeless> just by not caching annotations
[05:50] <lifeless> (4m23 to 3m50)
[05:50] <igc> lifeless: interesting
[05:59] <abentley> lifeless: that's strange, because annotations do require sequence matching, but so does knit delta generation, and AIUI, they share the same sequence matching.
[06:00] <lifeless> we do less string manipulation without annotations
[06:00] <lifeless> because annotations are stored as line prefixes in the knit record
[06:01] <abentley> So even changing our annotation representation might help a lot?
[06:02] <lifeless> potentially
[06:02] <poolie> lifeless, one thing you could try is using lzo compression
[06:02] <poolie> which uses less cpu than gzip
[06:03] <lifeless> I found nearly no difference using one gzip file versus one-per-record
[06:03] <lifeless> user    4m29.457s
[06:03] <lifeless> user    4m3.963s
[06:03] <lifeless> in fact, it went backwards
[06:03] <lifeless> which was weird
[06:04] <abentley> Smaller working set, maybe.
[06:05] <poolie> lifeless, is there already a container record that says "give me the contents of the bytes record at (off,len)"?
[06:06] <lifeless> poolie: EPARSE
[06:06] <lifeless> do you mean API ?
[06:06] <poolie> my index tells me i want the record at a certain location in the container
[06:06] <poolie> yes, api
[06:06] <poolie> mistyped
[06:07] <lifeless> pack.make_readv_reader
[06:08] <poolie> excellent
[06:09] <lifeless> abentley: I don't think so; compressing the entire pack to a single zip should have nearly identical memory use
[06:10] <lifeless> I htink there is still room for considerable noise
[06:10] <lifeless> btw feisty gutsy sid repos on bazaar-vcs.org have bzr/bzrtools/bzr-gtk 0.90 now
[06:10] <abentley> lifeless: nice.
[06:10] <abentley> Edgy?
[06:10] <lifeless> on my list
[06:11] <abentley> Ah.  Not as easy to update, then?
[06:11] <lifeless> not quite, got to back out some packaging changes that removed explicit versioning on depends
[06:11] <ajmitch> etch is the same?
[06:12] <lifeless> yah
[06:15] <NamNguyen> can we cast a vote with BB's web interface?
[06:15] <lifeless> if you have an account; accounts are granted when abentley things you are sane
[06:15] <NamNguyen> lifeless: i'm running bb on my machine
[06:16] <NamNguyen> but i cant find any button to approve or decline a merge request
[06:16] <abentley> NamNguyen: Congratulations.  AFAIK, that's the first independent install.
[06:16] <abentley> NamNguyen: You have to be logged in.
[06:16] <NamNguyen> abentley: and i have logged in
[06:16] <igc> ManNguyen: have a read of http://bazaar-vcs.org/IanClatworthy/CoreDeveloperHandbook. It should answer some of the questions you had yesterday
[06:17] <igc> NamNguyen: ^^^
[06:17] <abentley> So it should show you voting options from "reject" to "approve" on the request page.
[06:18] <NamNguyen> i see a list of tabs, but i dont see any buttons
[06:18] <poolie> lifeless, it looks like i want something like that, but creating a BytesRecordReader, not a ContainerReader...
[06:18] <abentley> You need to go to the page for a particular request.
[06:18] <lifeless> poolie: you want one record out?
[06:19] <poolie> well, possibly more than one
[06:19] <lifeless> poolie: thats going to perform badly on high latency links
[06:19] <abentley> By clicking on the summary link
[06:19] <lifeless> poolie: I don't see why it doesn't do what you need - you iterate the container to get the byte records you want
[06:20] <NamNguyen> abentley: thank you, it's weird, now i can see it, i was so sure i didn't see that before
[06:20] <poolie> oh i see
[06:20] <abentley> No problem.
[06:20] <poolie> there's just one more layer...
[06:21] <abentley> I saw earlier you were upset it used procmail.  Does your server not have procmail?
[06:21] <NamNguyen> it's running on windows
[06:22] <abentley> Amazing.
[06:22] <NamNguyen> so i wrote a pop3 client to manually poll at 5-min interval
[06:22] <NamNguyen> and submit it to the web
[06:23] <abentley> Hmm.  Maybe that makes sense for Windows.
[06:23] <NamNguyen> yea, it doesn't have local maildir
[06:23] <NamNguyen> but of course, then it wouldn't be "real-time" enough
[06:23] <lifeless> cygwin has procmail if you want it
[06:25] <abentley> Well, you certainly can set up a local mail server on Windows, I just imagine it's a pain.
[06:25] <NamNguyen> i'm using gmail apps
[06:25] <lifeless> setup.exe from cygwin, select fetchmail and procmail; or at least thats what I'd do:)
[06:25] <NamNguyen> it's better just to write a few lines of pop3
[06:27] <abentley> lifeless: You shameless former-cygwin-developer, you :-)
[06:27] <lifeless> :)
[06:30] <abentley> NamNguyen: Well, if you've got any feedback on Bundle Buggy, I'd be interested to hear.  But I'm off to bed in a minute.
[06:30] <NamNguyen> linking bb and pqm
[06:30] <NamNguyen> but, good night aaron
[06:30] <NamNguyen> it'd be a complete solution for patch management
[06:31] <abentley> Ah.  The reason BB doesn't submit to PQM is because usually by the time a patch has been approved, it no longer merges cleanly.
[06:33] <NamNguyen> so a human is required after all
[06:33] <abentley> Well, for the Bazaar codebase at least.
[06:34] <poolie> it would be nice to have them integrated
[06:34] <poolie> someday
[06:34] <abentley> We are constantly updating the top of the NEWS file, so we get conflicts there.
[06:35] <lifeless> the big difference is in userspace
[06:35] <lifeless> hg spend 1 minute in userspace
[06:35] <lifeless> we spend 3.5-4.5
[06:35] <poolie> and is it mostly in gzip, or was that a wild goose chase?
[06:36] <lifeless> we spend 1m20 in gzip
[06:36] <lifeless> gzip each hunk
[06:36] <lifeless> (with hot source files)
[06:36] <lifeless> real    4m23.884s
[06:36] <lifeless> user    4m3.963s
[06:36] <lifeless> sys     0m11.649s
[06:36] <lifeless> no gzip
[06:36] <lifeless> real    7m8.611s
[06:36] <lifeless> user    2m41.846s
[06:36] <lifeless> sys     0m16.821s
[06:36] <lifeless> gzip entire pack
[06:36] <lifeless> real    4m46.153s
[06:36] <lifeless> user    4m29.457s
[06:36] <lifeless> sys     0m11.961s
[06:37] <AfC> "hot source files"
[06:38] <abentley> G'night, folkds.
[06:38] <abentley> folks, even.
[06:40] <lifeless> night abentley
[06:40] <lifeless> this is interesting
[06:40] <lifeless>  du -sh .bzr/
[06:40] <lifeless> 142M    .bzr/
[06:40] <lifeless> thats the pack repo
[06:40] <lifeless> hg had a 280M repo
[06:41] <lifeless> with no annotations, naturally
[06:41] <lifeless> poolie: up to a chat ?
[06:41] <AfC> (what are annotations?)
[06:42] <poolie> lifeless, in a sec
[06:42] <AfC> (heard them mentioned here a few times as having a space impact)
[06:42] <poolie> AfC, our memory of what revision changed a line
[06:42] <lifeless> AfC: precalculated line -> revision id mappings
[06:42] <poolie> it makes gannotate and weave merge fast
[06:42] <lifeless> AfC: what makes 'bzr blame' so fast
[06:42] <AfC> Huh
[06:42] <AfC> Neat. Thanks.
[06:43] <lifeless> poolie: ok, ring my mobile please, I'm going for a walk
[06:44] <fullermd> Pack repo of what?
[06:45] <poolie> mozilla
[06:46] <fullermd> That's freakin' small.
[06:46] <poolie> just the initial import i think
[06:48] <AfC> Not sure if you gents saw this on planet.gnome.org or elsewhere, but this post by Alex Gravely is excellent, http://www.beatniksoftware.com/blog/?p=74
[06:50] <fullermd> Oooh, ok.  So it's merely "rather nice", not "mind-zonkingly tiny".
[07:11] <lifeless>  du -sh .
[07:11] <lifeless> 669M    .
[07:11] <lifeless>  du -sh .bzr/
[07:11] <lifeless> 142M    .bzr/
[07:11] <lifeless> so 550M for the source
[07:47] <lifeless> holy fuck this test is taking forever
[07:47] <lifeless> a$ python -m timeit -s 'from bzrlib.tuned_gzip import GzipFile; from bzrlib.osutils import pumpfile' "of=GzipFile('/dev/null', 'wb'); pumpfile(file('../mozilla.tar', 'rb'), of); of.close()"
[08:06] <abadger1999> Hmm... bzr branch bzr+ssh:// seems to have a regression compared to bzr branch sftp://
[08:06] <abadger1999>  bzr branch bzr+ssh://fedorapeople.org/home/fedora/toshio/public_html/bzr-repo/packagedb/fedora-packagedb-stable
[08:06] <abadger1999> Copying repository content as tarball...
[08:06] <abadger1999> bzr: ERROR: Tags not supported by BzrBranch5('file:///var/tmp/fedora-packagedb-stable/'); you may be able to use bzr upgrade --dirstate-tags.
[08:07] <lifeless> there is a bug on this
[08:08] <abadger1999> Cool.  I'll go look in launchpad.
[08:08] <lifeless> (but no fix yet)
[08:08] <lifeless> when spivs patches arrive they will fix it
[08:12] <abadger1999> excellent.  Thanks for the info.
[08:16] <lifeless> (by deprecating that other api)
[09:55] <poolie> spiv, hi?
[09:58] <spiv> poolie: hello
[10:01] <spiv> Hmm, will have to finish this email on the train.
[10:07] <Lo-lan-do> Hello all.
[10:08] <poolie> spiv, quick call?
[10:08] <Lo-lan-do> Is there a way to have a branch living under another directory than where the repository is stored?
[10:08] <poolie> no, it has to be contained within the repository
[10:09] <dato> but, you can just put it elsewhere
[10:09] <poolie> this is more for avoiding confusion than technical reasons
[10:09] <Lo-lan-do> Is that a theoretical impossibility?
[10:09] <Lo-lan-do> Ah, no, good.
[10:09] <poolie> um
[10:09] <dato> the revisions will not be transferred to the repository, but you can push them by hand
[10:09] <Lo-lan-do> Actually, let me come up with the context.
[10:09] <poolie> let me make sure i understand? do you mean you want a branch whose history is stored in a directory that's not above the branch?
[10:09] <dato> or you can create a lightwheit checkout of a branch elsewhere in the filesystem
[10:58] <lifeless> Lo-lan-do: yes, local push will create trees; there should be a bug on that
[10:59] <Lo-lan-do> 'kay.  I can live with that for now, since there's remove-tree :-)
[11:02] <Lo-lan-do> Ah, but bzr branch doesn't know about --create-prefix.
[12:30] <mwhudson> is there a bzr-gtk 0.90 deb yet?
[12:31] <jelmer> there is one in debian, not sure whether it's been uploaded to bazaar-vcs.org or ubuntu yet
[12:31] <mwhudson> ah
[12:31] <fullermd> thumper: Whoops, I lied.  It's post-0.90, so no release yet.
[12:32] <hstuart> mwhudson, jelmer, it's up in feisty at least
[12:33] <hstuart> at least an apt-get upgrade fetched it for me this morning
[12:33] <mwhudson> it is?
[12:33] <jelmer> ah, ok - so it's up on bazaar-vcs.org
[12:33] <mwhudson> oh
[12:33] <mwhudson> i don't have bazaar-vcs.org in my repo list
[12:33] <hstuart> I live life dangerously ;)
[12:36] <mwhudson> well, i run bzr.dev most of the time...
[12:36] <elmo> bzr's managed to take a 30Mb tree and turn it into 51Mb just to import - is that ratio expected?
[12:37] <hstuart> hmm, the bzr upgrade on my second box is failing, though
[12:37] <hstuart> getting a: error in control file: `Files' value not specified at /usr/sbin/install-docs line 804, </usr/share/doc-base/bzr> line 10
[12:41] <mwhudson> elmo: i'm not quite sure what you mean by 'import'
[12:41] <mwhudson> that ratio does seem a little big, how compressible is the stuff you're importing?
[12:42] <elmo> mwhudson: bzr init; bzr add; bzr commit
[12:43] <elmo> mwhudson: it's /etc/gconf from a feisty fesktop; I suspect very compressible in a tar sense, less so in an indiviual file sense
[12:43] <mwhudson> i would expect that to increase the size of the tree by ~the size of the tree when gzipped
[12:43] <mwhudson> each file gzipped independently
[12:44] <mwhudson> hstuart: hm, me too
[12:46] <hstuart> so... who do we lynch? ;)
[12:48] <rocky> hmm... the new feisty deb for bzr 0.90 seems busted?
[12:48] <hstuart> slightly
[12:48] <rocky> lol
[12:48] <rocky> kk... just making sure someone knew ;)
[12:48] <hstuart> you can solve it by adding this line to /usr/share/doc-base/bzr : Files: /usr/share/doc/bzr/html/index.html   as the last line
[12:49] <hstuart> not sure whether that's a decent fix, but it got the rest through installation here
[12:50] <rocky> ah thanks
[12:51] <rocky> here's a quick question ... when i install bzr deb it says "INFO: using old version '/usr/bin/python2.3'" because i manually installed python2.3 into /usr/bin ... /usr/bin/python points at python2.5 so why would it be saying that?
[12:51] <hstuart> no idea, sorry
[12:52] <rocky> hm... time to ask #ubuntu i suppose ;)
[01:02] <dato> hstuart: yeah, known problem (re install-docs). I think lifeless is on top of it.
[01:09] <hstuart> ok, great
[01:22] <lifeless> yes
[01:22] <lifeless> had a missing output dir, but otherwise its looking good
[01:42] <lunatic> is it possible to cancel a pending merge ?
[01:43] <dato> lunatic, `bzr revert`, if I understood you correctly
[01:44] <lunatic> yes but revert does not stop the status message to display "pending merge"
[01:45] <dato> lunatic: it does, it does. at least here it does.
[01:46] <lunatic> ok, so I perhaps have a strangeness here
[01:46] <lunatic> thanks for all
[01:51] <abentley> lunatic: "revert ." will not clear the pending merge, only "revert" with no arguments.
[02:02] <abentley> lifeless: The major costs in annotation, diffing and merging are sequence matching operations.  It would be nice to serialize the get_matching_blocks output.  Could you investigate how much that costs?
[02:03] <lifeless> whats the difference between that and our deltas today?
[02:04] <lifeless> hmm, actually 10pm here
[02:04] <kiko-afk> lifeless, one trivial question
[02:04] <lifeless> I'm going to finish my talk slides and sleep
[02:04] <lifeless> remind me tomorrow :)
[02:04] <kiko-afk> lifeless, does the new (packs?) format produce a smaller file than the knit?
[02:05] <kiko-afk> our knits are now 250MB!
[02:05] <lifeless> kiko-afk: launchpads ?
[02:05] <kiko-afk> yes
[02:06] <lifeless> 250M seems a little small to me
[02:07] <mwhudson> i think kiko just means the inventory.knit ?
[02:07] <lifeless> $ ls -lh launchpad.packs/.bzr/repository/packs
[02:07] <lifeless> total 347M
[02:07] <lifeless> -rw-r--r-- 1 robertc warthogs 346M 2007-08-16 07:55 9e0bcc57d834ca3ae0b5f5844d82dedb.pack
[02:07] <lifeless> ~$ ls -lh launchpad.packs/.bzr/repository/indices/
[02:07] <lifeless> total 25M
[02:07] <lifeless> -rw-r--r-- 1 robertc warthogs 2.1M 2007-08-16 07:55 9e0bcc57d834ca3ae0b5f5844d82dedb.iix
[02:07] <lifeless> -rw-r--r-- 1 robertc warthogs 2.1M 2007-08-16 07:55 9e0bcc57d834ca3ae0b5f5844d82dedb.rix
[02:07] <lifeless> -rw-r--r-- 1 robertc warthogs 1.2M 2007-08-16 07:55 9e0bcc57d834ca3ae0b5f5844d82dedb.six
[02:07] <lifeless> -rw-r--r-- 1 robertc warthogs  19M 2007-08-16 07:55 9e0bcc57d834ca3ae0b5f5844d82dedb.tix
[02:07] <lifeless> du -sh on a knit repo:
[02:08] <lifeless> 434M
[02:08] <lifeless> with --apparent, 395M
[02:08] <lifeless> so yes smaller
[02:09] <lifeless> mainly due to a more effective dictionay compression on the indices
[02:09] <lifeless> kiko-afk: the big win is the ability to partially read indices though
[02:10] <lifeless> and for you, the streaming network push will reduce push and pull times dramatically
[02:10] <lifeless> even without the smart server
[02:10] <kiko-afk> lifeless, yes, just the inventory.knit file.
[02:10] <kiko-afk> will that file be smaller?
[02:10] <lifeless> that file does not exist anymore
[02:11] <kiko-afk> are there any other large files like that?
[02:11] <lifeless> yes, the .pack files :)
[02:11] <lifeless> see the ls -lh I gave above
[02:12] <kiko-afk> 346mb, wow.
[02:12] <lifeless> its the entire database
[02:12] <lifeless> including your sample debs :)
[02:12] <lifeless> kiko-afk: I have sent instructions on how to dogfood packs to the bazaar mailing list
[02:13] <lifeless> kiko-afk: .pack files are write-once
[02:14] <lifeless> kiko-afk: they can be rsynced much more safely
[02:14] <kiko-afk> lifeless, so we rewrite the 346mb to other files later?
[02:14] <lifeless> though still not entirely as safe as using bzr itself; but I can push at 80% of rsync speed.
[02:15] <lifeless> kiko-afk: yes, with logarithmic backoff. So for that 346MB file we're probably at 20K commits in it
[02:15] <lifeless> or something like that.
[02:15] <lifeless> so I'd expect a rewrite of it at 100K commits
[02:15] <lifeless> until then its static
[02:16] <kiko-afk> lifeless, I wonder why using a single file that large is a good idea -- why shouldn't we have a smaller ceiling in order to avoid disk frag and just general problems with dealing with it.
[02:17] <lifeless> the design rationale covers this I believe
[02:18] <lifeless> in short, we have a smaller VFS requirement set, better control over physical disk layout, the ability to avoid many roundtrips to access data
[02:18] <kiko-afk> by using a single file?
[02:18] <kiko-afk> I'd be interested in reading that
[02:18] <lifeless> we write a single file & its indices during commit
[02:19] <lifeless> every 10 commits we collapse these to 1 files with 10 commits
[02:19] <lifeless> every 100 commits we collapse 10x10 commits packs to 1x100 commit pack
[02:19] <lifeless> etc
[02:19] <kiko-afk> how interesting
[02:19] <kiko-afk> does that not grow exponentially more expensive?
[02:19] <lifeless> logarithmic backoff
[02:20] <kiko-afk> i.e. when it's time to move the 1000 commits it will hurt? :)
[02:20] <lifeless> it will, but:
[02:20] <lifeless> bzr+ssh does it on the server
[02:20] <lifeless> the move is cheap as its little more than a readv + write
[02:21] <lifeless> when we do a push we create a single pack anyway, regardless of the number of commits being pushed
[02:22] <lifeless> so its actuall less often than every 10 operations that this kicks in remotely, in the common case
[02:22] <lifeless> we can only issue a single readv for one file at a time
[02:22] <lifeless> our biggest network performance problem is latency
[02:22] <lifeless> so consider moz - 55K files
[02:22] <lifeless> 55K indices
[02:23] <lifeless> thats 110K * RTT at a minimum
[02:24] <lifeless> 112000 commits - thats 4 .pack files, wit 4 indices each - we can in principal pull the whole data in 16 * RTT
[02:46] <lifeless> kiko: anyhow, my performance figures so far back up this strategy; I can push from here to london only 25% slower than rsync, and thats without much tuning at all
[02:46] <kiko> lifeless, that's pretty sweet. good job!
[02:46] <kiko> lifeless, I was wondering if the larger pack size doesn't hurt on local operations too though -- it should of course
[02:47] <lifeless> total data is the same
[02:47] <lifeless> so the page cache pressure cannot be worse
[02:47] <lifeless> however the number of files is smaller
[02:47] <lifeless> so there's less dentries to care about
[03:15] <lifeless> night all
[04:06] <ignas> how do i revert a bzr checkout to some older date?
[04:08] <bwinton> bzr help revert
[04:08] <gabe_> bzr revert -r 45
[04:08] <bwinton> followed by: bzr help revisionspec
[04:08] <gabe_> for example?
[04:09] <bwinton> I think he meant more "bzr revert -r date:yesterday", Gabe...
[04:09] <bwinton> Or "bzr revert -r date:2007-08-14,17:10:14"...
[04:10] <ignas> bwinton: thank you
[04:10] <bwinton> My pleasure!  (It's amazing what bzr help will tell you...  I swear it's one of my favourite features...)
[04:11] <ignas> bwinton: indeed, just that it was "Waaah, it's broken, how do i make it work again" situation ;)
[07:55] <ubotu> New bug: #135891 in bzr "bzr 0.9.0 package blows up" [Undecided,New]  https://launchpad.net/bugs/135891
[09:04] <jkakar> So, it looks like the problem I reported above (#135891) has resulted in a completely b0rked bzr install.
[09:05] <jkakar> I'm getting this complaint when I try to run bzr: bzr: ERROR: Couldn't import bzrlib and dependencies.
[09:05] <jkakar> I guess the quickest/easiest thing I can do is download a tarball from the website and munge my PYTHONPATH.
[09:08] <bwinton> I thought the quicker fix would be to add the Files line, and re-install...
[09:10] <bwinton> (I'm looking up the message on gmane for you, but there was a thread about it earlier today...)
[09:11] <jkakar> bwinton: Oh, maybe you're right.
[09:11] <jkakar> bwinton: Thanks for looking up the message.
[09:12] <dato> jkakar: try this:
[09:12] <bwinton> (Sadly, it looks like the web interface is down...)
[09:12] <jkakar> bwinton: I found it (in my mail), thanks.
[09:12] <dato> # echo "Files: /usr/share/doc/bzr/html/*.html" >>/usr/share/doc-base/bzr
[09:12] <dato> # dpkg --configure -a
[09:12] <bwinton> No worries.  I'm glad you could find it.
[09:13] <jkakar> dato: Thanks!
[09:13] <dato> I'm fairly confident it will work, but please report back :)
[09:14] <jkakar> dato: Not quite.
[09:14] <jkakar> $ sudo echo "Files: /usr/share/doc/bzr/html/*.html" >>/usr/share/doc-base/bzr
[09:14] <jkakar> bash: /usr/share/doc-base/bzr: Permission denied
[09:14] <jkakar> Editing the file by hand with 'sudo emacs ...' works. :)
[09:14] <dato> right, you cant use >> with sudo
[09:14] <dato> since the >> runs as your user
[09:15] <bwinton> Can't you do something along the lines of "sudo ( cat ... >> foo )", to spawn a root process?
[09:15] <dato> bwinton: yes. eg. sudo bash -c "echo "Files: /usr/share/doc/bzr/html/*.html" >>/usr/share/doc-base/bzr"
[09:17] <jkakar> bwinton, dato: Thanks for the help; I'm happy and unblocked. :)
[09:18] <bwinton> My pleasure.
[09:18] <bwinton> Hey, is it possible for a mere mortal to run a Launchpad instance of their own?
[09:19] <bwinton> i.e. if I wanted something Launchpad-y for my company's private internal source code...
[09:19] <Odd_Bloke> bwinton: Nope, Launchpad isn't Free software yet for precisely that reason.
[09:19] <bwinton> Wait, for precisely which reason?
[09:20] <Odd_Bloke> It's intended to be a central point of development which doesn't work so well if there are several hundred of them. :p
[09:20] <tetron|mac> I get a syntax error trying to set up bzr on OS X.  something about 'from bzrlib.symbol_versioning import (deprecated_function,'  ?
[09:20] <bwinton> So it's aiming more to be a Sourceforge, and less to be a Trac?
[09:21] <jkakar> bwinton: I recommend you talk to emurphy@canonical.com about private commercial access to LP.
[09:21] <jkakar> bwinton: He's statik on freenode, and often present in this channel.
[09:22] <bwinton> jkakar: Thanks.  I probably won't since my company is still using VSS, but it's good to know that there's a contact for that sort of thing...
[09:22] <tetron|mac> this is with bzr 0.90, the latest release...  and stock Python 2.4.4 on OS X.  is this a known bug?
[09:22] <jkakar> bwinton: Oh, VSS is so sad.  I feel for you. :)
[09:23] <bwinton> Yeah.  The server went down one day, and the whole office stopped working for a couple of hours...  Actually, it was kind of nice...  :)
[09:26] <jkakar> Heh
[09:26] <tetron|mac> anyone?  anyone have any idea why "setup.py" on bzr 0.90 just totally fails?
[09:29] <bwinton> Which platform, what's the error message?
[09:29] <bwinton> Sorry, OSX, failed import...
[09:29] <bwinton> No idea.  I can say that it works for me on OSX.  But that's not exactly helpful, is it?
[09:30] <tetron|mac> never mind, I think I know what's wrong
[09:30] <bwinton> I'm on Python 2.4.3, installed as a framework.
[09:30] <bwinton> Yeah?  What was it?
[09:31] <tetron|mac> it's suddenly decided to revert to using the system Python 2.3.5...  I swear I have 2.4 installed though
[09:32] <bwinton> Yeah...  I get that a lot too.  I've gone so far as to put /Library/Frameworks/Python.Framework/Versions/Current/... in the #! line of a bunch of my cgi scripts...
[09:40] <g0ph3r> erm... i'm not sure but it seems that bzr got recently updated (to 0.90) on my ubuntu box, which seems to have broken my bzr installation. i'm unable to run it and i see dpkg errors in synaptic... is this related to the earlier thread here? (in other words: can i fix this issue by the echo command above?)
[09:40] <dato> g0ph3r: yes
[09:40] <bwinton> gopher: Give it a try, and let us know.  ;)
[09:40] <g0ph3r> ok, will do so
[09:45] <g0ph3r> ok, this fixed it. synaptic now completed the package setup and i'm able to run bzr now...
[09:46] <g0ph3r> is there somewhere where this should/needs to be tracked as a bug
[09:46] <g0ph3r> +?
[09:46] <dato> g0ph3r: it's reported already, https://launchpad.net/bugs/135891
[09:46] <ubotu> Launchpad bug 135891 in bzr "bzr 0.9.0 package blows up" [Undecided,New] 
[09:47] <g0ph3r> thx
[09:52] <g0ph3r> ok, just left a comment with the error message that bzr threw (at least for me) for others to easier find this bug... seems i missed it since my search didn't find the error message :)
[09:52] <g0ph3r> thanks a lot for your help folks!
[10:14] <ddaa> Is it valid to have a branch reference point to a path, or are only file: URIs accepted for local references?
[10:21] <lifeless> ddaa: URL's only
[10:21] <beuno> yay! my patch seems to have fixed bug #107155. I should use bzr bundle to generate the patch and send it?
[10:21] <ubotu> Launchpad bug 107155 in bzr "_get_vendor_by_inspection incorrectly determines "plink" to be the executable" [Medium,Confirmed]  https://launchpad.net/bugs/107155
[10:21] <lifeless> beuno: bzr send
[10:21] <ddaa> lifeless: thx
[10:22] <beuno> lifeless, great, thanks
[10:23] <beuno> lifeless, bzr won't send it directly, right?  I have to generate the patch file first and attach it to an email?
[10:25] <lifeless> it will fire up your mail client
[10:25] <lifeless> if you have bzr.dev
[10:26] <beuno> wierd, it doesn't...  I'll just add -o and send it manually like last time
[11:54] <abentley> beuno: What happened when you tried send without -o?
[11:56] <lifeless> morning abentley
[11:56] <abentley> morning.
[11:56] <beuno> abentley, it opened up nano
[11:57] <lifeless> abentley: interesting performance note
[11:57] <beuno> aaah, wait, I needed to write my message there  :p
[11:57] <beuno> I'm not very bright today
[11:57] <lifeless> time to write 1MB of data in python - as a single block of bytes - 19usec. Time to write 1MB of 1000 lines using writelines - 500usec, Time to ''.join(lines) then write - 620usec.
[11:58] <lifeless> beuno: :)
[11:58] <beuno> I wrote the patch yesterday though  :p
[11:59] <abentley> beuno: If you install xdg-utils, it will use your default mail client.  It also can be configured directly for Thunderbird, Evolution and Kmail.
[12:00] <beuno> abentley, great, installing now, thanks
[12:00] <beuno> works perfectly  :D  (is that a suggested in the deb package?)
[12:01] <dato> no, this conv. reminded me of that, thanks
[12:02] <dato> but gnite now