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
>>
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
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
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
Simon Richter writes:
>> > No, and that's not our job. There are a lot of people out there building
>> > non-systemd systems.
[...]
> 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
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,
Hi,
On Thu, Oct 31, 2019 at 03:45:47PM +0100, Marco d'Itri wrote:
> > That is work we have to do regardless of whether we want to support
> > alternatives or not, but in the simple case we just list what is supported
> > by the systemd version we have decided to ship in the last stable release,
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.
>
>
Theodore Y. Ts'o - 31.10.19, 16:03:29 CET:
> 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
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
Hi,
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 stance on what Debian is
>
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
60 matches
Mail list logo
