[00:07] <jelmer> ok
[00:08] <jelmer> packaged bzr-loom, bzr-avahi and bzr-upload
[00:08] <lifeless> nice
[00:08] <lifeless> bzr-search ? :P
[00:08] <lifeless> hmm
[00:08] <lifeless> time to grab trackerd's source
[00:09] <jelmer> lifeless: Sure, once it's not under such heavy development anymore :-)
[00:13] <beuno> lifeless, I thought of something I'll need for loggerhead in bzr-search. Using custom locations for indexes
[00:14] <lifeless> beuno: open_index_for is the place to extend to do that
[00:14] <beuno> I'll take a shot at a patch as soon as I properly get LH using bzr-search
[00:14] <lifeless> I wrote it with that in mind, e.g. to allow indexing bzr-svn repositories to ~/.bazaar/search/UUID/
[00:15] <beuno> great, should be easy-ish then
[00:15] <lifeless> specifically, an index is given a root transport when its opened
[00:15] <lifeless> and separate branch object
[00:17] <beuno> jelmer, have you continued using bzr-upload?
[00:17] <jelmer> beuno: yeah, I use it now and then
[00:17] <beuno> vila was relunctant to make it public yet, but, if there's going to be a deb, I suppose we should announce it somehow
[00:18] <jelmer> beuno: Symlink support is a problem for some branches though, so I have to fallback to manual copying :-(
[00:18] <beuno> I have too, and haven't run into any major issues
[00:18] <jelmer> beuno: I've just created a package, it's not been uploaded yet
[00:18] <jelmer> If you'd rather not have it out there yet, I'd be happy to wait
[00:19] <beuno> actually, I'd prefer it is, so we can have more contributors  :)
[00:19] <beuno> and it seems to work good enough en most cases
[00:19] <beuno> but, well, vila has to agree too
[00:24] <lifeless> beuno: did you upload your bzr-search LH branch ?
[00:25] <beuno> lifeless, not yet, no. I was burnt out yesterday and was having problems getting the branch PATH to send to bzr-search (aka, don't hardcode the path)
[00:25] <beuno> I'm looking at it now, but I'm leaving to a birthday in ~20-30 minutes, so I don't know if I'll make it  :/
[00:26] <beuno> it's a stupid thing, really. I was just going around in circled yesterday
[00:32] <lifeless> release early release often :)
[00:32] <lifeless> just push-with-caveats
[00:33] <beuno> yes, I just thought making people edit the source code to change my local path seemed pushing that too far
[00:33] <beuno> I'll try to fix it, and, if now, push anywa
[00:33] <beuno> *anyway
[00:58] <beuno> lifeless, pushed it to: lp:~beuno/loggerhead/bzr-search_integration
[00:58] <lifeless> beuno: cool
[00:58] <lifeless> beuno: so why does LH need non-colocated indices?
[00:59] <lifeless> I mean:
[00:59] <beuno> lifeless, it may not, but there may be use cases where LH can't write to the .bzr directories
[00:59] <lifeless> if a user creates an index
[00:59] <lifeless> then other pull/push operations update it
[00:59] <lifeless> LH doesn't need to do indexing
[00:59] <beuno> yes, that should be the default behaviour
[01:00] <beuno> having that hook is perfect
[01:00] <beuno> right now we have an odd timer which re-scans every 6 hours  :/
[01:01] <beuno> but I can see a few use cases where LH will only be able to read the repos, not write to them
[01:01] <lifeless> oh man
[01:01] <lifeless> I am loving this
[01:01] <lifeless> I'm looking around the tracker source code
[01:02] <lifeless> so to find where dpopen occurs I do a bzr search dpopen :)
[01:02] <beuno> desktop integration, very sexy
[01:03] <lifeless> well
[01:03] <lifeless> I don't think bzr-search is a good idea for the searchbar ;)
[01:04] <lifeless> but I wanted to see what tracker does under the hood
[01:04] <lifeless> also look at telling it to ignore .bzr
[01:05] <lifeless> (I may be wrong about bzr-search being a good idea for the deskbar search, its just current opinion)
[01:06] <beuno> why don't you think it's a good idea?
[01:06] <lifeless> context
[01:06] <lifeless> which is another way of saying that it will reduce precision
[01:06] <beuno> hm, I haven't used tracker to know about how that can be achieved. It's the first thing I remove when doing fresh installs  :)
[01:07] <beuno> but, conceptually, being able to track down commits and source code *does* sound good for someone who uses such a thing
[01:08] <beuno> of course, there are many other more interesting places to get it working first, like bzr-gtk
[01:08] <beuno> and bzr-gedit
[01:09] <beuno> which I suspect can share the code
[01:09] <lifeless> yah
[01:12] <beuno> I'm off to get drun... ehm, a birthday party
[01:12] <lifeless> :)
[01:23] <lifeless> oh oh oh I should do suggestions
[01:27] <tro> vila: no packages for 1.6 for ubuntu yet. i didn't want to install it from source, that's all :)
[01:46] <tro> vila: nm. i see there's a beta-ppa repo available now. i'll install from there
[02:08] <lifeless> ok, this should be interesting
[02:08] <lifeless> indexing all debian source
[02:08] <bob2> haha
[02:08] <lifeless> remember that mega repo I created?
[02:08] <lifeless> 16K branches, 22G
[02:08] <lifeless> while index is per-branch the underlying code isn't so coupled
[02:08] <lifeless> so:
[02:09] <lifeless> >>> import bzrlib
[02:09] <lifeless> >>> from bzrlib.plugins import search
[02:09] <lifeless> >>> index = search.index.open_index_url('.')
[02:09] <lifeless> >>> r = bzrlib.repository.Repository.open('..')
[02:09] <lifeless> >>> from bzrlib.ui.text import TextUIFactory
[02:09] <lifeless> >>> bzrlib.ui.ui_factory = TextUIFactory()
[02:09] <lifeless> >>>
[02:09] <lifeless> >>> index.index_revisions(index._branch, r.all_revision_ids())
[02:09] <lifeless> :)
[02:12] <bob2> bwaha
[02:19] <tro> what does this mean? "bzr: ERROR: Repository KnitPackRepository('https://myusername@server.org/bzr/.bzr/repository/') is not compatible with repository KnitPackRepository('file:///home/tro/code/asdf/.bzr/repository/')"
[02:19] <tro> i'm trying to push an existing checkout to a remote webdav branch
[02:19] <tro> webdav repo, sorry
[02:21] <bob2> is bzr-svn involved?
[02:27] <lifeless> tro: one of the repositories is rich root, one isn't
[02:28] <tro> bob2: i thought it was, but i just tried with a brand-new empty one and it didn't work
[02:28] <lifeless> tro: how did you make the brand new empty one?
[02:28] <lifeless> bbiab
[02:28] <tro> lifeless: i think i created the repo with the same version of bzr, but maybe 1.5 instead of 1.6
[02:28] <tro> i used bzr init-repo --no-trees
[02:29] <tro> i'll try updating the bzr version on the remote side and recreate the repo (it's empty now anyway)
[02:30] <bob2> the remote one seems to be rich root
[02:30] <tro> what's the default that is created with "bzr init-repo"
[02:32] <bob2> --pack-092
[02:32] <tro> i don't have to worry about old bzr versions. should i just recreate the repo with --rich-root-pack ?
[02:33] <bob2> well, once you figure out which is whichm yeah
[02:43] <tro> how do i find out which format a tree is in?
[02:43] <bob2> repository, technically.  bzr info https://myusername@server.org/bzr/.bzr/repository/ ; bzr info file:///home/tro/code/asdf/.bzr/repository/
[02:44] <tro> ok, now i see that my checkout is the one that's in pack-0.92. any way to convert it to rich-root-pack?
[02:45] <bob2> what command ddi you run that caused that error? co?
[02:46] <tro> bzr push
[02:46] <tro> hmm .. when both the remote repo and the local checkout are in pack-0.92 i get the same error
[03:46] <bob2> dunno how you can get that error if both sides are pack-0.92, sorry
[04:30] <lifeless> tro: bzr info -v will tell you the format of a url
[04:30] <lifeless> tro: can you do that and show the repository format line here from each output
[04:32] <lifeless> afk again
[05:14] <tro> lifeless: from the shared repo:
[05:14] <tro>        control: Meta directory format 1
[05:14] <tro>     repository: Packs containing knits without subtree support
[05:14] <tro> from the checkout:
[05:14] <tro>        control: Meta directory format 1
[05:15] <tro>   working tree: Working tree format 4
[05:15] <tro>         branch: Branch format 6
[05:15] <tro>     repository: Packs containing knits without subtree support
[05:15] <tro> they're both pack-0.92
[06:08] <lifeless> tro: but you get that error when you push  ?
[06:08] <lifeless> tro: did you do 'bzr info -v URLITISPUSHINGTOO' ?
[06:30] <kumi2> hm, on linux I see a No handlers could be found for logger "bzr" message when I use the bzr command
[06:30] <kumi2> and I get duplicate messages on stdout
[06:30] <kumi2> [ 8249] 2008-06-12 23:11:37.746 INFO: All changes applied successfully.
[06:30] <kumi2> All changes applied successfully.
[08:02] <lifeless> kumi2: please file a bug, that shouldn't happen
[11:36] <mwhudson> codespeak's svn still seems to defeat bzr-svn
[11:40] <jelmer> 0.4 branch?
[11:41] <mwhudson> yeah
[11:41] <mwhudson> jelmer: http://pastebin.ubuntu.com/20308/
[12:12] <jelmer> hmm, something is not concatenating urls right
[12:30] <james_w> Hi all
[15:22] <sven_> hi! i get a traceback when running 'bzr parent bzr+ssh://some/repository/some/file'. see http://pastebin.com/m1c159a5c . not sure if thati
[15:23] <sven_> not sure if that's supposed to work, but it seems wrong to get a traceback anyways...
[15:25] <james_w> what's "bzr parent"?
[15:29] <jamesh> james_w: by the look of the arguments list in the output, not the problem
[15:29] <james_w> no, I was just curious
[15:29] <jamesh> probably the parent of the current branch
[15:30] <james_w> it's not a command I've seen before, I was wondering where it came from. It might be useful to have in the core.
[15:30] <jamesh>   mysql_plugins        /home/sven/.bazaar/plugins/mysql_plugins [0.3.7]
[15:32] <sven_> sorry, bzr parent is from a plugin library i'm using. new paste with `bzr parent` substituted: http://pastebin.com/m4523db02
[15:32] <sven_> jamesh, james_w ^
[15:32] <jamesh> sven_: so, looking at your output, the error came from the "bzr annotate" call rather than the "bzr parent" call in backticks
[15:33] <sven_> jamesh, yes
[15:35] <jamesh> sven_: just trying to reproduce locally
[15:36] <james_w> I think you are seeing https://bugs.edge.launchpad.net/bzr/+bug/237067
[15:37] <james_w> read John's first comment for the details.
[15:37] <jamesh> don't see an exception, but it is pegging the CPU (this is bzr+ssh to localhost)
[15:49] <sven_> hmm, ok. i don't understand the thread completely. should i add my paste to that bug report?
[15:51] <james_w> I don't think it's needed, John seems to know what's goind on.
[15:52] <james_w> I triaged the report, so hopefully it will get noticed and fixed.
[15:53] <sven_> james_w, jamesh, thank you!
[15:56] <james_w> no problem
[16:32] <qense> Does bazaar support something like this: http://upload.wikimedia.org/wikipedia/en/a/ac/Hgk.png ?
[16:32] <qense> I don't mean the graphical program, but the tree merging
[16:32] <qense> If it exists in bzr, how do you do it?
[16:35] <qense> (and is there a way to generate those fancy graphics? :))
[16:35] <jelmer> "bzr viz" is similar to hgk
[16:35] <jelmer> (part of bzr-gtk)
[16:44] <james_w> hi qense
[16:44] <qense> hello james_w
[16:44] <qense> bzr viz looks great
[17:15] <gour> qense: yes, it is really great
[19:59] <rockstar> Hey devs, I'd like to take a whack at fixing bug 109115.  It's marked trivial, so I didn't think it'd require too much.
[19:59] <james_w> hey rockstar
[19:59] <rockstar> Hi james_w
[20:01] <james_w> I'm not sure how that should be tested, perhaps create a file like class that returns a huge amount of data
[20:01] <james_w> the fixing it shouldn't be too hard though, just finding an appropriate place to put a try block.
[20:02] <james_w> you might want to start off by creating the exception that will be thrown when the error is hit: bzrlib/errors.py
[20:07] <rockstar> james_w, yea, I think I've got a fix.  The testing method seems to be the most difficult part.
[20:08] <james_w> it might be something that will be allowed in without a test, but if we can come up with a way then it would be better.
[20:08] <rockstar> Yea, it's always better to have a test.
[20:08] <rockstar> However, writing a test is what's going to help me personally start understanding the code base itself.
[20:09] <james_w> true
[20:09] <james_w> so the problem is when you commit it reads a copy of the file in to memory, and then falls over?
[20:10] <rockstar> Yea, if the file is too big, it fills up virtual memory.
[20:12] <james_w> at what level did you put the try block?
[20:14] <rockstar> bzrlib.tuned_gzip:352 has an if statement that makes sure the filesize > 0.  I added a filesize max limit to it.
[20:15] <james_w> ah, ok.
[20:15] <james_w> so this can be tested really low then
[20:15] <james_w> I've never looked at tests for that area though.
[20:16] <rockstar> Yea, I'll have to explore.  I'm still reading HACKING.txt - Thought it would be good to just give everyone a heads up that I was working on it.
[20:17] <james_w> ah cool, thanks for working on it.
[20:18] <james_w> had you used bzr before you started your current job?
[21:02] <bpeterson> are there any plans to allow blocking and unblocking of revisions like svnmerge.py
[21:42] <mdamt> Any insight how to run bzr like in launchpad.net? I mean the client uses bzr+ssh:// but don't want to provide the shell access to the users. Using /usr/bin/scponly didn't work.
[21:43] <mwhudson> well, launchpad uses a custom ssh server
[21:43] <mdamt> Hmm tricky...
[21:43] <fullermd> You could do it with any restricted shell.  I think scponly has some configurability...
[21:43] <mwhudson> but you can allow users to only be able to execute 'bzr serve --inet --allow-writes /'
[21:44] <mwhudson> or whatever it is bzr+ssh uses
[21:44] <mdamt> So basically using the shell that only allows to run bzr?
[21:45] <mwhudson> not really
[21:46] <mwhudson> it's an openssh thing, you can restrict the commands a given user can run
[21:46]  * mwhudson has to run away, biab
[21:46] <mdamt> Ok, many thanks!
[22:10] <mdamt> Wow the solution was very easy. I made this script as the bzr-use-only shell: ﻿http://dev.blankonlinux.or.id/browser/infrastruktur/bzr-ssh-shell/bzr-ssh-shell
[23:22] <beuno> mwhudson, I've been spying on your paste branch...  seems we're close to dropping turbogears and cherrypy  :_
[23:22] <beuno> :)
[23:23] <mwhudson> beuno: yeah, let's hope so
[23:23] <mwhudson> it's very very hackish at the moment, but it does work
[23:27] <beuno> mwhudson, btw, you wouldn't happen to know a good way to get a branch's path through the history object, would you?
[23:27] <mwhudson> path?
[23:27] <beuno> yes, absolute path to it
[23:28] <mwhudson> i guess by looking at the bzrlib branch object
[23:28] <mwhudson> why do you want it though?
[23:28] <mwhudson> currently loggerhead works fine with branches access over e.g. http
[23:29] <beuno> bzr-search integration  :)
[23:29] <mwhudson> and, mumble, it would be nice if it carried on that way
[23:30] <beuno> http://bazaar.launchpad.net/~beuno/loggerhead/bzr-search_integration/annotate/argentina%40gmail.com-20080614235107-upywmflu0p2b1t1w?start_revid=argentina%40gmail.com-20080614235315-sd5uapabc2aym4f0&file_id=search.py-20080614235103-lpt63f7b2drplju8-1
[23:30] <beuno> that's where I need to plug it in
[23:31] <beuno> (I call that within the History class, so I can pass on an extra value)
[23:32] <lifeless> moin
[23:33] <beuno> howdy lifeless
[23:34] <thumper> lifeless: morning
[23:37] <lifeless> hi thumper
[23:38] <thumper> lifeless: are you at the vibe?
[23:38] <lifeless> not yet
[23:38] <thumper> going though?
[23:39] <lifeless> wtoday for sure
[23:39] <lifeless> other days will depend on stacked progress
[23:56] <mwhudson> beuno: ah, um, ok
[23:56] <mwhudson> beuno: h._branch.transport.base ?
[23:56] <mwhudson> no, that probably isn't right
[23:56] <poolie> hello
[23:57] <poolie> me too
[23:57] <beuno> mwhudson, I suppose I can pass whatever location LH is using too, of course. I meant
[23:57] <beuno> absolute path as in "branch location"  :)
[23:57] <beuno> hi poolie
[23:57] <mwhudson> beuno: right :)
[23:57] <mwhudson> i think the kids call these things URLs nowadays
[23:58] <lifeless> mwhudson: the function is open_index_url :P
[23:58] <lifeless> beuno: I refactored though, there is open_index_branch too now
[23:59] <mwhudson> sounds like a better fit
[23:59]  * beuno looks
[23:59] <igc> lifeless: quick heads up on that performance testing - all ok at first glance