[00:00] <jelmer> lifeless: Thanks
[00:00] <jelmer> lifeless, hopefully I'll be able to find some time next month to transform bzr-rebase into bzr-rewrite
[00:06] <verterok> jelmer: I'm trying to build a universal (ppc & i386) static svn in order to ship it with bzr-svn
[00:08] <verterok> jelmer: I'm failing to build it as universal, but I think it's a matter of configure it with the right flags, atm I'm trying to build apr as universal, as it seems the svn iself works ok
[00:13] <lifeless> spiv: success:
[00:14] <lifeless>         raw_record_map = self.vf._get_record_map_unparsed(keys, allow_missing=True)
[00:14] <lifeless>         record_map = self.vf._raw_map_to_record_map(raw_record_map)
[00:14] <lifeless> spiv: if we serialise raw_record_map, a dict of simple types, we can resume this function on the other side .
[00:14] <lifeless> spiv: 'yay'
[00:15] <lifeless> -> appointment
[00:15] <spiv> lifeless: :)
[00:46] <eferraiuolo> I'm wondering what the best way is to do SVN style keyword substitution is in bzr?
[00:47] <eferraiuolo> I would like to replace $Date$ and $Rev$ in my files in a certain project (repo/branch)
[00:48] <spiv> eferraiuolo: there was a thread about that on the mailing list recently
[00:48] <spiv> I think igc is looking at writing code to do that?
[00:48] <spiv> igc: ^
[00:49] <eferraiuolo> oh alright; so I shouldn't expect it to be baked into bzr right now then?
[00:51] <RAOF> You can get the same sort of effect semi-automatically, ish.
[00:55] <RAOF> eferraiuolo: 'bzr help version-info' will give you something a (very) little bit like what you want.
[00:57] <eferraiuolo> So do you put things like {date} in your source code then run the command?
[00:58] <igc> eferraiuolo: see https://launchpad.net/bzr-keywords
[00:59] <igc> eferraiuolo: the main sticking point is that bzr.dev doesn't supporting content filtering yet - a patch is up for review for that
[01:00] <eferraiuolo> not sure I totally get the workflow with bzr version-info
[01:01] <RAOF> eferraiuolo: What you'd have to do is stick {date} in your source code, and then filter it through sed with the output of version-info (urgh).
[01:02] <RAOF> gnome-do uses version-info in the buildsystem, to define a nice, complete version string with revno and branch nick and such.  It works well for that.
[01:04] <spiv> eferraiuolo: a cleaner way to use version-info tends to be to have a command to use it to generate a single, small source code file with the values in it.  e.g. a header file for C with a #define.
[01:05] <spiv> eferraiuolo: and then have the rest of your project reference that file, and have your makefile regenerate it when appropriate.
[01:05] <eferraiuolo> yeah, although I'm looking at doing this in a JavaScript file
[01:06] <spiv> Ah.  That does sound awkward :)
[01:07] <eferraiuolo> :-) It's mainly to help people keep track of what revision my small JS file is in so they know if the one they are using is old or not
[01:07] <eferraiuolo> so I just wanted it in the comment block at the top of the file
[01:07]  * spiv nods
[01:57]  * igc lunch
[02:07] <jml> what's the default merge algorithm these days?
[02:10] <poolie> jml, i think it's lca
[02:12] <jml> I just had an interesting conflict experience where I removed a large chunk of code in one branch, and the branch I merged in had removed adjacent but independent large chunks of code.
[02:12] <jml> reading the herringbones was a little tricky at first. the solution (under a weave merge) was just to delete everything inside conflict markers
[02:17] <mwhudson> i think the default is still merge3 actually
[02:17] <mwhudson> as i've done bzr remerge --show-base and not had it complain at me
[02:42] <baxissimo> how do you sever the connection between bzr-svn checkout brach from svn?  I want to switch to "mirroring" setupd.
[02:48] <RAOF> baxissimo: I'd guess that you'd do that with 'bzr unbind', assuming bzr-svn works as I'd expect.
[03:03] <baxissimo> RAOF: "convert the current checkout into a regular branch"  -- That sounds like that should do it!
[03:03] <baxissimo> What kind of non-regular branches are there?
[03:04] <baxissimo> Just checkouts and branches?  Is that the distinction?
[03:04] <RAOF> Pretty much, yes.
[03:05] <baxissimo> And big difference with a checkout is that bzr ci actually pushes to the remote repo automatically?
[03:06] <baxissimo> (Looking into bzr after a while using hg...)
[03:07] <lifeless> baxissimo: yes, checkouts behave like svn checkouts, branches behave like, well, branches
[03:17] <baxissimo> Hmm, "bzr bind" on the bzr-svn tree says "No location supplied and no previous location known"
[03:17] <lifeless> baxissimo: you can supply a url
[03:17] <lifeless> baxissimo: this is the one oddity - you can turn a brnach into a checkout by doing 'bzr bind URL'
[03:17] <lifeless> )
[03:17] <lifeless> :)
[03:19] <baxissimo> What I mean is that RAOF said bzr-svn was like a checkout, but unlike a checkout "bzr bind" doesn't report the currently bound location (the SVN tree).
[03:21] <RAOF> bzr-svn, in my experience, basically makes bzr treat svn URLs the equivalent of bzr branches.  So you can 'bzr checkout svn://wherever', and get a checkout, or you can 'bzr branch svn://wherever' to get a branch.
[03:21] <baxissimo> Anyway, what I really wanted to know was how to determine if a given source tree is a branch or checkout.
[03:22] <RAOF> 'bzr info' will probably get you that.
[03:22] <baxissimo> I thought "bzr bind" with no arg would give that, but maybe not.
[03:23] <baxissimo> Beautiful.  Thanks.  Ok, and "bzr bind" apparently will rebind to the previously bound location.  "bzr unbind && bzr bind" seems to get me back where I started.
[03:28] <igc> lifeless: see line 145 in http://bazaar.launchpad.net/~bzr/bzr-usertest/trunk/annotate/head%3A/scripts/script_common.py
[03:29] <igc> lifeless: also log -v takes days/hours for large repos so I don't include a benchmark for it yet. I will soon
[03:37] <lifeless> igc: is that a 'tree only' answer?
[03:40] <baxissimo> I had one more newbie question -- hg folks recommend NOT setting up repos SVN style with lots of separate projects all together under one common top directory. How about bzr?
[03:41] <baxissimo> I think with Hg the problem is that there's no way to check out just a single directory of a repository, so you end up having to pull everything in just to get that one dir.
[03:41] <baxissimo> Is Bzr the same in that respect?
[03:41] <bob2> bzr doesn't conflate branches and repositories
[03:42] <bob2> also repositories are just storage optimisations for bzr
[03:43] <bob2> so "no"
[03:43] <baxissimo> So can "bzr branch" make a branch of just a particular directory of a remote repository?
[03:43] <bob2> sure
[03:43] <bob2> with bzr, repository = box of branches sharing a common revision store
[03:43] <baxissimo> Ok, but I want the offline check-in goodness, too.
[03:44] <bob2> the only downside is that operations modifying revision data will lock the whole repository (I think)
[03:44] <bob2> that is unrelated
[03:44] <baxissimo> Ok.
[03:46] <baxissimo> So what would be the command to get a branch of just the bar directory of the foo repository?
[03:46] <igc> lifeless: yes
[03:48] <bob2> bzr branch bar/foo
[03:49] <bob2> foo foo/bar, obviously
[03:49] <bob2> holy crap
[03:49] <bob2> bzr branch foo/bar
[03:49] <baxissimo> bob2: that tells me ERROR: Not a branch: "........foo/bar"
[03:51] <bob2> are you sure you're clear on what a branch is?
[03:51] <baxissimo> bob2: but just   "bzr branch foo" works.
[03:51] <bob2> you can't "branch" a subdirectory of a branch
[03:51] <baxissimo> bob2: not entirely sure what it means in bzr-o world, no.
[03:51] <bob2> then foo is a branch, not a repository
[03:52] <baxissimo> bob2: Ah, ok.  So they're different with bzr.  I sort of see what you mean about bzr not conflating the two concepts.
[03:52] <bob2> bar is just a subdirectory in a branch, and you can't checkout (or branch) just that bit (no dvcs I've heard of can)
[03:53] <baxissimo> Ok.
[03:54] <baxissimo> You can do it with SVN, so SVN repos tend to have lots of only loosely related stuff in them.  Like 'baxissimo-repo".
[03:54] <bob2> if hg works differently, it is pretty unique among version control systems
[03:54] <bob2> svn is just a versioned filesystem
[03:54] <bob2> it doesn't really have branches
[03:54] <rexbron> james_w: So, profiles did not make the cut outstanding merges on bzr-bd? Do you still see it as nessicary and/or useful?
[03:54] <bob2> except by convention
[03:54] <baxissimo> No hg can't do it, svn can.
[03:55] <baxissimo> Those are the two vcs's I know best.  So I wanted to know what about bzr.
[03:55] <bob2> I was refering to hg's idea of a "repository"
[03:56] <baxissimo> I'm about to convert a big svn repo to bzr, and I want to know if I should try to split it up into separate bzr repos ... er "branches" I guess I mean.
[03:56] <lifeless> bob2: hg doesn't work differently
[03:56] <lifeless> baxissimo: 'bzr-svn' can split it up into different branches for you
[03:56] <lifeless> baxissimo: in fact,it tries quite hard to guess correctly. The easiest way to find out is 'bzr branch svn://foo/bar'
[03:57] <bob2> lifeless: ah
[03:59] <baxissimo> lifeless: easiest way to find out what?  What it actually did?   I used TortoiseBzr to make the svn->bzr checkout.  It looks like it put everything in one big branch.
[03:59] <baxissimo> By that I mean there's only one .bzr file at the top.
[04:00] <lifeless> baxissimo: if you did a checkout, then yes. As a special case though, bzr-svn considers a checkout of a whole svn repo different to checking out one branch within a svn repo
[04:00] <lifeless> baxissimo: so did you checkout the root of your svn repo, or a subdir?
[04:00] <baxissimo> I checked out the root.
[04:01] <baxissimo> So I should do dir-by-dir checkouts instead?
[04:01] <lifeless> baxissimo: yes
[04:01] <lifeless> baxissimo: also, there is a command 'bzr svn-import' that will convert the entire repo for you in one hit
[04:01] <lifeless> I doubt that tortoise exposes that, but you might like to give it a go
[04:02] <lifeless> jelmer: that special case ^ seems to confuse people regularly, can we make it more inaccessible or something, so it only works when its really the right thing to do?
[04:02] <jelmer> lifeless, it's not a special case
[04:03] <jelmer> lifeless, at the moment bzr-svn will warn if it thinks you should not be checking out the root
[04:03] <baxissimo> lifeless: Looks like it does not expose it.  So svn-import will split things up automatically?
[04:04] <jelmer> baxissimo, did you see such a warning?
[04:05] <baxissimo> lifeless: or do I need --standalone?
[04:05] <jelmer> baxissimo, yeah, it will split up automatically, no need for --standalone
[04:06] <baxissimo> jelmer: ugh, ok here goes another 3 hr checkout/conversion process
[04:07] <jelmer> baxissimo, what bzr-svn are you running? Newer versions should be significantly faster
[04:07] <jelmer> baxissimo, also, did you see a warning about checking out the repository root when you ran "bzr checkout" originally?
[04:07] <baxissimo> 1.11 seems to be the newest installer version for windows
[04:07] <baxissimo> No saw no warnings, but maybe tbzr just didn't pass them along?
[04:08] <jelmer> baxissimo, ah, that could indeed be what's happening
[04:08] <baxissimo> I have to pull 1116 revs from france to tokyo, so it may not be bzr's fault here :-)
[04:09] <jelmer> I think the 1.11 installer still has an older bzr-svn, but still one that does have the warning
[04:11] <baxissimo> Anyway, it is time for lunch over here, so I'll just let svn-import chew, while I go do some chewing of my own.
[04:12] <baxissimo> Thanks for the help jelmer, bob2, lifeless and RAOF.
[04:29] <lifeless> jelmer: will you see a warning from the gui?
[04:29] <jelmer> lifeless, I don't know what tortoisebzr/qbzr do, bzr-svn just calls trace.warning
[04:30] <lifeless> jelmer: I suspect nothing :)
[04:30] <jelmer> I suspect you suspect right
[04:30] <lifeless> jelmer: if its not on bzrlib.ui.ui_factory, I'd expect everything to disappear
[04:33] <jelmer> lifeless, so, the alternative is to just flat out refuse checkouts from the root if that doesn't match the layout (as set by the user or guessed)
[04:34] <jelmer> lifeless, I'm divided as to what is the right thing to do here
[04:34] <jelmer> some users seem to actually *want* to check out the root, but the current behaviour also allows others to shoot themselves in the foot
[04:44] <lifeless> jelmer: I agree its difficult
[04:58] <lifeless> poolie: I have made a minor edit, I'm not sure i'm finished, but there is plenty there
[06:28] <poolie> is it just me or does 1.12rc1 not give progress bars on windows?
[06:30] <ronny> jelmer: sup?
[06:32] <ronny> jelmer: after my exams i'll tackle compiling python down to c a bit using annotations + inference, i hope i'll be able to apply that to dulwich
[06:39] <lifeless> poolie: I have made a minor edit, I'm not sure i'm finished, but there is plenty there
[06:57] <poolie> lifeless: i hope you haven't been doing that since lunchtime?
[07:01] <lifeless> poolie: oh no,
[07:01] <lifeless> poolie: you d/c'd when I went to tell you before
[07:01] <lifeless> 15:55 < lifeless> poolie: I have made a minor edit, I'm not sure i'm finished, but there is plenty there
[07:01] <lifeless> 15:56 -!- poolie [n=mbp@ppp112-44.static.internode.on.net] has quit [Read error: 60 (Operation timed out)]
[07:02] <lifeless> poolie: I have just sent in a [MERGE] for byte-encoding for record streams
[07:02] <lifeless> poolie: which means that tomorrow spiv and I will be glueing the various bits together, we should have a wart-free push working to stacked branches, without the ucky upcast to full texts used previously
[07:03] <ronny> lifeless: why are tags bencoded?
[07:03] <lifeless> poolie: however, I'm well past 'done time' :) so sayonara, and chat to you tomorrow
[07:04] <lifeless> ronny: I don't know
[07:04] <ronny> lifeless: also, are there things like signed tags? (git has those as objects)
[07:05] <lifeless> ronny: sorry, I need to head off, hopefully someoneelse can chat :)
[07:05] <lifeless> ciao
[07:06] <ronny> cu
[07:17] <vila> hi all
[07:48] <CBro2007> hi guys I am just checking out bzr and I am a newbie...
[07:49] <CBro2007> I have gone ahead and done the steps to reach my "initial import" and now I am wondering how I can proceed by keeping a good working copy and working on another copy that I will add features to?
[07:49] <CBro2007> Any suggestions as to how I should be doing this?
[07:52] <Peng_> You should read the documentation.
[07:55] <CBro2007> Peng: I am
[07:55] <CBro2007> its a bit convoluted
[07:56] <CBro2007> I am used to CVS and then SVN's trunk/branch model
[07:56] <CBro2007> just wondering how I can achieve the same using bzr
[07:56] <keithcu> Hi;
[07:56] <keithcu> I have a basic BZR question. Can I ask it here?
[07:56] <CBro2007> after the initial import do I just start working on the "working copy"?
[07:56] <CBro2007> or should I create a different "dev" branch and work on that ... then merge the branch to the main branch?
[07:57] <CBro2007> Peng: any suggestions?
[07:57] <keithcu> I peng: it seems like you are trying to do something similar to me. You should have two branches
[07:58] <keithcu> One that is the main one, and then your personal one where you do your work.
[07:58] <keithcu> (Or maybe two branches, if they are totally different areas that you are working)
[07:58] <keithcu> Then, when you are satisfied with something, you push it to the main one.
[07:58] <keithcu> I guess that is for CBro2007, sorry.
[07:59] <CBro2007> keithcu: yes
[08:00] <keithcu> That is what I am trying to setup. Unfortunately, the docs I see don't give such clear help in the context of launchpad
[08:00] <CBro2007> keithcu: my understanding is that maybe I don't need to start a NEW branch and I can just use the working dir
[08:00] <Peng_> Some people like to use the main branch for simple things, and separate branches for mroe complicated stuff.
[08:00] <CBro2007> aha
[08:00] <CBro2007> that is the concept
[08:00] <keithcu> Yes, if it is just you, you can party in one branch
[08:00] <CBro2007> so when I reach a major milestone I commit my changes to the MAIN branch (or trunk)
[08:01] <CBro2007> and then I should in theory be able to start up a new branch yeah?
[08:01] <CBro2007> I have done the initial import... now how do I create a new branch from this?
[08:02] <Peng_> CBro2007: "bzr branch"
[08:03] <CBro2007> bzr: ERROR: command 'branch' requires argument FROM_LOCATION
[08:04] <CBro2007> how do I view a list of my branches?
[08:04] <Peng_> CBro2007: "bzr branch path/to/your/branch some_new_path"
[08:04] <CBro2007> it tells me how I can branch from a PUBLISHED branch
[08:04]  * Peng_ points to the documentation
[08:04] <Peng_> CBro2007: You can branch from any branch.
[08:05] <CBro2007> so how do I branch a copy from my Original Import?
[08:05] <CBro2007> and when do I "publish" a branch? Is this done so other people on the project can COPY this branch and work on it?
[08:06] <Peng_> CBro2007: Yes.
[08:06] <CBro2007> k
[08:07] <keithcu> I have a question: I have setup two branches: https://code.launchpad.net/openracing
[08:08] <keithcu> My keithcu work branch is fine, but now I'm trying to push these changes to trunk.
[08:08] <CBro2007> ok managed to create a new branch from my existing initial import
[08:09] <keithcu> I don't know how to do that.
[08:09] <keithcu> I tried bzr init, bzr merge ../work, bzr push lp:openracing, but that didn't work
[08:10] <CBro2007> you want to know how to branch from the initial import?
[08:10] <CBro2007> ?
[08:10] <Peng_> keithcu: 1.) What's the point of merging into an empty branch? Heck, you can use pull then, 2.) You need commit after merging
[08:10] <Peng_> keithcu: Did you want "bzr branch"?
[08:11] <CBro2007> keithcu: is that what you wanted?
[08:11] <keithcu> I just wanted to push my changes to trunk. I have my work directory branch and that is it!
[08:11] <Peng_> keithcu: "bzr push", then?
[08:12] <CBro2007> Peng_: How do I look at a list of branches ?
[08:12] <keithcu> Okay, so I go to my work directory, and when I type: bzr push lp:openracing
[08:12] <CBro2007> keithcu: if you have done the initial import and want to create a branch off that initial import --> "bzr branch . something.dev"
[08:12] <keithcu> it tells me that the target directory already exists, but does not have a valid .bzr file
[08:13] <Peng_> CBro2007: Unlike git, there's only one branch per directory, so you can just use ls...
[08:13] <Peng_> CBro2007: The bzrtools plugin adds a "bzr branches" command if you really want it.
[08:14] <CBro2007> so u saying that I cannot have more than one branch in this directory?
[08:14] <Peng_> CBro2007: You cannot. Fortunately, most file systems support having multiple directories. :P
[08:15] <CBro2007> mmm
[08:15] <keithcu> I haven't done any import. I just have my work branch and I'm trying to setup a connection to setup a connection to trunk and pull to it, but I don't know how to do that.
[08:15] <keithcu> and push to it
[08:15] <CBro2007> so if I navigate to my .dev branch... that would be the files that I should be working on?
[08:16] <Peng_> CBro2007: Sure? You might want to use multiple branches, or you might not.
[08:17] <CBro2007> Peng_: At the moment I just want to test out the simple case where I can branch a new dev copy ... work on it.. be able to revert changes if I screw up, commit to a branch and then finally merge it to my main branch
[08:17] <Peng_> Okay.
[08:18] <CBro2007> so let me get this right
[08:18] <CBro2007> I just created a branch called "something.dev"
[08:18] <CBro2007> I navigate to that directory and work on the copy there
[08:18] <Peng_> You can do that.
[08:18] <CBro2007> and then I should be able to issue commands like "bzr status" etc in that dir
[08:19] <CBro2007> Peng_: what other way is there?
[08:19] <keithcu> There are 1 million ways to work with bzr
[08:19] <CBro2007> how do I start to work on the branch I just created and only be constrained to this branch?
[08:19] <CBro2007> thats the problem! :)
[08:19] <CBro2007> I just need one... not a million..
[08:19] <CBro2007> maybe the solo case for now
[08:19] <keithcu> How many people are you working wiht?
[08:20] <CBro2007> two more
[08:20] <CBro2007> so the trunk branch model would suffice
[08:20] <keithcu> Okay, so you create your work branch (and they create their work branch)
[08:20] <CBro2007> Once I am comfy with this whole branching stuff I will publish the branch on launchpad for the rest (atleast that is the plan)
[08:20] <keithcu> And then when any of you are satisfied, you push your changes to the trunk branch
[08:20] <CBro2007> yep!
[08:21] <CBro2007> or they send their changes to me first and I commit it to the main trunk
[08:21] <keithcu> Yes, that is doable too.
[08:21] <keithcu> My problem is that I don't know how to setup the trunk branch
[08:21] <keithcu> I have one:
[08:21] <Peng_> CBro2007: Send how? Patch files?
[08:22] <CBro2007> isn't there a way they can do a "bzr send" or something
[08:22] <CBro2007> or maybe they can send me their branch
[08:22] <CBro2007> and I can merge it from my end
[08:22] <CBro2007> possible?
[08:23] <Peng_> CBro2007: "bzr help send" :D
[08:23] <CBro2007> you love pointing out the documentation don't ya?
[08:23] <CBro2007> you might as well give us some pointers mate! :)
[08:24] <Peng_> The people who wrote the documentation are better writers than me. :P
[08:24] <keithcu> Well, how do you setup the trunk branch?
[08:24] <keithcu> I set one up: https://code.launchpad.net/~openracing/openracing/main
[08:24] <keithcu> but I can't push to it.
[08:24] <Peng_> keithcu: Honestly, I'm not sure. Try "bzr push --use-existing-dir"
[08:25] <Peng_> CBro2007: You can use "bzr send -o foo.patch" to create a patch-like file that also preserves the history, then "bzr merge path/to/foo.patch" in another branch.
[08:25] <Peng_> CBro2007: "bzr send" can also help you send an email with the file attached; see the edocs.
[08:25] <Peng_> Err, docs*
[08:26] <keithcu> Okay, I'm trying that and overriding the warning.
[08:27] <keithcu> It seemed to work...
[08:27] <keithcu> that seemed to kill my work branch! grr
[08:28] <keithcu> oh well, I'll figure it out another time.
[08:28] <CBro2007> I am sure they could have made it easier :)
[08:28] <CBro2007> wish someone wrote a cool GUI tool that fronted all this backend stuff
[08:29] <keithcu> I just wish there were docs specifically walking through the basic launchpad setup.
[08:29] <poolie> keithcu: you want something like
[08:29] <keithcu> I've read all I can find, but it wasn't enough. Some of it was clearly written before it was integrated into launchpad
[08:29] <poolie> bzr push bzr+ssh://bazaar.launchpad.net/~openracing/openracing/main
[08:31] <keithcu> I was doing bzr push lp:openracing
[08:31] <CBro2007> poolie: so i just created a new branch.... does this mean I can navigate to this branch and start modifying the contents?
[08:31] <keithcu> CBro2007: yes
[08:32] <CBro2007> poolie: would this mean that I am contraining the changes to this branch only?
[08:32] <CBro2007> keithcu: ok
[08:32] <CBro2007> keithcu: do you have to publish your changes?
[08:32] <keithcu> CBro2007, it works better when you have a basic question to ask rather than a long series of them
[08:33] <CBro2007> yeah thanks :)
[08:33] <Peng_> keithcu: Oh, did you ever run "bzr launchpad-login your_username"?
[08:33] <CBro2007> bazaar does raise a LOT OF QUESTIONS
[08:33] <poolie> we have lots of answers too
[08:33] <keithcu> yep
[08:34] <keithcu> I think I've hosed my stuff. It shows 2 branches, but only makes one visible, etc.
[08:34] <Peng_> Though not all of the answers match up to the questions. ;D
[08:34] <keithcu> I'll start over and try that longer syntax for bzr push
[08:34] <Peng_> keithcu: What? Two branches where? Launchpad?
[08:34] <poolie> slow down
[08:34] <poolie> where/
[08:35] <keithcu> yes, launchpad.
[08:35] <poolie> on which page?
[08:35] <keithcu> I'll come back another time. I'll fiddle around more. I just want to understand a very simple question:
[08:35] <Peng_> Eh.
[08:36] <keithcu> I've got my work branch all setup, and I'm trying to setup / push to the trunk branch
[08:36] <poolie> ok
[08:36] <keithcu> I used bzr push lp:openracing, but maybe I should try bzr push bzr+ssh://bazaar.launchpad.net/~openracing/openracing/main
[08:36] <keithcu> It sort of seems like they are the same but maybe not
[08:38] <keithcu> I deleted my trunk branch which was in launchpad and I'll try it again.
[08:38] <Peng_> keithcu: lp:openracing is just a shortcut. If bzr+ssh://bazaar.launchpad.net/~openracing/openracing/main is the openracing project's default branch, it'llpoint to it.
[08:38] <keithcu> Yes, that is what I thought.
[08:38] <poolie> ok
[08:38] <poolie> what i suggest you do is
[08:38] <poolie> delete that branch on launchpad
[08:38] <poolie> push to the ssh url
[08:38] <poolie> then link it as the main branch for the product through the web ui
[08:39] <CBro2007> guys I am testing by committing changes to a branch.. basic stuff. Now how do I revert to previous revisions in the branch?
[08:39] <CBro2007> bzr revert?
[08:40] <keithcu> Okay, poolie, I wil try that.
[08:41] <keithcu> jeez, cBro2007, sit down with the documentation and experiment.
[08:42] <keithcu> Poolie, that worked. I think I created the branch in launchpad first and that messed things up or something
[08:43] <poolie> CBro2007: check out http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html
[08:44] <keithcu> Poolie: my mistake was that I registered a hosted branch before I created it.
[08:44] <keithcu> And when I do that, I can't push to it, or something.
[08:44] <poolie> thumper, jml ^^
[08:44] <poolie> it should work
[08:44] <poolie> it is kind of a confusing situation
[08:44] <jml> poolie: we are aware of it and have decided on a course of action :)
[08:44] <poolie> oh yeah
[08:44] <jml> poolie: but neither of us will do anything about it tonight.
[08:45] <poolie> (:
[08:45] <poolie> you're going to remove the option to create them?
[08:45] <jml> basically, yeah.
[08:45] <jml> there's an open bug.-
[08:45] <keithcu> okay, so that was my problem?
[08:45] <poolie> thought so
[08:45] <jml> keithcu: in the meantime, bzr push --use-existing-dir, IIRC
[08:46] <keithcu> Okay, I tried that but thought something went wrong. But I think that might have worked.
[08:46]  * igc dinner
[08:46] <keithcu> But now it works and everything looks good: https://code.launchpad.net/openracing?field.lifecycle=ALL
[08:46] <keithcu> Thanks!!!!!!!!!!!!!!!!!!!!!!!
[08:47] <keithcu> I spent an hour on that simple thing...
[08:47] <Peng_> Well, congrats on getting it working. :)
[08:47] <keithcu> yep, feels good.
[08:48] <keithcu> okay, thanks again, I understand the "suggested" workflow. Bye
[08:48] <poolie> sorry for the confusion
[08:48] <keithcu> no problem. But I do suggest to focus your documentation on the launchpad workflow as many bzr people will be using launchpad
[08:49] <keithcu> Well, I'm off to code. Thanks for your help...
[09:46] <CBro2007> whats the difference between doing a "revert" and an "uncommit"?
[09:46] <CBro2007> Just want to know the consequences of doing that
[09:47] <Peng_> CBro2007: Revert is about the working tree, Uncommit is about the branch history.
[09:47] <CBro2007> ok
[09:48] <CBro2007> so revert will not get rid of any of the committed branches yeah?
[09:48] <Peng_> CBro2007: Right.
[09:48] <CBro2007> k
[10:07] <Kamping_Kaiser> i've rm'ed a few files. how can i remove them from my bzr repo? bzr is refusing to ci/rm the files because they dont exist.
[10:07] <Lo-lan-do> Just commit?
[10:08] <Peng_> Kamping_Kaiser: For better or for worse, "bzr commit" automatically removes missing files.
[10:08] <Kamping_Kaiser> Peng, ah, ok. i'll ignore a few things then commit the missing files. cheers.
[10:10] <Lo-lan-do> If you have other changes, you could also shelve them, then commit the removals, then unshelve.
[10:18] <Kamping_Kaiser> i have a dozen files i want ignored (which bzr isnt ignoring), and these 5 pngs. I could ... i wonder . brb.
[10:18]  * rockstar loves the new progress bar.
[10:19] <Kamping_Kaiser> still doesnt ignore if the files are added. oh well.
[10:19] <fullermd> Well, that's because ignore is a filter on nadd  :p
[10:19] <Kamping_Kaiser> on what?
[10:20] <fullermd> nadd.  It's sorta like add.  The 'n' is silent.
[10:20] <Kamping_Kaiser> it must be bzrs fault, i can't *possibly* be at fault :P
[10:20]  * Kamping_Kaiser wishes ;s
[10:21] <Kamping_Kaiser> commitng the dir the images were in seems to be doing the trick. probably what Lo-lan-do was trying to tell me 15 min ago *heh*
[10:22] <Lo-lan-do> Not really, I was suggesting a full commit; but you're right, I should remember about the possibility of committing a single dir, I often forget about it.
[10:26] <Kamping_Kaiser> thanks for the pointers - think i'm getting ignore sussed too. (remove --keep is handy too)
[10:28]  * fullermd has rm aliased to --keep, and dark memories of the day when it was changed   :p
[10:30] <james_w> rexbron: they just weren't merged yesterday, I still plan to review them
[10:43] <gioele> hello
[10:45] <gioele> is there a way to run a command when bzr commit is run but *before* the actual commit? I'd like to modify a file on every commit, before and save the modified file with in the same commit
[10:53] <Lo-lan-do> gioele: There's probably a hook for that.
[11:03] <SteveA> lifeless: ping
[11:08] <jelmer> gioele, look for the start-commit hook
[11:14] <gioele> Lo-lan-do, jelmer: thank you. I'll use those. Actually my hope was to just write a line in a conf file and have my script run on every commit, but those python hooks are nice enough
[11:55] <CBro2007> guys if I have setup the shared repository structure as shown in the user guide, I was wondering whether I have to copy my files to the "trunk" dir and then do a bzr add?
[11:55] <CBro2007> do I have to do a "bzr init" in the project dir?
[11:56] <CBro2007> ?
[12:00] <CBro2007> can someone help?
[12:01] <CBro2007> project1/          # A repository for project1
[12:01] <CBro2007>  +- trunk/         # The mainline of development of project1
[12:01] <CBro2007>  +- branches/      # A container directory
[12:01] <CBro2007>      +- foo/       # Branch for developing feature foo of project1
[12:01] <CBro2007>        ...
[12:01] <CBro2007> I use this model
[12:01] <CBro2007> should I then have to get into the "trunk" directory and do a "bzr init"?
[12:01] <CBro2007> before I can add files to this dir?
[12:01] <asabil> CBro2007: how did you create the trunk/ directory ?
[12:01] <CBro2007> manually
[12:02] <CBro2007> I created the repository with init-repo
[12:02] <asabil> then yes, you will need to cd trunk && bzr init .
[12:02] <CBro2007> and then went into that dir to add in the structure I wanted
[12:02] <CBro2007> then copy my files into trunk and bzr add , then initial import -commit yeah?
[12:04] <asabil> yep exactly
[12:04] <CBro2007> And then I need to fork out like a seperate branch from this trunk
[12:04] <CBro2007> like a fresh copy to start adding features on
[12:05] <CBro2007> Can I just go :  bzr branch /proj1/trunk /proj1/branches/foo
[12:05] <CBro2007> ?
[12:06] <CBro2007> asabil: would that work? or do I have to PUBLISH my branch first?
[12:06] <asabil> CBro2007: that works perfectly
[12:06] <asabil> (that's the workflow I use myself)
[12:06] <CBro2007> which one? the first one?
[12:07] <CBro2007> so I can branch out first and then publish my branch later so others can collaborate?
[12:08] <CBro2007> it says the target directory already exists
[12:08] <CBro2007> maybe I should get rid of the branch
[12:23] <asabil> CBro2007: yes, you don't need to create the directories yourself
[12:23] <asabil> bzr branch will do it
[12:49] <CBro2007> yep done all that
[12:50] <CBro2007> worked out real good... also managed to PUBLISH my branches
[12:50] <AfC> Is there a reason you keep saying "publish" in all capitals?
[12:55] <crisb> hiya, i'm getting a MemoryError when I try to commit a move of some directories  (containing arround 700 files) into another directory - http://paste.pocoo.org/show/104281/
[12:55] <crisb> this is on AIX...
[13:03] <fullermd> AfC: It's an acronym for Putative Unsubstantiated Brilliant Lunch In Some House.
[13:05] <crisb> seems to be in patiencediff
[13:15] <msmits> could some please help me out with some bzr-svn issues?
[13:15] <msmits> s/some/someone/
[13:15] <jelmer> msmits, hi
[13:16] <msmits> jelmer> hi, is it supposed to work with Python 2.4?
[13:16] <jelmer> msmits: 0.5.0 doesn't work with python2.4 at the moment
[13:17] <msmits> jelmer: what version would you recommend for Python 2.4?
[13:17] <jelmer> msmits, I would recommend upgrading to Python2.5..
[13:17] <msmits> (I've run into the defaultdict requirement)
[13:18] <msmits> that's not an option, work environment dictates python 2.4 (I guess I could install 2 versions but would rather avoid that)
[13:18] <jelmer> the 0.4.x series work with python2.4
[13:19] <jelmer> however, a lot of bugs (>40) in the 0.4.x series of bzr-svn are fixed in 0.5.0, and the 0.4.x, and performance is also worse in 0.4.x than in 0.5.x
[13:20] <msmits> jelmer: I've also tried 0.4.17 and have run into a fairly serious problem
[13:20] <msmits> hang on while i get the logs
[13:22] <msmits> jelmer: http://pastebin.com/m48b4b358
[13:22] <jelmer> msmits, that's a known bug, fixed in 0.5
[13:23] <msmits> jelmer: no easy way to backport the fix to the 0.4 series?
[13:24] <jelmer> msmits: That particular bug might be fairly easy to backport
[13:25] <msmits> hmmm, maybe i should just install python 2.5 next to python 2.4...
[13:25] <jelmer> no guarantee you won't run into more older bugs
[13:26] <msmits> can you point me at the fix, in case i decide to backport it?
[13:29] <jelmer> bug 329284
[13:30] <msmits> jelmer: thanks very much for your help, that's awesome
[13:31] <jelmer> msmits, alternatively, it should be possible to provide replacement implementations of defaultdict and deque in bzr-svn 0.5.0
[13:31] <msmits> jelmer: yep, i've got substitute versions lying around
[13:32] <msmits> jelmer: I can think of other reasons to have Python 2.5 installed so I might try that approach first
[13:32] <vila> crisb: worth filing a bug
[13:32] <jelmer> msmits, I would be more than happy to accept patches that make bzr-svn use substitutes when running under python < 2.5
[13:32] <vila> crisb: did you get less traumatic response times since last week-end ?
[13:32] <jelmer> msmits, ok
[13:33] <msmits> jelmer: ok, if that's the case you might get some patches from me soon
[13:38] <crisb> vila: I have fixed it now, its an AIX malloc funny - returns NULL if malloc(0)... :)
[13:39] <crisb> i will file it though with patch
[13:41] <vila> wow, that kind of bug makes me think about the worst I encountered: memcpy copying 655[56] bytes when asked to copy 0 or 1 bytes... did wonders for C variables in the stack...
[13:41] <vila> s/655[56]/65536-[01]
[13:42] <crisb> its running slightly faster now, but selftest is still incredibly slow
[13:43] <ronny> oO
[13:44] <ronny> its ok of malloc(0) returns NULL
[13:44] <crisb> ronny: not according to the patiencediff extension ;)
[13:44] <ronny> ah
[13:45] <ronny> manpages say it may return 0 or a unique value that works with free
[13:48] <crisb> indeed
[13:49] <crisb> one patiencediff test is still failing unique_lcs - error return without exception set when doing unique_lcs('', '')
[13:59] <fullermd> Er?  malloc(0) is painting outside the lines.  Demons are allowed to fly out of your nose.
[14:00] <fullermd> The only requirement is that the return value work with free(), which NULL does everywhere but freakin' dmalloc.
[14:00] <fullermd> (well, maybe that's fixed by now, it's been a couple years since last I fired it up)
[14:01] <Odd_Bloke> "If  size is 0, then malloc() returns either NULL, or a unique pointer value that can later be successfully passed to free()." suggests that it's not painting outside the lines.
[14:01] <fullermd> It's painting outside the lines in that it's implementation-defined.
[14:02] <fullermd> "If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object."
[14:02] <Odd_Bloke> Oh, yeah, there's a spec. :p
[14:02] <fullermd> (C99 7.20.3)
[14:06] <crisb> my fix is just to fail if we return NULL from malloc and the size is not 0
[14:06] <crisb> rather than just when we return NULL
[14:07] <luks> the proper fix would be to not even try to allocate 0 bytes, because diff of empty documents can be easily special-cased :)
[14:08] <vila> fullermd: ha ! At least the spec matches my mental model (which includes never calling free with NULL, but that's just healthy paranoia :-)
[14:08] <vila> luks: nag the patiencediff C extension author ;-)
[14:08] <ronny> whats the name of that new repo format again?
[14:08] <luks> vila: he is too lazy :)
[14:09] <vila> luks: :)
[14:09] <vila> ronny: split-inventories nick-name brisbane-code or bbc for short
[14:09] <vila> ronny: split-inventories nick-name brisbane-coRe or bbc for short
[14:09] <crisb> luks - is that you? ;)
[14:09] <luks> yes
[14:11] <crisb> any idea about test_unique_lcs failing with "error return without exception set" on 2 empty sets?
[14:11] <crisb> Traceback (most recent call last):
[14:11] <crisb>   File "/opt/freeware/lib/python2.6/site-packages/bzrlib/tests/test_diff.py", line 782, in test_unique_lcs
[14:11] <crisb>     self.assertEquals(unique_lcs('', ''), [])
[14:11] <crisb> SystemError: error return without exception set
[14:12] <luks> crisb: it's the memory error problem, but masked
[14:12] <luks> crisb: I think that was fixed in recent versions of bzr, what version are you using?
[14:13] <crisb> 1.12
[14:13] <crisb> all new stuff ;)
[14:13] <luks> hm
[14:13] <luks> is this your changed version?
[14:16] <luks> yeah, the testing function don't set exceptions as well
[14:17] <crisb> yes, my changed version.  works fine on my linux
[14:18] <luks> well, the code currently expects malloc(0) to return a valid pointer
[14:18] <luks> you could fix the SystemError by setting MemoryError
[14:18] <luks> but to fix the functionality it needs to avoid allocating 0 bytes
[14:21] <crisb> got it - all tests passed now :)
[14:21] <crisb> cheers luks
[14:29] <vila> crisb: all tests for the whole test suite or just patiencediff ?
[14:38] <igc> jam: any eta on the development5 formats?
[14:38] <igc> jam: also, I'd like to pick just one initially and focus my testing & tuning on it
[14:39] <igc> jam: do you have a leaning wrt hash16 vs hash255?
[14:39] <fullermd> Why's one a power of 2, and the other isn't?
[14:40] <crisb> vila: patiencediff :) theres a hang on one of the tests (around 98)
[14:42] <vila> fullermd: the other *is* a power of 2, but minus one :) The reason being that one char can't be used in the hash key  and is replaced by another (already used, hence 256 -1)
[14:43] <vila> crisb: ghaa 98 means nothing to me :-) try 'bzr selftest -v'
[14:43] <igc> jam: also, I'm getting a DeprecationWarning when trying to upgrade to development4-hash255: chk_map.py line 78: "i" format expects a number within a given range
[14:43] <igc> jam: is that serious?
[14:43] <vila> igc: are you using a 64bits host ?
[14:43] <igc> vila: yes
[14:44] <igc> anyhow, it's past my bedtime
[14:44] <igc> night all
[14:44] <vila> igc: if your branches are used on a 64bits host only you should be safe, I noticed the problem yesterday and is talking about it with jam
[14:44] <vila> igc: cu
[14:45] <igc> thanks vila. If you could ask jam for me about the Qs above when he's offline, that would be great
[14:46] <vila> He's connected, so I think he will read them, I'll remind them if not
[14:47] <jam> igc, vila: hey
[14:47] <vila> jam: hi :-)
[14:47] <jam> igc: --dev5 will probably be sent for review today
[14:48] <jam> as for -16 versus -255...
[14:48] <jam> my earlier work suggested 16
[14:48] <jam> however the groupcompress work (so far) is favoring 255
[14:48] <jam> igc, vila: as for the deprecation warning, I'm pretty sure we could safely do "crc = zlib.crc32()&0x7FFFFFFF" if we want to avoid it
[14:49] <jam> we don't need *all* the bits
[14:49] <jam> have a good night igc, if I haven't missed you yet
[14:49] <crisb> vila: blackbox.test_check.ChrootedCheckTests.test_check_missing_branch
[14:52] <vila> crisb: doesn't ring a belll. Make sure you didn't left some breakpoint somewhere since that's a blackbox test, outputs are redirected
[14:57] <Odd_Bloke> Where can I see the bzr PQM?
[14:57] <beuno> Odd_Bloke, pqm.bazaar-vcs.org
[14:58] <Odd_Bloke> I'm getting a 503 from there.
[15:02] <vila> jam: that sounds perfectly right for 32bits, bu will truncate the value on 64bits which sounds wrong
[15:02] <jam> vila: there are only 32 bits either way
[15:02] <jam> I'm just chopping off the 32nd one
[15:03] <jam> so you are left with 31
[15:03] <jam> which is always the same signed or unsigned
[15:03] <vila> which is wrong for unsigned values
[15:03] <jam> nope
[15:03] <jam> try it
[15:04] <vila> 0xFFFFFFFF is valid
[15:04] <jam> vila: I'm *intentionally* chopping off the 32nd bit, by using 0x7FF...
[15:05] <vila> That's the wrong part, I have dirstate files with values > 2^31
[15:05] <jam> do you have any with values > 2^32 ?
[15:05] <vila> :-)
[15:05] <jam> the *point* is that we universally sacrifice one bit
[15:05] <jam> for platform uniformity
[15:06] <jam> (it won't work for dirstate being compatible with dirstate)
[15:06] <jam> but we don't have to worry about chk_map compatibility *yet*
[15:07] <vila> But going with struct.pack('>L' instead of struct.pack('>i', just works everywhere without sacrifying anything including having a valid crc
[15:08] <vila> and regarding dirstate, we don't use (anymore ?) the crc anyway so that may not be such a big deal
[15:09] <jam> vila: "l == i" for all platforms (IIRC)
[15:09] <jam> you could use "Q" but we don't have 64 bits of actual data
[15:09] <vila> Oh my, I sure hope not !
[15:09] <jam> long == int
[15:09] <jam> long long != int
[15:10] <vila> long == 32bits
[15:10] <vila> int == 32bits or 64bits
[15:10] <jam> except for maybe 16-bit platforms
[15:10] <jam> vila: I haven't seen a platform yet where "int == 64 bits"
[15:10] <luks> isn
[15:10] <luks> er
[15:10] <jam> I could be wrong, but I'm pretty sure long should always be >= int
[15:10] <luks> isn't it the other way around, long == 64, int == 32?
[15:10] <jam> luks: "long long == 64 bits"
[15:11] <jam> I think there were 16-bit platforms
[15:11] <luks> yeah, I know
[15:11] <jam> where long == 32 bits ,and int == 16 bits
[15:11] <jelmer> vila, any idea why every apache process start by bzr-lts would disappear?
[15:11] <jam> jelmer: the subvertpy 0.6.2 release is just win32 changes, right? (I noticed you didn't upload 0.6.2 to the ppa)
[15:12] <jelmer> jam, yeah
[15:12] <jelmer> vila, I don't get much more than: [Tue Feb 17 16:09:24 2009] [alert] Child 27932 returned a Fatal error... Apache is exiting!
[15:13] <vila> jelmer: not from the top of my head, but there is a log file
[15:13] <jelmer> vila, that comes from the log file, it's basically the only thing in there
[15:14]  * fullermd blinks.
[15:14] <fullermd> Long is required to be >= int...
[15:14] <vila> jelmer: have you checked the conf with apache2 -t ?
[15:15] <fullermd> And there are/were plenty of 16 bit platforms.  I'm perfectly willing to say "who cares" in 2009 though.  Heck, I was willing in 1999...
[15:15] <jelmer> vila, yep, that's fine
[15:16] <vila> jelmer: hmm, did you load all the required modules ? Did you try running as root ?
[15:16] <vila> jelmer: running as root is bad and may create files you won't be able to modify afterward caveat testor
[15:17] <vila> jelmer: did you set LogLevel debug ?
[15:17] <jelmer> vila, I'm running as root since /usr/sbin is not in my standard PATH
[15:18] <jelmer> vila, even "bzr lts-start apache2" doesn't work
[15:18] <vila> jelmer: ha, progress :)
[15:18] <vila> You *have* apache2 aren't you ? :-)
[15:19] <jelmer> yes :-)
[15:20] <jelmer> vila, the system one starts fine
[15:21] <vila> did the local_test_server/work/apache2 directory got created ?
[15:21] <vila> with data, etc, var inside ?
[15:23] <jelmer> yeah
[15:23] <jelmer> the pid file also gets created but the process dies
[15:24] <vila> jelmer: and the pid file is deleted ?
[15:24] <jelmer> vila, yeah, I've deleted the pid file (otherwise it won't start)
[15:26] <vila> hmm, so something is wrong inside apache regarding workers spawns, what OS are you using ? I think the Ubuntu apache2 may come linked with some modules that you may miss and need to load explicitly
[15:26] <jelmer> I'm running Debian
[15:26] <jelmer> it does actually start, it just aborts right after
[15:26] <vila> what does 'apache2 -l' say
[15:26] <jelmer> If I add syntax errors, it neatly aborts on the commandline
[15:27] <vila> It's  core.c, mod_log_config.c, mod_logio.c, worker.c, http_core.c and mod_so.c here
[15:29] <jelmer> same here
[15:31] <vila> Ghaa, what machine were you using when you contributed apache2-svn ?
[15:33] <jelmer> vila, much older installation
[15:35] <vila> jelmer: can't you spot an obvious mistake between local-test-server/apache2.conf and /etc/apache2.conf ?
[15:38] <vila> jelmer: or add /sbin in your path (I can't remember if apache2 can be run as root or need a dedicated user)
[15:42] <vila> jam: I just realized you meant to apply the work-around to _search_key_255, not dirstate, I'm fine with the former, the later still needs discussion I think or should I just file a bug ?
[15:44] <jelmer> vila, it seems to silently exit if there's no group set
[15:44] <jelmer> and no user
[15:44] <jam> vila: we can file a bug, and yes it was mostly just about _search_key_255
[15:44] <jam> Though there may be tests that need updating
[15:44] <jam> the other possibility is to do:
[15:44] <jam> if platform == 64bit && val > 2^31: val = val - 2^32
[15:44] <jam> or something to that efffect
[15:46] <vila> jam: we need something that works if the disk format is used from both 32bits and 64bits so the &0x7FFFFFFF sounds better for that
[16:14] <ronny> lifeless: are there any plans to store things like tags in the history store instead of unversioned files?
[16:15] <ronny> (not as normal revs/commits tho)
[16:17] <vila> jelmer: sorry, I missed your last comment, where are you at ?
[16:17] <jelmer> vila, apache silently exits if there's no user set
[16:17] <vila> jelmer: apache2 can't be run as root ?
[16:17] <jelmer> at least not the Debian sid package
[16:17] <vila> jelmer: so you tried adding /sbin to your path a running as normal user ?
[16:18] <vila> jelmer: so you tried adding /sbin to your path and running as normal user ?
[16:19] <jelmer> vila, yeah, and that's working
[16:19] <vila> jelmer: haaa, real progress now :) Good.
[16:20] <Kobaz> bzr: ERROR: This tree contains left-over files from a failed operation.
[16:20] <Kobaz> how do i fix that
[16:20] <Kobaz>     Please examine /usr/local/library/.bzr/checkout/limbo to see if it contains any files you wish to
[16:20] <Kobaz> i have no files in there
[16:27] <jelmer> vila: lp:~jelmer/+junk/bzr-lts-krb5
[16:28] <vila> Kobaz: I think you cut the part where it says: "and delete it when you are done"
[16:28] <fullermd> bzr: It's krb5!
[16:29] <vila> jelmer: errors.NotBranch, still pushing ?
[16:29] <Kobaz> yeah
[16:29] <jelmer> vila, whoops, sorry, yeah
[16:29] <vila> jelmer: ok, got ot no
[16:29] <jelmer> vila, it's done now
[16:29] <Kobaz> i delete it
[16:29] <Kobaz> and then it complains about another dir
[16:30] <vila> err got it now :)
[16:30] <Kobaz> and then i delete the other dir, and then it complains about a lock
[16:30] <Kobaz> and then i remove the lock, and then it complains about limbo
[16:30] <Kobaz> endless loop
[16:30]  * jelmer hands fullermd a ticket granting ticket
[16:30] <Kobaz> hmm
[16:31] <Kobaz> i did bzr shelve -all
[16:31] <fullermd> Sorry, I can't use that.  My branch isn't rich-ticket.
[16:31] <Kobaz> and that did it
[16:31] <Kobaz> i couldn't shelve an individual file, otherwise i would get into the limbo loop
[16:31] <vila> jelmer: great, you're nearly there, you need to update test_server.get_permutations though
[16:32] <Odd_Bloke> Kobaz: What version of bzr are you using?
[16:33] <Kobaz> .10
[16:33] <vila> And a final 'bzr selftest -s bt.test_http krb5' passing will be the reward :)
[16:35] <Kobaz> i'll try and reproduce the problem
[16:35] <vila> jelmer: and some bzr-add krb5.keytab may be missing too ? Or it is private ?
[16:35] <jelmer> vila: it's pointless without a KDC
[16:36] <vila> jelmer: ok, just say so in comments in the apache2.conf file then with any hints you feel relevant (a copy/paste from your mail for example)
[16:37] <vila> jelmer: and thanks for the instant feedback :-)
[16:37] <jelmer> vila: Hmm, I'm not getting the tests to show up
[16:38] <vila> try --list for a start
[16:38] <vila> if they don't show up with --list, the feature may have say the server is not available, check that's it's started
[16:46] <Odd_Bloke> Kobaz: There have been a few fixes to shelve recently, you might want to update to .12.
[16:47] <jelmer> vila, ok, that passes now
[16:47] <jelmer> vila, pushing new bzr-lts
[16:47] <vila> jelmer: yeah !
[16:49] <jelmer> vila, it's pushed (lp:~jelmer/+junk/bzr-lts-krb5 again)
[16:49] <vila> jelmer: if you needed to declare a new user and/or run some additional commands there will make a nice addition to the comments :-)
[16:49] <jelmer> Ran 12 tests in 4.178s
[16:49] <jelmer> I've added a note about the keytab file
[16:49] <vila> jelmer: yeah, that's generally slow
[16:50] <jelmer> now I need to teach Subversion about Kerberos, and that'll be trickier :-/
[16:52] <jelmer> vila: thanks for the help getting bzr-lts updated
[16:55] <vila> jelmer: thanks for updating it :-) Now you just have to add a new one that does svn *and* kerberos and you'll have a nice test server for implementing the svn part :-)
[16:57] <jelmer> vila, how do you plan on implementing bug 256612 ? It seems somewhat related to the mandatory username thing I came across
[16:58]  * jelmer updates bug 256612
[17:00] <vila> I think there are several steps, 1) raise ConnectionError instead of 401, 2) Prompt for users or something like that, 3) delegate to auth handlers the decision about requiring user
[17:01] <vila> jelmer: I have to run, I'll be back later
[17:01] <jelmer> vila, ok
[17:24] <sender> hi all. please advice, what to do after a "bzr merge -r0..-1" from branch without common ancestry. Remove all the '.moved' items and add the new items, or rename?
[17:31] <ollie> i guess this question must of been asked many times but i am having the parmiko error: Unable to import paramiko (required for sftp support): No module named paramiko. System is Ubuntu 8.04.1 Bazaar (bzr) 1.3. Any ideas?
[17:31] <ollie> was trying to do a bzr co sftp://blah
[17:31] <ollie> zr: ERROR: Unsupported protocol for url
[17:33] <santagada> ollie: install paramiko... it is probably a package in ubuntu
[17:34] <santagada> maybe it is from the MOTU repositories
[17:34] <ollie> santagada: i did apt-get source python-paramiko
[17:35] <ollie> dpkg-source: applying ./paramiko_1.6.4-1.1.diff.gz
[17:35] <santagada> ollie: why get the source?
[17:35] <ollie> it is just what apt-get did
[17:36] <Tak> is there a way to directly get a branch from a workingtree?
[17:36] <Tak> err, the workingtree's branch instance
[17:36] <santagada> ollie: try apt-get install python-paramiko next time :D
[17:36] <ollie> ah yeah odd
[17:37] <ollie> i see what you mean not sure why i would of done that
[17:37] <santagada> apt-get source installs the source code
[17:37] <santagada> apt-get install install a package
[17:38] <ollie> yep not sure why i typed it
[18:41] <evarlast> can anyone point me to how I can help get the windows installer onto the http://bazaar-vcs.org/Download page?
[18:45] <crisb> seems like on AIX a fair few tests involving http server hang - how can I find out more about where the tests are hanging?
[18:49] <crisb> using the debugger it seems like one thread is stuck in sock_dealloc and one in fd_select (i guess this is the server?)
[18:53] <fullermd> Some sorta *lock in close() sounds like?
[18:56] <crisb> yeah, im pretty sure i've had this before porting to AIX ;-)
[18:56] <crisb> its bringing back memories
[18:56] <fullermd> I find that alcohol helps with that.
[18:57]  * fullermd fails to clarify whether the alcohol is introduced into one's self or the machine...
[19:04] <hughesw> question to the room. Say I wanted to wipe out all revprops set by bzr-svn on a repository, how would I go about doing so? My repository has a bunch of ghosts in it and it's still causing bzr-svn to crash on branch.
[19:04] <hughesw> would svn pd with all of the bzr: props I see with a pl do it?
[19:04] <jelmer> hughesw, uhm, how did you get into that situation in the first place?
[19:04] <hughesw> jelmer: I'm not sure honestly.
[19:05] <jelmer> hughesw, and what doesn't work exactly?
[19:06] <hughesw> starting around bzr 0.4.10 and the version of bzr-svn that shipped with it, it seems to have stopped pushing up revisions from local branches, so now when I do a checkout, a pull, etc fresh from the svn repo
[19:06] <hughesw> I can't branch the checkout or anything as it just dies
[19:06] <jelmer> hughesw, how does it die?
[19:06] <jelmer> what error?
[19:07] <hughesw> hold, writing it out so I can upload it
[19:41] <jelmer> JAM!
[19:52] <Lo-lan-do> Too late...
[19:53] <Lo-lan-do> jelmer: Any news on git-serve, by the way?
[19:53] <jelmer> Lo-lan-do, hi
[19:53] <jelmer> Lo-lan-do, bzr dpush works (but that wasn't what you were asking..)
[19:54] <jelmer> Lo-lan-do, John mainly works on bzr git-serve, I'm focusing on performance at the moment
[19:55] <Lo-lan-do> Cool.
[19:57]  * Lo-lan-do would really like to get rid of that SVN we keep as a pivot between bzr and git
[19:58] <jelmer> Lo-lan-do, roundtripping bzr revisions in git is still quite some time away though
[19:59] <Lo-lan-do> I thought the bzr-receive-pack and bzr-upload-pack was supposed to work for that... did I misunderstand something?
[20:02] <jelmer> Lo-lan-do, that's roundtripping git into bzr
[20:02] <jelmer> which is much simpler, since bzr has transitive history and things like revision properties
[20:03] <Lo-lan-do> If that works and we can use bzr as the pivot, then I'm *quite* happy :-)
[20:04] <Lo-lan-do> The one git user can access the bzr repo through that "gateway", the rest of us can do bzr, and everyone wins.
[20:05] <Jc2k> Lo-lan-do: i havent had time to poke git-serve lately, so i dont know if its got bit rot
[20:05] <Jc2k> (so need to figure out a sane way to test it..)
[20:30] <jam> morning igc, you're up early
[20:30] <jam> igc: dev5 has been submitted to the list
[20:31] <igc> jam: saw that - thanks
[20:32] <jam> it should actually cause a slight amount of 'bloat' to the repos
[20:32] <jam> maybe 1-2%
[20:32] <jam> as we don't actually have delta compression enabled
[20:32] <jam> and it adds about 2bytes per record
[20:33] <jam> by the way, igc, I was really happy to see usertest runs on the different formats
[20:34] <jam> I was benchmarking size
[20:34] <jam> but speed is also an important factor
[20:34] <jam> and certainly I didn't expect "bzr branch" to be 2x faster with -255 versus -16
[20:34] <jam> which is why I have both formats in there
[20:34] <jam> I'm pretty positive we don't want plain "--development5", though I think lifeless is less sure
[20:38] <igc> jam: the revno for the mysql branch I used was 2677
[20:38] <igc> I'm pulling mysql now and I'll build and use an updated archive
[20:38] <jam> which branch?
[20:38] <jam> (they have a lot :)
[20:38] <igc> mysql-server
[20:39] <jam> lp:mysql?
[20:39] <igc> yes
[20:39] <igc> (I think that's it)
[20:39] <jam> well, it is "lp:mysql-server" which is the 5.1 branch
[20:39] <jam> good enough
[20:39] <jam> it is just nice to know which
[20:39] <jam> as I mentioned, you may want to hack in the little change for "bzr upgrade"
[20:41] <igc> jam: shall do
[20:41] <jam> I'm not sure if it safe for the other commands, but I've used it here for "bzr branch" quite a bit
[20:41] <jam> (using branch to convert, rather than 'upgrade')
[20:42] <igc> jam: any thoughts on the time required to upgrade from dev5 to dev5h16?
[20:42] <igc> will it be just as slow as btree->dev5?
[20:42] <jam> it should be faster
[20:42] <jam> because the delta logic from the source is faster
[20:42] <igc> likewise, will upgrading from dev5h16 -> dev5h255 be slow or quikc?
[20:43] <jam> dev5 => dev5h16 should be ~the same as dev5h16 => dev5h255
[20:43] <jam> I have some other updates in my 'hack' branch which I should put together for review
[20:44] <igc> jam: what do those hacks do?
[20:44] <jam> it changes the copy logic to use a 'more-optimal' ordering
[20:44] <jam> igc: http://bzr.arbash-meinel.com/branches/bzr/brisbane/hack
[20:44] <jam> if you want to check it out
[20:44] <jam> it was where I was exploring the various hashes, etc
[20:44] <igc> jam: would it be better for me to benchmakr that than brisbane-core?
[20:45] <jam> igc: I would be curious to see what results you get from that, but I don't think it is strictly better than brisbane-core
[20:45] <jam> It does stuff like knit-delta compression
[20:45] <jam> hash-16
[20:45] <jam> 'get_record_stream' ordering, etc
[20:45] <jam> It was just my "play with this and get ideas" branch
[20:45] <jam> so I'm slowly getting things out of it, and properly tested into brisbane-core
[20:46] <igc> jam: ok, I'll probably stick with brisbane-core then
[20:47] <jam> well, I *would* like to see how much my knit-delta helps these repos (at least for size) and how much it hurts (for copying/extracting performance)
[20:52] <fullermd> Does anybody else find it irritating how the wiki no longer gives you a handy link to your userpage?
[20:53] <jam> fullermd: that was actually intentional, because people were creating non-useful userpages
[20:53] <jam> you are one of the *few* exceptions
[20:55] <mwhudson> beuno: bzr upload bzr+ssh:/// seems not to work
[20:55] <mwhudson> is that expected?
[20:56] <fullermd> Well, shucks.  Can't we just lay on a few LART's instead of making me type it in?
[20:56] <beuno> mwhudson, well, there's not upload smart server, so yes
[20:57] <mwhudson> is just a transport though?
[20:57] <mwhudson> ah well, i guess i'll fight with it some other day
[20:57] <mwhudson> (fwiw, the error is bzr: ERROR: Invalid url supplied to transport: "diff.html")
[20:57] <beuno> yeah, but vila discriminates it for some reason
[20:58] <beuno> and I have not had any incentive to understand why yet
[20:59] <mwhudson> fair enough :)
[21:03] <vila> mwhudson: If you have ssh access you'd better run 'bzr update' locally...
[21:03] <jam> fullermd: after about the 10th LART we decided to make it harder for people to do it by default
[21:03] <jam> you can always bookmark your own page :)
[21:03] <mwhudson> vila: i guess i could use push-and-update indeed
[21:04] <beuno> mwhudson, you have ssh and not sftp?
[21:04] <chx> i did google but can only find sporadic remakrs that 'it wont be hard to do' from years ago -- so is it possible to somehow check out from a bzr branch with an svn client?
[21:04] <vila> beuno: it's not that I discriminate, if the transport support the required operations it should just work, if it doesn't it may be a bug or that bzr doesn't implement some needed VFS command
[21:04] <mwhudson> beuno: nah, i have sftp
[21:04] <beuno> vila, I know, I know  :)
[21:04] <mwhudson> i just tried bzr+ssh first
[21:05] <vila> mwhudson: if you want to update a working tree with a colocated branch, push-and-update is better suited
[21:05] <vila> bzr-upload is not meant to replace bzr update, it's meant to allow building a remote working tree when the remote branch doesn't exist
[21:05] <jam> chx: I thought Jelmer implemented something along those lines, but I don't know that he completed it
[21:06] <lifeless> SteveA: pong
[21:07] <chx> jelmer: that would be VERY interesting to me.
[21:07] <jam> chx: are you talking something like bug 127768 ?
[21:08] <jam> I'll note that jelmer at least implemented it a bit here: https://lists.ubuntu.com/archives/bazaar-commits/2008-October/010639.html
[21:09] <chx> jam: yes , i even found that issue but as you can see the last comment is from 2007.
[21:09] <jam> and with 'bzr-svn' installed, there *is* a "bzr svn-serve" command available
[21:09] <poolie> hello
[21:10] <chx> davidstrauss: ping
[21:11] <jelmer> chx, So, bzr svn-serve does some things properly at the moment; checkout and log are among them
[21:11] <jelmer> the main missing things are update and commit
[21:13] <davidstrauss> chx: pong
[21:24] <infinit_> does anyone know how to setup Bazaar plugin on eclipse? I get the error that it needs the xmlrpc plugin. I've downloaded the plugin and add it in eclipse but it gives more errors when I do that. Any solution?
[21:25] <jelmer> infinit_, you need to add it in bzr
[21:25] <infinit_> how?
[21:26] <jelmer> copy it in ~/.bazaar/plugins/xmloutput
[21:26] <jelmer> I think it's documented on the xmloutput wiki page
[21:26] <ronny> hmm, wouldnt it make more sense if they used dbus?
[21:26] <infinit_> I did that but still there are errors
[21:27] <infinit_> usage: bzr [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
[21:27] <infinit_>    or: bzr --help [cmd1 cmd2 ...]
[21:27] <infinit_>    or: bzr --help-commands
[21:27] <infinit_>    or: bzr cmd --help
[21:27] <infinit_> error: invalid command 'xmlversion'
[21:27] <infinit_> this is the error
[21:27] <jam> jelmer: well, 'bzr svn-serve' is currently broken in a few ways, mostly just forgetting to import functions that it calls
[21:27] <jelmer> ronny, for communication between IDE's and the VCS?
[21:27] <ronny> yeah
[21:27] <lifeless> ronny: its eclipse; xmlrpc is more portable for it than dbus; think win32
[21:27] <jelmer> jam, ah
[21:27] <jam> and using "port" without converting it to an integer
[21:27] <jam> etc
[21:27] <jelmer> jam, untested code is broken code :-)
[21:27] <jam> I'm trying it here
[21:28] <jam> and "svn co svn://localhost/ test" does seem to try to do something
[21:28] <jam> but doesn't get very far
[21:28] <jam> it seems to be hung
[21:28] <ronny> lifeless: last time i took a look at xmlrpc it was a damn ugly mess tho
[21:28] <ronny> dbus is a lot more nice
[21:28] <ronny> and it actually works on win32
[21:28] <ronny> at least deluge uses it
[21:29] <lifeless> ronny: also dbus isn't particularly good at 'call a command', its better at 'get a service'
[21:29] <ronny> lifeless: objects + methods, sound perfectly fine to me
[21:29] <lifeless> ronny: xmlrpc is dead trivial, if you close your eyes and ignore the xml :)
[21:29] <ronny> the only thing thats nasty with dbus is generators, as they would need a callback
[21:30] <lifeless> anyhow, I'm not the author of bzr-eclipse, so don't really hold an opinion :)
[21:30] <ronny> lifeless: dbus more featurefull, efficient and not a fscking ugly mess ^^
[21:30] <ronny> well, i generaly prefer background threads tho
[21:31]  * ronny writes the vcs integration of pida
[21:31] <lifeless> ronny: cool
[21:32] <nitind> .part
[21:32] <ronny> lifeless: 0.6 will have native support for bzr workingtrees - and somewhere in betwen 0.6 and 0.7 i will add branch management
[21:33] <ronny> the fun part in that is that _every_ vcs play its own little __fscked__ up game about branch management
[21:34] <lifeless> oh yeah, we're all different
[21:34] <lifeless> sometimes usefully, sometimes less so
[21:34] <lifeless> bzr's not ideal
[21:34] <ronny> bascially everyone does it wrong
[21:34] <ronny> by default
[21:35] <fullermd> Hey, where would Edison be if he didn't try all the wrong filaments?   :p
[21:36] <ronny> fullermd: branch management has a much larger social component that light bulbs
[21:36] <ronny> so by default one can do it only wrong
[21:37] <ronny> lifeless: btw, what would you change about bzr's branch management?
[21:38] <fullermd> A Gandhian answer may be appropriate...
[21:39] <ronny> i kinda belive that for every vcs the correct answer should be *everything*
[21:39] <CardinalFang> Ugh.  How do I track down what causes IllegalUseOfScopeReplacer exceptions?
[21:40] <CardinalFang> dev guide says, """It also is incorrect to assign ImportReplacer objects to other variables. Because the replacer only knows about the original name, it is unable to replace other variables. The ImportReplacer class will raise an IllegalUseOfScopeReplacer exception if it can figure out that this happened. But it requires accessing a member more than once from the new variable, so some bugs are not detected right away."""
[21:40] <CardinalFang> I don't even see anything lazily imported around my code.
[21:43] <jam> lifeless: I think I worked out why "pack" is failing for GC repos
[21:43] <jam> at least one item
[21:43] <jam> is that packer assumes it knows the format of the "value" index
[21:43] <jam> sorry "value in an index"
[21:43] <jam>             for key, value in items:
[21:43] <jam>                 # ---- KnitGraphIndex.get_position
[21:43] <jam>                 bits = value[1:].split(' ')
[21:44] <jam> unfortunately, that is only true for non gc values
[21:44] <jam> which start with a "EOL" marker
[21:45] <lifeless> ronny: It's very nice that we have url's per branch, and that we don't particularly couple branch to repo, so you can have several projects and just organise the branches like you do directories
[21:46] <lifeless> ronny: I *love* that
[21:47] <jam> lifeless: anyway, from what I can tell, we need a custom Packer to handle it properly.
[21:48] <ronny> lifeless: i only like it if i want it, else i dont
[21:48] <ronny> lifeless: however collated branches might fix that for me
[21:48] <lifeless> ronny: however, we have some scaling issues related to that (expensive to query 'branches') and it would be nice to allow 'getting started' to give more than one branch
[21:49] <jam> CardinalFang: doing "from bzrlib.XXX import foo" where 'foo' is a lazy import in *that* module will cause the problem
[21:49] <jam> I would double check your imports
[21:49] <lifeless> jam: I am sure it used to work, or something
[21:49] <jam> lifeless: well if you left a space for EOL (which was always empty) it might work
[21:49] <lifeless> jam: anyow yes thats one of the root causes, repo assuming it knows the format
[21:49] <ronny> bbl, gota sleep early today
[21:50] <lifeless> jam: no, we want to recompress in gc pack, at least some fo the time
[21:50] <jam> ah, and it seems packer writes out the index based on its assumptions as well
[21:50] <jam> so it would be broken anyway
[21:50] <jam> (Packer assumes it understands index_memo, which it obviously doesn't )
[21:52] <jam> anyway, it is non-trivial to fix Packer
[21:53] <jam> so perhaps we should just change GCRepository to do record_streams and live with that
[21:53] <lifeless> as a first cut setting up a VF with just a writable index and selecting into it would at least let full conversions work
[21:56] <jelmer> lifeless, pqm is down :-(
[21:57] <jelmer> lifeless: (well, the web page gives a 503
[21:57] <CardinalFang> jam, found it.  Thanks.
[21:57] <lifeless> spm: ^
[21:59] <CardinalFang> Strange that it suddenly stopped working.  Schroedinbugs are cool.
[22:01] <jfroy|work> jelmer: holy **** 0.5.1 is fast, good job!
[22:02] <jfroy|work> I am, quite honestly, shocked at the snappy :)
[22:02] <jelmer> jfroy|work, thanks :-)
[22:02] <jelmer> it should be significantly faster yet after some of my patches for bzr.dev land
[22:04] <CardinalFang> Sorry to butt in, but what is that, jfroy|work?
[22:06] <jfroy|work> CardinalFang: hum?
[22:06] <CardinalFang> "0.5.1 is fast"
[22:07] <CardinalFang> Svn plugin?
[22:08] <Jc2k> CardinalFang: Yes
[22:08] <jfroy|work> yeah
[22:08] <jfroy|work> bzr-svn
[22:08] <jfroy|work> jelmer: pulling a 216070 rev repository right now
[22:08] <jfroy|work> (which was migrated from CVS, actually)3
[22:09] <jfroy|work> it's building the cache right now, and unfortunately it doesn't report revisions/sec
[22:09] <jfroy|work> (which would be interesting as a benchmark)
[22:25] <lifeless> abentley: is bb dead?
[22:26] <lifeless> spiv: you're popping over here yeah?
[22:26] <abentley> lifeless: restarted.
[22:27] <lifeless> abentley: thanks
[22:28] <lifeless> abentley: It would be nice to allow the same tree to be nested multiple times; I know thats not trivial but perhaps worth thinking about, if you're hoping to get the format out in advance of the support
[22:28] <spiv> lifeless: yeah.
[22:28] <lifeless> spiv: I sent in my branch, so I'm all set to pair
[22:29] <abentley> lifeless: To me, the cost/benefit ratio isn't nearly good enough.
[22:29] <lifeless> spiv: until you get here I think I'm going to setup a effort test on new-branch-push and start ratcheting
[22:29] <lifeless> abentley: I'm specifically thinking of the gnome pattern of a common reused library nested at multiple points
[22:30] <lifeless> abentley: projA/common, projB/common, and projA and projB are nested conceptually in 'release/projA' and 'release/projB'
[22:30] <lifeless> abentley: but as you say there is a significant cost
[22:31] <abentley> lifeless: It would basically mean redesigning all our tree operations so they don't use file-ids.
[22:31] <lifeless> abentley: I'm pretty convinced we need something beyond fileids, have been for a long time; but our plates are all pretty full.
[22:32] <lifeless> abentley: so I'm entirely happy with this staying in dreamland, I was just noting a 'would be nice' :)
[22:32] <abentley> lifeless: Well, I do recall that you wanted that.
[22:42] <spm> lifeless: jelmer: pqm web front end is restored
[22:43] <jelmer> spm: Thanks!
[22:51] <lifeless> bbs, fooding
[22:52] <mtaylor> hey all... bzr on windows breaks for me
[22:53] <mtaylor> pretty substantially...
[22:53] <mtaylor> install bzr 1.11 ... do bzr branch lp:libdrizzle
[22:53] <lifeless> spiv: could you pastebin the blackbox stacked new acceptance test please
[22:53] <mtaylor> get an error about no such file or directory about some file in .bzr/checkout/limbo/new-12
[22:53] <lifeless> spiv: I want to use that for ratchetting till we meet up
[22:54] <lifeless> mtaylor: I'm just popping out for a minute, but that rings some bug bells - do a lp bubg search for bugs with 'limbo', you may find something helpful
[22:54] <mtaylor> k
[23:03] <spiv> lifeless: ok
[23:04] <spiv> lifeless: http://rafb.net/p/CydF0b17.html
[23:26] <lifeless> mtaylor: any luck?
[23:26] <mtaylor> lifeless: yup. it's not a bzr bug
[23:26] <mtaylor> lifeless: it's that you can't create a file called "con.h" on windows
[23:26] <lifeless> mtaylor: ah yes, that will be difficult
[23:28] <lifeless> it would be nice to give a better error
[23:28] <chx> omg even after all these years, windows still can't name a file con.foo?
[23:30] <lifeless> mtaylor: if you care to file a bug with the error you got, and why[con.h] + the actual backtrace, we can look at improving the reporting
[23:30] <mtaylor> lifeless: hrm... that'll require more touching of the windows computer...
[23:31] <lifeless> mtaylor: just think of it as payment for the lovely linux box you use mostly
[23:32] <chx> http://blogs.msdn.com/oldnewthing/archive/2003/10/22/55388.aspx#55399
[23:32]  * chx chuckles
[23:34] <lifeless> spiv: a *little* more context please :)
[23:34] <lifeless> spiv: setup_smart_call_log etc - just the whole hunk or something :)
[23:37] <enigma42> apt keeps complaining about not the debs from the PPA not being signed.
[23:37] <enigma42> Is there a key for the PPA that I somehow missed?
[23:37] <enigma42> Or are the packages just unsigned by design?
[23:37] <lifeless> enigma42: I don't think the ppa keys are fully live yet
[23:37] <enigma42> OK.
[23:37] <lifeless> enigma42: they are currently unsigned, that is a ppa bug and its getting fixed
[23:37] <enigma42> I'll just keep ignoring the messages then.
[23:37] <enigma42> :-)
[23:38] <enigma42> Thanks for the help. :-)
[23:45] <Peng_> I thought they were live for bzr's PPA though.
[23:45] <Peng_> Maybe not the beta PPA?
[23:46] <enigma42> specifically, I'm using: https://launchpad.net/~bzr/+archive/ppa
[23:46] <enigma42> And: deb http://ppa.launchpad.net/bzr/ppa/ubuntu hardy main
[23:47] <Peng_> Eh. https://edge.launchpad.net/~bzr/+archive/ppa lists the key.
[23:47] <Peng_> Anyway, lifeless is probably right. It's a new feature, so maybe it's not fully live yet.
[23:48] <spiv> lifeless: that was the whole hunk :P
[23:48] <lifeless> spiv: can you do from the thread below?
[23:48] <lifeless> like both acceptance threads
[23:48] <lifeless> or something
[23:48] <lifeless> +        self._setup_smart_call_log() is definitely new
[23:48] <lifeless> and knowing the line number I can put it in the same spot :)
[23:48] <spiv> Yeah, just a sec
[23:49] <spiv> http://rafb.net/p/ObfhP236.html
[23:49] <nevans> Peng_, enigma42: try out "sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com   37B19B80"
[23:49] <spiv> lifeless: ^
[23:50] <chx> wow
[23:50] <chx> never knew apt-key adv before
[23:50] <lifeless> spiv: thanks
[23:50] <chx> that's a useful trick
[23:50] <nevans> or 8C6C1EFD for the non-beta PPA
[23:51] <nevans> chx: it doesn't seem to be documented on the manpage.  odd.  I wonder where I learned it?  :)
[23:51] <jfroy|work> jelmer: checkout that large svn repository is painful
[23:51] <enigma42> nevans: Even the 37B19B80 part?
[23:51] <enigma42> What's that?
[23:52] <jfroy|work> 216071, Python's at 1.26 GB of real memory while doing "determining revisions to fetch"
[23:52] <nevans> enigma42: 37B19B80 for bzr-beta
[23:52] <jfroy|work> *216071 revisions
[23:52] <enigma42> Hm...looks like "apt-key adv" is a secret command for those in the know....
[23:52] <nevans> enigma42: 8C6C1EFD for the non-beta PPA
[23:53] <enigma42> OK...let me get both.
[23:53] <enigma42> nevans: Thanks!
[23:54] <chx> just the other day i googled for this and it's certainly gpg import-export and piping everywhere in google
[23:55] <chx> nevans: by lurking in the darkest channels on irc where such things are passed along in secrecy? ;) ?
[23:55] <nevans> chx: I think it must have been on some launchpad help page or something webby like that.  :)
[23:55] <enigma42> I almost feel like I need to put on a brown cloak before typing in that "apt-key adv" command...
[23:56] <nevans> but ever since then, I just use "^Rapt-key" to recall the last time I did it, then edit the command line for the new key  (^R in bash, another cool tip to send around in dark IRC channels)
[23:57] <nevans> I wonder what "adv" stands for, anyway?  "advanced-dark-magic"?  :)
[23:58] <enigma42> I know...I'm addicted to "^R", but it seems that almost no one I run into has used it before...
[23:58] <lifeless> thanks spiv
[23:58] <enigma42> nevans: LOL!
[23:59] <LeoNerd> I prefer the non-default stuff I have bound to my pageup
[23:59] <LeoNerd> "\e[5~": history-search-backward