On Fri, 2019-12-06 at 22:50:32 +0100, Kurt Roeckx wrote:
> That's 5, I'll update everything.
Thanks for this Kurt! Much appreciated!
Regards,
Guillem
Quoting Kurt Roeckx (2019-12-06 23:06:28)
> On Fri, Dec 06, 2019 at 10:50:32PM +0100, Kurt Roeckx wrote:
> >
> > That's 5, I'll update everything.
>
> The website should be updated very soon.
Thanks a lot, Kurt!
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843
On Fri, Dec 06, 2019 at 09:51:50PM +0100, Guillem Jover wrote:
> [ Sorry, resending signed this time around. :/ ]
>
> Hi!
>
> Ok, so here's what I'd like (or would have liked) to get into the ballot,
> given the new context after the addition of the combined D+G option. But
> it's not very clear
On Fri, Dec 06, 2019 at 10:50:32PM +0100, Kurt Roeckx wrote:
>
> That's 5, I'll update everything.
The website should be updated very soon.
Kurt
On Fri, Dec 06, 2019 at 09:51:50PM +0100, Guillem Jover wrote:
> X<
> Title: Reaffirm our commitment to support portability and multiple
> implementations
>
> Principles
> ~~
>
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different soft
On Friday, December 6, 2019 3:59:43 PM EST Kurt Roeckx wrote:
> On Fri, Dec 06, 2019 at 09:04:39PM +0100, Guillem Jover wrote:
> > Hi!
> >
> > Ok, so here's what I'd like (or would have liked) to get into the ballot,
> > given the new context after the addition of the combined D+G option. But
> >
On Fri, Dec 06, 2019 at 04:48:48PM -0500, Scott Kitterman wrote:
>
> Seconded.
That's 5, I'll update everything.
Kurt
On Friday, December 6, 2019 3:51:50 PM EST Guillem Jover wrote:
> [ Sorry, resending signed this time around. :/ ]
>
> Hi!
>
> Ok, so here's what I'd like (or would have liked) to get into the ballot,
> given the new context after the addition of the combined D+G option. But
> it's not very clear
> X<
> Title: Reaffirm our commitment to support portability and multiple
> implementations
>
> Principles
> ~~
>
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with
Hi
On 2019/12/06 22:51, Guillem Jover wrote:
> [ Sorry, resending signed this time around. :/ ]
>
> Hi!
>
> Ok, so here's what I'd like (or would have liked) to get into the ballot,
> given the new context after the addition of the combined D+G option. But
> it's not very clear to me whether thi
* Guillem Jover: " Option G update [signed] (was Re: Proposal: Reaffirm our
commitment to support portability and multiple implementations)" (Fri, 6 Dec
2019 21:51:50 +0100):
> [ Sorry, resending signed this time around. :/ ]
>
> Hi!
>
> Ok, so here's what I&#
On Fri, Dec 06, 2019 at 09:04:39PM +0100, Guillem Jover wrote:
> Hi!
>
> Ok, so here's what I'd like (or would have liked) to get into the ballot,
> given the new context after the addition of the combined D+G option. But
> it's not very clear to me whether this will be acceptable or not to the
>
[ Sorry, resending signed this time around. :/ ]
Hi!
Ok, so here's what I'd like (or would have liked) to get into the ballot,
given the new context after the addition of the combined D+G option. But
it's not very clear to me whether this will be acceptable or not to the
Secretary, and what would
[ dropping all recipients except debian-vote@l.d.o ]
Quoting Guillem Jover (2019-12-06 21:04:39)
> X<
> Title: Reaffirm our commitment to support portability and multiple
> implementations
>
> Principles
> ~~
>
> The Debian project reaffirms its commitment to be the glue that bi
Hi!
Ok, so here's what I'd like (or would have liked) to get into the ballot,
given the new context after the addition of the combined D+G option. But
it's not very clear to me whether this will be acceptable or not to the
Secretary, and what would be the actual procedure to replace the existing
o
Hi,
On Thu, Dec 05, 2019 at 08:32:28AM -0500, The Wanderer wrote:
> At minimum, "X is the default" means "you will get X if you don't take
> any action to avoid doing so". All definitions I can think of seem to
> share that baseline.
> At something like maximum, "X is the default" could be read
On 2019-12-05 at 04:34, Raphael Hertzog wrote:
> Hi,
>
> On Mon, 02 Dec 2019, Guillem Jover wrote:
>
>> Reframing -
>>
>> Why have init systems become such a contentions and toxic issue? I
>> mean yeah, it potentially integrates with many parts of the system,
>> but we do have other com
Hi,
On Mon, 02 Dec 2019, Guillem Jover wrote:
> Reframing
> -
>
> Why have init systems become such a contentions and toxic issue? I mean
> yeah, it potentially integrates with many parts of the system, but we do
> have other components in the distribution with multiple or non-portable
>
Hi Ian,
On Di 03 Dez 2019 13:54:40 CET, Ian Jackson wrote:
* Should I adopt Guillem's framing as a preamble to my own proposal ?
(Should this be a new alternative or a replacement?)
* Would Guillem's framing make a good preamble to Dmitry's option ?
* Or do the supporters of Guillem's opti
In some sense I am asking the same questions as Russ.
Guillem Jover writes ("Reframing (was Re: Proposal: Reaffirm our commitment to
support portability and multiple implementations)"):
> I've to say, that while I think I understand where your and other similar
> reactions
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 ini
I'm going to make a similar point to Sam's but in a slightly different
way that hopefully will help. (Also, I apologize for sounding rather too
absolute in my initial response to your proposal. There were better ways
of phrasing my concerns.)
Guillem Jover writes:
> I'm actually not sure how t
> "Guillem" == Guillem Jover writes:
Guillem> The key here, I guess, is that each situation needs to be
Guillem> evaluated independently, and no magic decision tree will
Guillem> ever fix trying to work things out with other people, in
Guillem> good faith, and trying to find s
guil...@debian.org wrote:
> * The traditional-only way camp: This group outright rejects things
> like systemd, and other similar technologies. Some of this group was
> part of Debian in the past, but found a new home in Devuan. People
I read all my emails with mutt (which I used to maintain)
Hi!
[ I'm sorry this has gotten a bit long, but I assume I'm going to run out
of time for any discussion, due to the imposed timeline, so I'm trying
to put it all upfront. ]
On Sat, 2019-11-30 at 11:54:09 -0700, Bdale Garbee wrote:
> Guillem Jover writes:
> > I think the current GR is incorr
Adam Borowski writes:
> * dependencies on "systemd | other" rather than "other | systemd"; this is
> a no-op on a systemd system (installed by debootstrap before any
> non-base packages) but causes apt to force an init+rc switch elsewhere
It's very likely not a no-op on systemd systems a
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 opt-in
Hi,
On 02.12.19 00:20, Simon McVittie 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 practice
Hi!
I've been busy late yesterday and today, and not been able to reply
to some of the questions presented. I've got an early flight in a few
hours, so I'm unable to finish the draft reply I've started but which
I plan to send tomorrow (Monday). Sorry about this, but the rushed
timeline is not ver
Hi,
On 01.12.19 23:24, Simon McVittie wrote:
> dbus-user-session is not, and probably will not be, usable on non-systemd
> systems. If per-user service managers other than `systemd --user` exist
> and can be configured to provide equivalent semantics, I'd be happy
> to review the necessary integr
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)
>
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 pr
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 available
Simon Richter mailto:sjr%40debian.org>> wrote:
> On 01.12.19 02:54, Russ Allbery wrote:
>
> >> Russ> Could you provide some more information about what your
> >> Russ> concern is here? libsystemd-dev depends only on libsystemd0,
> >> Russ> which has a pretty tiny list of dependencies
Hi,
On 01.12.19 20:13, Russ Allbery wrote:
>> Right, but the dependency chain is there to make sure the package is
>> usable on systemd systems, i.e. we'd have to accept a regression for the
>> systemd case in order to facilitate the non-systemd case, which is what
>> we don't want, or live with
Simon Richter writes:
> Right, but the dependency chain is there to make sure the package is
> usable on systemd systems, i.e. we'd have to accept a regression for the
> systemd case in order to facilitate the non-systemd case, which is what
> we don't want, or live with unrelated packages changi
Hi Russ,
On 01.12.19 18:16, Russ Allbery wrote:
>> https://lists.debian.org/debian-devel/2019/08/msg00278.html
> This is a point that Ian's proposal specifically addresses by accepting
> the possibility that packages will be installable but not usable on
> non-systemd systems in order to avoid t
Hi Adam,
On 12/1/19 12:24 AM, Adam Borowski wrote:
> * there's a lot of use cases where systemd fails[1]. This makes it unfit
> for being the sole init+rc of an universal operating system.
I assume you've opened bugs for all those cases?
If I understand the problems you're mentioning right, th
Simon Richter writes:
> That was a thread I started on debian-devel:
> https://lists.debian.org/debian-devel/2019/08/msg00278.html
> The resolution of that thread seemed to be that people were mostly fine
> with the dependency chain because every decision in the path makes
> sense, even if the
On 01.12.19 02:54, Russ Allbery wrote:
>> Russ> Could you provide some more information about what your
>> Russ> concern is here? libsystemd-dev depends only on libsystemd0,
>> Russ> which has a pretty tiny list of dependencies and shouldn't
>> Russ> require that systemd be runnin
Ian Jackson writes ("Re: Proposal: Reaffirm our commitment to support
portability and multiple implementations"):
> I think your proposal would work well as a preamble to many of the
> other options, notably mine and Dmitry's.
I've read the rest of the thread now. I t
Guillem Jover writes ("Proposal: Reaffirm our commitment to support portability
and multiple implementations"):
> X<
> Title: Reaffirm our commitment to support portability and multiple
> implementations
I really like much of what you write in your proposal.
How
Sam Hartman writes:
>> "Russ" == Russ Allbery writes:
> Russ> Could you provide some more information about what your
> Russ> concern is here? libsystemd-dev depends only on libsystemd0,
> Russ> which has a pretty tiny list of dependencies and shouldn't
> Russ> require that
> "Russ" == Russ Allbery writes:
Russ> Could you provide some more information about what your
Russ> concern is here? libsystemd-dev depends only on libsystemd0,
Russ> which has a pretty tiny list of dependencies and shouldn't
Russ> require that systemd be running so far as I
Adam Borowski writes:
> * request a list of non-systemd-hostile policies to be changed[4], initial
> contents being:
> • an unrelated package forcing an init switch on a straightforward apt
> invocation is RC-buggy (usually caused by an unthoughtful deps ordering)
For the record, I suspe
[I purposefully abstained in participating in this discussion so far, as I
have quite strong views, and I hoped it will stay mostly civilised. But
alas, last developments seem to fails these hopes. Thus, let's help Guillem
improve his proposal.]
On Sat, Nov 30, 2019 at 02:11:56PM -0500, Sam Hart
On Sat, Nov 30, 2019, 4:41 PM Bernd Zeimetz wrote:
> Hi,
>
> > X<
> > Title: Reaffirm our commitment to support portability and multiple
> implementations
>
> ... so how does this help the project? We are all wasting lots of time
> in discussing policy and if we want to support init and f
On Sat, Nov 30, 2019 at 06:46:27PM +0100, Guillem Jover wrote:
>
> I'm thus proposing the following:
That is now on the website.
Kurt
Hi,
> X<
> Title: Reaffirm our commitment to support portability and multiple
> implementations
... so how does this help the project? We are all wasting lots of time
in discussing policy and if we want to support init and friends and if
bugs are RC or not. You are basically saying that
On Sat, Nov 30, 2019 at 08:43:38PM +, Mike Gabriel wrote:
> Seconded.
Your message wasn't signed.
Kurt
On Sat, Nov 30, 2019 at 06:46:27PM +0100, Guillem Jover wrote:
> X<
> Title: Reaffirm our commitment to support portability and multiple
> implementations
>
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or
Hi,
Am Samstag, 30. November 2019 schrieb Guillem Jover:
> Hi!
>
> I think the current GR is incorrectly framing the problem at hand,
> as if it was just an init system selection. It seems to me, that an
> init system is in principle just one of the many technologies we ship
> and integrate. But
> "Bdale" == Bdale Garbee writes:
Bdale> Guillem Jover writes:
>> I think the current GR is incorrectly framing the problem at
>> hand, as if it was just an init system selection.
Bdale> This resonates with me, but...
>> I'm thus proposing the following:
Bdale> I f
Guillem Jover writes:
> I think the current GR is incorrectly framing the problem at hand,
> as if it was just an init system selection.
This resonates with me, but...
> I'm thus proposing the following:
I find this really appealing as a higher-level statement of values and
intent, but unfortu
Guillem Jover writes:
> I'm thus proposing the following:
> X<
> Title: Reaffirm our commitment to support portability and multiple
> implementations
Should this be on the ballot, I will vote it below FD because it provides
essentially no guidance to how to resolve the concrete Policy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Guillem Jover said:
>X<
>Title: Reaffirm our commitment to support portability and multiple
>implementations
>The Debian project reaffirms its commitment to be the glue that binds
>and integrates different software that provides similar or
* Guillem Jover: " Proposal: Reaffirm our commitment to support portability and
multiple implementations" (Sat, 30 Nov 2019 18:46:27 +0100):
> X<
> Title: Reaffirm our commitment to support portability and multiple
> implementations
>
> The Debian project
On Sat, 30 Nov 2019 18:46:27 +0100
Guillem Jover wrote:
[...]
> I'm thus proposing the following:
>
> X<
> Title: Reaffirm our commitment to support portability and multiple
> implementations
>
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates diffe
On Sat, 30 Nov 2019 at 18:46:27 +0100, Guillem Jover wrote:
> I'm thus proposing the following:
>
> X<
> Title: Reaffirm our commitment to support portability and multiple
> implementations
>
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates differe
Quoting Guillem Jover (2019-11-30 18:46:27)
> I'm thus proposing the following:
>
> X<
> Title: Reaffirm our commitment to support portability and multiple
> implementations
>
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that
On Sat, 30 Nov 2019 18:46:27 +0100, Guillem Jover wrote:
> I'm thus proposing the following:
>
> X<
> Title: Reaffirm our commitment to support portability and multiple
> implementations
>
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different
On 30.11.19 18:46, Guillem Jover wrote:
> I'm thus proposing the following:
>
> X<
> Title: Reaffirm our commitment to support portability and multiple
> implementations
>
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that pr
Hi!
I think the current GR is incorrectly framing the problem at hand,
as if it was just an init system selection. It seems to me, that an
init system is in principle just one of the many technologies we ship
and integrate. But at least when it comes to systemd, choosing that in
detriment to anyth
63 matches
Mail list logo
