[10:54] <mdke> boredandblogging: pong
[14:50] <boredandblogging> mdke: is it still policy to encourage Ubuntu-related teams not to use LP mailing lists?
[16:48] <johnc4510> tyche: i'll be checking my feeds for stuff since tues. that i haven't added
[16:48] <tyche> johnc4510: Take a look at the "Notifications, indicators, and alerts" entry.  I tried to cover it adequately, but he had a LOT of information in there.
[16:49] <johnc4510> k
[16:49] <nizarus> johnc4510, the UWN will be back this week ?
[16:49] <nizarus> hello boredandblogging :)
[16:49] <johnc4510> yep
[16:50] <nizarus> cool johnc4510
[16:50] <johnc4510> :)
[16:50] <nizarus> johnc4510, what do you think about this : https://wiki.ubuntu.com/TunisianTeam/TeamReporting#ENIS Event 8.12
[16:50] <johnc4510> looking
[16:50] <nizarus> it can be in the UWN ?
[16:53] <johnc4510> nizarus: we can include the Dec. 2008 stuff for sure
[16:53] <tyche> nizarus: Looks like you've been busy.  :-)
[16:54] <nizarus> yes johnc4510 tyche
[16:54] <nizarus> it waq the first abisius project for our LoCo
[16:54] <nizarus> waq/was
[16:54] <nizarus> so we made a big effort
[16:54] <johnc4510> looks good
[16:55] <nizarus> to have it working
[16:55] <johnc4510> tyche: i added the link to that
[16:55] <nizarus> and we hope continue it on January
[16:55] <johnc4510> cool
[16:55] <tyche> kk.  I'll catch up.
[16:55] <nizarus> where more then 1000 PC are waiting to be freed
[16:55] <nizarus> :p
[16:56] <johnc4510> very nice
[16:56] <nizarus> actually it's just an abstract johnc4510
[16:56] <johnc4510> ah
[16:56] <nizarus> we are working to prepare a detailled report for the fridge or so on
[16:57] <johnc4510> k
[16:57] <nizarus> but if it can be published in the uwn it will be great :p
[16:57] <johnc4510> give it to boredandblogging or myself when it's ready
[16:57] <johnc4510> and we'll get it in the fridge
[16:57] <nizarus> ok johnc4510 :)
[18:27] <johnc4510> tyche: i'll add the dec. team reports to the issue. they're up now on the wiki
[18:28] <tyche> That's good.
[18:29] <nizarus> johnc4510, including team reports on the uwn can generate duplicates
[18:29] <johnc4510> yeah, we try to watch that
[18:29] <nizarus> we got this in our loco last time the team report was included on the uwn
[18:30] <johnc4510> k
[18:31] <nizarus> but this time i tried to put only the titels on team report with a link for a detailled abstract to avoid this
[18:31] <johnc4510> k thx
[19:00] <johnc4510-laptop> tyche: ok, team reports are up now
[19:00] <johnc4510-laptop> i'm going to have lunch and visit with the family a bit
[19:00] <johnc4510-laptop> bbl
[19:01] <tyche> kk
[19:01] <tyche> I'm working on Tunisia, then will probably take a nap.
[19:01] <johnc4510-laptop> k
[19:01] <johnc4510-laptop> later dude
[19:02] <nizarus> tyche, if you need mor info i'm here :)
[19:02] <tyche> I hope not to be any later than I already am.    Hee hee
[19:02] <tyche> nizarus: It looks pretty straight forward.  But I'll keep your offer in mind.  Thanks
[19:03] <nizarus> okidoki
[19:14] <tyche> nizarus: The presentations for ENIS - those are in French?
[19:14] <nizarus> yes tyche :/
[19:14] <nizarus> as it's our studying laungage
[19:15] <tyche> No problem.  I just wanted to indicate that when I put in the link.  That way people wouldn't get confused when they see them.
[19:15] <nizarus> +1 tyche
[19:16] <tyche> And, since I flunked French in high school, I wanted to be sure that I was noting it appropriately.  :-)
[23:19] <mdke> boredandblogging: yes, where an Ubuntu mailing list is available
[23:24] <nizarus> tyche, here ?
[23:28] <tyche> Yep.  Just
[23:29] <nizarus> i rectefied a mistake on the 123# uwn
[23:31] <tyche> did I goof?
[23:32] <nizarus> tyche, the presentation of Ali was in the FOSS day not during enis event :)
[23:33] <tyche> OK, I miss-read.  sorry.
[23:33] <tyche> Thanks for catching that.
[23:35] <nizarus> oh, that's a minimum :)


[16:59] -queuebot:#ubuntu-release- Unapproved: cups-browsed (lunar-proposed/main) [2.0~rc1-0ubuntu1 => 2.0~rc1-0ubuntu1.1] (no packageset)


[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
[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