[01:24] hi all === poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie [07:57] hi all ! [07:58] * fullermd gives vila a sickly wave. [07:58] hoo [07:58] or ooh ? [07:59] Today, it's more like 'ow' :| [07:59] ha right, this one [08:20] vila: oh hai [08:24] _o/ [08:45] maxb: gentle nudge about 2.3.1 in ppas, any news ? [08:46] hi [08:47] vila: I've attempt to write up the small doc for shared repo stuff using bzr+ssh. [08:47] vila: how do I now do the next parts to make it a merge candidate? [08:47] there's this dh_python2 packaging migration that is somewhat blocking [08:48] mr-russ: push a branch on launchpad and propose it for merging (bzr push ; bzr lp-open) [08:49] maxb: not for all ubuntu versions I hope ? [08:49] all but natty [08:50] vila: sorry I'm a real noob here. push to? the bzr trunk, or somewhere else. [08:50] maxb: ok, I'm lost, where should I look to learn more ? [08:51] mr-russ: push to launchpad: bzr push lp~/bzr/ [08:51] grrlp*:* [08:51] shudder [08:52] mr-russ: push to launchpad: bzr push lp:~/bzr/ [08:52] vila: my/jelmer's brain? [08:52] maxb: ok, downloading right now [08:52] :) [08:52] * mr-russ waits for upload [08:53] maxb: I've missed some episodes, what's the intent of dh_python2 and why does it matter ? [08:54] basically the debian unstable packagings have all shifted to track a major change in python packaging system [08:54] and now we need to figure out the best way to backport stuff [08:55] but why does it impact more than natty ? [08:55] (and even natty for that matter >-/) [08:56] because we used to reuse sid packaging across all distroseries [08:57] and why don't we postpone that to after 2.3.1 ? [09:04] vila: Hi, sorry, lost phone reception as I entered my office block [09:05] So, the thing is that in the past we have just re-used sid packagings unmodified [09:05] So, we either solve the migration question first and continue to do so [09:05] Or, we just independently update the 2.3.0 ppa packaging to 2.3.1 [09:06] granted, perhaps we should do the latter, as a pragmatic solution to getting 2.3.1 packages out in the PPAs on time [09:07] maxb: +1 :) [09:08] o:) even [09:48] meh, bug #654733 regressed on FreeBSD 8-/ [09:48] Launchpad bug 654733 in Bazaar "bp.launchpad.test_register.TestBranchRegistration.test_onto_transport tests fail on Python 2.7" [High,Fix released] https://launchpad.net/bugs/654733 [09:49] It turns out the natty xmlrpclib.py carries an additional patch [09:49] Where should I search to identify this patch and its rationale ? [09:50] http://paste.ubuntu.com/580061/ [09:53] How purdy. [09:53] Purdy, MO (city, FIPS 60176) [09:53] Location: 36.81846 N, 93.92068 W [09:54] shudder [09:55] ok, it's part of https://launchpad.net/ubuntu/natty/+source/python2.7/2.7.1-5/+files/python2.7_2.7.1-5.diff.gz but not part of lp:ubuntu/natty/python2.7 8-/ [09:56] Is that just a test failure, or something broader? [09:58] fullermd: only a test failure and due to some test fake object and a patch is on its way, but still, I'd like to understand what happened there (probably for reasons similar to the ones behind your question ;) [09:59] fullermd: don't let that make your blood boil ;) [10:02] jelmer: do you know, will jam be around today? [10:02] Oh, I won't. This is why I tricked you into going py27 before me :p [10:03] * vila restore freebsd8 slave backup and forgot about the issue ;) [10:03] fullermd: naaah, evrything went well except for that glitch [10:04] Hm. Funnily enough, I just came across a commit disabling the py-yolk package due to possibly the same thing. [10:04] http://psf.upfronthosting.co.za/roundup/tracker/issue8194 [10:05] So it looks like that patch is in upstream for some future release. Doesn't help the releases already out, ghouh. [10:05] Or though, even. Eye khan tipe. [10:07] right, thanks fullermd, that answer my question about the rationale [10:08] and that ^ answers lifeless question ;) [10:09] lifeless: there he is :) [10:09] lifeless: care to share this summoning trick ? [10:09] jam1: hi === jam1 is now known as jam [10:09] hi lifeless [10:09] jam1: that loggerhead bug - in the lp qa queue - can we test that remotely ? [10:10] lifeless: I think so [10:10] https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html (good morning) [10:10] I don't know how to tell if qastaging gets a loggerhead oops [10:10] but any HEAD request would trigger it [10:10] if HEAD qastaging.../changes doesn't generate an oops, then we're good [10:10] I don't know how the apache proxy figures in, but I think we'd still get a 500 if it failed [10:10] jam: care to give it a spin ? [10:11] lifeless: do you know that qastaging has the newer loggerhead? [10:11] yes [10:11] well, newer launchpad wrapping of loggerhead [10:11] its in the report [10:11] which means its autodeployed [10:13] lifeless: on qastaging I'm just getting the "infinite redirect bug" [10:14] foo/bar/changes redirects to foo/bar/changes [10:14] can't test loggerhead there, I believe [10:14] I don't remember exactly why [10:14] argh [10:14] uhm [10:14] do you think this could make things worse ? [10:14] lifeless: I'm pretty confident on the patch, since I was able to reproduce it locally. [10:14] And in the immediate term, [10:15] mthaddon switched us to using GET anyway [10:15] jam: mark it qa-untestable then [10:15] lifeless: If you tell me when its deployed, I can qa it then [10:15] sure, but for now ... need to fill in the paper work :) [10:15] lifeless: marked [10:17] fullermd: 2.7 is the official default now right ? [10:19] _PYTHON_PORTBRANCH=.. 2.7 [10:19] _PYTHON_DEFAULT_VERSION=. ${_PYTHON_PORTBRANCH} [10:19] fullermd: thanks [10:21] (post-8.2/7.4) [10:23] fullermd: EPARSE, does this mean the change is part of an as-yet-unreleased version ? [10:23] fullermd: or did I just expose my ignorance again ? [10:23] Mmm. Culture gap. [10:24] There's a tarball of ports on the CD/DVD/etc you grab to install $VERSION, which is roughly enough just a snapshot of the point in time "somewhere around" when the release was cut. [10:25] The default was changed after those snaps for 8.2/7.4. But the default has to do with _ports_, not the OS release, so if you e.g. updated the ports tree after your 8.2 install before installing stuff, you'd get 2.7 default. [10:26] But whatever you build builds against whatever you have installed, so if you installed bzr right away, it would go with the prior default (2.6). And after updating ports, you'd keep using 2.6 for stuff until you switched it around. [10:26] (special cases aside of course, like programs that require 2.7 would refuse to build) [10:26] ok, right, so the parallel with Ubuntu would be that this is part of -update (IIUC) which is official enough for me (especially since this means the test failure can't be triggered except on unlucky setups) [10:27] So you can't say "FreeBSD X.Y uses version Z" really, just "As of X.Y, the default was Z". [10:27] * vila nods [10:27] Well, who runs tests anyway? :p [10:27] hehe, babune does [10:28] Probably most installs out there are 2.6 now. That'll tip over the next few months, probably. I don't have a general feel for how quickly the change will be followed by existing installs. [10:28] I've still got perl 5.8 on my system here frex (that way I don't accidentally write code requiring a later version) [10:29] right, so switching to 2.7 on babune sounds still valid (and was triggered by a need to install sphinx anyway which I will do once I've finished sorting out this glitch) [10:29] * fullermd nods. [11:15] hmm [11:22] jelmer: who usually reviews your dulwich patches? I'm surprised to see it addressed to "vcs-imports" [11:23] jam: If they're possibly controversial I usually send them to the dulwich-users@ mailing list for review so people can speak up if they object [11:24] jam: I was submitting them as LP merge reviews as well so I wouldn't lose track of the ones I had submitted, I hadn't considered that that would result in email for ~vcs-imports members.. [11:24] jelmer: I'm perfectly capable of ignoring them, I just haven't seen them before [11:25] jam: Perhaps I should unsubscribe ~vcs-imports from lp:dulwich [11:25] and wasn't sure what you were asking [11:25] well, if you're wondering about reviews... ;-) [11:26] hi jam, jelmer, vila [11:26] hi poolie [11:26] 'evening poolie [11:26] welcome back :) [11:26] poolie: eerk, don't start too strong after your vacations ! It's nice to see you but I'd like to see you for long ! ;D [11:30] jelmer: in your export tar revisit, you mention fixing bug #102234, but when I test it manually using bzr.dev, I don't see the extra dir [11:30] Launchpad bug 102234 in Bazaar "bzr export embeds the tarfile path; causes problems with 7zip" [Low,In progress] https://launchpad.net/bugs/102234 [11:32] vila, hi :) [11:32] jelmer: also, AIUI, XZ != LZMA, though I have to poke through your details [11:32] poolie: nice to see you back, our vacations overlapped and we didn't met since... like.. a month ? :D [11:32] they have the same underlying compression, but different framing [11:34] jam: Newer versions of python already take the base dir name [11:34] jam: thanks for the review ! [11:35] jelmer: so it is just a different python version that we are working around? [11:35] i'd like to just pull out the xmlrpc stuff [11:35] inbox 0! [11:36] jam: yeah [11:36] poolie: not bad after 2 (non consecutive) weeks of vacation [11:36] jam: It seemed easy enough to do (and add a test for) [11:36] a big select and discard? [11:36] poolie: inbox 0 ! wow, congrats ! [11:37] of course, poolie, didn't review all of jelmer's pending changes, either. So clearly he skipped *some* parts of his inbox :) [11:38] poolie: by the way, it would be awesome if you could push a bit on the SRU[s] [11:38] jam: lzma/xz is a good point, I'll dig deeper.. [11:39] jelmer: why did you indirect from "ie.symlink_target" to "tree.get_symlink_target()", for RevisionTree, etc, it is extra overhead for sure (since it then has to look up the InventoryEntry by file_id, and return the value you have) [11:39] jam: It means you can directly export from a working tree [11:40] I noticed that it otherwise wouldn't work (also for ie.text_size) when writing tests. [11:40] jelmer: http://news.softpedia.com/news/Introducing-LZMA-and-XZ-Compression-Algorithms-124883.shtml [11:40] I believe [11:41] looks like I was slightly rwong [11:41] wrong [11:41] XZ is, indeed, a new format entirely [11:41] but seems able to understand lzma streams [11:42] The strange thing is that "file" reports the .tar.lzma streams we're generating as being XZ [11:43] jam: I guess we should strictly change it to .tar.lzma, or at least add that to the list of extensions [11:45] jelmer: yeah, and it looks like no chance to get XZ in 2.X http://bugs.python.org/issue6715 [11:45] since it missed 2.7, it won't be in any 2.x release [11:45] jam: I'm using an external lzma module with xz support so that shouldn't be an issue [11:46] jelmer: XZ? or lzma ? [11:46] jam: the lzma module has an option to force xz or lzma [11:47] I looked into lzma quite a bit when we were doing the groupcompress work. Looking here: http://stephane.lesimple.fr/wiki/blog/lzop_vs_compress_vs_gzip_vs_bzip2_vs_lzma_vs_lzma2-xz_benchmark_reloaded [11:47] I'm reminded why we chose to skip it. [11:47] The knee on the "time to compress" curve is huge for lzma [11:48] bzip2 is "slow" at 22s to compress. [11:48] jam :) i'm going to do some code reviews separately from email [11:48] lzma and xz default compression is 100s [11:48] i still have some mail that needs action [11:48] and i also have SRUs on my list [11:48] poolie: does that count as inbox 0? I can certainly file all my "unread" mail into other folders... [11:50] jam: updated to include .tar.lzma support [11:53] jam: the original patch was correct in that the default from the lzma python module is strangely enough to use xz compression [11:53] everything's been scanned and i have an idea what i need to still deal with [11:53] jelmer: I would expect that depends highly on the version of the module [11:53] i think that's the original definition [11:53] jam: I'm forcing the format now [11:54] jelmer: I'm a little concerned about external dependency, but not critical. Certainly we aren't going to implement it ourselves :) [11:54] poolie: I use this definition roughly too (inbox is really unsorted mail for me) [11:55] jam: We'll raise DependencyNotPresent if the user doesn't have it installed, and we won't attempt to use it unless the user explicitly asks for a .tar.xz/.tar.lzma tarball. [11:57] jam: I guess it could live in a plugin, but that seems too much trouble for something that's only rougly 20 actual lines of code :) [11:57] jelmer: yeah, not a big deal [11:57] as you say, it is isolated to being pretty optional [11:58] and probably just gives a Recommends sort of flag [11:58] (or even Suggests?) [11:58] Suggests seems most appropriate at the moment, perhaps Recommends if .tar.xz becomes much more popular. [12:00] Since Recommends are installed by default on modern Debian/Ubuntu systems I'm hesitant to add every optional dependency to it. [12:00] In the past we had bzr Recommend bzrtools and bzrtools recommend graphviz and graphviz depending on some X libraries. Which meant that installing bzr on a server pulled in some X libraries. [12:01] jelmer: yeah, I remember [12:01] Hm. bzr info now blows up on weave_fmt stuff :| [12:01] fullermd: definitely jelmer's fault, and something that should be fixed [12:02] jelmer: for export-to-stdout, I'd rather use pure relative paths than "-/" [12:02] is it hard to change? [12:02] (so "export -" would create a file with all files rooted at '.') [12:03] fullermd: I think my "misc" branch should fix that, it's some confusing interaction with imports. [12:03] fullermd: it's in the PQM queue [12:03] How do we not have a test that caught that? [12:04] fullermd: it's the order in which the imports happen, the testsuite loads all formats first [12:04] Even for blackbox's? [12:05] fullermd: most things are "run_bzr" which runs in-process [12:05] jam: That seems reasonable. My only concern is that tarballs without a root folder can be pretty annoying to unpack if you don't create a separate directory before unpacking. [12:05] Ah. That makes sense. [12:05] a few things are "run_bzr_subprocess" but we avoid them because they are *very slow* [12:05] jam: Not sure how much of a concern that is. [12:05] Using "-" is also certainly not very nice. [12:05] jelmer: I agree, but people should use a root, or pass a path [12:05] -/ is just ugly [12:05] Yeah. If they were all that, it would take too forkin' long. [12:06] :) [12:06] jam: Perhaps we can change "-" to "." and print a warning? [12:08] jelmer: I don't see a need to warn. I don't really know why people want to export to '-',but if they do, they get what they asked for [12:08] I don't think anyone doing it is asking for '-/' [12:09] jam: I agree "-" is wrong, but as somebody who has once overwritten half his home folder by unpacking a dodgy tarball I feel inclined to warn when not using a root dirname... [12:10] jelmer: from my experience, it is very common in the Zip world [12:10] jelmer: Yes, it seems fixed now. [12:10] such that by default, Windows extracts into a directory named by the zip name [12:10] (so "proper" zip files get extracted to foo/foo/files) [12:12] jam: urgh [12:13] jelmer: I'm not really against a warning, especially because tarball etiquette specifies one [12:13] but I don't really want to say stuff if I think people won't listen to it [12:14] jam: fair enough [12:16] jam: I'd be happy to leave it without a warning for now, since this is a fairly unusual use case anyway and if it's not uncommon in the zip world. [12:18] general question for the audience. what is the best way to test that work *isn't* done? [12:19] (I have a query that starts at the tip, and should only process, 20 items and return them. How do I tell that the next 20 weren't touched?) [12:19] jam: updated to default the root to '' if dest is '.' [12:20] jelmer: does that make it "/" ? which would probably be worse than "./" [12:20] (though I'm pretty sure tar strips that by default) [12:20] jam: No, there are tests that check the paths. [12:29] jam: assert something about the count of items examined, or the identities of items examined, or lay booby traps on items that should not be examined... [12:30] hey spiv. Yeah, I was thinking some sort of booby traps [12:30] I'm reminded of tests that hook the hpss client and then assert things about self.hpss_calls [12:30] problem is injecting booby traps in Branch history [12:30] (this is loggerhead code) [12:31] jam: oh, that's easy, just put the unwanted history in a stacked-on repo that isn't accessible ; [12:31] ;) [12:32] spiv: isn't it almost midnight there? [12:32] * spiv goes to bed before he thinks of a really silly idea [12:32] (yes) [12:32] sleep well, sir, good to see you around [12:44] jam, hey, I'm Jasper, what exactly do you want for tests? [12:44] For the redirects, that is. [12:45] magcius: for the redirect stuff, a test that what is really a file under /files redirects to /view, and the reverse for accessing a dir under /view [12:45] basically, just a rough test that the change really does what you want [12:45] probably can put it in test_simple.py [12:46] jam, will it give me a mock inventory? [12:46] though I'll note "setUpLoggerhead()" defaults to using HTTPExceptionHandler. It might be easier to not use it, and just catch the exception in an "assertRaises". [12:46] magcius: you can use "self.createBranch" and "self.build_tree()" to create a real one. [12:47] OK. [12:47] actually, it fits better in "test_controllers" [12:57] vila: wrong ping channel :). [13:02] jelmer, thanks for your export branch, it looks like exactly what I was needing :) [13:07] jam: Thanks for the review! [13:07] jelmer: not, I caught "assert" late. [13:08] jam: I was literally about to press "e" [13:08] note [13:08] jam: this is the assert in bzrlib.export.tar_exporter ? [13:09] jelmer: I believe so. PQM would catch it, but you don't have to wait for it :) [13:09] bzr selftest -s bt.test_source [13:10] jam: perhaps I should just kill the assertion, lzma itself also checks that the format is supported. [13:11] jelmer: however you like [13:11] just letting you know you can't submit it like it is :) [13:12] jam, how do I run tests? [13:14] magcius: bzr selftest -s bp.loggerhead will run all loggerhead tests [13:14] jam, Ran 0 tests in 0.000s [13:15] magcius: do you have loggerhead installed as a bzr plugin? [13:15] not sure [13:15] how can I do that? [13:15] magcius: cd ~/.bazaar/plugins [13:15] ln -s $LOGGERHEAD_DIR loggerhead [13:15] and? [13:15] aha [13:21] jam, when building the test: ValueError: cannot get null revision inventory [13:22] self.createBranch(); self.build_tree(('file', 'folder/', 'folder/file')) [13:22] magcius: you need a "tree.commit()" in there [13:22] after build tree [13:22] you probably also need to tree.add [13:22] if you look at TestInventoryUI [13:22] there should be some hints there [13:25] aha, thanks [14:07] jam: the mtime argument to gzip.GzipFile is only available on Python >= 2.7. [14:07] jam: Does this look reasonable: http://bazaar.launchpad.net/~jelmer/bzr/export-tgz-711226/revision/5740 [14:08] The other options are to check sys.version or to use the inspect module [14:15] jelmer: if you want to be evil, you could override time.time() for the __init__ timeframe [14:16] or we could overrride GzipFile._write_gzip_header [14:16] jam: I'm fine with just doing the right thing on Python 2.7 [14:16] I'm also never quite sure when python raises TypeError vs AttributeError [14:16] jelmer: most people who want that functionality want in on py2.6 [14:16] still the default in natty [14:17] I believe [14:17] jam: they won't get this new bzr until oneiric though [14:17] though I guess if we don't patch GzipFile or time.time we should at least mention this in the release notes [14:17] Unless they use the ~bzr PPA [14:18] jelmer: right, the patch notes would be "support fixed tar.gz on Python2.7 which exposes 'mtime'" or somesuch === james_w` is now known as james_w [15:14] jam: is there a particular reason CHKSerializer uses XML for inventory serialization? Just because that infrastructure was already in place? [15:14] jelmer: for bundle transmission, IIRC [15:14] ideally, we wouldn't need it [15:15] at one point we used it for transmitting it for conversions [15:15] but spiv fixed it to use an inventory delta instead [15:15] jam: is there something CHK-based that might work for bundles? [15:16] jelmer: well, not without reworking bundles [15:16] arguably the ideal would be to treat a bundle as a branch stacked on a hypothetical repo that has restricted availability ,and then we would use it as a StreamSink [15:16] so the data would be similar to what we would otherwise transmit [15:17] jam: hmm, that does sound nice [15:17] jelmer: the other big win, is that on the other side you can treat it as a StreamSource [15:18] jelmer: doh, I dunno what happened with bug #731240 (probably some double edit with different UIs), but thanks for setting it straight ;D [15:18] Launchpad bug 731240 in Bazaar "opening over http in dumb mode fails in selftest" [Low,Fix released] https://launchpad.net/bugs/731240 [15:18] vila: least I could do after you've been fixing Triaged bugs for me for the last two months ;-) [15:19] jelmer: hehe, tha's what made me laugh after the initial "Huh ? Didn't fix a similar bug recently" when receiving the mail and thinking it was a new one ;) === zyga is now known as zyga-ill [15:31] hello, i have unneeded binary files in my past revisions. is there any way to clean the repository ? [15:40] tacone: Unfortunately not, unless you are willing to rewrite the the entire history in a way which will break the ability to do merges between the new and the old incarnations [15:40] :-( [15:40] thanks :) [15:40] If this is acceptable to you, the fastimport plugin and fast-import-filter would be what you would need [15:40] uhm ? [15:41] If you did want to perform the kind of rewriting that I was implying, the 'bzr-fastimport' plugin, and its "bzr fast-import-filter" command would be the tools you would need to look at [15:42] ok [15:42] i'm looking it up right now. thanks ! === deryck is now known as deryck[lunch] [16:26] maxb: Just submitted debian bug 618349 with patch [16:26] Debian bug 618349 in python-configobj "python-configobj: ConfigObj writes out the wrong kind of triple quotes" [Normal,Open] http://bugs.debian.org/618349 === deryck[lunch] is now known as deryck [19:03] How can I get bzr to output progress information when cloning in a non-interactive shell? [19:15] When I commit to my bzr branch, it automatically pushes to an svn branch. That's not what I want, and I have no idea how I got there [19:15] how do I get it to do local commits? [19:15] "bzr unbind" claims it's not a bound branch [19:36] PenguinOfDoom: is it a checkout perhaps? [19:36] hunger: I don't think there is any way to do that - how would you want to get that information, anyway? [19:37] jelmer: I don't think it's a checkout, but how do I tell? [19:37] (I think it's a branch in a shared repository) [19:39] PenguinOfDoom: bzr info will tel you [19:39] *tell [19:39] Hi, I am using bzr for development of websites, and I have created a clone by using the branch command. Now I have continued to work on the main and I want to re-branch those changes (as I have not done any changes to the branch). Is this possible? or shall I just delete the old branch and re-clone the solution again? [19:40] jelmer: bzr info doesn't mention anything about the branch being a checkout [19:40] PenguinOfDoom: what does it say about the format? "Standalone branch" / "Shared repository branch" / etc ? [19:41] http://pastebin.com/H6FZx7Jh [19:41] trond-: I'm not sure if I understand what you mean exactly, but I think "bzr pull" from the main branch should do what you need [19:42] jelmer, ok. So I'll be in the branch-directory/job and bzr pull then? [19:42] trond-: depending on what branch-directory/job is, yes [19:42] PenguinOfDoom: I'm pretty sure that shouldn't push if you commit [19:43] jelmer: I know that it shouldn't, but it does. [19:43] PenguinOfDoom: it should only do so if you explicitly run push or pull [19:43] ehm, just push I mean [19:44] PenguinOfDoom: does "bzr config" mention a bound branch? [19:44] There's no such command. I'm using bzr 2.2.1 from maverick [19:45] PenguinOfDoom: in that case, does "grep bound ~/.bazaar/bazaar.conf ~/.bazaar/locations.conf .bzr/branch/branch.conf" return anything ? [19:46] Nope! branch.conf has three lines, parent_location, push_location and submit_location [19:48] I'm at a loss then, sorry. :-/ [19:49] derp [19:49] are you sure the branch wasn't bound earlier and unbound now? [19:49] is there any reference to the location it pushed to anywhere? [19:49] do you have a plugin that autopushes or something that installed perhaps? [19:50] It autopushes to the push location. I didn't install any such plugin on purpose [19:50] also, I deleted branch.conf and now it doesn't push any more maybe [19:51] PenguinOfDoom: how did you originally create the branch? [19:52] I created it in svn with "svn cp", then did a "bzr branch svn+ssh://svn.twistedmatrix.com/svn/Twisted/branches/iocp-tcp-large-write-3233-2" locally [19:52] jelmer, yup pull seemed to work. Had some conflicts, but I believe I have resolved those. Thanks for the help.. [20:00] is there a way to use bzr-svn with a repository in which I have permission for a subdirectory, but not for the root? [20:00] denys: only with newer versions of bzr-svn, and if you disable the cache and manually specify the repository layout [20:01] I am using lp:bzr-svn so I guess I just need to tweek some configuration stuff [20:04] denys: yeah, disable the configuration and set the repository layout [20:05] *should* do it [20:12] jelmer: I found some info on layout in bzr help svn-layout, but nothing about "disabling the cache". could you give me a small clue where to look? [20:12] denys: set "use-cache = False" in the relevant entry in ~/.bazaar/subversion.conf [20:13] jelmer: thank you [20:16] jelmer: bzr-builddeb looks to be a bit broken in sid, missing the upstream/ dir :( [20:17] ajmitch: Urgh, that's what we get for running the testsuite from the source directory. Sorry, will fix. [20:18] eventually the BTS will get my mail about it [20:20] hi, I'm a web developer, I'm developing in php and I want to keep track of my sources, I'm thinking to have a working copy and to use bzr to verions it, then backup the repository on a usb disk and on dropbox, what's the best way to achieve this? there is an example somewhere? [20:23] coreGrl: you should be able to simply "bzr push" to the locations where you would like a copy of your history to be [20:23] coreGrl: if you'd like to upload a copy of your files without the history to the web server, have a look at the bzr-upload plugin [20:24] jelmer, there is documentation about this scenario? [20:26] coreGrl: there is documentation about the individual uses of bzr push and bzr upload, though not on this scenario specifically. A couple of common use cases are explained in the user guide @ http://doc.bazaar.canonical.com/latest/en/user-guide/index.html [20:30] tanx jelmer [21:30] hi all [22:08] ajmitch: any chance you could add a changelog entry referencing the LP and debian bugs? [22:08] sure [22:08] version it as 2.7.2? [22:08] ajmitch: seems reasonable [22:13] jelmer: pushed, you'll want to tweak it before uploading I think [22:16] ajmitch: \o/ [22:30] Hey, bzr is broken some more, again, continuously, http://buildbot.twistedmatrix.com/builders/lucid64-py2.6-select/builds/674/steps/bzr/logs/stdio [22:30] Sorry, it's really bzr-svn I guess [22:30] but in my rage I am not sure if I can reliably distinguish between them [22:30] :/ [22:30] I am going to switch to git I think [22:30] can you get the backtrace out of there? [22:30] or set -Derror when running it? [22:32] Here's the crash log file, http://twistedmatrix.com/~exarkun/bzr-20110314212803-3315.crash [22:32] oops, permissions [22:32] okay, fixed [22:33] exarkun: that's bzr-svn [22:33] a permissions problem gave you a keyerror? [22:33] 'morning poolie [22:33] no, sorry, the permission problem was on the log file I uploaded to my website :) [22:34] I don't know what caused the bzr-svn problem [22:34] hi jelmer [22:35] exarkun: the quick fix is to remove the tdb cache file, though can you perhaps move it out of the way for debugging? [22:37] Okay [22:37] I can post the tdb file somewhere too if that will help debug the problem [22:38] and the traceback please [22:38] exarkun: yeah, that'd be great. was a previous pull perhaps interrupted or something like that? [22:40]