Hi!
On Fri, 2019-11-01 at 11:36:19 +, Simon McVittie wrote:
> On Thu, 31 Oct 2019 at 17:51:28 -0700, Russ Allbery wrote:
> > I think we should adopt sysusers.d fragments as the preferred mechanism
> > for creating system users
>
> I have been tempted to write a small reimplementation of
On Fri, 01 Nov 2019 at 14:16:37 +0100, Ansgar wrote:
> Possibly also tmpfiles, but without an init system nothing would start
> the service and it would have to be invoked manually. Maintainer
> scripts might use it though to setup directories in /var/lib or similar
> locations.
Yes, that's
On Di, Nov 05, 2019 at 05:45:34 +0100, Ansgar wrote:
Simon Richter writes:
Yes, that's one of the questions I have asked: is systemd a core
system component that we want to provide a stable release for, or is
it one of the peripheral packages that users can upgrade to
a backported version if
Simon Richter writes:
> On Sat, Nov 02, 2019 at 07:40:52PM +0100, Thomas Goirand wrote:
>> There's no need to do that. If a backported package is using such
>> features, then it just should depend on the correct version of systemd.
>> You may have seen that systemd 242 is already in
Hi,
On Sat, Nov 02, 2019 at 07:40:52PM +0100, Thomas Goirand wrote:
> There's no need to do that. If a backported package is using such
> features, then it just should depend on the correct version of systemd.
> You may have seen that systemd 242 is already in buster-backports...
Yes, that's
On Thu, Oct 31, 2019 at 03:45:47PM +0100, Marco d'Itri wrote:
> http://www.islinuxaboutchoice.com/
https://grep.be/blog/en/computer/cluebat/Systemd__Devuan__and_Debian/
--
To the thief who stole my anti-depressants: I hope you're happy
-- seen somewhere on the Internet on a photo of a
> "Svante" == Svante Signell writes:
Svante> Marco, I think your information about elogind is not
Svante> up-to-date: https://tracker.debian.org/pkg/elogind
Svante> testing migrations: excuses: Migration status for elogind
Svante> (239.3+20190131-1+debian1 to
On 11/1/19 3:20 PM, Simon Richter wrote:
>> If we do need to have a GR, we need to be very careful how the choices
>> are worded. We should be clear whether we are giving carte blanche
>> for Debian developers to use every possible systemd feature under the
>> sun, whether or not there are
Vincent Bernat writes:
> An alternative for many system users is to use the DynamicUser feature
> of systemd.
Yeah, I completely agree, and we haven't even started talking about that
yet. This is what I mean by ten or more facilities like this that we
probably want to approach from the same
Hi,
On Thu, Oct 31, 2019 at 04:32:28PM -0400, Theodore Y. Ts'o wrote:
> That's true SO FAR. The fact remains that systemd has *tons* and
> *tons* of new features which to date, aren't yet getting used in huge
> numbers of open source software packages or in Debian packaging --- YET.
I think
Simon McVittie writes:
> On Thu, 31 Oct 2019 at 17:51:28 -0700, Russ Allbery wrote:
>> I think we should adopt sysusers.d fragments as the preferred mechanism
>> for creating system users
>
> I have been tempted to write a small reimplementation of systemd-sysusers
> suitable for init-less
On 01.11.19 02:33, Thomas Goirand wrote:
...the bigger question is: why systemd-sysusers is part of systemd, and
not a standalone thing, which we could make an essential package. If we
want it to be part of a package standard toolkit, it means systemd
becomes an essential package, which isn't
On Thu, 31 Oct 2019 at 17:51:28 -0700, Russ Allbery wrote:
> I think we should adopt sysusers.d fragments as the preferred mechanism
> for creating system users
I have been tempted to write a small reimplementation of systemd-sysusers
suitable for init-less containers and sysvinit systems, so
On 11/1/19 3:16 AM, Russ Allbery wrote:
> Thomas Goirand writes:
>
>> ...the bigger question is: why systemd-sysusers is part of systemd, and
>> not a standalone thing, which we could make an essential package. If we
>> want it to be part of a package standard toolkit, it means systemd
>>
On 11/1/19 9:21 AM, Martin Steigerwald wrote:
> However, there are only a few
> really large public cloud providers and most of them are US companies.
I would count at least OVH as a "really large public cloud provider",
yet they aren't originally from the US. There's also countless small
Martin Steigerwald writes:
> Of course that raises the question on what relationship with a
> downstream like Devuan to aim for.
Debian has so many downstream distributions, one more fringe
distribution doesn't make any difference in relationships with
downstream distributions.
Besides that,
On Fri, 2019-11-01 at 06:47 +, Adam D. Barratt wrote:
> On Fri, 2019-11-01 at 00:54 +0100, Svante Signell wrote:
> > On Thu, 2019-10-31 at 22:40 +0100, Marco d'Itri wrote:
> > > On Oct 31, Svante Signell wrote:
> > >
> >
> > Marco, I think your information about elogind is not up-to-date:
>
Martin Steigerwald - 01.11.19, 09:25:07 CET:
> Adam D. Barratt - 01.11.19, 07:47:48 CET:
> > On Fri, 2019-11-01 at 00:54 +0100, Svante Signell wrote:
> > > On Thu, 2019-10-31 at 22:40 +0100, Marco d'Itri wrote:
> > > > On Oct 31, Svante Signell wrote:
> > > > > When elogind enters testing there
❦ 31 octobre 2019 17:51 -07, Russ Allbery :
> I think we should adopt sysusers.d fragments as the preferred mechanism
> for creating system users (with some rules, such as a standard for how to
> name the users and a requirement that the UID be specified as - unless one
> goes through the normal
Adam D. Barratt - 01.11.19, 07:47:48 CET:
> On Fri, 2019-11-01 at 00:54 +0100, Svante Signell wrote:
> > On Thu, 2019-10-31 at 22:40 +0100, Marco d'Itri wrote:
> > > On Oct 31, Svante Signell wrote:
> > > > When elogind enters testing there would be many more people
> > > > running
> > > > Debian
Hi Thomas,
Thomas Goirand - 01.11.19, 01:26:58 CET:
> On 10/31/19 5:13 PM, Martin Steigerwald wrote:
> > It is similar with "the" cloud.
>
> Why is there quotes around "the", and why do you think there's only a
> single instance of a cloud out there?
Well exactly for the reason that there is no
On Fri, 2019-11-01 at 00:54 +0100, Svante Signell wrote:
> On Thu, 2019-10-31 at 22:40 +0100, Marco d'Itri wrote:
> > On Oct 31, Svante Signell wrote:
> >
> > > When elogind enters testing there would be many more people
> > > running
> > > Debian with sysvinit/elogind. elogind is needed for
Thomas Goirand writes:
> ...the bigger question is: why systemd-sysusers is part of systemd, and
> not a standalone thing, which we could make an essential package. If we
> want it to be part of a package standard toolkit, it means systemd
> becomes an essential package, which isn't really what
On 11/1/19 1:51 AM, Russ Allbery wrote:
> Thomas Goirand writes:
>
>> IMO, this type of decision should go in the policy, case by case, and
>> I'm not sure a GR is the solution: it's going to be a generic "use all
>> of systemd" vs a "be careful to use only things implemented elsewhere".
>> I
Thomas Goirand writes:
> IMO, this type of decision should go in the policy, case by case, and
> I'm not sure a GR is the solution: it's going to be a generic "use all
> of systemd" vs a "be careful to use only things implemented elsewhere".
> I don't think this works, as often, there is maybe a
Hi Martin!
On 10/31/19 5:13 PM, Martin Steigerwald wrote:
> It is similar with "the" cloud.
Why is there quotes around "the", and why do you think there's only a
single instance of a cloud out there?
> Yet, there are attempts to disrupt the cloud already by making
> machines powerful enough
On 10/31/19 9:32 PM, Theodore Y. Ts'o wrote:
> Let's take e2fsprogs for example. I had applied a patch which had a
> cron script alternative on top of the timer unit file. It turns out
> the cron script was buggy, and it took multiple tries before we got it
> right --- because I don't maintain a
On Thu, 2019-10-31 at 22:40 +0100, Marco d'Itri wrote:
> On Oct 31, Svante Signell wrote:
>
> > When elogind enters testing there would be many more people running
> > Debian with sysvinit/elogind. elogind is needed for desktop usage
> > when not using systemd as PID 1.
> elogind is already in
On 10/31/19 11:30 PM, Russ Allbery wrote:
> Craig Small writes:
>> On Fri, 1 Nov 2019 at 08:27, Thomas Goirand wrote:
>
>>> However, this doesn't mean that anything non-systemd must implement all
>>> things that systemd does, or just die. It really doesn't make sense to
>>> tell that, for
Craig Small writes:
> On Fri, 1 Nov 2019 at 08:27, Thomas Goirand wrote:
>> However, this doesn't mean that anything non-systemd must implement all
>> things that systemd does, or just die. It really doesn't make sense to
>> tell that, for example, OpenRC should be forced into implementing a
>>
On Fri, 1 Nov 2019 at 08:27, Thomas Goirand wrote:
> However, this doesn't mean that anything non-systemd must implement all
> things that systemd does, or just die. It really doesn't make sense to
> tell that, for example, OpenRC should be forced into implementing a
> parser of .timer files,
On Oct 31, Svante Signell wrote:
> When elogind enters testing there would be many more people running
> Debian with sysvinit/elogind. elogind is needed for desktop usage when
> not using systemd as PID 1. And as said numerous times Debian
elogind is already in testing: I will be delighted to
On 10/30/19 10:54 PM, Josh Triplett wrote:
> It seems evident based on the history of such efforts that there is
> *not* sufficient people/interest/motivation to reimplement the majority
> of systemd features, let alone doing so in a way that meets the
> additional constraints imposed on such
On Thu, Oct 31, 2019 at 01:44:58PM +, Ian Jackson wrote:
> Martin Steigerwald writes ("Re: Integration with systemd"):
> > As to this, I did not yet see that the migration of elogind to testing
> > has been accepted.
>
> Yes.
>
> I find these conversatio
On Thu, Oct 31 2019, Theodore Y. Ts'o wrote:
> It may be that sysvinit is doomed. But we shouldn't be accelerating
> the process.
You are quite right. I have also found myself wondering, though, what
are the BSDs doing? Clearly systemd isn't going to be workable for
them. Is their approach
Svante Signell writes:
> And as said numerous times Debian maintainers don't have to create
> sysvinit scripts, they have only to _accept_ patches to add or fix
> sysvinit scripts.
Even as someone who does not really care about the init system (being a
desktop user, I use whatever is the base
pate nor
> require tight integration with systemd, and that software is still useful,
> so it makes sense to ship it. It is niche, but it is the niche we have been
> traditionally good at, so I don't see a reason for leaving that and
> focusing on an oversaturated field without even marg
Ian Jackson writes:
> The question is: are we going to permit those technical contributions
> into Debian ? Are we going to keep making it awkward or are we actually
> going to _welcome_ them ?
> Are we going to say to those of our contributors who want to see a nice
> tidy hegemony, "sure,
Should we look at
downloads or at popcon statistics? Do autobuilders pulling systemd-sysv as
a dependency of libgtk-3-dev count?
My point with that sentence is a different one though: a lot of Free
Software exists outside the Linux sphere that does neither anticipate nor
require tight i
On Thu, 2019-10-31 at 15:45 +0100, Marco d'Itri wrote:
> > On Oct 31, Simon Richter wrote:
> >
> > No, and that's not our job. There are a lot of people out there
> > building non-systemd systems.
> Data says: not really a lot.
When elogind enters testing there would be many more people running
Russ Allbery wrote:
> Josh Triplett writes:
> > Part of the problem is that the people interested in sysvinit don't tend
> > to care about those features and often argue that others shouldn't care
> > either, and the people interested in those features don't tend to care
> > about sysvinit. It's
Marco d'Itri - 31.10.19, 15:45:47 CET:
> On Oct 31, Simon Richter wrote:
[…]
> > The freedom to configure a system without things I do not want is
> > one of the main reasons that made me switch over from Windows to
> > Debian, a bit more than twenty years ago.
>
>
question would also be: Are we just following
the lead of other distributions? Or are we actually inventing things not
seen elsewhere. Just implementing more of Systemd integration would not
be anything new. Others have been there before. What makes Debian unique
these days if not the community?
--
Martin
On Thu, Oct 31, 2019 at 01:19:56PM +0100, Martin Steigerwald wrote:
> alienate me away from Debian. This laptop, for the sake of packaging
> flexible I/O tester, is the last of my machines still running on Debian.
> All the others are running Devuan. I am not looking back. I have no
> intention
On Oct 31, Simon Richter wrote:
> However, a lot of our software comes from the BSD world and will never
> fully switch to systemd, and that software is often used in server contexts
> by people who know exactly what they are doing. I don't see why we
> shouldn't support these people anymore,
Martin Steigerwald writes ("Re: Integration with systemd"):
> As to this, I did not yet see that the migration of elogind to testing
> has been accepted.
Yes.
I find these conversations draining, exhausting, awful. I am sure
that most people who are sceptical of systemd agre
Martin Steigerwald - 31.10.19, 13:19:56 CET:
> While I do not expect maintainers of Debian packages to implement
> support for alternate init systems themselves, I still believe if
> someone works constructively and consistently on making such support
> available in Debian, it would be good to be
Hi!
I thought about just silently unsubscribing from debian-devel… but as I
got the impression that almost no one argues for the freedom to choose
the init system here in this thread, I decided to speak up:
Theodore Y. Ts'o - 31.10.19, 00:57:48 CET:
> And if we do this in core Debian
Russ Allbery writes:
> Josh Triplett writes:
>
>> Part of the problem is that the people interested in sysvinit don't tend
>> to care about those features and often argue that others shouldn't care
>> either, and the people interested in those features don't tend to care
>> about sysvinit. It's
Simon Richter writes:
> On Wed, Oct 30, 2019 at 05:17:57PM -0700, Russ Allbery wrote:
>
>> One can individually say that one doesn't care about those features, but
>> we just cannot say Debian as a whole should not care about those features.
>> It doesn't work. We have to take an affirmative
it files given
- apt being able to blacklist packages and hide packages that depend on
those
This cuts both ways: for packages with optional systemd integration, I'd
expect "sysvinit" variants to pop up, and we don't want users running
systemd to accidentally install these if a tighter
On Oct 31, "Theodore Y. Ts'o" wrote:
> handled on a case by case basis. Exactly how much of a win do we get
> if we use a particular systemd feature in core Debian packaging? How
> hard is it to emulate that for non-systemd systems? I don't think
> that decision can be made in the abstract,
Josh Triplett writes:
> Part of the problem is that the people interested in sysvinit don't tend
> to care about those features and often argue that others shouldn't care
> either, and the people interested in those features don't tend to care
> about sysvinit. It's difficult to motivate people
On Wed, Oct 30, 2019 at 01:51:07PM -0700, Josh Triplett wrote:
> > So mostly, this isn't going to be up to us. It's going to be up to
> > the upstream. Eventually, for each package where upstream has chosen
> > to use these technologies, our choice will be (a) to drop the package
> > from
Hello,
On Wed 30 Oct 2019 at 12:16PM -07, Russ Allbery wrote:
> It's not clear to me whether we need a faster policy *process* or if we
> just need more hands, but I completely agree that the current policy
> process is too slow. I haven't had much time to work on it for about five
> years; if
Russ Allbery wrote:
> One of the options that I find interesting is to enumerate a list of
> features in unit files that Debian supports, and require that any
> Debian init system be able to handle unit files with those features.
> This standardzes an *API* for both package maintainers and
On Wed, Oct 30, 2019 at 03:30:17PM -0400, Theodore Y. Ts'o wrote:
> On Wed, Oct 30, 2019 at 05:14:02AM -0700, Josh Triplett wrote:
> > Today, people can't use systemd persistent timers in place of cron (and
> > in place of anacron's "wake up periodically" approach). You have to have
> > a cron job
> "Russ" == Russ Allbery writes:
Russ> I also completely agree with Josh's message and with your
Russ> other message that we need to make a lot of decisions about
Russ> what systemd features packages can assume, or what workarounds
Russ> they have to have in place if they
"Theodore Y. Ts'o" writes:
> So mostly, this isn't going to be up to us. It's going to be up to
> the upstream. Eventually, for each package where upstream has chosen
> to use these technologies, our choice will be (a) to drop the package
> from Debian, (b) add backwards compatibility support
On Wed, Oct 30, 2019 at 05:14:02AM -0700, Josh Triplett wrote:
>
> Today, people can't use systemd persistent timers in place of cron (and
> in place of anacron's "wake up periodically" approach). You have to have
> a cron job as well, and there's no good mechanism to automatically
> prevent a
Simon Richter writes:
> I believe this GR is less about technical than about organizational
> aspects. If we want to fully adopt systemd, we need a faster policy
> process, which will disenfranchise users with less-common use cases,
> because there is no time to integrate their concerns (I'm
[Please CC me on replies.]
Simon Richter wrote:
> On Wed, Oct 30, 2019 at 05:14:02AM -0700, Josh Triplett wrote:
> > If we're going to have a GR, part of the goal should be to either
> > confirm the current state that we're never moving very far past the
> > capabilities of sysvinit even when
Hi,
On Wed, Oct 30, 2019 at 05:14:02AM -0700, Josh Triplett wrote:
> If we're going to have a GR, part of the goal should be to either
> confirm the current state that we're never moving very far past the
> capabilities of sysvinit even when most people don't run it, or that
> we're allowed to
Russ Allbery wrote:
> If we're not, we should unambiguously free people from doing
> additional work that they don't want to do and can't test easily
I really appreciate your mail, and I think this point is entirely true.
I also feel there's a key detail to add here, in that this isn't just about
64 matches
Mail list logo
