Re: General Resolution: non-free firmware: results

2022-10-05 Thread Simon McVittie
On Wed, 05 Oct 2022 at 16:34:27 +0200, Philip Hands wrote: > I didn't want to inflict work on the debian-cd > team, and I assume that nobody will object if volunteers turn up to help > build/test the free images. If they're built and tested, I'm pretty sure > they'll be published. As one of the

Re: Possible draft non-free firmware option with SC change

2022-09-12 Thread Simon McVittie
On Mon, 12 Sep 2022 at 19:20:29 +0200, Simon Josefsson wrote: > Steve McIntyre writes: > > Many common laptops in the last 5-10 years don't come with wired > > ethernet; it's becoming rarer over time. They ~all need firmware > > loading to get onto the network with wifi. Many now need firmware

Re: Draft ballot voting secrecy GR

2022-03-12 Thread Simon McVittie
On Sat, 12 Mar 2022 at 18:09:20 +0100, Kurt Roeckx wrote: > Choice 3: Reaffirm public voting > > > ince we can either have [...] I assume this was meant to start with "Since"? smcv

Re: GR: Change the resolution process (corrected)

2021-11-25 Thread Simon McVittie
I've lost track of who wrote: > > > Suggest making this "None of the above" instead of "Further discussion" > > > to avoid two different default options for TC decisions vs project > > > decisions. On Thu, 25 Nov 2021 at 10:28:55 -0600, Gunnar Wolf wrote: > I would prefer the change to extend

Re: Draft proposal for resolution process changes

2021-09-28 Thread Simon McVittie
On Tue, 28 Sep 2021 at 13:56:21 +0200, Karsten Merker wrote: > In this case the chair surely wouldn't vote to overrule > themselves as that would be a completely nonsensical behaviour, The casting vote cannot be used to select an option that is not in the Schwartz set (loosely: it can only be

Re: New option for the RMS/FSF GR: reaffirm the values of the majority

2021-04-03 Thread Simon McVittie
On Sat, 03 Apr 2021 at 21:46:08 +0200, someone claiming to be Enrico Zini wrote: > We explicitly refuse to acknowledge irrelevant political issues I was surprised to read this apparently coming from Enrico, particularly since it doesn't seem consistent with what Enrico has said in other threads

Re: Q to all candidates: NEW queue

2020-03-28 Thread Simon McVittie
On Fri, 27 Mar 2020 at 23:06:55 +, Holger Levsen wrote: > another option would be 'unstable-proposed' (or whatever) where packages get > uploaded to, and which only gets moved to 'unstable' if they don't fail > piuparts, > autopkgtests (plain build tests) and so forth... Do you mean this to

Re: Some thoughts about Diversity and the CoC

2019-12-13 Thread Simon McVittie
On Thu, 12 Dec 2019 at 23:54:16 +, Scott Kitterman wrote: > I think when people personally feel excluded/diminished/pick your term > then it's appropriate to work on how to frame things to see how to make > them feel welcome (e.g. if someone is more comfortable being referred > to by they,

Re: If we're Going to Have Alternate Init Systems, we need to Understand Apt Dependencies

2019-12-08 Thread Simon McVittie
On Sun, 08 Dec 2019 at 09:37:07 +, Anthony DeRobertis wrote: > it seems like there is an alternative — have them provided by > a different package. Probably one package providing quite a few of > them. It'd need some way to only try to start installed daemons, but > that sounds solvable. Not

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

2019-12-03 Thread Simon McVittie
On Mon, 02 Dec 2019 at 00:28:54 +0100, Simon Richter wrote: > Wasn't there a plan to add support for containers managed through > systemd that have filtered access to the system dbus, or is that just a > special case of a service unit? As a general rule, "heavyweight" containers with their own

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

2019-12-02 Thread Simon McVittie
On Mon, 02 Dec 2019 at 04:26:53 +0100, Simon Richter wrote: > My expectation was that with systemd, dbus activation functionality > would have moved into the main systemd binary for better process > tracking and to avoid code duplication with the other activation methods. Yes ish, but on an

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

2019-12-01 Thread Simon McVittie
On Sun, 01 Dec 2019 at 22:14:06 +0100, Laurent Bigonville wrote: > It's bin:libpam-systemd that pulls bin:systemd-sysv (the package that makes > systemd the init on the system), not bin:systemd. Here it's dbus-user-session > that pulls it because it needs a logind (dunno if it works with elogind)

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

2019-12-01 Thread Simon McVittie
On Sun, 01 Dec 2019 at 22:02:31 +0100, Simon Richter wrote: > In that particular case, the user session must be available to allow > activation of gsettingsd via dbus There is no such thing as gsettingsd. Presumably you mean dconf-service (which is conceptually one of many backends, although in

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

2019-12-01 Thread Simon McVittie
On Sun, 01 Dec 2019 at 11:13:46 -0800, Russ Allbery wrote: > Simon Richter writes: > > Right, but the dependency chain is there to make sure the package is > > usable on systemd systems > > My recollection is that these dependencies are mostly about either making > sure user sessions are

Re: Please drop/replace the use of the term "diversity"

2019-11-27 Thread Simon McVittie
On Wed, 27 Nov 2019 at 11:27:13 +, Chris Lamb wrote: > May I gently request we replace the use of the word "diversity" > throughout the "init systems and systemd" General Resolution prior to > it being subject to a plebiscite? Thank you for raising this, Chris. I agree. I have been