| vila | thumper: still around ? | 07:19 |
|---|---|---|
| vila | hi all | 07:19 |
| mgrandi | hihi | 07:21 |
| mgz | morning | 08:21 |
| vila | morning mgz | 08:25 |
| thumper | vila: yeah | 08:30 |
| vila | thumper: regarding create_signatures, what value do you want and under which conditions ? | 08:30 |
| thumper | hi vila | 08:31 |
| thumper | I want wikkid to not ask for signatures even if the main bazaar conf specifies it when committing changes | 08:31 |
| vila | which conditions ? | 08:32 |
| thumper | all conditions | 08:33 |
| vila | don' t set it in the conf then :) | 08:34 |
| vila | you're asking bzr to do something, it does, why are you complaining ? | 08:34 |
| vila | if the actual behavior does not suit your needs there are ways to use it differently, hence my question: under which conditions do you want a different configuration ? | 08:35 |
| vila | thumper: ? | 08:40 |
| thumper | vila: I don't want someone to have to think about what sigs they may have set in their normal bazaar conf when using wikkid | 08:40 |
| thumper | wikkid should just never ask for signing | 08:41 |
| vila | bzr wikkid -Ocreate_signatures=never | 08:41 |
| thumper | ? | 08:42 |
| thumper | what if using bin/wikkid-serve ? | 08:42 |
| thumper | in order to have a more complicated setup? | 08:43 |
| vila | branch.get_config_stack().set('create_signatures', 'never') ? | 08:44 |
| vila | for all branches used by wikkid ? | 08:44 |
| thumper | will that work? | 08:44 |
| vila | why wouldn't it ? | 08:44 |
| thumper | I don't know... that is why I'm asking :) | 08:45 |
| thumper | is there a way to query the create_signatures value? | 08:45 |
| thumper | get('create_signatures')? | 08:45 |
| vila | yup | 08:45 |
| vila | but the value may come from somewhere else than branch.conf | 08:46 |
| vila | so a vicious user can still set it in locations.conf. In this case I'd blame the user though | 08:46 |
| thumper | that's fine | 08:46 |
| vila | cool | 08:46 |
| thumper | if I call set | 08:46 |
| thumper | that'll override locations? | 08:46 |
| vila | no | 08:46 |
| thumper | really? | 08:47 |
| vila | locations *is* the way to override | 08:47 |
| thumper | so if I call the set method, where does it set it? | 08:47 |
| thumper | in the local branch config? | 08:47 |
| vila | yes | 08:47 |
| thumper | so if I call get, find it is true, then call set | 08:48 |
| thumper | if I call get again | 08:48 |
| vila | a stack defines a list of config to query and a *single* config to modify | 08:48 |
| thumper | and it is true | 08:48 |
| thumper | it means set in locations? | 08:48 |
| vila | no, you need a different stack to set in locations (and one tailored to set in whatever section you specify) | 08:48 |
| thumper | ah... | 08:50 |
| thumper | no, i think you are misunderstanding me | 08:50 |
| vila | good, we're making progress ;) | 08:50 |
| thumper | if i call get, and it is true | 08:50 |
| thumper | then it could be set in one of three places right? | 08:50 |
| thumper | bazaar.conf, locations.conf, or the branch config | 08:50 |
| vila | no, that's not designed this way | 08:50 |
| thumper | oh? | 08:51 |
| thumper | that seems to be how it is working | 08:51 |
| thumper | to my untrained eye | 08:51 |
| vila | no, a stack defines only a *single* place for modifications | 08:51 |
| vila | optional even | 08:51 |
| vila | so you can have read-only stacks | 08:51 |
| thumper | sure, but I'm not specifing modifiction | 08:51 |
| thumper | I'm asking if I call "get(...)" and it returns true | 08:52 |
| vila | the value can come from several different places | 08:52 |
| thumper | then if i call ".set(...)" it changes the branch config (as in the one in the local .bzr) | 08:53 |
| vila | yes | 08:53 |
| vila | doesn't matter where the 'true' value came from | 08:53 |
| thumper | and then if I call .get(...) again, it may be true if specified in locations.conf? | 08:53 |
| thumper | if I specified .set(..., false) | 08:53 |
| vila | yes | 08:54 |
| thumper | right | 08:54 |
| thumper | that's all I need to know | 08:54 |
| vila | that's the 'vicious' user I was mentioning | 08:54 |
| vila | and you said that's fine | 08:54 |
| vila | (which I agree with ;) | 08:54 |
| jelmer | vila: wouldn't it be easier to just add a memory store as the first store in the stack, one which just sets create_signatures=never ? | 08:57 |
| vila | jelmer: how will a user be able to control that ? | 08:57 |
| vila | if he can't, it looks like a bad idea to me | 08:58 |
| jelmer | vila: why should the user be able to control it? This is running inside of wikkid. | 08:58 |
| jelmer | prompting for GPG passphrases in a non-interactive process is a bad idea. | 08:58 |
| vila | a user may come up with a solution for that and will be annoyed by being blocked trying to make it work | 08:59 |
| jelmer | vila: wikkid is essentially a web server - how can that ever properly prompt for a GPG signature if it does so on the server side? | 09:00 |
| vila | fine, if it's a server it can be configured to not ask for gpg sigs, don't make a simple problem more complicated than it needs | 09:01 |
| jelmer | vila: this discussion is how wikkid can properly configure it to not ask for gpg sigs | 09:02 |
| jelmer | having to edit your configuration each time before running wikkid would be annoying | 09:04 |
| vila | jelmer: the *user* decides how to configure, code should not remove this ability if there are ways to keep the user in control | 09:04 |
| jelmer | vila: code can also decide what the author or revision properties of a new commit is going to be, there is no way for the user to override that | 09:05 |
| vila | jelmer: do we have config options for that ? | 09:05 |
| jelmer | vila: if an API user wants to create a commit without a signature (and it's got a good reason), I don't particularly see why we shouldn't accomodate that | 09:05 |
| vila | -Ooption=value | 09:05 |
| vila | the fact that the API (bzrlib/library_state) doesn't (yet) allow that is a known bug | 09:06 |
| jelmer | vila: it doesn't make sense for *any* commits from wikkid to be signed, why should the user have to know or care about mandatory config options? | 09:06 |
| vila | jelmer: famous last words | 09:07 |
| jelmer | vila: the committer email comes from the config, and API users can override that | 09:07 |
| vila | which is a bad idea given that there are ways to do that while still respecting what the user is asking for | 09:08 |
| vila | jelmer: what's the point of pretending that an option can be configured if the code ignores what the user is saying ? | 09:09 |
| vila | the code can be as smart as you want as long as it provides a *default* value. Once the user asks for a specific value though, the code must comply. | 09:11 |
| vila | If the code cannot handle what the user is asking, an error is appropriate | 09:12 |
| jelmer | vila: the point is that any value but "never" doesn't make sense in this case | 09:12 |
| vila | If the code cannot handle what the user is asking, an error is appropriate | 09:12 |
| jelmer | vila: an error may be appropriate if "create_signatures" is set to always | 09:12 |
| jelmer | but it can also be set to when-required | 09:13 |
| vila | does that address wikkid case ? | 09:13 |
| jelmer | vila: that's still not particularly useful though | 09:13 |
| jelmer | vila: I have create_signatures=always set; I do want bzr to always create signatures, but I never want wikkid to | 09:14 |
| vila | 'always' doesn't match your use case then | 09:14 |
| vila | but setting it in bazaar.conf while overriding it in specific branches does | 09:15 |
| jelmer | vila: what does match my use case then? | 09:15 |
| vila | setting it to 'always' in bazaar.conf while overriding it to 'never' in wikkid branches | 09:16 |
| vila | no code needed | 09:16 |
| vila | if you want to be fancy do create_signatures={wikkid.create_signatures} and set wikkid.create_signatures to an appropriate value when wikkid is running | 09:17 |
| jelmer | vila: I run wikkid often in the same branches where I run bzr from the cli | 09:17 |
| vila | see above | 09:17 |
| jelmer | vila: anyway, perhaps we should abandon this discussion | 09:17 |
| vila | well, that's the second time we have it :) | 09:18 |
| jelmer | vila: that adds a bunch of extra setup for when I want to run wikkid? | 09:18 |
| vila | setting an optin in bazaar.conf == 'a bunch of extra setup' ??? | 09:19 |
| jelmer | vila: and for every other wikkid user too | 09:19 |
| jelmer | vila: wikkid not working out of the box, but requiring editing of bazaar.conf is annoying | 09:20 |
| vila | what's the out-of-the-box value for create_signatures ? | 09:20 |
| lifeless | wikkid wants to not sign its commits | 09:21 |
| lifeless | I'm not saying that makes sense (it doesn't to me), but there it is. | 09:21 |
| lifeless | thumper: have you considered having wikkid sign its commits as itself ? | 09:21 |
| lifeless | still needs to inject some behaviour, but it wouldn't lead to partially-signed trees | 09:22 |
| jelmer | lifeless: it would have to take care of creating a password-less GPG key etc in that case | 09:22 |
| lifeless | jelmer: something like that, and package install scripts are pretty good at that sort of thing | 09:22 |
| lifeless | jelmer: also need a port to listen on, firewall holes etc | 09:23 |
| jelmer | lifeless: I've usually run it as an ordinary user (myself), not as a system-wide daemon | 09:24 |
| thumper | lifeless: no... actually I have not considered that | 09:38 |
| thumper | lifeless: is it easy? | 09:38 |
| thumper | lifeless: wikkid may be running on a box where there isn't someone to sign :) | 09:39 |
| thumper | lifeless: but I guess there could be a GPG key that doesn't have a password | 09:39 |
| mgz | I've done that in the past (the passwordless gpg signing thing) | 09:41 |
| mgz | and then felt bad because it seemed like gpg 2 solved the same problem in a better way | 09:43 |
| mgz | but simplest thing etc. | 09:43 |
| * jelmer lunches | 10:13 | |
| === Ng_ is now known as Ng | ||
| === yofel_ is now known as yofel | ||
| === deryck is now known as deryck[afk] | ||
| === deryck[afk] is now known as deryck | ||
| eagleon | hi | 21:41 |
| eagleon | is it possible to run basic bzr commands using php? | 21:41 |
| beuno | eagleon, only by executing the commands | 21:41 |
| beuno | you can use xmloutput to parse the output | 21:42 |
| beuno | 4 or 5 years ago I wrote php code to do exactly that | 21:42 |
| beuno | eagleon, so something like: $command = 'bzr log '.$path_to_bzr.' -vv --xml --show-ids -r -1 ' | 21:47 |
| beuno | with xmloutput installed | 21:47 |
| beuno | and then parse the xml output with something like simplexml | 21:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!