[04:24] <jelmer> hey peitschie
[04:56] <poolie> hi all
[04:57] <mkanat> Hey poolie.
[04:58] <poolie> hi max
[04:59] <mkanat> poolie: Can I /msg you?
[04:59] <poolie> sure
[04:59] <mkanat> Cool.
[05:43] <peitschie> hiya jelmer :)
[05:43] <peitschie> hi poolie
[07:46] <vila> hi all !
[07:48]  * fullermd waves.
[07:49] <vila> _o/
[09:32] <vila> jelmer: ping
[10:28] <catphish> is there anywhere i can find a list of wireprotocol commands?
[10:28] <catphish> specifically i want to know which ones constitute a write request
[10:41] <Nazcafan> hello
[10:41] <Nazcafan> how do I get color diffs with bzr diff?
[10:43] <Nazcafan> ah, found it
[10:43] <Nazcafan> cdiff
[10:43] <Nazcafan> take care
[10:50] <Peng> catphish: You'd probably have to read the source dode.
[10:50] <Peng> code*
[10:50] <catphish> Peng: thanks, I thought that might be the case, was just hoping to same some time :)
[10:52] <fullermd> 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] <Peng> haha
[11:02] <m4rku5> 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] <fullermd> Conceptually?  Sure.  I don't think anybody's implemented such a thing though.
[11:04] <fullermd> I'm not sure that qualifies as abuse, though; sounds like something that's Just Fittin'.
[11:04] <m4rku5> yeah it fits, but it sure was not the original purpose of signed commits
[11:05] <m4rku5> 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] <fullermd> Are you trying to prevent malice or stupidity?
[11:11] <catphish> m4rku5: i'd say the easiest way is with ssh keys and a wrapper script
[11:11] <catphish> rather than signed commits
[11:12] <catphish> im implementing a shared repo with ssh and http ACLs
[11:35] <m4rku5> catphish, i was thinking about that, how would you do that ? match the part of the url before .bzr/smart?
[11:36] <m4rku5> oh what ssh and http?
[11:37] <catphish> m4rku5: on ssh you need a wrapper that knows what access you have and runs the appropriate bzr serve commands
[11:38] <catphish> with http, yes, you detect the string before .bzr/smart and inject that as the branch name
[11:38] <catphish> i spent a whole day figuring that part out
[11:39] <m4rku5> 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] <catphish> with http you use http basic auth
[11:40] <m4rku5> yeah ive got it setup to use basic auth via htpasswd atm
[11:41] <m4rku5> and i was thinking about ways to have per project access
[11:41] <catphish> well that's fine isn't it?
[11:41] <catphish> you can use htpasswd like that
[11:41] <m4rku5> yeah well at the moment it is: you have access everywhere or nowhere
[11:42] <catphish> you can use htaccess filesto set that up
[11:42] <m4rku5> if i had used apache i could ;) using lighttpd right now, which I think might be a problem
[11:43] <catphish> i don't know
[11:43] <catphish> never used acl in it
[11:43] <catphish> my implementation is based on a custom ruby server
[14:31] <ccxCZ> 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] <ccxCZ> is post_change_branch_tip the right hook for that?
[14:32] <ccxCZ> did anybody implement this yet?
[15:03] <jam> morning vila
[15:04] <vila> morning jam !
[15:04]  * vila lower volume damn it
[15:07] <ccxCZ> would you guys help me writing a hook for bzr?
[15:07] <ccxCZ> s/writing/write/
[15:10] <ccxCZ> I want to update (lightweight) checkout upon a commit to specific branch, serverside
[15:11] <ccxCZ> 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
[15:16] <ccxCZ> how do I get some useable object from the checkout's path?
[15:16] <vila> ccxCZ: have a look into builtins.py, best source of examples
[15:16] <vila> open_containing_*(path)
[15:19] <ccxCZ> ah, checkout == WorkingTree in bzr lingo
[15:44] <pickscrape___> 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).
[16:33] <ccxCZ> when using b.c.Config / BranchConfig, do I have to flush changes somehow?
[16:33] <ccxCZ> or use locking, for that matter
[18:42] <lifeless> vila: around?
[19:24] <pickscrape> 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:25] <jelmer> pickscrape: just getting rid of the .bzr/checkout directory and then running 'bzr co' IIRC
[19:26] <pickscrape> jelmer: thanks, I'll get him to give that a try tomorrow.
[19:27] <maxb> 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] <jelmer> maxb: looking
[19:29] <jelmer> maxb: is this based on the packaging in debian or completely independent?
[19:29] <maxb> it is based on debian, the changes are few, if any
[19:30] <maxb> None for bzr-git, just some minor tweaks for dulwich/karmic
[19:30] <jelmer> maxb: the version of C git used is too old I think
[19:30] <jelmer> hmm
[19:31] <jelmer> no, that's not it
[19:32] <jelmer> maxb: sorry, I don't know what's happening there. I haven't those errors before, either.
[19:32] <maxb> Ok :-)
[19:32] <jelmer> *seen
[19:33] <maxb> The bzr-git problem doesn't reproduce on my local maverick box, which could make debugging "interesting"
[19:34] <jelmer> have you tried on a karmic vm?
[19:58] <maxb> I don't have VMs conveniently to hand, perhaps I'll try in a pbuilder chroot
[22:14] <Rcart> 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] <Rcart> Any suggestion trying to unpatch the files?
[22:19] <maxb> Rcart: The quilt metadata in the branch may be incorrect, is my best guess
[22:22] <Rcart> 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] <maxb> replace it completely, including history? (quite a major/destructive change?)
[22:24] <Rcart> no, just replace the patch in the branch
[22:25] <maxb> Then I don't understand what you're saying, sorry, because your two last lines appear to imply different things
[22:26] <maxb> It might be easier if you gave links to the two branches on Launchpad to illustrate the situation
[22:27] <Rcart> Ok, here's the branch: lp:~rcart/ubuntu/natty/bittornado/fix-420387
[22:28] <Rcart> i want to remove the las patch that i aplied before pushing the branch
[22:28] <Rcart> when i get my branch i LP, i cannot remove the patch (quilt pop patchname.patch) and says: "no patches deleted"
[22:29] <Rcart> because i cannot remove the patch, i get an original branch from bittornado: bzr branch lp:/ubuntu/bittornado
[22:30] <Rcart> and the, created a patch that would replace the patch in the LP branch
[22:34] <maxb> erm, why are you creating .dpatch files in a quilt-managed project?
[22:35] <maxb> updating Standards-Version in an Ubuntu package is wrong
[22:36] <maxb> oh, sorry, ok, the packaging in debian is a bit mad, and uses .dpatch naming
[22:36] <Rcart> 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] <Rcart> i just followed the naming, the patch i quilt format (:
[22:37] <Rcart> is*
[22:37] <maxb> You should not remove the CVS directory, it does no harm, and unnecessary deviation from debian is to be avoided
[22:38] <maxb> You certainly shouldn't only remove one CVS directory of the many throughout the tree
[22:39] <maxb> 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] <maxb> If so, bzr push --overwrite is what you're looking for
[22:39] <Rcart> yeah, i got that correction from the comments of users in the branch
[22:41] <Rcart> any consequences replacing the branch in LP ?
[22:42] <maxb> 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] <maxb> In this case it should be fine
[22:44] <Rcart> the branch is proposing for merge, but needs fixes, so i think according to what you say that there's no problem (:
[22:47] <Rcart> maxb: btw, i removed the CVS directory because when trying to use debcommit command, it was complaining about .cvs directory
[22:48] <Rcart> so, taking advantage of the occasion, what's the difference between bzr commit and debcommit?
[22:52] <maxb> debcommit wraps bzr commit, providing a commit message suggested from the changes to debian/changelog
[22:56] <Rcart> 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] <maxb> debcommit does not *only* work for bzr, it aims to detect the version control system in use and behave appropriately
[23:06] <Rcart> maxb: Ok, thanks a lot for your help.
[23:12] <jam> morning poolie
[23:13] <jam> that is, if you've recovered from your flight back by now
[23:18] <lifeless> jam: we was around earlier
[23:38] <poolie> hi jam, i am back and i'm doing ok
[23:42] <jam> poolie: good to hear