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