mwhudson | epsy: try bzr -Derror rocks | 00:00 |
---|---|---|
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:01 |
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:02 |
epsy | i'll upgrade | 00:03 |
epsy | for that i would need bzr 1.6 right? | 00:13 |
mwhudson | yep | 00:13 |
epsy | alright | 00:14 |
* meteoroid is excited to be the rhel5 x86_64 buildbot host for drizzle (the new mysql) using bzr :) | 02:46 | |
markh | when a test fails we see its trace output - how can I see the same output when the test passes? | 03:32 |
james_w | hi markh, I don't know of a way to do it for tests | 03:35 |
markh | hrmph - oh well, hackery must be done then! | 03:36 |
james_w | markh: actually, there is support for it | 03:37 |
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:38 |
markh | or possibly be_quiet() | 03:39 |
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:40 |
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:42 |
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) | 03:43 |
* AfC is sad that bzr-svn is still segfaulting for him. | 04:00 | |
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:01 |
* 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:02 |
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:03 |
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:04 |
jelmer | Hmm, that's pretty similar to what I have here except that I'm on sid rather than gentoo | 04:05 |
jelmer | Odd_Bloke, ah, all freedom and no sleep ? :-) | 04:07 |
Odd_Bloke | Something very much like that. :D | 04:08 |
Verterok | AfC: I can try to reproduce it (I have a x86 box with Gentoo) | 04:09 |
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:10 |
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:11 |
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:12 |
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:13 |
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:14 |
* 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:15 |
Odd_Bloke | Has anyone looked at packaging PQM? | 04:22 |
Odd_Bloke | jelmer: ^ | 04:22 |
jelmer | Odd_Bloke, yep | 04:23 |
jelmer | Odd_Bloke, let me find the URL | 04:23 |
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:24 |
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:25 |
jelmer | AfC, http://samba.org/~jelmer/tmp/python.supp | 04:27 |
AfC | jelmer: (understood). Thanks. | 04:27 |
jelmer | AfC, It's shipped with Debian, not sure where they get it from though | 04:28 |
AfC | k | 04:29 |
AfC | jelmer: http://rafb.net/p/NmyJzz74.html | 04:31 |
jelmer | AfC, please try again with r1627 | 04:33 |
jelmer | AfC, I've added some extra error checks that may help determine what's going wrong | 04:34 |
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:36 |
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:37 |
AfC | That's exciting | 04:38 |
Odd_Bloke | jelmer: CDBS. D: | 04:40 |
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:45 |
AfC | jelmer: take 2: http://rafb.net/p/zK9p2492.html | 04:47 |
jelmer | AfC, can't think of anything that may be going wrong | 04:51 |
AfC | Still, "Address 0x0 is not stack'd, malloc'd or (recently) free'd" is pretty funny | 04:52 |
* AfC heads out. | 04:53 | |
AfC | jelmer: thanks for looking | 04:53 |
AfC | Without wanting to be negative, /me hopes Verterok reproduces what I am hitting. | 04:54 |
AfC | See ya | 04:54 |
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 | 04:59 |
Odd_Bloke | jelmer: I've found debhelper 7 to be pretty good for trivial packages. | 05:10 |
jelmer | does that deal with setup.py ok? | 05:11 |
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:22 |
Verterok | jelmer: I wasn't able to reproduce AfC's problem with bzr-svn, only 1 test failure | 05:51 |
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. | 06:06 |
clemente | How can I see the changes that would be made if I did a pull? | 09:26 |
mwhudson | 'bzr missing' is a bit like that | 09:27 |
luks | bzr diff --new :parent maybe, not sure | 09:28 |
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:30 |
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:31 |
clemente | Ah, ok, I actually wanted to put the example of Subversion, not git. This works in Subversion: svn log -r BASE:HEAD | 09:34 |
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:35 |
clemente | Well, I am inside a branch inside a repository, and it tries to use the repository as branch; then it fails | 09:36 |
luks | what does `bzr info` says? | 09:37 |
luks | the parent branch: line | 09:37 |
clemente | It refers to the repository. That's bad | 09:38 |
luks | perhaps you ran 'bzr pull --remember' with the wrong URL? | 09:38 |
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:39 |
clemente | What should I set as parent? It's the branch for lp:bzr | 09:41 |
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:43 |
clemente | Ok, now it works; a bit slow, but works | 09:45 |
clemente | Luckily „bzr missing“ is a lot easier than in Subversion or git | 09:46 |
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:53 |
luks | I'd use `bzr diff --new :parent` | 09:54 |
clemente | That shows nothing | 09:56 |
clemente | I want just from „the revision before 3647“ to revision 3647, both in the remote branch | 09:57 |
clemente | -r 3647:lp:bzr seems to select more than 1 revision: not only 3647 but also the ones before | 09:59 |
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:05 |
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:06 |
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:07 |
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:10 |
lifeless | anyhow, are you having some problem ? | 10:11 |
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:12 |
lifeless | "the way to refer to XXXX" - I don't know what XXX is | 10:13 |
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:14 |
clemente | And then you don't have to specify that you are talking about the local branch? | 10:15 |
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:16 |
lifeless | I agree | 10:17 |
clemente | I'd like to fix bugs or improve documentation, but I still don't know how to do it in Bazaar | 10:18 |
lifeless | do you ahve a branch of bzr ? | 10:19 |
clemente | yes | 10:19 |
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:20 |
lifeless | our review pocess will catch english issues | 10:21 |
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:23 |
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:25 |
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:26 |
clemente | Ok, that's good (and long!), I read it | 10:27 |
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:31 |
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:56 |
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. | 11:57 |
lifeless | twb: I appreciate that, nevertheless | 12:00 |
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:03 |
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:06 |
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:07 |
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:08 |
AnMaster | wait this is #bzr right? | 14:09 |
lifeless | [ | 14:09 |
lifeless | AnMaster: yes it is | 14:09 |
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:10 |
twb | I dunno that using ~ isn't "accurate". | 14:11 |
twb | Merely not non-normalized | 14:11 |
AnMaster | heh | 14:11 |
lifeless | twb: read std66, urls are not defined to be in any encoding | 14:15 |
lifeless | twb: it could be in EBCIDIC | 14:15 |
lifeless | the recommended encoding is utf8, but servers don't have to follow that | 14:16 |
=== jaypipes-afk is now known as jaypipes | ||
epsy | hi | 17:05 |
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:06 |
clemente | lifeless: by the way, thanks; I just posted my first patch to the mailing list. | 17:09 |
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:16 |
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 |
ubottu | Launchpad bug 206258 in bzr "incompatible repository error messages are unhelpful" [Medium,Fix committed] | 17:17 |
epsy | heh | 17:17 |
LarstiQ | epsy: the bzr branch needs to have rich root support | 17:17 |
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:18 |
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 |
ubottu | 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 |
clemente | Oops, I meant 206258 | 17:20 |
epsy | is it fixed in rc5 ? | 17:21 |
epsy | it says fix committed and not fix released | 17:21 |
clemente | Ah, ok. | 17:22 |
clemente | I think this is important and undangerous for the release... | 17:23 |
epsy | how do i show "sub-revisions" with bzr log ? | 17:23 |
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:24 |
epsy | negative revision numbers ew.. | 17:25 |
LarstiQ | hmm? | 17:26 |
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:27 |
epsy | [and it goes on] | 17:28 |
epsy | (yes, with even more typos :P) | 17:28 |
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:29 |
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:30 |
LarstiQ | did you commit after the merge? | 17:31 |
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:32 |
=== fta_ is now known as fta | ||
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:33 |
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:35 |
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:36 |
epsy | yeah | 17:37 |
epsy | jelmer, bzr init --rich-root-pack && bzr merge [some svn checkout] && bzr ci -m "test123" && bzr log --line | 17:37 |
jelmer | epsy, does "bzr log" (without --line) print antyhing sensible? | 17:38 |
epsy | nope, it seems that it stops at 1 anyway | 17:38 |
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:39 |
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:40 |
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:41 |
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:45 |
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 | 17:59 |
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:01 |
epsy | right | 18:02 |
epsy | how do i manually choose a merge base revision ? | 18:43 |
epsy | oh, right, that's what's before the .. in -r 1..2 :) | 18:51 |
=== emgent is now known as emgent` | ||
jelmer | epsy, any chance of that tarball? | 19:14 |
epsy | jelmer, it's taking ages :( | 19:14 |
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:15 |
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:50 |
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:51 |
LarstiQ | jelmer: right. | 19:53 |
LarstiQ | epsy: with the bzr branch you merged the svn checkout into, did it have any revisions before you committed the merge? | 19:54 |
=== mark1 is now known as markh | ||
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:55 |
epsy | LarstiQ, i could work around it making an empty commit first | 19:56 |
LarstiQ | epsy: ok, let me try to reproduce that with bare bzr. | 19:59 |
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:00 |
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:01 |
epsy | go for it, i dont think i have much more detail than you | 20:03 |
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:04 |
epsy | brb, dinner | 20:05 |
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:07 |
jelmer | siretart, ping | 20:57 |
siretart | jelmer: pong | 21:18 |
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:19 |
siretart | jelmer: yes :) - sorry, no, I had a family party today and was busy the whole weekend with preparations. | 21:25 |
siretart | jelmer: I'll look at it tomorrow. btw, have you done some commits since my last comments? | 21:26 |
jelmer | siretart, Yeah, I clarified the copyright file slightly | 21:27 |
siretart | jelmer: okay, thanks. I'll get to it tomorrow morning | 21:28 |
jelmer | siretart, thanks ! | 21:28 |
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:53 |
Lani78 | Is there anything else that I need to do? I've restarted X as well. | 21:54 |
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? | 21:55 |
Lani78 | Anyone awake? | 22:01 |
cody-somerville | I am | 22:06 |
Lani78 | ok :) Hi there, do you know anything about the nautilus extension for bazaar? | 22:07 |
jelmer | Lani78, do you have python-nautilus installed? | 22:10 |
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:12 |
Lani78 | Ah, ok, I will try that right away! | 22:13 |
Lani78 | Do I have to restart X then? | 22:15 |
jelmer | you'll have to restart nautilus | 22:15 |
jelmer | though restarting X will take care of that | 22:16 |
Lani78 | ok | 22:16 |
Lani78 | I've got some new menu entries now :) | 22:20 |
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:22 |
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:26 |
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:27 |
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:28 |
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:29 |
Lani78 | I cannot find any menu entry for checkout | 22:30 |
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:31 |
Lani78 | jelmer: I agree ;) | 22:32 |
jelmer | Lani78, Any chance you can file a wishlist bug about it? | 22:33 |
Lani78 | jelmer: sure, I'll do that | 22:34 |
Lani78 | at launchpad, bzr-gtk, right? | 22:34 |
jelmer | Lani78, yep | 22:36 |
Lani78 | How do I mark it as a "Wishlist"-thing? | 22:36 |
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:37 |
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:43 |
ubottu | Launchpad bug 260960 in bzr-gtk "The Nautilus extension should have a "checkout" command." [Undecided,New] | 22:43 |
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:44 |
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:55 |
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:56 |
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:57 |
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:58 |
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? | 22:59 |
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:00 |
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:01 | |
Lani78 | jelmer: sure I can do that ;) | 23:02 |
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:05 |
* cody-somerville pokes pygi | 23:10 | |
pygi | cody-somerville, poke back? | 23:10 |
Lani78 | https://bugs.launchpad.net/bzr-gtk/+bug/260967 | 23:11 |
ubottu | Launchpad bug 260967 in bzr-gtk "Add repositrory information to the commit dialog in the Nautilus extension" [Undecided,New] | 23:11 |
Lani78 | I misspelled repository and I cannot find an edit button :P | 23:13 |
Lani78 | Now I found it :) | 23:14 |
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:15 |
Lani78 | Another wish/question, why don't you have ppa repository packages for Hardy Heron for bzr-gtk? | 23:22 |
jelmer | re | 23:27 |
jelmer | Lani78, Not sure, the ppa is maintained by other people | 23:27 |
* jelmer runs Debian :-) | 23:27 | |
Lani78 | ok | 23:28 |
Lani78 | Do you do all this work in bzr-gtk in your spare time? | 23:29 |
Verterok | ls | 23:33 |
Verterok | AfC: ping | 23:33 |
mwhudson | is Transport.ensure_base fairly new? | 23:33 |
lifeless | Lani78: yes, bzr-gtk is a community project | 23:34 |
Lani78 | lifeless: Ok, That's impressive | 23:34 |
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:36 |
=== mario_ is now known as pygi | ||
AfC | Verterok: pong | 23:39 |
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:40 |
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:42 |
lifeless | could it be the server? | 23:43 |
Verterok | AfC: did you tried a 'revdep-rebuild -p'? | 23:43 |
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:44 |
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:46 |
AfC | Verterok: yeah, it all seems sane though. We'll see what revdep-rebuild has to say. | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!