=== asabil_ is now known as asabil [00:23] when i'm inside a Transport and want to raise like a security error, what's the proper type of exception to raise? [00:24] * rocky finds bzrlib.errors [00:27] rocky, :-) [00:28] jelmer: i'm building a very simple ACLTransport for my ClueBzrServer ;) [00:29] rocky: Ah, cool [00:29] rocky: Is there no branch open hook you could use? [00:30] i thought i went down that path originally and found the branch hooks rather limited ;) [00:37] rocky: we can always add more [00:39] lifeless: this is my first experiment so i'm not entirely sure what i need or what would make my life easier ... i'm gonna try building this up the best i can and look back and see if i can make some suggestions :) [00:47] lifeless: just testing my bzr package building setup. I notice the beta PPA only has 12 rc1. It would make sense for it to have 12 right? [01:04] definitely [01:06] ok I'll use that as my test that everything works. [02:44] grrnk [02:45] you know you're doing something wrong when you're reading dirstate code on a sunday [02:47] mwhudson: loom should be fixed btw, in trunk [02:52] lifeless: it is, i landed trunk into rocketfuel earlier [02:52] thanks [02:58] does every change to stdlib need a pep ? [04:49] hey, the C extensions that Bazaar uses: [04:49] are they plain C-API extensions, or Cython? [04:50] Hi. If I have a directory containing several unrelated branches and I want to turn that directory into a shared repo, how can I move the repository data in each branch into the shared repo? [04:52] fynn: some are plain C-API, most are pyrex [04:52] fynn: Cython is a version of pyrex, more or less [04:53] fbond: if they are unrelated you won't get much benefit; anyhow - bzr init-repo ; bzr branch dir/branch1 dir/branch1-using-repo; rinse and repeat [04:53] lifeless: yeah, I should have s/Cython/Pyrex [04:54] lifeless: Thanks. The reason I'm doing it is because trac-bzr doesn't seem to like to deal with multiple repositories... === `6og is now known as Kamping_Kaiser [05:12] lifeless, fbond: Alternatively: bzr init-repo ; cd ; bzr reconfigure --use-shared [05:41] abentley: ah sweet [05:55] hey, is bzr checkout what I want to do if I am doing connected work/ [05:55] ? [06:08] yes [06:25] mwhudson, ok thanks [06:25] it just seemed to take for-freaking-ever but I guess that's because the repo is kinda big === thunderstruck is now known as gnomefreak [07:03] sohail: maybe you mean co --lightweight? [07:06] mwhudson, ah I thought that was it [07:06] so what is the difference between that and straight bzr co? [07:14] sohail: co gets the entire history of the branch [07:14] sohail: co --lightweight just fetches the most recent revision (a bit like 'svn co') [07:16] mwhudson, ah I see [07:16] ok I'm getting the hang of it... thanks :-) [08:31] lifeless: bzr: ERROR: Revision {('forest.bond@logicsupply.com-20081210015641-515ojqps68c9fdyk',)} not present in "". [08:32] I get that when branching in the new shared repository, but only for some branches. [08:32] Others seem to work fine. [08:32] bzr Bazaar (bzr) 1.3.1 [08:37] that's rather old [08:38] current is 1.12 [08:43] Toksyuryel: 1.3.1 is less than a year old. I'm hoping to avoid upgrading, so a work-around would be helpful. [08:44] not sure how much help you'll be able to find; good luck [08:46] fbond: I'm not sure; it may be a bug in 1.3.1 of the branching into the repo [08:47] fbond: if so, using 1.12 and starting over will work well; its possible to use a little python to manually fetch everything, but thats more complex [09:37] Does anyone have any idea when a bzr newer than 1.5 will go into Debian unstable? [09:39] two years from the date 1.5 went in, 1.6 will go in [09:39] cammoblammo: well, should be soon now that debian has released [09:40] lifeless: Let's hope so! Is it that hard to install it from source? And is there any reason why I'd want to? [09:43] well, 1.12 is a lot better than 1.5 :) [09:44] its trivial to run from source - grab the tarball [09:44] run 'make' [09:44] and symlink something to 'bzr' [09:45] Yeah, I'm looking at it now. I just have to make sure it doesn't stuff anything else up on my box. I don't think it will. [09:47] Ah, I see. It installs into /usr/loca/ so it should live quite hapily with my Debian install. I just have to make sure it comes first in my $PATH, which I'm pretty sure is the case anyway. [09:48] cammoblammo: you don't even have to install it [09:48] just unpack the tarball, run 'make' in the source dir [09:48] and ln -s $(pwd)/bzr /usr/local/bin/bzr [09:49] Yeah, I see that. Too easy. [09:49] cammoblammo: easiest though is probably to use the bzr ppa, which should be compatible with debian; unstable is roughly jaunty [09:50] I thought of that, but I've had bad experiences with that in the past. [09:50] fair enough [09:50] it would be nice to have a unstable specific ppa [09:51] ppa? what happened to deb? [09:51] If it's just a matter of a symlink, it's probably easiest to pull the bzr repo. Does it break that often? [09:52] * cammoblammo likes playing with stuff he doesn't understand! [09:54] Toksyuryel: ppa - personal package archive - a mini debiana archive [09:54] I... see. [09:54] Ah, bother. The bzr code requires bzr 1.6 to pull. Grr. [09:55] you could install bzr 1.12 via the method described above and then use that to pull :) [09:55] Yeah, that'll have to do! [10:10] thanks vila [10:10] Hmm. No biggy, but the python script installed bzr to /usr/bin instead of /usr/local/bin as http://bazaar-vcs.org/InstallationFaq seems to think. [10:12] lifeless: :-) Me ? Why ? I'm not even there :) By the way, does the following makes sense to you: [10:12] while _tasks and now >= _tasks[0].timeout: [10:12] IndexError: list index out of range [10:15] vila: erggg [10:15] vila: oh damn, my patch isn't python 2.4 compatible === chx is now known as chx_sleeping [10:15] vila: can I get a rubberstamp for fixing it to be so? [10:15] lifeless: sure enough [10:16] vila: _tasks is a list, but _tasks[0] is out of range - hmm, threads involved? [10:16] lifeless: hehe, good, I wanted confirmation for that, yes, threads are involved, and sockets too [10:17] vila: make sure that anything removing from tasks is excluded from anything reading it [10:19] lifeless: yeah, that's the hard part :-/ I know I do some dirty thing, and I know which, I didn't suspect it could lead to that though... [10:20] vila: I would guess that a concurrent block of code is executing between _tasks, and 'and now >= _tasks[0].timeout [10:24] lifeless: yeah, my thought too. The problem is that the bug is transient, weird interaction between the python scheduler and the kernel socket handling obviously, bug go isolate that junk :-/ The good thing is that it's more or less related to that other discussion about branches leaking sockets (in a rather convoluted way, but yet) [10:26] lifeless: anyway, I should leave, I'm on the right track I think to better understand how we should handle servers in their own thread running into that mess... (and some of that knowledge should apply to the http servers too (this one is with ftp servers)) [10:27] vila: so if this is in the progress updating code? [10:27] vila: you should probably do something in the ftp code to do thread sync there [10:28] so that non-threaded transports don't pay the cost of thread primitives [10:53] so python 2.5 changed self._methodName from self.__methodName [10:53] jml: ^ [11:44] vila: ok that looks like its going through === arjenAU2 is now known as arjenAU [14:20] can someone help me get started with bazaar on launchpad? [14:20] everything i do results in: bzr: ERROR: Not a branch: ... [14:21] andersfeder: what command triggers that error? [14:21] james_w: bzr push lp:~anders-feder/+junk/test [14:21] and what is the rest of the error? [14:22] bzr: ERROR: Not a branch: "/home/feder/branch/+junk/test/". [14:22] what does "bzr info" say? [14:22] bzr: ERROR: Not a branch: "/home/feder/branch/+junk/test/". [14:23] ok, so you're not inside a branch [14:23] did you create a branch with "bzr init"? [14:23] notes /home/feder/branch [14:23] instead of lp:~.. [14:23] james_w: no, i am a noob .. can you explain how? [14:23] andersfeder: ok, before you can push a branch you have to create one to push [14:23] that is done with the "bzr init" command [14:24] okay [14:24] if you run that with no arguments it will create a branch rooted in your current directory [14:24] i see [14:24] i try it [14:24] you can then create some files, and run "bzr add" [14:24] then "bzr commit" will commit the first revision in to that branch [14:24] okay [14:24] you can then run "bzr log" to see that revision [14:24] once that is all ok you can push your new branch to launchpad [14:24] ah [14:25] running the command you were trying before should then work [14:25] up until 'bzr push', everything is something being configured locally? [14:26] yeah [14:27] when i do 'bzr commit', i get thrown into a text editor showing a log reading "This line the following will be ignored..." [14:27] how come? [14:28] or is that just a log of the commit operation? [14:32] andersfeder: you are thrown into your default text editor in order to create a commit message [14:32] aha [14:33] mneptok: so i just type something into the editor, save and exit? [14:33] andersfeder: one would hope you'd type a meaningful message instead of mashing the keyboard with your palm, but yes. ;) [14:33] right :) [14:34] one man's meat is another man's poison. "verbose commit messages" threads on developer lists prove this axiom. [14:38] well, everything seemed to work .. thanks everyone, bye === toytoy_ is now known as toytoy === Pilky_ is now known as Pilky === thunderstruck is now known as gnomefreak === chx_sleeping is now known as chx === chx is now known as chx_sleeping [16:31] guys how do I revert to the last committed copy of my project, removing all changes made in my local dir? [16:31] I did a "bzr revert" and it gave me the latest one from the repository but my new changes since last commit where still in there [16:32] is this possible? [16:32] CBro2007: use either uncommit or branch/checkout again [16:32] uncommit? [16:32] wouldn't that remove the last committed copy from my repo? [16:33] I want to keep the last GOOD copy in the repository... but just change my working directory to the good copy [16:33] edcrypt: whats the command to do that? [16:34] CBro2007 'bzr uncommit -r X' , where X is the revision you want it to go back [16:35] CBro2007 or maybe I'm not undestanding it right... [16:36] says no revisions to uncommit [16:36] but bzr log shows 3 revisions [16:36] well basically I have 3 commited copies in my repository and my working copy is not working well [16:37] so I want to get to my last good commited copy [16:37] this should be common stuff with bzr [16:38] have you pushed this revisions? [16:38] pushed how? [16:39] I just did "bzr commit -m "Initial comments... blah" [16:39] when I committed copies of my project [16:39] you know the revision number of this 'good' commit, right? [16:39] yeah its 3 [16:40] have you tried 'bzr uncommit -r 3' ? [16:40] Macintosh-2:xxx$ bzr uncommit -r 3 [16:40] No revisions to uncommit. [16:41] it must be at the revision 3 already, then [16:41] 'bzr revno' [16:42] Macintosh-2:xxx$ bzr log [16:42] ------------------------------------------------------------ [16:42] revno: 3 [16:42] committer: xxx [16:42] branch nick: XXX.dev [16:42] timestamp: Tue 2009-02-24 07:42:17 +0000 [16:42] message: [16:42] Added new table [16:42] ------------------------------------------------------------ [16:42] revno: 2 [16:42] committer: xxx [16:42] branch nick: xxx.dev [16:42] timestamp: Thu 2009-02-19 15:07:55 +0000 [16:42] message: [16:42] XXX: Added [16:42] ------------------------------------------------------------ [16:42] revno: 1 [16:42] committer: xxx [16:42] branch nick: trunk [16:42] timestamp: Tue 2009-02-17 12:03:25 +0000 [16:42] message: [16:42] Initial Import [16:42] shit sorry.... [16:42] accidental paste [16:42] trying to show you what its at [16:42] just >bzr revno? [16:42] or [16:42] >bzr 3? [16:43] its at 3 [16:43] bzr revno = 3 [16:43] I had done a "bzr revert" earlier on [16:44] but it kept ALL the changes that I made in the file [16:44] ok, you can't go back to r3 because it is already in this revision. [16:44] CBro2007: bzr diff shows something? [16:45] yeah quite a lot [16:46] have you tried 'bzr revert FILENAME' ? [16:47] it would be very, very strange if it would't nuke all your changes :) [18:29] bzr is supposed to be user-friendly, right? ;) [18:29] piper:~|master|.tmp/cdt.UPlIXyzw% bzr launchpad-login madduck #3,10003 [18:29] piper:~|master|.tmp/cdt.UPlIXyzw% bzr clone lp:pytagsfs #10004 [18:29] Permission denied (publickey). [18:29] bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) [18:29] -Dhpss does not give any other info [18:35] madduck: heya [18:35] hi [18:35] i figured out the problem [18:35] launchpad still had my old keys... [18:35] printing out the key info after the Permission denied from openssh might help [18:36] the messages I get during the clone are very disconcering [18:36] piper:~|master|.tmp/cdt.UPlIXyzw% bzr clone lp:pytagsfs #10006 [18:36] Format for lp-45955728:///~forest-bond/pytagsfs/dev/.bzr is deprecated - please use 'bzr upgrade' to get better performance [18:36] Server is too old for streaming pull, reconnecting. (Upgrade the server to Bazaar 1.2 to avoid this) [18:36] Format for lp-45955728:///~forest-bond/pytagsfs/dev/.bzr is deprecated - please use 'bzr upgrade' to get better performance [18:36] Branched 518 revision(s). [18:40] yeah, it's unfortunate === fta_ is now known as fta [19:17] I've been enjoying digging through bzrlib and figuring out Command and friends work. The code and facilities here are very nice. [19:24] i think i just found a bug, have a look at http://pastebin.ca/1350390 [19:24] i am using 1.11 as this is shipped with fedora 10 [19:26] could anybody look at it and say wether it is expected? why was the user.png not commited is my question ... [19:32] Hi, which branch of bzr-loom is appropriate for use with bzr 1.12? [19:33] fm, because bzr commit -m requires an argument, and user.png is interpreted as an argument for -m [19:43] thekorn: thnaks, i should sleep ... === chx_sleeping is now known as chx [20:03] what's the best way to publicly expose a bzr repository besides SFTP? [20:03] authentication would be nice as wel [20:04] smth like svnserve [20:05] RaceCondition: reading or writing? http/bzr+ssh/bzr:// [20:06] I'd like to be able to both read and write [20:06] but I'd like to be able to give either just read permissions or rw permissions to users [20:06] * LarstiQ is happy with posix acl and bzr+ssh [20:07] RaceCondition: if all your users already have system accounts [20:07] well I don't want all of them to have system accounts [20:07] I want to pull updates to client deployments and I don't want clients to be able to access my server over SSH [20:10] RaceCondition: right [20:13] RaceCondition: surely if you are wanting to pull from client deployments, isn't that your answer? [20:13] RaceCondition: for you to pull, not them to push [20:14] no [20:14] I want them to be able to pull from my central repository to get updates [20:14] without being able to write nor access any system accounts [20:15] RaceCondition: then serve over http for them to pull should be fine [20:15] hmm, OK [20:16] would I have to use HTTP auth then? [20:16] umm... [20:16] I guess so [20:16] not done it myself [20:16] ok [20:16] I'll try [20:48] RaceCondition: put the directory somewhere on a http server, use http auth, then the clients pull from that url [21:19] lifeless: thanks, I'll try that [21:24] I wonder how hard it would be to completely the separate the bzrlib.commands and surrounding infrastrucure from the code in bzr that uses it. [21:26] It doesn't look like it would be terribly hard. [21:30] jkakar: its pretty easy; import bzrlib.commands :) [21:32] RaceCondition: for writing over http, you need the webdav plugin, or to follow the smart server http guide, in the documentation [21:32] RaceCondition: (I missed that you wanted writing above, or I'd have said this initially) [21:32] I'd rather write over SFTP [21:32] so that the same ŕepo would be exposed through both SFTP and HTTP [21:33] lifeless: I want to use it without making Bazaar's builtin commands (and plugins). Which is requiring a bit of wrangling (read: monkey patching). [21:33] s/without making/without including/ [21:33] lifeless: I want to use it to build an application with a bzr-like '$program $command' type interface. [21:35] jkakar: I'd be happy to review patches that make using it (by importing) not automatically expose bzr's builtins [21:35] jkakar: plugins seems easier (don't call bzrlib.plugin.load_plugins()) [21:35] jkakar: but I'd consider an answer to 'how to stop a plugin registering a command, even though its needed for $my-program' [21:36] lifeless: Great, thanks. I'm not sure what the right answer is yet, so I'll continue with brute force. If/when I come up with something better I'll let you know. [21:37] RaceCondition: that will work fine too [21:37] RaceCondition: though I recommend using 'bzr+ssh://' as the protocol, not sftp - it also uses openssh for authentication and encryption, but its faster. [21:37] OK, that's good to know [21:38] I've been using SFTP though and the upload plugin with success because my repositories are small [21:38] RaceCondition: if you're happy with it - stick with it by all means :) [21:38] yeah [21:38] but I'll remember the bzr ssh combo for future :) [21:39] RaceCondition: if/when you start feeling 'if only this was faster' - well, you have an answer ;) [21:40] yeah [21:45] lifeless: I knew that about py 2.5 -- trial.TestCase works around that. [21:45] lifeless: I unsubscribed from py-dev [21:45] lifeless: I'm not around :) [21:45] jelmer: pong [21:46] jml: py-ideas? [21:46] jml: I've been trying to find the rejection for assertRaises -> theException [21:47] jml: getUniqueString and run would appear to break on 2.4 [21:49] lifeless: no, I'm not on py-ideas. The rejection was py-dev [21:49] lifeless: testtools only supports 2.5+ atm. [21:49] jml: ah, that explains it :P [21:49] (for no good reason, other than being sick to death of 2.4) [21:49] lifeless: now, I'm at a sprint. [21:49] bye [21:50] jml: ciao :P [21:59] jml: if/when you surface, I'd love a review or two :) [22:05] morning [22:14] Agh, I'm having a hard time getting an svn repository converted. I'm getting http://bazaar.launchpad.net/%7Easabil/bzr-interactive/trunk/. [22:14] Oops wrong paste. [22:14] AssertionError: base checksum mismatch: '2d5c2c8ce179bd24a696676890af367b' != '5d43b775c320bea1a509debdc5431eef' [22:15] Anyone seen anything like this before? [22:24] fbond: no, is there a backtrace? [22:26] igc: http://en.wikipedia.org/wiki/Rabin-Karp_string_search_algorithm [22:28] lifeless: https://bugs.edge.launchpad.net/bzr/+bug/336373 [22:29] Ubuntu bug 336373 in bzr "error upgrading emacs to gc-plain-chk255" [Undecided,New] [22:31] igc: which gc are you using? [22:32] lifeless: rev 56 [22:33] igc: of what brbanch [22:34] lifeless: https://code.edge.launchpad.net/~bzr/bzr-groupcompress/trunk [22:36] igc: so, be interesting to know what is None [22:36] the locations, or the key [22:36] igc: either way, have you tried rolling back to the last version that worked? [22:37] lifeless: not yet. jam was keen for me to use rev 55 and rev 56 has a pretty obvious bug fix [22:39] igc: I'd either start debugging the gc code, or rollback [22:39] igc: myself, I'd rollback because the rabin stuff hassn't landed in trunk yet [22:40] lifeless: shall do [22:58] lifeless: Yes, I can post a backtrace. [22:59] lifeless: Prefered paste site? [23:11] lifeless: http://pastebin.ca/1350545 [23:11] jelmer: This is a bzr-svn traceback, FYI. [23:12] The repository I'm importing from has been around for a few years, and I've used early-ish versions of bzr-svn with it. I've dealt with some svn property conflicts related to bzr-svn metadata. It's possible some of them were not resolved perfectly. Not sure if any of this is relevant. [23:29] fbond: I'd file a bzr-svn bug [23:30] fbond: it looks to me like it got the wrong text out of svn somehow [23:31] lifeless: Hm, what a bummer. I'd really like to get this thing converted. Thanks. [23:35] once I have a loom with a stacked series of patches, how do I then generate a ‘quilt’ series? [23:38] bignose: Are you looking to generate a series of patches? [23:41] fbond: specifically, a series of patches that I can use with ‘quilt’. [23:41] so, the closer I get to what quilt calls a “patch series”, the better. [23:42] naming the patches after the thread names would be good [23:43] as would generating the “patch header” that ‘quilt’ can use [23:43] bignose: Hm, I didn't know that quilt could import patches. [23:43] bzr-loom is, as I understand things, a replacement for quilt. [23:43] fbond: um? I'm talking about what the quilt system handles natively. [23:43] But generating a series of patches from a loom is easy enough. [23:43] bignose: I may not know quilt well enough. [23:44] nor I :-) [23:44] However, to generate a patch for thread foo: [23:44] bzr switch foo; bzr diff -r thread: >foo.patch [23:44] I'm using a loom to generate the patches, but a Debian package can't have a loom [23:44] but it *can* have a quilt series of patches, so that's what I'm trying to generate [23:44] I see. [23:44] that's the extent of my knowledge of quilt :-) [23:45] bignose: There are a few other patch systems that can be easily used in debian packaging. [23:45] Others might be simpler, given your use-case. [23:46] well, simplest for me would be to simply generate a new tree, and generate a diff against the original files [23:46] I would generate patches, toss them in debian/patches, and use cdbs with simple-patchsys. [23:46] but I'm trying to find a way to be nicer to others than that [23:47] bignose: You can explode a loom into separate branches for each thread... [23:47] and from what I understand, quilt is the most accepted system [23:48] fbond: but then generating the patch for each one would require knowledge of which branch precedes it in the series. [23:48] so I think generating the patches from the loom is the approach with most promise [23:48] bignose: quilt has the concept of patch order, too. [23:48] yes, and that's what I'm trying to feed it. [23:48] my point was that exploding the patches to separate branches looses that order. [23:49] s/loose/lose/ [23:49] bignose: Right. I would generate patches from the loom directly. [23:49] okay. [23:49] currently only possible manually then? [23:50] bignose: As far as I am aware. [23:52] fbond: thanks for your help. [23:53] bignose: No problem.