=== AfC1 is now known as AfC === Ursinha is now known as Ursinha-afk [04:24] hey peitschie [04:56] hi all [04:57] Hey poolie. [04:58] hi max [04:59] poolie: Can I /msg you? [04:59] sure [04:59] Cool. [05:43] hiya jelmer :) [05:43] hi poolie [07:46] hi all ! [07:48] * fullermd waves. [07:49] _o/ [09:32] jelmer: ping [10:28] is there anywhere i can find a list of wireprotocol commands? [10:28] specifically i want to know which ones constitute a write request [10:41] hello [10:41] how do I get color diffs with bzr diff? [10:43] ah, found it [10:43] cdiff [10:43] take care [10:50] catphish: You'd probably have to read the source dode. [10:50] code* [10:50] Peng: thanks, I thought that might be the case, was just hoping to same some time :) [10:52] Well, you could just build a list of all of 'em, then script up running them all against something you don't have write access to, and see what blows up ;) [10:53] haha [11:02] hey, is it possible to "abuse" signed commits for authentication? i.e. only allow commits from certain users (and only if they signed them)? [11:02] Conceptually? Sure. I don't think anybody's implemented such a thing though. [11:04] I'm not sure that qualifies as abuse, though; sounds like something that's Just Fittin'. [11:04] yeah it fits, but it sure was not the original purpose of signed commits [11:05] I'm still thinking about how to implement per project authorization for a shared smart-server (i.e. it is hosting multiple projects and I don't feel like giving everyone ssh access) [11:05] Are you trying to prevent malice or stupidity? [11:11] m4rku5: i'd say the easiest way is with ssh keys and a wrapper script [11:11] rather than signed commits [11:12] im implementing a shared repo with ssh and http ACLs [11:35] catphish, i was thinking about that, how would you do that ? match the part of the url before .bzr/smart? [11:36] oh what ssh and http? [11:37] m4rku5: on ssh you need a wrapper that knows what access you have and runs the appropriate bzr serve commands [11:38] with http, yes, you detect the string before .bzr/smart and inject that as the branch name [11:38] i spent a whole day figuring that part out [11:39] yeah but with https only (which is what i am planning) you would need to use different auth. backend depending on the path before .bzr/smart [11:40] with http you use http basic auth [11:40] yeah ive got it setup to use basic auth via htpasswd atm [11:41] and i was thinking about ways to have per project access [11:41] well that's fine isn't it? [11:41] you can use htpasswd like that [11:41] yeah well at the moment it is: you have access everywhere or nowhere [11:42] you can use htaccess filesto set that up [11:42] if i had used apache i could ;) using lighttpd right now, which I think might be a problem [11:43] i don't know [11:43] never used acl in it [11:43] my implementation is based on a custom ruby server === Ursinha-afk is now known as Ursinha === tchan1 is now known as tchan [14:31] a question about hooks if I may, I want to do equivalent of push_and_update, only for specific repository and on a server side preferably [14:32] is post_change_branch_tip the right hook for that? [14:32] did anybody implement this yet? === bac` is now known as bac [15:03] morning vila [15:04] morning jam ! [15:04] * vila lower volume damn it === jam changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | 2.2.3 is frozen, time to build the installers ! (rm vila) [15:07] would you guys help me writing a hook for bzr? [15:07] s/writing/write/ [15:10] I want to update (lightweight) checkout upon a commit to specific branch, serverside [15:11] now first thing that would be handy would be some good API docs. So far I googled this: http://naesten.dyndns.org:8080/bzrlib-docs/bzrlib.html === mbarnett` is now known as mbarnett [15:16] how do I get some useable object from the checkout's path? [15:16] ccxCZ: have a look into builtins.py, best source of examples [15:16] open_containing_*(path) [15:19] ah, checkout == WorkingTree in bzr lingo [15:44] Hi, a colleague of mine just encountered bug 400351 using bzr 2.2.2. Should I reopen the bug, and what is the best way for him to recreate his dirstate? (Oh, and bzr check --tree triggers the same error). [15:44] Launchpad bug 400351 in Bazaar "bzr: ERROR: exceptions.AssertionError: Could not find target parent in wt: reports" [Undecided,Fix released] https://launchpad.net/bugs/400351 === Ursinha is now known as Ursinha-lunch === beuno is now known as beuno-lunch [16:33] when using b.c.Config / BranchConfig, do I have to flush changes somehow? [16:33] or use locking, for that matter === beuno-lunch is now known as beuno === Ursinha-lunch is now known as Ursinha [18:42] vila: around? === Ursinha is now known as Ursinha-brb === pickscrape___ is now known as pickscrape [19:24] Hi, a colleague of mine just encountered bug 400351 using bzr 2.2.2. Should I reopen the bug, and what is the best way for him to recreate his dirstate? (Oh, and bzr check --tree triggers the same error). [19:24] Launchpad bug 400351 in Bazaar "bzr: ERROR: exceptions.AssertionError: Could not find target parent in wt: reports" [Undecided,Fix released] https://launchpad.net/bugs/400351 [19:25] pickscrape: just getting rid of the .bzr/checkout directory and then running 'bzr co' IIRC [19:26] jelmer: thanks, I'll get him to give that a try tomorrow. [19:27] jelmer: Hi. I seem to be experiencing some odd test failures with bzr-git (maverick and below) and dulwich (karmic) in ~bzr/proposed. Do you think you could eyeball the buildlogs and see if they are at all meaningful to you? [19:28] maxb: looking [19:29] maxb: is this based on the packaging in debian or completely independent? [19:29] it is based on debian, the changes are few, if any [19:30] None for bzr-git, just some minor tweaks for dulwich/karmic [19:30] maxb: the version of C git used is too old I think [19:30] hmm [19:31] no, that's not it [19:32] maxb: sorry, I don't know what's happening there. I haven't those errors before, either. [19:32] Ok :-) [19:32] *seen [19:33] The bzr-git problem doesn't reproduce on my local maverick box, which could make debugging "interesting" [19:34] have you tried on a karmic vm? [19:58] I don't have VMs conveniently to hand, perhaps I'll try in a pbuilder chroot === Ursinha-brb is now known as Ursinha === nlisgo_ is now known as nlisgo [22:14] Hello. I've pushed a branch to lp:~id/ubuntu/etc/etc, and i want to remove the quilt patch that i applied to that branch. So, i follow these steps to try to make it: get the branch, cd the branch, quilt pop thepatch.patch, but here says: "No patches deleted" and the patched files still keep patched. Sorry if this isn't the correct place to ask. [22:15] Any suggestion trying to unpatch the files? === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk [22:19] Rcart: The quilt metadata in the branch may be incorrect, is my best guess === Ursinha-afk is now known as Ursinha [22:22] maxb: Ok, i have another branch (of the same package) that would like to replace the pushed branch on lp, can i do that? [22:23] replace it completely, including history? (quite a major/destructive change?) [22:24] no, just replace the patch in the branch [22:25] Then I don't understand what you're saying, sorry, because your two last lines appear to imply different things [22:26] It might be easier if you gave links to the two branches on Launchpad to illustrate the situation [22:27] Ok, here's the branch: lp:~rcart/ubuntu/natty/bittornado/fix-420387 [22:28] i want to remove the las patch that i aplied before pushing the branch [22:28] when i get my branch i LP, i cannot remove the patch (quilt pop patchname.patch) and says: "no patches deleted" [22:29] because i cannot remove the patch, i get an original branch from bittornado: bzr branch lp:/ubuntu/bittornado [22:30] and the, created a patch that would replace the patch in the LP branch [22:34] erm, why are you creating .dpatch files in a quilt-managed project? [22:35] updating Standards-Version in an Ubuntu package is wrong [22:36] oh, sorry, ok, the packaging in debian is a bit mad, and uses .dpatch naming [22:36] yeah yeah, the reviewer in the branch told me that too, that's why i've worked in a new patch to fix the corrections [22:37] i just followed the naming, the patch i quilt format (: [22:37] is* [22:37] You should not remove the CVS directory, it does no harm, and unnecessary deviation from debian is to be avoided [22:38] You certainly shouldn't only remove one CVS directory of the many throughout the tree [22:39] So, am I understanding right that you now have a replacement change in a fresh branch off lp:ubuntu/bittornado, and you wish to blow away the existing contents of lp:~rcart/ubuntu/natty/bittornado/fix-420387, replacing it with your new fresh branch? [22:39] If so, bzr push --overwrite is what you're looking for [22:39] yeah, i got that correction from the comments of users in the branch [22:41] any consequences replacing the branch in LP ? [22:42] If there was any likelyhood your existing changes had been merged anywhere or others were basing changes of their own on them, it would be undesirable [22:43] In this case it should be fine [22:44] the branch is proposing for merge, but needs fixes, so i think according to what you say that there's no problem (: [22:47] maxb: btw, i removed the CVS directory because when trying to use debcommit command, it was complaining about .cvs directory [22:48] so, taking advantage of the occasion, what's the difference between bzr commit and debcommit? [22:52] debcommit wraps bzr commit, providing a commit message suggested from the changes to debian/changelog === Ursinha is now known as Ursinha-afk [22:56] maxb: but when i was trying to use debcommit, this was complaining about the CVS directoy and just worked when i removed it, but when i used bzr commit there was no problem, what do you think was the problem? [23:04] debcommit does not *only* work for bzr, it aims to detect the version control system in use and behave appropriately [23:06] maxb: Ok, thanks a lot for your help. [23:12] morning poolie [23:13] that is, if you've recovered from your flight back by now [23:18] jam: we was around earlier [23:38] hi jam, i am back and i'm doing ok [23:42] poolie: good to hear