[00:00] <mwhudson> epsy: try bzr -Derror rocks
[00:01] <epsy> same thing
[00:01] <epsy> $ bzr -Derror rocks
[00:01] <epsy> Unable to load plugin 'svn' from '/home/epsy/.bazaar/plugins'
[00:01] <epsy> It sure does!
[00:01] <mwhudson> hm
[00:01] <epsy> jelmer, i'm at it, second
[00:01] <mwhudson> epsy: which version of bzr?
[00:01] <epsy> 1.5
[00:01] <mwhudson> ... and which version of bzr-svn, i guess?
[00:02] <epsy> 0.140  looking for plugins in /home/epsy/.bazaar/plugins
[00:02] <epsy> 0.162  bzr-svn: using Subversion 1.4.6 ()
[00:02] <epsy> [ 9154] 2008-08-24 01:00:02.301 WARNING: Unable to load plugin 'svn' from '/home/epsy/.bazaar/plugins'
[00:02] <epsy> 0.165  Traceback (most recent call last):
[00:02] <epsy>   File "/usr/lib/python2.5/site-packages/bzrlib/plugin.py", line 208, in load_from_dir
[00:02] <epsy>     exec "import bzrlib.plugins.%s" % name in {}
[00:02] <epsy>   File "<string>", line 1, in <module>
[00:02] <epsy>   File "/home/epsy/.bazaar/plugins/bzr_svn/__init__.py", line 158, in <module>
[00:02] <epsy> AttributeError: 'module' object has no attribute 'properties_handler_registry'
[00:02] <epsy> er
[00:02] <epsy> sorry that was a bit much
[00:02] <jelmer> epsy: your version of bzr is too old for your version of bzr-svn
[00:02] <epsy> mwhudson, just checked it out
[00:02] <epsy> ah, right
[00:03] <epsy> i'll upgrade
[00:13] <epsy> for that i would need bzr 1.6 right?
[00:13] <mwhudson> yep
[00:14] <epsy> alright
[02:46]  * meteoroid is excited to be the rhel5 x86_64 buildbot host for drizzle (the new mysql) using bzr :)
[03:32] <markh> when a test fails we see its trace output - how can I see the same output when the test passes?
[03:35] <james_w> hi markh, I don't know of a way to do it for tests
[03:36] <markh> hrmph - oh well, hackery must be done then!
[03:37] <james_w> markh: actually, there is support for it
[03:38] <james_w> markh: I just don't think it's in the UI
[03:38] <markh> yeah - I think we just need to arrange for trace.set_verbosity_level() to be called
[03:39] <markh> or possibly be_quiet()
[03:40] <markh> 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] <james_w> so, there's soem way of stopping it from deleting the log file
[03:42] <james_w> but I don't know if that's useful, or how to enable it
[03:42] <markh> I guess it might be...
[03:43] <james_w> test._log_contents = ''
[03:43] <james_w> that makes it look like some hackery will be required
[03:43] <james_w> (in addSuccess)
[04:00]  * AfC is sad that bzr-svn is still segfaulting for him.
[04:01] <Odd_Bloke> AfC: Does jelmer know about it?
[04:01] <lifeless> AfC: 64-bit ?
[04:01] <jelmer> wtf, are all the Europeans living in .au tz these days?
[04:01] <AfC> 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] <AfC> Odd_Bloke: yes. I got him a gdb backtrace the other day
[04:02] <AfC> (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] <jelmer> AfC, I didn't see anything obviously wrong and can't reproduce it here
[04:03] <jelmer> AfC, what platform/architecture are you on?
[04:04] <AfC> Linux, x86
[04:04] <lifeless> gentoo :)
[04:04] <AfC> Subversion 1.5.1
[04:04] <AfC> Bazaar 1.6-rc5
[04:04] <AfC> bzr-svn from current 0.4 branch tip
[04:05] <jelmer> Hmm, that's pretty similar to what I have here except that I'm on sid rather than gentoo
[04:07] <jelmer> Odd_Bloke, ah, all freedom and no sleep ? :-)
[04:08] <Odd_Bloke> Something very much like that. :D
[04:09] <Verterok> AfC: I can try to reproduce it (I have a x86 box with Gentoo)
[04:10] <Verterok> AfC: steps to reproduce?
[04:10] <AfC> Verterok: Unfortunately it seems like a fairly fundamental flaw (which is why I doubt bzr-svn is to blame)
[04:10] <AfC> Verterok: I upgraded from bzr 1.5 & bzr-svn 0.4.10
[04:11] <AfC> Verterok: to bzr 1.6-rc5 and bzr-svn from the 0.4 branch
[04:11] <AfC> Verterok: meanwhile, Subversion upgraded to 1.5.1
[04:11] <AfC> (care of Portage)
[04:12] <AfC> 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] <AfC> with a segmentation fault.
[04:12] <AfC> (joy)
[04:12] <jelmer> AfC, does the testsuite for bzr-svn pass?
[04:13] <AfC> jelmer: not sure. I've never tried to run the Bazaar test suite before.
[04:13] <jelmer> AfC, should be a matter of running "make check" in the bzr-svn dir
[04:14] <Verterok> 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] <AfC> jelmer: ah, indeed? Well then, I shall do that presently.
[04:14] <AfC> jelmer: `make check` segfaults right quickly
[04:15]  * AfC curses again
[04:15] <AfC> (as I am certain that I have done something wrong, though of course haven't the faintest idea what)
[04:15] <jelmer> AfC, can you perhaps paste the output of "make valgrind-check" ?
[04:15] <AfC> jelmer: gonna have to grab Valgrind first. Wait, out.
[04:22] <Odd_Bloke> Has anyone looked at packaging PQM?
[04:22] <Odd_Bloke> jelmer: ^
[04:23] <jelmer> Odd_Bloke, yep
[04:23] <jelmer> Odd_Bloke, let me find the URL
[04:24] <AfC> jelmer: FATAL: can't open suppressions file '/usr/lib/valgrind/python.supp'
[04:24] <AfC> Is that something I can do something about?
[04:24] <jelmer> AfC, you may have to tweak the Makefile to point at the right suppressions file
[04:24] <Odd_Bloke> jelmer: https://code.edge.launchpad.net/~jelmer/pqm/debian ?
[04:24] <jelmer> Odd_Bloke, http://bzr.debian.org/pkg-bazaar/pqm/unstable
[04:25] <jelmer> Odd_Bloke, yeah, that's the lp mirror
[04:25] <jelmer> weird coincidence, I actually put that up today
[04:25] <AfC> jelmer: any idea where I can get one?
[04:25] <jelmer> AfC, without the python suppressions, there'll be a lot of noise from valgrind
[04:27] <jelmer> AfC, http://samba.org/~jelmer/tmp/python.supp
[04:27] <AfC> jelmer: (understood). Thanks.
[04:28] <jelmer> AfC, It's shipped with Debian, not sure where they get it from though
[04:29] <AfC> k
[04:31] <AfC> jelmer: http://rafb.net/p/NmyJzz74.html
[04:33] <jelmer> AfC, please try again with r1627
[04:34] <jelmer> AfC, I've added some extra error checks that may help determine what's going wrong
[04:36] <AfC> Um
[04:36] <jelmer> Odd_Bloke, it uses my distutils code though, and that's not upstream et
[04:36] <AfC> 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] <jelmer> AfC, yeah, that's the one
[04:37] <jelmer> I'm pushing, it's just slow..
[04:37] <AfC> Huh
[04:37] <AfC> ah
[04:37] <AfC> nevermind
[04:37] <jelmer> pushing over bzr+ssh is slower than over svn+ssh these days...
[04:38] <AfC> That's exciting
[04:40] <Odd_Bloke> jelmer: CDBS. D:
[04:45] <Odd_Bloke> jelmer: The distutils install-html target seems to be broken.
[04:45] <Odd_Bloke> It's trying to install into /usr rather than the build-area.
[04:47] <AfC> jelmer: take 2: http://rafb.net/p/zK9p2492.html
[04:51] <jelmer> AfC, can't think of anything that may be going wrong
[04:52] <AfC> Still, "Address 0x0 is not stack'd, malloc'd or (recently) free'd" is pretty funny
[04:53]  * AfC heads out.
[04:53] <AfC> jelmer: thanks for looking
[04:54] <AfC> Without wanting to be negative, /me hopes Verterok reproduces what I am hitting.
[04:54] <AfC> See ya
[04:59] <jelmer> Odd_Bloke, yeah, cdbs is kinda nice when you have a package that's trivial to package
[04:59] <jelmer> Odd_Bloke, when you need to customize things a bit, it gets nasty
[05:10] <Odd_Bloke> jelmer: I've found debhelper 7 to be pretty good for trivial packages.
[05:11] <jelmer> does that deal with setup.py ok?
[05:22] <Odd_Bloke> jelmer: I think you still have to issue the setup.py line yourself.
[05:22] <Odd_Bloke> 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] <Verterok> jelmer: I wasn't able to reproduce AfC's problem with bzr-svn, only 1 test failure
[06:06] <Odd_Bloke> 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] <clemente> How can I see the changes that would be made if I did a pull?
[09:27] <mwhudson> 'bzr missing' is a bit like that
[09:28] <luks> bzr diff --new :parent maybe, not sure
[09:30] <clemente> In git there's BASE (latest here) and HEAD (latest there), and you can get the log between the two
[09:30] <luks> bzr missing if you want a log
[09:30] <clemente> But in „bzr help revisionspec“ I don't find anything like that
[09:31] <luks> and I think you have BASE and HEAD in git backwards
[09:31] <luks> er, backwards is not the right word
[09:31] <luks> but BASE is probably 'latest there', and HEAD 'latest here'
[09:34] <clemente> Ah, ok, I actually wanted to put the example of Subversion, not git. This works in Subversion: svn log -r BASE:HEAD
[09:35] <luks> well, in that case you want bzr missing
[09:35] <clemente> 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] <clemente> (I mean automatically)
[09:35] <luks> it does, doesn't it?
[09:36] <clemente> Well, I am inside a branch inside a repository, and it tries to use the repository as branch; then it fails
[09:37] <luks> what does `bzr info` says?
[09:37] <luks> the parent branch: line
[09:38] <clemente> It refers to the repository. That's bad
[09:38] <luks> perhaps you ran 'bzr pull --remember' with the wrong URL?
[09:39] <luks> it defaults to the location you branched from
[09:39] <clemente> 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] <luks> ah, that would be the problem
[09:41] <clemente> What should I set as parent? It's the branch for lp:bzr
[09:43] <luks> http://bazaar-vcs.org/bzr/bzr.dev/ probably
[09:43] <clemente> So the same as the attribute „checkout of branch“ which „bzr info“ shows
[09:43] <clemente> parent_location == bound_location
[09:45] <clemente> Ok, now it works; a bit slow, but works
[09:46] <clemente> Luckily „bzr missing“ is a lot easier than in Subversion or git
[09:53] <clemente> I have seen the log. What if I want to see a particular diff?
[09:53] <clemente>  bzr diff -r 3647:lp:bzr  ?
[09:54] <luks> I'd use `bzr diff --new :parent`
[09:56] <clemente> That shows nothing
[09:57] <clemente> I want just from „the revision before 3647“ to revision 3647, both in the remote branch
[09:59] <clemente> -r 3647:lp:bzr seems to select more than 1 revision: not only 3647 but also the ones before
[10:05] <clemente> 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] <clemente> Obviously there's something wrong
[10:05] <lifeless> clemente: thats a valid range, yes
[10:06] <clemente> But it's ambiguous
[10:06] <lifeless> how so ?
[10:06] <clemente> You don't always know if .. will be a separator or not
[10:07] <lifeless> thats true, but its possible to look and see :)
[10:07] <lifeless> branch:FOO - FOO is eaten by the parser and returns the unused portion
[10:10] <clemente> Then at „bzr help revisionspec“ it's missing a section about revision ranges. Nowhere it says that .. is the range operator
[10:10] <lifeless> ok, we should fix that
[10:11] <lifeless> anyhow, are you having some problem ?
[10:12] <clemente> I also don't find at that page the way to refer to „the head of the current branch“
[10:12] <lifeless> sorry, I see some unicode glyph there
[10:12] <lifeless> terminal issue
[10:13] <lifeless> "the way to refer to XXXX" - I don't know what XXX is
[10:14] <clemente> ok; without Unicode :-( :   to refer to: the head of the current branch
[10:14] <mwhudson> '-1' usually does that job, if i understand what you're saying
[10:15] <clemente> And then you don't have to specify that you are talking about the local branch?
[10:16] <lifeless> right
[10:16] <lifeless> bzr diff -r -1
[10:16] <lifeless> ==
[10:16] <lifeless> show me changes in the working tree against the branches tip
[10:16] <clemente> That could be also explained in the example in   bzr help revisionspec
[10:17] <lifeless> I agree
[10:18] <clemente> I'd like to fix bugs or improve documentation, but I still don't know how to do it in Bazaar
[10:19] <lifeless> do you ahve a branch of bzr ?
[10:19] <clemente> yes
[10:20] <clemente> I don't have much expertise with English; I don't know if I should write much documentation
[10:20] <lifeless> revision spec help is in bzrlib/revisionspec.py
[10:21] <lifeless> our review pocess will catch english issues
[10:23] <clemente> So I'm allowed to check in the changes even if they're not perfect? To which branch?
[10:23] <lifeless> your own
[10:25] <clemente> Yes. And how can then other developers access my branch? (ssh, http, ...)
[10:25] <clemente> Probably I have to push the branches to Launchpad
[10:26] <lifeless> you can push it to launchpad, or just send in a bundle via email
[10:26] <lifeless> the HACKING document explains the contribution process
[10:27] <clemente> Ok, that's good (and long!), I read it
[11:31] <twb> 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] <twb> bzr checkout --lightweight lp:nxhtml nxhtml
[11:56] <lifeless> twb: fast != small :) - less data locally means more remote access
[11:56] <lifeless> twb: bzr branch --stacked is likely more efficient than checkout --lightweight
[11:57] <twb> lifeless: all I will ever do to this copy is get the initial copy, then pull in updates
[11:57] <twb> Really all I care about is the working tree, and the ability to update it.
[12:00] <lifeless> twb: I appreciate that, nevertheless
[14:03] <AnMaster> $ bzr pull --remember http://rage.kuonet.org/~anmaster/bzr/cfunge
[14:03] <AnMaster> http://rage.kuonet.org/%7Eanmaster/bzr/cfunge is permanently redirected to http://rage.kuonet.org/~anmaster/bzr/cfunge/
[14:03] <AnMaster> that seems odd
[14:03] <AnMaster> anyone can explain it?
[14:06] <twb> %7E is an escaped version of ~
[14:06] <twb> If you use curl -sLI, you get
[14:06] <twb> HTTP/1.1 301 Moved Permanently
[14:06] <twb> Location: http://rage.kuonet.org/~anmaster/bzr/cfunge/
[14:06] <AnMaster> true
[14:07] <AnMaster> but I gave ~ on command line
[14:07] <twb> So what's happening is that the HTTP server is redirecting to include a /
[14:07] <AnMaster> ah
[14:07] <AnMaster> right
[14:07] <twb> And something (bzr) is escaping the ~ just because it can
[14:07] <twb> Probably it's passing through some sort of normal form-izing printer
[14:08] <twb> (I'm just speculating; I don't normally even use bzr.)
[14:08] <twb> So in summary, if you use the trailing slash in your original pull, the notice should disappear
[14:09] <AnMaster> wait this is #bzr right?
[14:09] <lifeless> [
[14:09] <lifeless> AnMaster: yes it is
[14:10] <lifeless> AnMaster: the ~ is because bzr only emits accurate urls, to aid debugging in the event of unusal servers (there are many such :()
[14:10] <AnMaster> hm
[14:10] <AnMaster> ok
[14:10] <lifeless> AnMaster: but we accept things like ~ and normalise them for ease of use
[14:11] <twb> I dunno that using ~ isn't "accurate".
[14:11] <twb> Merely not non-normalized
[14:11] <AnMaster> heh
[14:15] <lifeless> twb: read std66, urls are not defined to be in any encoding
[14:15] <lifeless> twb: it could be in EBCIDIC
[14:16] <lifeless> the recommended encoding is utf8, but servers don't have to follow that
[17:05] <epsy> hi
[17:06] <epsy> 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] <epsy> bzr: ERROR: KnitPackRepository('file:///home/epsy/CODE/armagetron/http-auth-server-bzr/.bzr/repository/')
[17:06] <epsy> is not compatible with
[17:06] <epsy> SvnRepository('https://armagetronad.svn.sourceforge.net/svnroot/armagetronad')
[17:06] <epsy> different rich-root support
[17:09] <clemente> lifeless: by the way, thanks; I just posted my first patch to the mailing list.
[17:16] <clemente> 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] <clemente> But first make a backup of your .bzr/ ...
[17:16] <epsy> clemente, in the svn checkout? Oo
[17:16] <epsy> well, the bzr branch is completely new
[17:17] <epsy> as in, in just typed bzr init
[17:17] <clemente> I don't know... I only knew that because I read it here: https://bugs.launchpad.net/bzr/+bug/206258
[17:17] <epsy> heh
[17:17] <LarstiQ> epsy: the bzr branch needs to have rich root support
[17:18] <LarstiQ> epsy: what does `bzr info` say on the bzr branch?
[17:18] <clemente> So this can work: bzr upgrade --rich-root-pack
[17:18] <epsy> how do i turn that on?
[17:18] <epsy> ok
[17:20] <clemente> 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] <clemente> Oops, I meant 206258
[17:21] <epsy> is it fixed in rc5 ?
[17:21] <epsy> it says fix committed and not fix released
[17:22] <clemente> Ah, ok.
[17:23] <clemente> I think this is important and undangerous for the release...
[17:23] <epsy> how do i show "sub-revisions" with bzr log ?
[17:24] <LarstiQ> epsy: just bzr log. Or --long to be sure it isn't overriden.
[17:24] <epsy> it only shows with bzr log --line
[17:24] <epsy> wait
[17:25] <epsy> negative revision numbers ew..
[17:26] <LarstiQ> hmm?
[17:27] <epsy> $ bzr log --line
[17:27] <epsy> 1: epsy46 2008-08-24 Imported from svn
[17:27] <epsy> 0: epsy 2008-08-15 redirects back
[17:27] <epsy> -1: epsy 2008-08-15 moar typos
[17:27] <epsy> -2: epsy 2008-08-15 fixed bugs typos and turtles
[17:27] <epsy> -3: epsy 2008-08-15 typo
[17:27] <epsy> -4: epsy 2008-08-15 some old stuff i forgot to commit
[17:28] <epsy> [and it goes on]
[17:28] <epsy> (yes, with even more typos :P)
[17:29] <LarstiQ> 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] <epsy> LarstiQ, i was merging from a bzr checkout
[17:29] <epsy> er
[17:29] <epsy> an svn checkout*
[17:29] <epsy> using the svn plugin
[17:30] <LarstiQ> epsy: so where are you running log on?
[17:30] <epsy> the bzr branch
[17:30] <epsy> after merging stuff from the svn one
[17:31] <LarstiQ> did you commit after the merge?
[17:32] <epsy> yes, as i thought it didn't commit anything, as nothing showed up on bzr log without arguments
[17:32] <epsy> 1: epsy46 2008-08-24 Imported from svn
[17:32] <LarstiQ> ok, you certainly aren't using just default bzr )
[17:32] <epsy> ill file a bug to the bzr-svn guys :)
[17:33] <LarstiQ> epsy: bzr-svn also doesn't do that
[17:33] <LarstiQ> epsy: try 'bzr log --long'?
[17:33] <epsy> too late, i started over
[17:33] <epsy> second
[17:33] <LarstiQ> epsy: and check `bzr plugins` for any obvious culprits. If that fails, peek at ~/.bazaar/bazaar.conf for aliases
[17:33] <jelmer> epsy, what's going wrong with bzr-svn?
[17:35] <epsy> jelmer, bzr init --rich-root-pack && bzr merge [some svn checkout] && bzr log --line
[17:35] <jelmer> epsy, what's it not doing right?
[17:36] <epsy> assigning revision numbers, i guess, they show up as negatives
[17:36] <epsy> the last revision being 0
[17:36] <epsy> wait, you need to commit something before it show up
[17:37] <epsy> yeah
[17:37] <epsy> jelmer, bzr init --rich-root-pack && bzr merge [some svn checkout] && bzr ci -m "test123" && bzr log --line
[17:38] <jelmer> epsy, does "bzr log" (without --line) print antyhing sensible?
[17:38] <epsy> nope, it seems that it stops at 1 anyway
[17:39] <epsy> while --line continues as long as there are available revisions
[17:39] <jelmer> epsy, but shows the bzr-svn revisions below revision 1?
[17:39] <epsy> it only shows revision 1
[17:39] <epsy> er
[17:39] <jelmer> epsy, can you put the bzr repo with this bug up somewhere?
[17:39] <epsy> now it calls it revision 34
[17:40] <epsy> well, i could reproduce it over and over
[17:40] <jelmer> I can't, that's why it would be useful to be able to analyse this branch :-)
[17:41] <epsy> 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] <epsy> revisions*
[17:45] <jelmer> 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] <epsy> second
[17:59] <epsy> jelmer, also, what is the expected behaviour? i don't have much experience with merging
[17:59] <jelmer> epsy: "bzr log --line" should just show the revisions on mainline
[17:59] <epsy> [i'm still at packing an example tarball]
[17:59] <jelmer> epsy: so not the merged revisions
[18:01] <epsy> jelmer, is there a way we can somehow track these?
[18:01] <jelmer> epsy: The merged revisions are shown indented when you run "bzr log" (no --line)
[18:02] <epsy> right
[18:43] <epsy> how do i manually choose a merge base revision ?
[18:51] <epsy> oh, right, that's what's before the .. in -r 1..2 :)
[19:14] <jelmer> epsy, any chance of that tarball?
[19:14] <epsy> jelmer, it's taking ages :(
[19:15] <epsy> i would need a not-so-big bzr branch for testing
[19:15] <epsy> gnah
[19:15] <epsy> i mean an svn branch
[19:50] <LarstiQ> epsy: is the svn branch public? Then maybe jelmer could reproduce it locally.
[19:50] <LarstiQ> jelmer: or did you already try that?
[19:51] <jelmer> LarstiQ, he's busy tarring up the bzr branch
[19:51] <jelmer> I doubt this is related to bzr-svn, rather a bug in bzr log --line
[19:53] <LarstiQ> jelmer: right.
[19:54] <LarstiQ> epsy: with the bzr branch you merged the svn checkout into, did it have any revisions before you committed the merge?
[19:55] <LarstiQ> 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] <epsy> LarstiQ, no, this seems to be characteristic
[19:56] <epsy> LarstiQ, i could work around it making an empty commit first
[19:59] <LarstiQ> epsy: ok, let me try to reproduce that with bare bzr.
[20:00] <epsy> i think at some point i could reproduce it with plain bzr stuff, without svn stuff, but i'm not sure anymore
[20:00] <LarstiQ> epsy: yup, thanks, that does it.
[20:01] <epsy> right
[20:01] <epsy> :)
[20:01] <LarstiQ> epsy: so, that explains the negative revnos were we don't expect them. Was there anything else fishy?
[20:01] <LarstiQ> epsy: do you want to file the bug, or shall I do it?
[20:03] <epsy> go for it, i dont think i have much more detail than you
[20:04] <epsy> LarstiQ, the different listing behavoir of normal bzr log and bzr log --line
[20:04] <epsy> 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] <epsy> brb, dinner
[20:07] <LarstiQ> 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] <LarstiQ> epsy: the --long formatting is slightly more involved, but same cause.
[20:57] <jelmer> siretart, ping
[21:18] <siretart> jelmer: pong
[21:19] <jelmer> siretart: Did you have a chance to look at the loggerhead package?
[21:19] <jelmer> siretart, You asked me to ping you about it a couple of days back :-)
[21:25] <siretart> jelmer: yes :) - sorry, no, I had a family party today and was busy the whole weekend with preparations.
[21:26] <siretart> jelmer: I'll look at it tomorrow. btw, have you done some commits since my last comments?
[21:27] <jelmer> siretart, Yeah, I clarified the copyright file slightly
[21:28] <siretart> jelmer: okay, thanks. I'll get to it tomorrow morning
[21:28] <jelmer> siretart, thanks !
[21:53] <Lani78> 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] <Lani78> Is there anything else that I need to do? I've restarted X as well.
[21:55] <Lani78> 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] <Lani78> Anyone awake?
[22:06] <cody-somerville> I am
[22:07] <Lani78> ok :) Hi there, do you know anything about the nautilus extension for bazaar?
[22:10] <jelmer> Lani78, do you have python-nautilus installed?
[22:12] <Lani78> jelmer: I'm not sure if I've done it correctly, I've downloaded bzr-gtk 0.95
[22:12] <Lani78> ﻿I've put the nautilus-bzr.py file in the ~/.nautilus/python-extensions
[22:12] <jelmer> Lani78, you need to install the nautilus support for python bindings as well
[22:13] <Lani78> Ah, ok, I will try that right away!
[22:15] <Lani78> Do I have to restart X then?
[22:15] <jelmer> you'll have to restart nautilus
[22:16] <jelmer> though restarting X will take care of that
[22:16] <Lani78> ok
[22:20] <Lani78> I've got some new menu entries now :)
[22:22] <Lani78> Is it possible to do a checkout from within Nautilus, instead of the command line: "bzr checkout sftp://server/bzr/proj1 dev
[22:22] <Lani78> "
[22:26] <jelmer> I'm not sure if we added an option for that yet
[22:26] <jelmer> if not, please file a wishlist bug
[22:26] <epsy> is there a way i can prevent myself from committing a file, while it still being versionned?
[22:26] <jelmer> epsy, bzr commit has a -x option now
[22:27] <jelmer> (bzr 1.6)
[22:27] <epsy> i mean, permanently
[22:27] <epsy> a bit like .bzrignore
[22:27] <jelmer> why would you want to version it then?
[22:27] <epsy> it's a config file
[22:28] <Lani78> 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] <epsy> and i don't want my passwords and other crap being committed, do i? :)
[22:29] <jelmer> epsy, I would not keep it versioned then
[22:29] <jelmer> instead, just commit foo.conf.example and ignore foo.conf in .bzrignore
[22:29] <epsy> good idea
[22:30] <Lani78> I cannot find any menu entry for checkout
[22:31] <Lani78> 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] <Lani78> I just did a commit now, that went ok.
[22:31] <jelmer> Lani78, if you can't find it where you expect it to be, it's also a flaw :-)
[22:31] <jelmer> lamont, I think it's very possible we don't have a checkout menu entry yet
[22:32] <Lani78> jelmer: I agree ;)
[22:33] <jelmer> Lani78, Any chance you can file a wishlist bug about it?
[22:34] <Lani78> jelmer: sure, I'll do that
[22:34] <Lani78> at launchpad, bzr-gtk, right?
[22:36] <jelmer> Lani78, yep
[22:36] <Lani78> How do I mark it as a "Wishlist"-thing?
[22:37] <Lani78> I can only find "Report a bug"
[22:37] <jelmer> Lani78, Once you've reported it, you can change the importance
[22:37] <Lani78> Ah ok, thanks
[22:43] <Lani78> jelmer: I've filed it now: https://bugs.launchpad.net/bzr-gtk/+bug/260960 but I cannot change the Importance, I guess that only a member of the bzr-gtk crew can do that? I tried to explain it as well as I can, with my very limited knowledge of Bazaar.
[22:44] <jelmer> Lani78, thanks!
[22:44] <jelmer> Lani78, Ah, yeah, that may be. We'll look at fixing that
[22:44] <Lani78> Np, thank you for helping me to get it to work at all :)
[22:55] <Lani78> I'm a bit paranoid when it comes to storing my projects source codes. This might be a very basic question, but how can I be sure that the project has been commited to the server successfully. Can I assume that all went fine if the Nautilus extension doesn't give me an error when I commit?
[22:56] <jelmer> Lani78: yeah
[22:56] <jelmer> Lani78, You can look at the logs of the branch to make sure
[22:56] <Lani78> jelmer: Ah ok, investigating right away ;)
[22:57] <jelmer> Lani78, If there are other things you're missing, please do not hesitate to let us know
[22:57] <Lani78> jelmer: There is, an menu option to see the logs? ;)
[22:58] <jelmer> Yeah, I'm pretty sure there is
[22:58] <Lani78> Or is the "history" the same as the logs?
[22:58] <jelmer> yeah, History sounds about right
[22:59] <Lani78> ok, but how can I be sure that it hasn't just been committed to my local .bzr and that it has gone all the way to my server?
[23:00] <Lani78> jelmer: also, in the "commit" dialog. I would like to see there where my commit is going, so that I can see to what server and what path. Or am I missing something obvious that removes that need?
[23:00] <pygi> Laney, when you commit, you commit locally
[23:01] <pygi> you need to "push" to the repository
[23:01] <jelmer> Lani78, No, that sounds sensible
[23:01]  * Laney eyes pygi 
[23:01]  * Laney points to Lani78 
[23:01] <jelmer> Lani78, any chance you can file a bug about that as well ? :-)
[23:01] <pygi> Lani78, what? xD
[23:01] <jelmer> pygi, Not necessarily; if the branch is bound it goes to the server as well?
[23:01] <pygi> Laney, ah yes, sorry :p
[23:01] <pygi> jelmer, ah, right
[23:01]  * pygi wasn't thinking of that now :p
[23:02] <Lani78> jelmer: sure I can do that ;)
[23:05] <Lani78> Another thing that I would like is to have some sort of "status screen", where you could see if it is a local repository or if it is connected to a remote repository. What other branches that exists on that repository and other useful stuff. But I only have one branch now so maybe this is obvious when you have several branches (I will soon try ;))
[23:10]  * cody-somerville pokes pygi 
[23:10] <pygi> cody-somerville, poke back?
[23:11] <Lani78> https://bugs.launchpad.net/bzr-gtk/+bug/260967
[23:13] <Lani78> I misspelled repository and I cannot find an edit button :P
[23:14] <Lani78> Now I found it :)
[23:15] <Lani78> I'm really curious about the release of the Launchpad source code. I saw an article about that it should be released within 12 month!
[23:22] <Lani78> Another wish/question,  why don't you have ppa repository packages for Hardy Heron for bzr-gtk?
[23:27] <jelmer> re
[23:27] <jelmer> Lani78, Not sure, the ppa is maintained by other people
[23:27]  * jelmer runs Debian :-)
[23:28] <Lani78> ok
[23:29] <Lani78> Do you do all this work in bzr-gtk in your spare time?
[23:33] <Verterok> ls
[23:33] <Verterok> AfC: ping
[23:33] <mwhudson> is Transport.ensure_base fairly new?
[23:34] <lifeless> Lani78: yes, bzr-gtk is a community project
[23:34] <Lani78> lifeless: Ok, That's impressive
[23:36] <Lani78> ﻿How can I make sure that I'm running the correct version of Olive from bzr-gtk? The About dialog doesn't show now. I want to make sure as I'm getting an error when I try to add a new file.
[23:39] <AfC> Verterok: pong
[23:40] <lifeless> Lani78: I would check ~/.bzr.log
[23:40] <Verterok> AfC: Hi, I can't reproduce the segfault (with bzr-svn) in my gentoo box
[23:42] <AfC> Verterok: well, that's good (for you and for bzr-svn) and bad (for me)
[23:42] <AfC> Verterok: thanks very much for trying
[23:42] <Verterok> AfC: installed packages: apr/apr-util 1.3.2, neon  0.28.2 and subversion 1.5.1
[23:42] <AfC> Verterok: same
[23:43] <lifeless> could it be the server?
[23:43] <Verterok> AfC: did you tried a 'revdep-rebuild -p'?
[23:44] <AfC> lifeless: I don't think so - the unit tests fail
[23:44] <AfC> Verterok: can't hurt, checking, but I mean, the stack is pretty tight
[23:46] <Lani78> I had an old version of bzr-gtk installed from the ubuntu repositories at the same time as I manually installed the latest version in another place, I've now removed the old version and everything worked fine :)
[23:46] <Verterok> AfC: also, a USEFLAGS double-check can't hurt :)
[23:47] <AfC> Verterok: yeah, it all seems sane though. We'll see what revdep-rebuild has to say.