On Tue, Nov 04, 2014 at 01:38:24AM +, Jonathan de Boyne Pollard wrote:
> Zbigniew Jędrzejewski-Szmek:
> >Distribution packages have been almost all converted to systemd
> > services, with a handful of less-used-packages remaining [1].
>
> Jóhann B Guðmundsson, the erstwhile feature owner for
Zbigniew Jędrzejewski-Szmek:
Distribution packages have been almost all converted to systemd
> services, with a handful of less-used-packages remaining [1].
Jóhann B Guðmundsson, the erstwhile feature owner for Fedora's System 5
rc to systemd units conversion project, states that the conversi
Josh Triplett writes:
> Russ Allbery wrote:
>> There are a ton, but because Debian architectures encode choice of
>> kernel, they're represented in the archive as packages that are not
>> available for kFreeBSD or Hurd, or only available for kFreeBSD, or only
>> available for Hurd.
> That said,
The Wanderer writes:
> On 11/02/2014 at 07:58 PM, Russ Allbery wrote:
>> That's because the point of systemd-shim is to provide the services
>> that logind requires without running systemd as PID 1, so that packages
>> can then depend on logind without requiring systemd be PID 1. That
>> didn't
(Responding quickly to only the part I think I can address well on short
notice, without needing to spend a long time thinking it over.)
On 11/02/2014 at 07:58 PM, Russ Allbery wrote:
> The Wanderer writes:
>> systemd-shim 8.2 and 7.1 do not list a dependency on systemd, or
>> appear to invoke
[I agree wholeheartedly with Russ's points regarding systemd and logind.
One tangential response to a different point:]
Russ Allbery wrote:
> There are a ton, but because Debian architectures encode choice of kernel,
> they're represented in the archive as packages that are not available for
> kFr
The Wanderer writes:
> Is it? I thought part of the problem is that there are packages whose
> upstream supports (or at least enables) compiling with / without
> integration to functionality provided by systemd, and which are provided
> in Debian only as compiled with that functionality enabled,
On Fri, Oct 31, 2014 at 06:07:20PM +0900, Tristan Van Berkom wrote:
> Is systemd the problem or is the GNOME Desktop Environment[0] ?
Could you maybe address this within GNOME first instead of on Debian?
Going to Debian because you have a concern within GNOME seems rather
counter productive. First
On Thu, Oct 30, 2014 at 11:02:22PM +0100, Svante Signell wrote:
> I should not have mentioned any company at` all, sorry :(
That would be the first step, yes.
--
WBR, wRAR
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas
On Fri, 2014-10-31 at 09:37 +0530, Rustom Mody wrote:
> On Thu, 30 Oct 2014 16:54:33 +0900 Tristan van Berkom wrote:
> > [Disclaimer: I am not a debian developer myself and probably do not have
> > the right to vote here, I am however a long time contributor and
> > maintainer in GNOME who has be
Russ Allbery writes:
> Every time I look at that web page, I find another egregious error.
> This time, I just noticed that their minimal PID 1 implementation that
> they think is the be-all and end-all of PID 1 ends with a call to
> execve. I'm going to be laughing about that for the rest of th
Svante Signell writes:
> PID 1 should be as small as possible, see a proposed implementation in:
> http://ewontfix.com/14/
That web page still cracks me up. Not only does the author have no idea
how systemd works and makes multiple claims that are simply false, they
have no idea how *sysvinit*
On Thu, 30 Oct 2014 16:54:33 +0900 Tristan van Berkom wrote:
> [Disclaimer: I am not a debian developer myself and probably do not have
> the right to vote here, I am however a long time contributor and
> maintainer in GNOME who has been watching this thread and I feel I have
> a responsibility
Hi,
Svante Signell:
>
> Why do you cut out the most important part of that message? You all
> trigged on the first part, I should not have mentioned any company at
> all, sorry :(
>
Oh well, if you insist:
>>> The more important that Debian does not drop support for sysvinit then,
>>> until alt
On Thu, Oct 30, 2014 at 01:24:55PM -0500, Jordan Metzmeier wrote:
> On Thu, Oct 30, 2014 at 12:32 PM, Jonas Smedegaard wrote:
> >
> > That does not sound to me as Fedora _only_ supporting systemd, or am I
> > missing something?
> >
>
> It looks like Fedora 20 still has a sysvinit package, but it
> Svante Signell:
> >
> > > And OpenSUSE also dropped support:
> >
> > Of course RHEL and Fedora dropped sysvinit support, they are Redhat
> > derived. Can anybody guess where systemd is developed?
> >
> Well, OpenSUSE (and several others who have by now switched to systemd)
> are not. So?
Why
On Thu, Oct 30, 2014 at 12:32 PM, Jonas Smedegaard wrote:
>
> That does not sound to me as Fedora _only_ supporting systemd, or am I
> missing something?
>
It looks like Fedora 20 still has a sysvinit package, but it won't
exist in the next release[1]. Upstart is also retired[2]. I would
consider
Quoting Josh Triplett (2014-10-30 15:04:04)
> Aigars Mahinovs wrote:
>> Fedora actually is not that decisive, as far as I read here -
>> https://fedorahosted.org/fpc/ticket/243
>
> That ticket turned down the suggested policy of "packages MUST NOT
> support sysvinit". That doesn't mean "packages
Hi,
Svante Signell:
>
> > And OpenSUSE also dropped support:
>
> Of course RHEL and Fedora dropped sysvinit support, they are Redhat
> derived. Can anybody guess where systemd is devloped?
>
Well, OpenSUSE (and several others who have by now switched to systemd)
are not. So?
Please stop the co
On Thu, Oct 30, 2014 at 11:12 PM, Svante Signell wrote:
> Can anybody guess where systemd is devloped?
No need to guess when they have git logs:
http://cgit.freedesktop.org/systemd/systemd/log/
I recognise people from these distros in the git logs: debian mageia
redhat archlinux ubuntu tizen su
> >
> > ArchLinux is clearly dropping sysvinit. RHEL documentation also seems
> > to imply that Sysvinit and Upstart are both dropped in 7+.
> >
> > Fedora actually is not that decisive, as far as I read here -
> > https://fedorahosted.org/fpc/ticket/243
>
> It wasn't 19 months ago, but is pett
On Thu, Oct 30, 2014 at 09:46:44AM +, Adam D. Barratt wrote:
> fwiw, as this seems to be a commonish error - you mean "could not
> care less". People who could care less by definition do care.
It's an en_US thing, I think.
http://public.wsu.edu/~brians/errors/couldcare.html
--
To UNSUBSCRI
At Thu, 30 Oct 2014 14:32:29 +0200,
Aigars Mahinovs wrote:
>
> On 30 October 2014 12:24, Cameron Stewart wrote:
> > On Thu, Oct 30, 2014 at 9:06 PM, Aigars Mahinovs wrote:
> >> Have other distros switched to _only_ supporting systemd? Changing the
> >> default is not the same. This is not a rhet
Aigars Mahinovs wrote:
> Fedora actually is not that decisive, as far as I read here -
> https://fedorahosted.org/fpc/ticket/243
That ticket turned down the suggested policy of "packages MUST NOT
support sysvinit". That doesn't mean "packages MUST support sysvinit",
or "packages MUST NOT depend o
On 30 October 2014 12:24, Cameron Stewart wrote:
> On Thu, Oct 30, 2014 at 9:06 PM, Aigars Mahinovs wrote:
>> Have other distros switched to _only_ supporting systemd? Changing the
>> default is not the same. This is not a rhetorical question - it would
>> actually be useful to know if other dist
On Thu, Oct 30, 2014 at 9:06 PM, Aigars Mahinovs wrote:
> Have other distros switched to _only_ supporting systemd? Changing the
> default is not the same. This is not a rhetorical question - it would
> actually be useful to know if other distros have actually already
> abandoned support for non-s
On 30 October 2014 11:43, Matthias Urlichs wrote:
> Arguments by popularity are not going to sway anybody here. Otherwise I
> could shut you up with a simple "most other distros have switched and are
> mostly-happy with it". :-P
Have other distros switched to _only_ supporting systemd? Changing t
Matthias Urlichs wrote:
Hi,
Florian Lohoff:
There are tons of people who think that all the above functionality does
not belong to a init systemd or ecosystem.
There are also tons of people who could care less, as long as it gets the
job done.
Then there are tons of people who are _very_ hap
On 2014-10-30 9:43, Matthias Urlichs wrote:
Hi,
Florian Lohoff:
There are tons of people who think that all the above functionality
does
not belong to a init systemd or ecosystem.
There are also tons of people who could care less, as long as it gets
the
job done.
fwiw, as this seems to be
Hi,
Florian Lohoff:
> There are tons of people who think that all the above functionality does
> not belong to a init systemd or ecosystem.
>
There are also tons of people who could care less, as long as it gets the
job done.
Then there are tons of people who are _very_ happy about the fact that
Hi,
On Wed, Oct 29, 2014 at 02:51:57PM +, Marco d'Itri wrote:
> ijack...@chiark.greenend.org.uk wrote:
>
> >I don't want to be having this conversation again in a year's time,
> > its replacements for syslog,
> You are not required to replace your syslog daemon, and indeed the
> Debian syst
On Thu, Oct 30, 2014 at 10:32:00AM +0200, Aigars Mahinovs wrote:
> This discussion can end for good in two ways:
> * Debian declares that user choice of init systems is important and
> applications must respect that;
> * Debian declares that only systemd is supported;
The currently GRs appear to b
Hi,
On Wed, Oct 29, 2014 at 11:10:59AM +0100, Josselin Mouette wrote:
> Which is why sticking to the lowest common denominator among init
> systems is the worst thing we could do as a project.
I would like to stick with lowest common denominator.
Everyone who likes the feature bloat of any softw
On 30 October 2014 04:35, Marco d'Itri wrote:
> ijack...@chiark.greenend.org.uk wrote:
>
>>If my GR fails I expect a series of bitter rearguard battles over
>>individual systemd dependencies.
> This looks like a great way to encourage people to make systemd
> mandatory just to be done with this on
Ian Jackson writes:
> That's not the problem. The problem is the possibility of packages wich
> requires systemd's syslog replacement, its cron replacement, or its ntpd
> replacement.
This isn't a reason for a GR. This is a reason for Policy saying that
packages must not do that and must inste
ijack...@chiark.greenend.org.uk wrote:
>If my GR fails I expect a series of bitter rearguard battles over
>individual systemd dependencies.
This looks like a great way to encourage people to make systemd
mandatory just to be done with this once and for all... :-)
>That's not the problem. The pro
Ian Jackson wrote:
> Marco d'Itri writes ("Re: Legitimate exercise of our constitutional
> decision-making processes [Was, Re: Tentative summary of the amendments]"):
> > ijack...@chiark.greenend.org.uk wrote:
> > >I don't want to be having this convers
On Wed, Oct 29, 2014, at 20:03, Matthias Urlichs wrote:
> And if that happens with journald, I fully expect that somebody will step
> up and provide a replacement implementation (either of the daemon, or the
> underpinnings it needs) that works without systemd-as-pid1. Just like
> systemd-shim.
Sp
Hi,
Ian Jackson:
> If my GR passes we will only have to have this conversation if those
> who are outvoted do not respect the project's collective decision.
>
As opposed to us having this discussion _now_ because some people
apparently cannot accept the fact that Debian works quite well
without i
On 2014-10-29 16:13, Ian Jackson wrote:
Marco d'Itri writes ("Re: Legitimate exercise of our constitutional
decision-making processes [Was, Re: Tentative summary of the
amendments]"):
ijack...@chiark.greenend.org.uk wrote:
>I don't want to be having this conversation
Marco d'Itri writes ("Re: Legitimate exercise of our constitutional
decision-making processes [Was, Re: Tentative summary of the amendments]"):
> ijack...@chiark.greenend.org.uk wrote:
> >I don't want to be having this conversation again in a year's time,
>
&
On Mittwoch, 29. Oktober 2014, Ian Jackson wrote:
> In the battle between those upstreams and Debian contributors [...]
please, don't mention the war.
signature.asc
Description: This is a digitally signed message part.
On Wed, Oct 29, 2014 at 12:27:40PM +, Ian Jackson wrote:
> Neil McGovern writes ("Re: Legitimate exercise of our constitutional
> decision-making processes [Was, Re: Tentative summary of the amendments]"):
> > As far as I'm aware, we don't actually say that any
ijack...@chiark.greenend.org.uk wrote:
>I don't want to be having this conversation again in a year's time,
And still, I am ready to bet that we will...
>with those upstreams and their like-minded Debian contributors saying
>things like `it is too late now; the world has moved on'.
It is *already
On Wed, Oct 29, 2014 at 02:16:14PM +0200, Aigars Mahinovs wrote:
> On 29 October 2014 13:40, Neil McGovern wrote:
> >> * if we go the MTA/sh route, then we define lowest common denominator
> >> interface of an init system and only init systems providing that
> >> (possibly with a systemd-shim) can
Neil McGovern writes ("Re: Legitimate exercise of our constitutional
decision-making processes [Was, Re: Tentative summary of the amendments]"):
> As far as I'm aware, we don't actually say that anywhere. Applications can
> only /rely/ on those interfaces, but it&#
Philip Hands writes ("Re: Legitimate exercise of our constitutional
decision-making processes [Was, Re: Tentative summary of the amendments]"):
> I thought you said that your GR (i.e. option 1) was effectively a NOP
> for Jessie (that's certainly how I read the text of y
On 29 October 2014 13:40, Neil McGovern wrote:
>> * if we go the MTA/sh route, then we define lowest common denominator
>> interface of an init system and only init systems providing that
>> (possibly with a systemd-shim) can be init systems in the archive and
>> also applications can only depend
On Tue, Oct 28, 2014 at 06:31:43PM +0200, Aigars Mahinovs wrote:
> On 28 October 2014 18:20, Russ Allbery wrote:
> > With all of those facilities, we've taken different approaches; with the
> > mail transport agent, for example, we've defined an interface that all
> > mail transport agents are req
Aigars Mahinovs writes ("Re: Legitimate exercise of our constitutional
decision-making processes [Was, Re: Tentative summary of the amendments]"):
> This is an interesting insight. It also can be used to identify
> possible solutions for the current issue:
>
> * if we go the
Hi,
Le mercredi 29 octobre 2014 à 09:22 +, Philip Hands a écrit :
> Of course, for the likes of Gnome, voting for Option 1 really will have
> an immediate effect, which will be to completely demotivate our Gnome
> maintainers, since this would be a vote against them.
>
> I think Debian withou
[cross-post to -project dropped]
Hi Ian,
Ian Jackson writes:
> Thanks to Steve for his perceptive and well-reasoned article.
>
> Steve Langasek writes ("Legitimate exercise of our constitutional
> decision-making processes [Was, Re: Tentative summary of the amendments]"):
>> There are also a l
(Dropping -project)
Le mardi, 28 octobre 2014, 17.26:32 Ian Jackson a écrit :
> Thanks to Steve for his perceptive and well-reasoned article.
>
> Steve Langasek writes:
> > There are also a lot of Debian users who are afraid of what the
> > future holds for an OS that they love very much; and the
Steve, thanks for writing up your note.
I strongly agree that Ian's resolution is legitimate. It's not a abuse
of process, it's reasonably to bring forward.
I also think Charles's amendment is legitimate in the same sense: to say
that we as a community do not choose to act as a community in this
Josselin Mouette writes:
> Russ Allbery wrote:
> If GNOME supported being built without those features, yes, it's
> fairly straightforward. I probably overstated it by saying it's
> trivial, but I don't think it would be that hard. But that's
> from the *packag
Russ Allbery wrote:
If GNOME supported being built without those features, yes, it's fairly
straightforward. I probably overstated it by saying it's trivial, but I
don't think it would be that hard. But that's from the *packaging*
perspective, which is the part o
On 10/28/2014 at 12:20 PM, Russ Allbery wrote:
> The Wanderer writes:
>
>> What I'm thinking of is cases where upstream has decided to depend
>> on functionality that is provided by one init system but not by
>> others, without graceful runtime fallback - compile-time choices,
>> essentially, wh
On 28 October 2014 18:20, Russ Allbery wrote:
> With all of those facilities, we've taken different approaches; with the
> mail transport agent, for example, we've defined an interface that all
> mail transport agents are required to implement, and MTA implementations
> that don't implement that i
The Wanderer writes:
> What I'm thinking of is cases where upstream has decided to depend on
> functionality that is provided by one init system but not by others,
> without graceful runtime fallback - compile-time choices, essentially,
> where functionality is omitted if the init system is not p
On 28 October 2014 04:29, Anthony Towns wrote:
> The corresponding question for services versus init systems would be:
>
> - package "foo" has a .service file upstream, but no init script
> - Alice packages foo, doesn't write an init script, and uploads it to
> unstable
> - it's automatically
(I wonder about the extent to which this remains on-topic... I didn't
hesitate about my previous post, since it was relatively brief and
addressed what I thought was an important and relevant single point, but
this is considerably longer and gets rather farther afield.)
On 10/27/2014 at 11:54 PM,
The Wanderer writes:
> Just as a note, one difference here is that there is support in the
> archive and package-distribution mechanisms for having multiple versions
> of a package for different architectures or (I think?) kernels, so that
> you can build a version with some optional features for
On 10/27/2014 at 10:29 PM, Anthony Towns wrote:
> On 28 October 2014 02:36, Steve Langasek wrote:
>>> It's clear that many who support systemd balk at the idea they
>>> might not be allowed to leverage systemd-specific features in
>>> Debian.
>
> I'm not sure I've seen people seriously proposin
-project dropped -- no need to spam multiple lists, and -vote seems
like the right place for this topic to me.
On 28 October 2014 02:36, Steve Langasek wrote:
> On Fri, Oct 24, 2014 at 01:32:36PM +, Anthony Towns wrote:
>> On Fri, Oct 24, 2014 at 01:48:33PM +0300, Aigars Mahinovs wrote:
>> >
Steve Langasek wrote:
> On Fri, Oct 24, 2014 at 01:32:36PM +, Anthony Towns wrote:
> > If you were literally beating people with a stick for not testing their
> > packages with other init systems, that would certainly be compulsion, no?
> > Using policy and RC bugs as a metaphorical stick to be
65 matches
Mail list logo
