[00:00] epsy: try bzr -Derror rocks [00:01] same thing [00:01] $ bzr -Derror rocks [00:01] Unable to load plugin 'svn' from '/home/epsy/.bazaar/plugins' [00:01] It sure does! [00:01] hm [00:01] jelmer, i'm at it, second [00:01] epsy: which version of bzr? [00:01] 1.5 [00:01] ... and which version of bzr-svn, i guess? [00:02] 0.140 looking for plugins in /home/epsy/.bazaar/plugins [00:02] 0.162 bzr-svn: using Subversion 1.4.6 () [00:02] [ 9154] 2008-08-24 01:00:02.301 WARNING: Unable to load plugin 'svn' from '/home/epsy/.bazaar/plugins' [00:02] 0.165 Traceback (most recent call last): [00:02] File "/usr/lib/python2.5/site-packages/bzrlib/plugin.py", line 208, in load_from_dir [00:02] exec "import bzrlib.plugins.%s" % name in {} [00:02] File "", line 1, in [00:02] File "/home/epsy/.bazaar/plugins/bzr_svn/__init__.py", line 158, in [00:02] AttributeError: 'module' object has no attribute 'properties_handler_registry' [00:02] er [00:02] sorry that was a bit much [00:02] epsy: your version of bzr is too old for your version of bzr-svn [00:02] mwhudson, just checked it out [00:02] ah, right [00:03] i'll upgrade [00:13] for that i would need bzr 1.6 right? [00:13] yep [00:14] alright [02:46] * meteoroid is excited to be the rhel5 x86_64 buildbot host for drizzle (the new mysql) using bzr :) [03:32] when a test fails we see its trace output - how can I see the same output when the test passes? [03:35] hi markh, I don't know of a way to do it for tests [03:36] hrmph - oh well, hackery must be done then! [03:37] markh: actually, there is support for it [03:38] markh: I just don't think it's in the UI [03:38] yeah - I think we just need to arrange for trace.set_verbosity_level() to be called [03:39] or possibly be_quiet() [03:40] it would be handy, eg, when you are working on a feature branch where a test fails - it would be very handy to see that same output on a branch where it works [03:42] so, there's soem way of stopping it from deleting the log file [03:42] but I don't know if that's useful, or how to enable it [03:42] I guess it might be... [03:43] test._log_contents = '' [03:43] that makes it look like some hackery will be required [03:43] (in addSuccess) [04:00] * AfC is sad that bzr-svn is still segfaulting for him. [04:01] AfC: Does jelmer know about it? [04:01] AfC: 64-bit ? [04:01] wtf, are all the Europeans living in .au tz these days? [04:01] lifeless: no [04:02] * Odd_Bloke starts a job on Tuesday, has to make the most of his last days of freedom. :p [04:02] Odd_Bloke: yes. I got him a gdb backtrace the other day [04:02] (although now that I see a fellow named jelmer in this channel, the least I can do is offer to run some other tests or diagnostics if it would help him) [04:03] AfC, I didn't see anything obviously wrong and can't reproduce it here [04:03] AfC, what platform/architecture are you on? [04:04] Linux, x86 [04:04] gentoo :) [04:04] Subversion 1.5.1 [04:04] Bazaar 1.6-rc5 [04:04] bzr-svn from current 0.4 branch tip [04:05] Hmm, that's pretty similar to what I have here except that I'm on sid rather than gentoo [04:07] Odd_Bloke, ah, all freedom and no sleep ? :-) [04:08] Something very much like that. :D [04:09] AfC: I can try to reproduce it (I have a x86 box with Gentoo) [04:10] AfC: steps to reproduce? [04:10] Verterok: Unfortunately it seems like a fairly fundamental flaw (which is why I doubt bzr-svn is to blame) [04:10] Verterok: I upgraded from bzr 1.5 & bzr-svn 0.4.10 [04:11] Verterok: to bzr 1.6-rc5 and bzr-svn from the 0.4 branch [04:11] Verterok: meanwhile, Subversion upgraded to 1.5.1 [04:11] (care of Portage) [04:12] anyway, somewhere in there bzr-svn stopped working. Both `bzr pull` on an existing bzr-svn branch and `bzr branch` attempting to create a new one crash [04:12] with a segmentation fault. [04:12] (joy) [04:12] AfC, does the testsuite for bzr-svn pass? [04:13] jelmer: not sure. I've never tried to run the Bazaar test suite before. [04:13] AfC, should be a matter of running "make check" in the bzr-svn dir [04:14] AfC: ok. I'll emerge subversion 1.5.1, try to branch a svn repo and come back with the results (in a while, I'm in the middle of a emerge -u world :P) [04:14] jelmer: ah, indeed? Well then, I shall do that presently. [04:14] jelmer: `make check` segfaults right quickly [04:15] * AfC curses again [04:15] (as I am certain that I have done something wrong, though of course haven't the faintest idea what) [04:15] AfC, can you perhaps paste the output of "make valgrind-check" ? [04:15] jelmer: gonna have to grab Valgrind first. Wait, out. [04:22] Has anyone looked at packaging PQM? [04:22] jelmer: ^ [04:23] Odd_Bloke, yep [04:23] Odd_Bloke, let me find the URL [04:24] jelmer: FATAL: can't open suppressions file '/usr/lib/valgrind/python.supp' [04:24] Is that something I can do something about? [04:24] AfC, you may have to tweak the Makefile to point at the right suppressions file [04:24] jelmer: https://code.edge.launchpad.net/~jelmer/pqm/debian ? [04:24] Odd_Bloke, http://bzr.debian.org/pkg-bazaar/pqm/unstable [04:25] Odd_Bloke, yeah, that's the lp mirror [04:25] weird coincidence, I actually put that up today [04:25] jelmer: any idea where I can get one? [04:25] AfC, without the python suppressions, there'll be a lot of noise from valgrind [04:27] AfC, http://samba.org/~jelmer/tmp/python.supp [04:27] jelmer: (understood). Thanks. [04:28] AfC, It's shipped with Debian, not sure where they get it from though [04:29] k [04:31] jelmer: http://rafb.net/p/NmyJzz74.html [04:33] AfC, please try again with r1627 [04:34] AfC, I've added some extra error checks that may help determine what's going wrong [04:36] Um [04:36] Odd_Bloke, it uses my distutils code though, and that's not upstream et [04:36] jelmer: sorry to be slow, but what Branch URL should I be using? http://people.samba.org/bzr/jelmer/bzr-svn/0.4/ says its at 1613 [04:37] AfC, yeah, that's the one [04:37] I'm pushing, it's just slow.. [04:37] Huh [04:37] ah [04:37] nevermind [04:37] pushing over bzr+ssh is slower than over svn+ssh these days... [04:38] That's exciting [04:40] jelmer: CDBS. D: [04:45] jelmer: The distutils install-html target seems to be broken. [04:45] It's trying to install into /usr rather than the build-area. [04:47] jelmer: take 2: http://rafb.net/p/zK9p2492.html [04:51] AfC, can't think of anything that may be going wrong [04:52] Still, "Address 0x0 is not stack'd, malloc'd or (recently) free'd" is pretty funny [04:53] * AfC heads out. [04:53] jelmer: thanks for looking [04:54] Without wanting to be negative, /me hopes Verterok reproduces what I am hitting. [04:54] See ya [04:59] Odd_Bloke, yeah, cdbs is kinda nice when you have a package that's trivial to package [04:59] Odd_Bloke, when you need to customize things a bit, it gets nasty [05:10] jelmer: I've found debhelper 7 to be pretty good for trivial packages. [05:11] does that deal with setup.py ok? [05:22] jelmer: I think you still have to issue the setup.py line yourself. [05:22] But, looking at my packages, most of my Python packages either predate (my knowledge of) debhelper 7 or are inherited and haven't needed enough changing to move away from CDBS. [05:51] jelmer: I wasn't able to reproduce AfC's problem with bzr-svn, only 1 test failure [06:06] jelmer: http://svn.debian.org/viewsvn/python-modules/packages/configobj/trunk/debian/rules?rev=6338&view=markup is an example of a debhelper 7 rules file for a Python package. [09:26] How can I see the changes that would be made if I did a pull? [09:27] 'bzr missing' is a bit like that [09:28] bzr diff --new :parent maybe, not sure [09:30] In git there's BASE (latest here) and HEAD (latest there), and you can get the log between the two [09:30] bzr missing if you want a log [09:30] But in „bzr help revisionspec“ I don't find anything like that [09:31] and I think you have BASE and HEAD in git backwards [09:31] er, backwards is not the right word [09:31] but BASE is probably 'latest there', and HEAD 'latest here' [09:34] Ah, ok, I actually wanted to put the example of Subversion, not git. This works in Subversion: svn log -r BASE:HEAD [09:35] well, in that case you want bzr missing [09:35] Is it necessary to specify the branch URL in „bzr missing“? Can't it use the URL which was used for checkout, or for pulling? [09:35] (I mean automatically) [09:35] it does, doesn't it? [09:36] Well, I am inside a branch inside a repository, and it tries to use the repository as branch; then it fails [09:37] what does `bzr info` says? [09:37] the parent branch: line [09:38] It refers to the repository. That's bad [09:38] perhaps you ran 'bzr pull --remember' with the wrong URL? [09:39] it defaults to the location you branched from [09:39] No, but I converted the branch to a „branch inside a repository“, and the repository happens to have the same URI as the former branch [09:39] ah, that would be the problem [09:41] What should I set as parent? It's the branch for lp:bzr [09:43] http://bazaar-vcs.org/bzr/bzr.dev/ probably [09:43] So the same as the attribute „checkout of branch“ which „bzr info“ shows [09:43] parent_location == bound_location [09:45] Ok, now it works; a bit slow, but works [09:46] Luckily „bzr missing“ is a lot easier than in Subversion or git [09:53] I have seen the log. What if I want to see a particular diff? [09:53] bzr diff -r 3647:lp:bzr ? [09:54] I'd use `bzr diff --new :parent` [09:56] That shows nothing [09:57] I want just from „the revision before 3647“ to revision 3647, both in the remote branch [09:59] -r 3647:lp:bzr seems to select more than 1 revision: not only 3647 but also the ones before [10:05] I don't understand the grammar for specifying revision ranges. If a range is REV..REV, and REV can be something like branch:/a (according to „bzr help revisionspec“), then a range could be for instance branch:/a..branch:/a [10:05] Obviously there's something wrong [10:05] clemente: thats a valid range, yes [10:06] But it's ambiguous [10:06] how so ? [10:06] You don't always know if .. will be a separator or not [10:07] thats true, but its possible to look and see :) [10:07] branch:FOO - FOO is eaten by the parser and returns the unused portion [10:10] Then at „bzr help revisionspec“ it's missing a section about revision ranges. Nowhere it says that .. is the range operator [10:10] ok, we should fix that [10:11] anyhow, are you having some problem ? [10:12] I also don't find at that page the way to refer to „the head of the current branch“ [10:12] sorry, I see some unicode glyph there [10:12] terminal issue [10:13] "the way to refer to XXXX" - I don't know what XXX is [10:14] ok; without Unicode :-( : to refer to: the head of the current branch [10:14] '-1' usually does that job, if i understand what you're saying [10:15] And then you don't have to specify that you are talking about the local branch? [10:16] right [10:16] bzr diff -r -1 [10:16] == [10:16] show me changes in the working tree against the branches tip [10:16] That could be also explained in the example in bzr help revisionspec [10:17] I agree [10:18] I'd like to fix bugs or improve documentation, but I still don't know how to do it in Bazaar [10:19] do you ahve a branch of bzr ? [10:19] yes [10:20] I don't have much expertise with English; I don't know if I should write much documentation [10:20] revision spec help is in bzrlib/revisionspec.py [10:21] our review pocess will catch english issues [10:23] So I'm allowed to check in the changes even if they're not perfect? To which branch? [10:23] your own [10:25] Yes. And how can then other developers access my branch? (ssh, http, ...) [10:25] Probably I have to push the branches to Launchpad [10:26] you can push it to launchpad, or just send in a bundle via email [10:26] the HACKING document explains the contribution process [10:27] Ok, that's good (and long!), I read it [11:31] I'm tracking a project's trunk, but never actually working on the codebase myself. Is this (still) the best way to get a minimal (fast / small) copy of trunk? [11:31] bzr checkout --lightweight lp:nxhtml nxhtml [11:56] twb: fast != small :) - less data locally means more remote access [11:56] twb: bzr branch --stacked is likely more efficient than checkout --lightweight [11:57] lifeless: all I will ever do to this copy is get the initial copy, then pull in updates [11:57] Really all I care about is the working tree, and the ability to update it. [12:00] twb: I appreciate that, nevertheless [14:03] $ bzr pull --remember http://rage.kuonet.org/~anmaster/bzr/cfunge [14:03] http://rage.kuonet.org/%7Eanmaster/bzr/cfunge is permanently redirected to http://rage.kuonet.org/~anmaster/bzr/cfunge/ [14:03] that seems odd [14:03] anyone can explain it? [14:06] %7E is an escaped version of ~ [14:06] If you use curl -sLI, you get [14:06] HTTP/1.1 301 Moved Permanently [14:06] Location: http://rage.kuonet.org/~anmaster/bzr/cfunge/ [14:06] true [14:07] but I gave ~ on command line [14:07] So what's happening is that the HTTP server is redirecting to include a / [14:07] ah [14:07] right [14:07] And something (bzr) is escaping the ~ just because it can [14:07] Probably it's passing through some sort of normal form-izing printer [14:08] (I'm just speculating; I don't normally even use bzr.) [14:08] So in summary, if you use the trailing slash in your original pull, the notice should disappear [14:09] wait this is #bzr right? [14:09] [ [14:09] AnMaster: yes it is [14:10] AnMaster: the ~ is because bzr only emits accurate urls, to aid debugging in the event of unusal servers (there are many such :() [14:10] hm [14:10] ok [14:10] AnMaster: but we accept things like ~ and normalise them for ease of use [14:11] I dunno that using ~ isn't "accurate". [14:11] Merely not non-normalized [14:11] heh [14:15] twb: read std66, urls are not defined to be in any encoding [14:15] twb: it could be in EBCIDIC [14:16] the recommended encoding is utf8, but servers don't have to follow that === jaypipes-afk is now known as jaypipes [17:05] hi [17:06] right, i've finally upgraded to 1.6rc5, but i'm still getting problems merging from an svn checkout into a bzr branch: [17:06] bzr: ERROR: KnitPackRepository('file:///home/epsy/CODE/armagetron/http-auth-server-bzr/.bzr/repository/') [17:06] is not compatible with [17:06] SvnRepository('https://armagetronad.svn.sourceforge.net/svnroot/armagetronad') [17:06] different rich-root support [17:09] lifeless: by the way, thanks; I just posted my first patch to the mailing list. [17:16] epsy: I don't know much about it, but maybe it's because of the format used. I think "bzr upgrade" can solve this [17:16] But first make a backup of your .bzr/ ... [17:16] clemente, in the svn checkout? Oo [17:16] well, the bzr branch is completely new [17:17] as in, in just typed bzr init [17:17] I don't know... I only knew that because I read it here: https://bugs.launchpad.net/bzr/+bug/206258 [17:17] Launchpad bug 206258 in bzr "incompatible repository error messages are unhelpful" [Medium,Fix committed] [17:17] heh [17:17] epsy: the bzr branch needs to have rich root support [17:18] epsy: what does `bzr info` say on the bzr branch? [17:18] So this can work: bzr upgrade --rich-root-pack [17:18] how do i turn that on? [17:18] ok [17:20] However, apparently bug 206250 was fixed and therefore you should have seen the message with the solution. If you didn't see it, maybe you complain on that bug report :-) [17:20] Launchpad bug 206250 in ubuntu "fonts visible in open office editer, but printed as square blocks" [Undecided,New] https://launchpad.net/bugs/206250 [17:20] Oops, I meant 206258 [17:21] is it fixed in rc5 ? [17:21] it says fix committed and not fix released [17:22] Ah, ok. [17:23] I think this is important and undangerous for the release... [17:23] how do i show "sub-revisions" with bzr log ? [17:24] epsy: just bzr log. Or --long to be sure it isn't overriden. [17:24] it only shows with bzr log --line [17:24] wait [17:25] negative revision numbers ew.. [17:26] hmm? [17:27] $ bzr log --line [17:27] 1: epsy46 2008-08-24 Imported from svn [17:27] 0: epsy 2008-08-15 redirects back [17:27] -1: epsy 2008-08-15 moar typos [17:27] -2: epsy 2008-08-15 fixed bugs typos and turtles [17:27] -3: epsy 2008-08-15 typo [17:27] -4: epsy 2008-08-15 some old stuff i forgot to commit [17:28] [and it goes on] [17:28] (yes, with even more typos :P) [17:29] epsy: why do you supply --line? And displaying negative revnos certainly isn't default behaviour. Do you have any plugins installed that modify log behaviour, or an alias? [17:29] LarstiQ, i was merging from a bzr checkout [17:29] er [17:29] an svn checkout* [17:29] using the svn plugin [17:30] epsy: so where are you running log on? [17:30] the bzr branch [17:30] after merging stuff from the svn one [17:31] did you commit after the merge? [17:32] yes, as i thought it didn't commit anything, as nothing showed up on bzr log without arguments [17:32] 1: epsy46 2008-08-24 Imported from svn [17:32] ok, you certainly aren't using just default bzr ) [17:32] ill file a bug to the bzr-svn guys :) === fta_ is now known as fta [17:33] epsy: bzr-svn also doesn't do that [17:33] epsy: try 'bzr log --long'? [17:33] too late, i started over [17:33] second [17:33] epsy: and check `bzr plugins` for any obvious culprits. If that fails, peek at ~/.bazaar/bazaar.conf for aliases [17:33] epsy, what's going wrong with bzr-svn? [17:35] jelmer, bzr init --rich-root-pack && bzr merge [some svn checkout] && bzr log --line [17:35] epsy, what's it not doing right? [17:36] assigning revision numbers, i guess, they show up as negatives [17:36] the last revision being 0 [17:36] wait, you need to commit something before it show up [17:37] yeah [17:37] jelmer, bzr init --rich-root-pack && bzr merge [some svn checkout] && bzr ci -m "test123" && bzr log --line [17:38] epsy, does "bzr log" (without --line) print antyhing sensible? [17:38] nope, it seems that it stops at 1 anyway [17:39] while --line continues as long as there are available revisions [17:39] epsy, but shows the bzr-svn revisions below revision 1? [17:39] it only shows revision 1 [17:39] er [17:39] epsy, can you put the bzr repo with this bug up somewhere? [17:39] now it calls it revision 34 [17:40] well, i could reproduce it over and over [17:40] I can't, that's why it would be useful to be able to analyse this branch :-) [17:41] in bzr log --line revision with commit message shows up as #1, with the older revisions from svn as 0 and negatives, while in normal bzr log, it shows up alone as rev #34 [17:41] revisions* [17:45] epsy, It's very hard to say anything about this without a look at the branch. Any chance you can upload a tarball or something somewhere? [17:45] second [17:59] jelmer, also, what is the expected behaviour? i don't have much experience with merging [17:59] epsy: "bzr log --line" should just show the revisions on mainline [17:59] [i'm still at packing an example tarball] [17:59] epsy: so not the merged revisions [18:01] jelmer, is there a way we can somehow track these? [18:01] epsy: The merged revisions are shown indented when you run "bzr log" (no --line) [18:02] right [18:43] how do i manually choose a merge base revision ? [18:51] oh, right, that's what's before the .. in -r 1..2 :) === emgent is now known as emgent` [19:14] epsy, any chance of that tarball? [19:14] jelmer, it's taking ages :( [19:15] i would need a not-so-big bzr branch for testing [19:15] gnah [19:15] i mean an svn branch [19:50] epsy: is the svn branch public? Then maybe jelmer could reproduce it locally. [19:50] jelmer: or did you already try that? [19:51] LarstiQ, he's busy tarring up the bzr branch [19:51] I doubt this is related to bzr-svn, rather a bug in bzr log --line [19:53] jelmer: right. [19:54] epsy: with the bzr branch you merged the svn checkout into, did it have any revisions before you committed the merge? === mark1 is now known as markh [19:55] epsy, jelmer: if that is so, I have a hunch it's a corner cases with the first revision assuming it doesn't have any merged revisions. [19:55] LarstiQ, no, this seems to be characteristic [19:56] LarstiQ, i could work around it making an empty commit first [19:59] epsy: ok, let me try to reproduce that with bare bzr. [20:00] i think at some point i could reproduce it with plain bzr stuff, without svn stuff, but i'm not sure anymore [20:00] epsy: yup, thanks, that does it. [20:01] right [20:01] :) [20:01] epsy: so, that explains the negative revnos were we don't expect them. Was there anything else fishy? [20:01] epsy: do you want to file the bug, or shall I do it? [20:03] go for it, i dont think i have much more detail than you [20:04] LarstiQ, the different listing behavoir of normal bzr log and bzr log --line [20:04] the commit that you do, which shows as #1 in bzr log --line, shows as a higher revision number in normal bzr log [20:05] brb, dinner [20:07] epsy: yeah, the root cause is the same, --line is correct for your committed revision, but it shouldn't show the others (and hence not count down through zero). [20:07] epsy: the --long formatting is slightly more involved, but same cause. [20:57] siretart, ping [21:18] jelmer: pong [21:19] siretart: Did you have a chance to look at the loggerhead package? [21:19] siretart, You asked me to ping you about it a couple of days back :-) [21:25] jelmer: yes :) - sorry, no, I had a family party today and was busy the whole weekend with preparations. [21:26] jelmer: I'll look at it tomorrow. btw, have you done some commits since my last comments? [21:27] siretart, Yeah, I clarified the copyright file slightly [21:28] jelmer: okay, thanks. I'll get to it tomorrow morning [21:28] siretart, thanks ! [21:53] Hello, I'm trying to get the Nautilus extension for Bazaar to work. I've downloaded the source for bzr-gtk 0.95 (as I could not find it in any repository?) I have Bazaar 1.6rc5 installed and I've tried to follow the installation instructions in the README. So I've put the nautilus-bzr.py file in the ~/.nautilus/python-extensions dir. [21:54] Is there anything else that I need to do? I've restarted X as well. [21:55] I then try to browse a folder in Nautilus to see if there are any new buttons, menu options or icons, but I cannot see anything, am I looking for the right thing? [22:01] Anyone awake? [22:06] I am [22:07] ok :) Hi there, do you know anything about the nautilus extension for bazaar? [22:10] Lani78, do you have python-nautilus installed? [22:12] jelmer: I'm not sure if I've done it correctly, I've downloaded bzr-gtk 0.95 [22:12] I've put the nautilus-bzr.py file in the ~/.nautilus/python-extensions [22:12] Lani78, you need to install the nautilus support for python bindings as well [22:13] Ah, ok, I will try that right away! [22:15] Do I have to restart X then? [22:15] you'll have to restart nautilus [22:16] though restarting X will take care of that [22:16] ok [22:20] I've got some new menu entries now :) [22:22] Is it possible to do a checkout from within Nautilus, instead of the command line: "bzr checkout sftp://server/bzr/proj1 dev [22:22] " [22:26] I'm not sure if we added an option for that yet [22:26] if not, please file a wishlist bug [22:26] is there a way i can prevent myself from committing a file, while it still being versionned? [22:26] epsy, bzr commit has a -x option now [22:27] (bzr 1.6) [22:27] i mean, permanently [22:27] a bit like .bzrignore [22:27] why would you want to version it then? [22:27] it's a config file [22:28] jelmer: ok, I'm poking around a little. You should probably update the README for bzr-gtk to include the need for "python-nautilus". As it might not be obvious to everyone :) [22:28] and i don't want my passwords and other crap being committed, do i? :) [22:29] epsy, I would not keep it versioned then [22:29] instead, just commit foo.conf.example and ignore foo.conf in .bzrignore [22:29] good idea [22:30] I cannot find any menu entry for checkout [22:31] So if I'm looking in the right place it might not be there, but I'm just learning bzr so it might be that I just have the wrong status of my project? [22:31] I just did a commit now, that went ok. [22:31] Lani78, if you can't find it where you expect it to be, it's also a flaw :-) [22:31] lamont, I think it's very possible we don't have a checkout menu entry yet [22:32] jelmer: I agree ;) [22:33]