[00:01] <mwhudson> jam: dammit
[00:01] <mwhudson> can you press the button again?
[00:11] <igc> ping poolie
[00:12] <igc> poolie: the --pack-0.92 options are screwing up the User Reference generation :-(
[00:12] <igc> Can I rename the format to pack-0-92? That fixes it.
[01:02] <fullermd> igc: Funnily enough, it was the -, not the ., in the format name that always glared out at me   ;)
[01:02] <poolie> igc, hm, except that may be confusing
[01:12] <igc> poolie: any thoughts?
[01:12] <igc> I've sent a patch to the list btw
[01:25] <Jammer> why does "bzr ignore" add the .bzrignore file into the repository? (I even have .bzrignore itself listed as ignored file)
[01:26] <igc> jammer: that doesn't sound right
[01:29] <Jammer> using version that is in Ubuntu repository
[01:32] <Odd_Bloke> Jammer: So that ignores get propagated to all copies of the branch.  If you want ignores specifically for you, there is a way to set it.
[01:32] <Odd_Bloke> I'm afraid I can't rememeber what this is as I've never had call for it. :(
[01:37] <poolie> igc, does the pdf actually need review? or is it just a version of that svg?
[01:37] <poolie> if it looks poor on evince, maybe file a bug to that effect
[01:37] <igc> poolie: just a version of the svg
[01:37] <igc> bug in evince me thinks
[01:41] <poolie> +1 then
[01:42] <igc> poolie: thanks - I'll submit it to pqm
[01:44] <jam-laptop> mwh: pushed
[02:23] <jam-laptop> I'm reviewing igc's work on switch
[02:23] <igc> thanks jam-laptop
[02:41] <spiv> I'm reviewing jam's status after merge.
[02:45] <jam-laptop> igc: review is finished, bb:tweak
[02:45] <igc> thanks
[02:45] <jam-laptop> A couple of small fixes, overall, I think it is worth 1.0
[02:45] <igc> cool
[02:46] <jam-laptop> is anyone else finding Bundle buggy to be slow?
[02:46] <jam-laptop> I think igc mentioned that it doesn't seem to be noticing merged patches
[02:46] <jam-laptop> which I have brought up with Aaron earlier in the week
[02:46] <jam-laptop> and he thought he saw that fixed
[02:46] <jam-laptop> (or at least forcing a rescan cleaned it up)
[02:47] <jam-laptop> igc: Any chance you can figure out why the PDF looks weird on Ubuntu?
[02:47] <jam-laptop> It would seem important to have it looking good there
[02:47] <igc> evince bug I think
[02:48] <jam-laptop> any chance we could not provoke the bug?
[02:48] <igc> :-)
[02:48] <jelmer> hmm, would be interesting to have bb support for irc (-:
[02:51] <jam-laptop> reviewing spiv's hpss translate root patches
[02:54] <igc> jam-laptop: if I use inkscape to generate the PDF instead of the script in the Makefile, the result is much better
[02:55] <jam-laptop> igc: You know you can script inkscape, right?
[02:55] <igc> I did but I haven't done it
[02:56] <jam-laptop> I don't see a command in my Makefile
[02:56] <jam-laptop> am I just missing it?
[02:56] <igc> doc/en/quick-reference/Makefile
[02:56] <jam-laptop> ah, wrong makefile
[02:56] <jam-laptop> yeah, I just found it
[02:57] <jam-laptop> I haven't done much with inkscape, other than to regenerate the .png files for the website
[02:57] <jam-laptop> :)
[02:57] <jam-laptop> anyway, I would probably recommend using inkscape if possible
[02:58] <igc> yeah - seems so
[02:58] <jam-laptop> hmm... the directory is quick-reference
[02:58] <jam-laptop> the target is 'bzr-quickref.png'
[02:58] <jam-laptop> but yet we call it the Quick Start Guide
[02:59] <igc> well, Quick Start Card right now
[02:59] <jam-laptop> igc: shouldn't the targets be renamed as well in the Makefile?
[02:59] <jam-laptop> bzr-quickref.png: $(OBJECTS)
[02:59] <igc> yes
[03:10] <spiv> jam-laptop: is abentley's concern about find_difference a showstopper for your "make 'bzr status' after merge faster" patch?
[03:10] <jam-laptop> spiv: maybe...
[03:11] <spiv> jam-laptop: trading slow-but-correct for fast-but-not-necessarily-correct seems worrying :)
[03:11] <jam-laptop> I didn't feel like it was a strict show-stopper, but
[03:11] <jam-laptop> the only time it is incorrect is when the shortcut is longer that the distance to origin
[03:11] <jam-laptop> and igc did point out that we could probably detect it
[03:12] <jam-laptop> spiv: the other trade off is that when it is "incorrect" it just means that a few more entries show up in
[03:12] <jam-laptop> pending-merges
[03:12] <jam-laptop> (it isn't a data loss/corruption/etc)
[03:12] <spiv> Ok, so it would only affect "status" output.
[03:12] <jam-laptop> correct
[03:13] <spiv> Although there's the risk that someone might look at this code and think "that looks like a good way to do it" and use the same approach somewhere more critical...
[03:13] <spiv> So I guess a big scary comment is called for :)
[03:13] <jam-laptop> spiv: it is currently on my todo plate
[03:13] <jam-laptop> it is what I was working on that lead me to the Graph.heads() fix
[03:13] <spiv> Yeah, I thought they might be related.
[03:13] <jam-laptop> which is mostly "get find_differences()" to be correct
[03:13] <spiv> It seemed a bit more than coincidence that you were reworking graph guts :)
[03:31] <Peng> Hey, there's a "bzr find-merge-base" command. No need to do "bzr revision-info ancestor:..." or anything.
[03:51] <igc> ping poolie: pack-092 or pack-0-92? I can adjust it before I submit to PQM
[03:54] <lifeless> its really ugly both ways
[03:54] <lifeless> how sure are you that its unavoidable ?
[03:56] <Peng> Okay, so you're going to stop introducting new formats in each version, you're just going to rename the current ones! :P
[03:57] <fullermd> Eh?  Microsoft bought bzr?
[03:58] <Odd_Bloke> Will there ever be a circumstance in which a revision won't have the 'branch-nick' property?
[03:58] <lifeless> yes
[03:58] <igc> lifeless: I tried to escape it and it didn't
[03:58] <fullermd> Odd_Bloke: Frex, I've got a number of revisions from before bzr started putting nicks in.
[03:59] <igc> I'm yet to look at the ReST code itself
[03:59] <fullermd> (0.7 it came in, I think?)
[03:59] <Odd_Bloke> OK, rephrase the question: s/revision/new revision/
[04:00] <lifeless> I think its worth looking at it; 0.92 is the version number, anything else will surprise people.
[04:00] <lifeless> Odd_Bloke: yes
[04:00] <Odd_Bloke> lifeless: Cool, thanks. :)
[04:00] <Peng> I'm always irritated by abbreviated version numbers. I was very happy that "pack-0.92" didn't do that.
[04:01] <lifeless> Odd_Bloke: primarily importers and such things
[04:10] <spiv> igc: I reckon we could monkey-patch the regexes in docutils.parsers.rst.Body fairly easily...
[04:17] <poolie> i'm really not keen on having docs that are almost but not quite rest
[04:18] <poolie> otoh it's ugly to change our program because of doc tool quasi-bugs
[04:21] <fullermd> We could just pretend 0.92 didn't happen, and call it 'pack-1'  ;)
[04:23] <igc> fullermd: :-)
[04:24] <lifeless> that would be pack-1.0
[04:30] <poolie> igc, lifeless: i think we should just pick one and do it, so we can get an rc out today
[04:34] <poolie> igc, spiv, can i recap what we're trying to review or merge today
[04:34] <lifeless> poolie: I would what spiv suggets - work around the bug by fixing rest on the fly
[04:34] <lifeless> s/would what/would do what/
[04:36] <spiv> It does seem backwards to have a documentation tool force us to lessen the beauty of our tool. :)
[04:36] <igc> can spiv give that a try? we ought to confirm that will work
[04:36] <poolie> spiv, do you think that kind of change could be accepted by upstream docutils?
[04:38] <spiv> Another hack would be to format the option list without using ReST's special option list format (seeing as it's apparently not appropriate for us!).  Maybe just a list of ":`--pack-0.92`: this option blah blah blah"?
[04:38] <poolie> or a table maybe
[04:38] <spiv> Yeah, or a table.
[04:38] <spiv> It's not as beautiful, but we avoid the rather strange restrictions on what ReST automagically considers to be valid option names.
[04:40] <spiv> ":`--pack-0.92`:" works, and looks pretty similar to the existing output.
[04:40] <spiv> (The online renderer at http://www.hosting4u.cz/jbar/rest/render.py is convenient)
[04:40] <poolie> or we could put the formats into a separate table from the options...
[04:41] <spiv> Or a *really* nasty hack is to s/\./DOT/ before feeding the file to docutils, then s/DOT/./ on the output ;)
[04:41] <poolie> heh
[04:43] <poolie> spiv, what did you mean by  ":`--pack-0.92`:"
[04:43] <spiv> Markup like:
[04:43] <spiv> The list of options is:
[04:43] <spiv>  
[04:44] <spiv>   :`--pack-0.92`:  use pack-0.92 format, which blah blah blah...
[04:44] <spiv>   :`--other-arg`:  do other thing
[04:44] <spiv> The :foo: is a description list, and the backticks formats the text like a literal.
[04:45] <poolie> don't we want two backticks then?
[04:46] <spiv> (Oops, that URL should have been http://www.hosting4u.cz/jbar/rest/rest.html)
[04:46] <spiv> poolie: oops, yeah.
[04:47] <spiv> My ReST is apparently rusty :)
[04:47] <poolie> yeah i worked that out
[04:47] <poolie> that's ok
[04:47] <poolie> single backticks have a kinda odd meaning
[04:47] <poolie> igc, how about changing it to render like that?
[04:47] <poolie> also, i wonder why this didn't cause the tests to fail
[04:47] <igc> sounds ok - better than hacking ReST code I think
[04:47] <spiv> 15:47 < igc> sounds ok - better than hacking ReST code I think
[04:48] <spiv> (for the benefit of poolie)
[04:48] <poolie> or changing our format thing now
[04:48] <igc> yes
[04:49] <spiv> Btw, there's near comment in the regexes for the option list parsing saying: "# @@@ Loosen up the pattern?  Allow Unicode?"
[04:49] <poolie> heh
[04:49] <spiv> So perhaps the docutils guys are amenable to changing this :)
[04:49] <poolie> so, maybe we should send them a patch after all, but use a non-option list syntax for today?
[04:49] <poolie> settled?
[04:50] <spiv> I agree.
[04:50] <igc> me too
[04:50] <igc> I'm bust tweaking switch so I'd like spiv to do the work :-)
[04:50] <igc> s/bust/busy/
[04:51] <poolie> spiv, what are you up to now?
[04:51] <spiv> poolie: just finished a review of jam's status after merge.
[04:52] <spiv> poolie: so now's a reasonable time to look at tweaking the doc generation, but I'd also was planning to review jam's "Graph.heads() optimization... 1500 times faster".
[04:57] <poolie> spiv, i'll look at the docs
[04:58] <Odd_Bloke> Are bzr planning on participating in Google's Summer of Code this year?  And, if so, how many people have been accepted for bzr in years past?
[04:58] <ubotu> New bug: #148087 in bzr ""bzr break-lock bzr+ssh://bazaar.launchpad.net/..." fails to break a lock" [High,Confirmed] https://launchpad.net/bugs/148087
[05:03] <spiv> poolie: ok
[05:14] <poolie> Odd_Bloke, we may, we had 3 people last year
[05:14] <poolie> are you interested in participating?
[05:21] <Odd_Bloke> poolie: Yeah, definitely.
[05:53] <Peng> Using find_differences to show pending merges in "status", how many could incorrectly show up?
[05:53] <Peng> Any is a serious problem, and I don't like that you'd sacrifice that for performance..
[05:57] <abentley> jam: it can also be incorrect if it hits a ghost.
[05:59] <poolie_> igc, just where does the problem with the --packs-0.92 name show up?
[05:59] <igc> make doc/en/user-reference/bzr_man.html
[06:00] <poolie_> i thought so
[06:00] <poolie_> oh, they're just warnings
[06:00] <igc> yes, but check the output
[06:00] <igc> in your browser
[06:01] <poolie_> yes i see
[06:25] <poolie> hm, so the rst generation is quite punned with the regular command line help...
[06:26] <poolie> and since we already use our own tool to generate the help, maybe it is reasonable to monkeypatch from there
[06:46] <spiv> A twisted user just brought bug 147836 to my attention.  The fix is trivial, so I just posted it to the list.  I hope we can get it into 1.0rc2.
[06:46] <ubotu> Launchpad bug 147836 in bzr "'RemoteRepository' object has no attribute '_make_parents_provider' - bundle command fails with bzr remote repositories" [High,Fix committed] https://launchpad.net/bugs/147836
[06:46] <spiv> It should be a quick review.
[06:46] <poolie> ok
[06:46] <poolie> this is a pain to monkeypatch :/
[06:46] <poolie> too much stuff is evaluated at load time
[07:49] <poolie_> igc, hey well done with bryce!
[07:49] <poolie_> have a good weekend, all!
[07:49] <igc> cheers poolie_!
[07:54] <igc> have a great weekend everyone
[08:40] <ubotu> New bug: #174607 in bzr ".bzrignore is not honoured. [Bazaar (bzr) 1.0.0.candidate.1 - win32]" [Undecided,New] https://launchpad.net/bugs/174607
[09:12] <wam> Hi
[09:13] <wam> When I bzr add a directory and commit, bzr status tells me, that several files were removed. All further commits say that these files were removed although they're there. Where could I start to debug/correct this?
[09:13] <wam> I tried to add the files several times without success.
[09:28] <spiv> wam: what platform?
[09:29] <spiv> wam: and what bzr version?
[09:30] <spiv> wam: that sounds a bit like a bug we've had on case-insensitive filesystems, but I'm not sure of the details.
[10:15] <wam> spiv: sorry, was afk. It's linux ext3 fs.
[10:15] <wam> bzr 0.15.0
[10:18] <fullermd> wam: Can you pastebin a 'bzr stat' output and an ls (from the root of the branch) of those files?
[10:21] <wam> fullermd: http://pastebin.org/10770
[10:22] <fullermd> Oh, I meant a regular unix 'ls', not the 'bzr ls'.  What does ls of the src/archetypes.schemaextender/archetypes.schemaextender.egg-info/ dir yield, say?
[10:22] <fullermd> (ls -l, probably)
[10:23] <wam> fullermd: http://pastebin.org/10771
[10:23] <wam> fullermd: added ls -ls
[10:26] <fullermd> Hm.  No symlinks in that path?
[10:26] <wam> fullermd: none
[10:27] <fullermd> That's the full 'bzr stat' output?
[10:28] <wam> fullermd: no, just for those 2 dirs. Do you need the full one?
[10:28] <wam> fullermd: second
[10:28] <wam> fullermd: there's only a unknow-section. This is all for "removed".
[10:28] <fullermd> Hm.  Does it have all those files in the unknown section?
[10:29] <wam> fullermd: this is the full output: http://pastebin.org/10773
[10:29] <wam> fullermd: both dirs are from a svn checkout.
[10:30] <fullermd> Hm.  Wacky...
[10:30] <wam> fullermd: maybe this means something? Because all other dirs work.
[10:30] <fullermd> Those names are all just plain 7-bit ascii like they look, right?  No weird chars that look normal?
[10:30] <wam> fullermd: not that I'm aware of.
[10:30] <wam> fullermd: navigation works w/o tabs. so I can at least type them ;)
[10:31] <fullermd> Note that it doesn't list the directories as removed; just the files in them.  That means it's still seeing the dir.
[10:32] <wam> fullermd: yeah - this is really strange.
[10:32] <fullermd> I don't remember any such bugs in the 0.15-now timeframe.
[10:32] <wam> fullermd: oh
[10:32] <wam> fullermd: second - i got something.
[10:33] <wam> http://pastebin.org/10774
[10:33] <wam> argh
[10:33] <wam> damn
[10:33] <wam> was in .bzr.
[10:33] <wam> forget it ;)
[10:34] <fullermd> Heh.
[10:34] <wam> fullermd: I can add one of the files and then call bzr stat again and it's shown as "removed".
[10:36] <wam> fullermd: when I remove the dirs where the buggy files are in, they (=the dirs) show up in bzr stat as "unknown".
[10:36] <wam> fullermd: as expected ;)
[10:37] <fullermd> Well, if you haven't changed those files (or anything else, but stat doesn't show any), a quick 'bzr revert' is probably the quickest way to get them all back.
[10:37] <wam> fullermd: well, I'm doing a svn up in those dirs sometimes.
[10:38] <wam> fullermd: but as the product also belongs to my project, I want the files in bzr also
[10:38] <fullermd> Oh, well, that'll probably resurrect them too   :)
[10:40] <wam> fullermd: so do you recommend to remove them from filesystem and get them back from somewherE?
[10:40] <fullermd> Well, when they show back up in the filesystem, bzr should notice them and move them back into unchanged (or changed, of course).
[10:48] <Peng> Worth trying a modern version of bzr anyway?
[10:49] <fullermd> Well, upgrading is always a good idea.  Though usually by the time you upgrade, the next release cycle has gone through...
[10:49] <spiv> 0.15 is many release cycles ago now :)
[10:49] <fullermd> If ressurecting the files doesn't do the job, I'd certainly try that; particularly if it's a dirstate tree, 0.15 was pretty squirrely.
[10:49] <spiv> I'd definitely try upgrading.
[10:50] <fullermd> Or even resurrecting them.  Take your pick.
[10:50]  * fullermd obviously needs sleep.
[10:52] <Peng> Ooh, rc2?
[10:52] <fullermd> See?  Told ya!  You upgraded, so there's a new [semi-]release   :p
[10:53] <Peng> Has the download page been updated yet?
[10:53] <Peng> If so, the /topic should be.
[10:55] <Peng> The website has been updated.
[10:55] <Peng> Who's an op?
[10:56] <Peng> 'Course, http://bazaar-vcs.org/releases/src/bzr-1.0rc2.tar.gz is a 404.
[10:57] <fullermd> Don't need to be op to set the topic.
[10:57] <Peng> The PGP sig has been uploaded, though!
[10:57] <Peng> That's the important part anyway...
[10:57] <fullermd> Does it match?   :]
[10:57] <alwyn> Hi, everyone
[10:59] <dato> poolie_: as reported by Peng above, seems that the rc2 tarball wasn't uploaded?
[10:59] <Peng> poolie_: Also, the /topic needs to be updated.
[10:59] <dato> 11:57 <fullermd> Don't need to be op to set the topic.
[11:00] <alwyn> I have a bit of a problem with the eclipse plugin for bzr.  My project root is a shared bzr repository. I used Team->Share, but it shows all files bzr status as question marks and really slows down my eclipse.  Known bug?
[11:01] <ubotu> New bug: #174625 in bzr "Performance regression with pack format in missing" [Undecided,New] https://launchpad.net/bugs/174625
[11:01] <Peng> dato: You're right. WTF?
[11:01] <Peng> If I was just slightly less mature...
[11:01] <alwyn> hmm, maybe I should not have used the word b u g.
[11:03]  * Peng gets the bug spray.
[11:04] <fullermd> I don't use a bug, I use a straight key   :]
[11:05] <ubotu> New bug: #174627 in bzr "Large performance regression when pulling from	dirstate-with-subtree into rich-root repo" [Undecided,New] https://launchpad.net/bugs/174627
[11:06] <Peng> Wheee.
[12:31] <ubotu> New bug: #174643 in bzr "help for --sort option of `tags` command needs more help" [Undecided,New] https://launchpad.net/bugs/174643
[16:09] <blauwal> jelmer: ping
[17:27] <jdstrand> is there any way for bzr to follow a symlink out of the bzr controlled tree?
[17:27] <jdstrand> (I don't want it to, I want to make sure it doesn't :)
[17:28] <Nafallo> jdstrand: hehe. almost scared me for a sec :-)
[17:31] <sabdfl> hi folks
[17:31] <sabdfl> is there a command to find the root of the current bzr working tree?
[17:31] <Nafallo> hiya sabdfl :-). how are you?
[17:31] <sabdfl> hey Nafallo, great thanks, how are you?
[17:32] <Nafallo> sabdfl: home sick, thanks for asking ;-). plans to be back at work on Monday :-)
[17:32] <Nafallo> sabdfl: bzr info shows that information it seems :-)
[17:33] <jelmer> sabdfl: yep, "bzr root"
[17:44] <sabdfl> jelmer: ah, thanks! so much better than bzr info | grep "repository branch" | cut -d":" -f2
[17:44] <sabdfl> :-p
[17:47] <Nafallo> hehe
[17:50] <jelmer> :-)
[18:12] <fullermd> jelmer: You doing bzr-gtk hacking?
[18:22] <jelmer> fullermd: yup
[18:23] <fullermd> Does viz on trunk work for you?
[18:24] <bialix> privet
[18:24] <jelmer> fullermd: yup, like a charm
[18:25] <jelmer> are you running bzr-gtk trunk?
[18:25] <fullermd> Crud.  Why does it hate me?
[18:25] <fullermd> Yah.
[18:25] <fullermd> ImportError: No module named about
[18:25] <jelmer> fullermd: we changed the owner of the branch
[18:25] <jelmer> ah
[18:25] <jelmer> fullermd: you're using the old location of trunk
[18:25] <jelmer> replace "~bzr" in the branch url with "~bzr-gtk"
[18:26] <fullermd> Ah, I forgot about that...
[18:27] <fullermd> Can we remove that old location so that morons like me can get error messages instead of just 'Nope, nothing new...'?
[18:29] <jelmer> fullermd: it's on launchpad - afaik it's not possible to remove stuff from there
[18:30] <bialix> jelmer: launchapd has button to delete branches
[18:30] <bialix> at least if it hosted
[18:30] <jelmer> bialix: where? I don't see anything on https://edge.launchpad.net/~bzr/bzr-gtk/trunk
[18:31] <bialix> https://edge.launchpad.net/~bzr/bzr-gtk/trunk/+delete
[18:32] <jelmer> it refuses to delete because there are subscribers
[18:32] <bialix> well, at least you could delete it via sftp
[18:32] <bialix> unsubsribe them!
[18:33] <jelmer> I can't unsubscribe other people afaik
[18:33] <jelmer> and deleting over sftp gives permission denied
[18:33] <bialix> you can ask this people, peraps, to unsubscribe
[18:34] <bialix> perhaps
[18:34] <bialix> for me it's the bug in launchpad
[18:34] <bialix> hey, launchpad people, are you here?
[18:48] <keescook> so, I've hit bug 152746.  It's not clear to me what the work-around is...
[18:48] <ubotu> Launchpad bug 152746 in bzr "bzr commit to bzr+ssh hangs on 'No handlers could be found for logger "bzr"'" [High,Confirmed] https://launchpad.net/bugs/152746
[18:52] <ddaa> where are the option:policy values documented?
[18:52] <ddaa> (for locations.conf)
[18:53] <ddaa> I'd need a policy which would be "the path for the inner subsection that matches this path, plus this fixed string"
[18:53] <ddaa> s/inner/innermost/
[19:00] <engla> hm. how to get a list of branches in a repo, and then switch to one of them?
[19:04] <bialix> poolie_: are you still here?
[19:06] <bialix> why no one report that 1.0rc2 tarball is actually missed on the server?
[19:06] <bialix> nobody download it? heh
[19:07] <dato> bialix: Peng noticed and I pinged poolie_ about it
[19:08] <bialix> we need to wait some hours probably until sun rise in the Oz land...
[19:08] <bialix> ok, no sources - no win32 installer
[19:09] <engla> if this project I checked out a branch of; if it had more than this trunk branch, would that show in bzr info?
[19:15] <bialix> engla: to get list of branches you can run bzr branches (you need to have bzrtools)
[19:15] <bialix> engla: info shows only actual info about your branch
[19:16] <bialix> bzr repository is optimisation technics, it's not dedicated to hold branches for only on project
[19:16] <bialix> you can mix several projects in one repo
[19:53] <engla> good help
[19:53] <engla> but I didn't have bzrtools
[22:39] <mw> hmmm, the rc2 tarball has some minor errors in various version_infos
[22:49] <abentley> In case anyone's wondering about Bundle Buggy, there's some kinda routing issue.  It's disrupting my email, too.