[07:19] <vila> thumper: still around ?
[07:19] <vila> hi all
[07:21] <mgrandi> hihi
[08:21] <mgz> morning
[08:25] <vila> morning mgz
[08:30] <thumper> vila: yeah
[08:30] <vila> thumper: regarding create_signatures, what value do you want and under which conditions ?
[08:31] <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:32] <vila> which conditions ?
[08:33] <thumper> all conditions
[08:34] <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:35] <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:40] <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:41] <thumper> wikkid should just never ask for signing
[08:41] <vila> bzr wikkid -Ocreate_signatures=never
[08:42] <thumper> ?
[08:42] <thumper> what if using bin/wikkid-serve ?
[08:43] <thumper> in order to have a more complicated setup?
[08:44] <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:45] <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:46] <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:47] <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:48] <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:50] <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:51] <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:52] <thumper> I'm asking if I call "get(...)" and it returns true
[08:52] <vila> the value can come from several different places
[08:53] <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:54] <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:57] <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:58] <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:59] <vila> a user may come up with a solution for that and will be annoyed by being blocked trying to make it work
[09:00] <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:01] <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:02] <jelmer> vila: this discussion is how wikkid can properly configure it to not ask for gpg sigs
[09:04] <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:05] <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:06] <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:07] <vila> jelmer: famous last words
[09:07] <jelmer> vila: the committer email comes from the config, and API users can override that
[09:08] <vila> which is a bad idea given that there are ways to do that while still respecting what the user is asking for
[09:09] <vila> jelmer: what's the point of pretending that an option can be configured if the code ignores what the user is saying ?
[09:11] <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:12] <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:13] <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:14] <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:15] <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:16] <vila> setting it to 'always' in bazaar.conf while overriding it to 'never' in wikkid branches
[09:16] <vila> no code needed
[09:17] <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:18] <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:19] <vila> setting an optin in bazaar.conf == 'a bunch of extra setup' ???
[09:19] <jelmer> vila: and for every other wikkid user too
[09:20] <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:21] <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:22] <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:23] <lifeless> jelmer: also need a port to listen on, firewall holes etc
[09:24] <jelmer> lifeless: I've usually run it as an ordinary user (myself), not as a system-wide daemon
[09:38] <thumper> lifeless: no... actually I have not considered that
[09:38] <thumper> lifeless: is it easy?
[09:39] <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:41] <mgz> I've done that in the past (the passwordless gpg signing thing)
[09:43] <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.
[10:13]  * jelmer lunches
=== 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
[21:41] <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:42] <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:47] <beuno> eagleon, so something like: $command = 'bzr log '.$path_to_bzr.' -vv --xml --show-ids -r -1 '
[21:47] <beuno> with xmloutput installed
[21:48] <beuno> and then parse the xml output with something like simplexml