Russ Allbery writes:
> My inclination would be to give maintainers technical advice to accept
> integrations with either existing synchronization protocols, but leave it
> as technical advice rather than the binding part of the decision.
I strongly agree.
Bdale
pgpOJBZR_5XNx.pgp
Description:
On 01/04/2014 01:42 AM, Ian Jackson wrote:
> Thomas Goirand writes ("Bug#727708: additional OpenRC information: OpenRC now
> in Debian Experimental!"):
>> OpenRC is now in Debian experimental! \o/
>
> Good, thanks.
>
>> I of course welcome anyone to try OpenRC and report bugs.
>
> Can you point
On Fri, 2014-01-03 at 18:41 -0800, Russ Allbery wrote:
> Uoti Urpala writes:
>
> > One case to consider is what should happen with GNOME if it requires
> > interfaces that nobody has implemented for sysvinit.
>
> The likelihood of this and possible impact is one of the things that I'm
> checking
Bdale Garbee writes ("Bug#727708: init system discussion status"):
> Russ Allbery writes:
> > My inclination would be to give maintainers technical advice to accept
> > integrations with either existing synchronization protocols, but leave it
> > as technical advice rather than the binding part of
Uoti Urpala writes ("Bug#727708: init system discussion status"):
> There are two different kinds of dependencies: dependencies expressed in
> package metadata, and functional dependencies (as in whether the package
> does anything useful with another init). Your earlier wording sounds
> like it wa
Le samedi 04 janvier 2014 à 12:47 +, Ian Jackson a écrit :
> Uoti Urpala writes ("Bug#727708: init system discussion status"):
> > Your earlier wording sounds
> > like it was talking about the former ("installable") and Ian's proposal
> > definitely was (explicitly mentioning package fields), b
Ian Jackson writes:
> Bdale Garbee writes ("Bug#727708: init system discussion status"):
>> Russ Allbery writes:
>>> My inclination would be to give maintainers technical advice to accept
>>> integrations with either existing synchronization protocols, but leave
>>> it as technical advice rather
Commenting as a porter, the decision on default init system might affect
me something like this:
If GNU/Linux defaults to Upstart, it's likely in porters' interest to
get that working as well as possible so we can keep consistency with
Linux arches. I'm really grateful of Dimitri's work on this a
On 01/04/2014 11:21 AM, Steven Chamberlain wrote:
Commenting as a porter, the decision on default init system might affect
me something like this:
If GNU/Linux defaults to Upstart, it's likely in porters' interest to
get that working as well as possible so we can keep consistency with
Linux arch
Anthony Towns writes ("Bug#727708: init system other points, and conclusion"):
> I wonder if folks could clarify what status they expect secondary init
> systems to have in Debian?
Thanks for bringing up this point so very clearly.
I agree entirely with the thrust of your argument. I would very
Russ Allbery writes ("Bug#727708: init system discussion status"):
> Ian Jackson writes:
> > Would that suit you both ?
>
> I may have lost the thread here, but that doesn't sound quite right.
> Wouldn't we want to say that each daemon package should implement the
> native non-forking startup pro
Steven Chamberlain writes ("Bug#727708: init system other points, and
conclusion"):
> Policy may need to explain whether hard systemd requirement is
> permissible, if it should be expressed in package dependencies, or what
> it should do otherwise (e.g. refuse to start, fail with error message,
>
Sjoerd Simons writes:
> Essentially this boils down to whether the logind interfaces will be
> available when using sysvinit. Most of the other interfaces (at least
> for current gnome as in experimental) would cause some functionality to
> either be missing or not work, but wouldn't yield a comp
Ian Jackson writes:
> Russ Allbery writes ("Bug#727708: init system discussion status"):
>> I may have lost the thread here, but that doesn't sound quite right.
>> Wouldn't we want to say that each daemon package should implement the
>> native non-forking startup protocol for the default init sys
Cory writes:
> If Debian go's with systemd they need to use systemd 207 as its
> supported in RHEL 7 so we know it's going to be supported for around 10
> years also why does Debian have systemd 204 in it's repos?? systemd 207
> is way better
Because it's the last version before cgroup handling
Russ Allbery writes ("Bug#727708: init system discussion status"):
> Ian Jackson writes:
> > Are the protocols offered by systemd and upstart each so plainly
> > reasonable, that we are willing to overrule a maintainer who feels they
> > protocol they are asked to support is too ugly or burdensome
Russ Allbery writes ("Bug#727708: init system discussion status"):
> Ian Jackson writes:
> > And the other is that IMO the proposed prescription for non-Linux ports
> > doesn't make sense for systemd. There is little prospect of systemd
> > being "ported" to those systems.
>
> I'd prefer to leav
(Josh, is there some reason why you replied to the TC list directly
rather than the bug report ? You should send your messages to the bug
so they are filed, displayed and archived there. Thanks.)
Josh Triplett writes ("Re: Bug#727708: init system discussion status"):
> Clint Adams wrote:
> > As
Ian Jackson writes ("Re: Bug#727708: init system discussion status"):
> Are you going to vote to overrule a maintainer who says
>
> I have already implemented non-forking readiness protocol X and I
> think support for all init systems in my daemon should be done via
> one protocol. Please
Russ Allbery writes ("Bug#727708: init system discussion status"):
> Ian Jackson writes:
> > It seems daft to go around making two (or perhaps three or more) patches
> > to every daemon when one patch to each daemon, and a couple of
> > compatibility modes in the init systems, would suffice.
>
>
Ian Jackson writes:
> Russ Allbery writes ("Bug#727708: init system discussion status"):
>> I think they are. Furthermore, I don't think there's any likely
>> prospect that either will adopt a socket-based synchronization protocol
>> other than systemd's, so saying that these aren't patches main
Ian Jackson writes:
> Russ Allbery writes ("Bug#727708: init system discussion status"):
>> Whether systemd upstream should support the SIGSTOP protocol is
>> certainly debatable, but I'm very reluctant to support an option that
>> tries to force the systemd maintainers to support the protocol
>>
Russ Allbery writes ("Bug#727708: init system discussion status"):
> I consider the TC, when working properly, to be like a court, not an
> executive or legislature.
One of our roles is to rule on the content of policy. That's much
more like a legislative role.
I think we should see what the oth
Ian Jackson writes:
> The question isn't what you would prefer. The question is this:
> Are you going to vote to overrule a maintainer who says
> I have already implemented non-forking readiness protocol X and I
> think support for all init systems in my daemon should be done via
> one
On 4 January 2014 15:46, Josselin Mouette wrote:
> Le samedi 04 janvier 2014 à 12:47 +, Ian Jackson a écrit :
>> Uoti Urpala writes ("Bug#727708: init system discussion status"):
>> > Your earlier wording sounds
>> > like it was talking about the former ("installable") and Ian's proposal
>> >
On Fri, Jan 03, 2014 at 04:40:54PM -0800, Russ Allbery wrote:
> > And the other is that IMO the proposed prescription for non-Linux ports
> > doesn't make sense for systemd. There is little prospect of systemd
> > being "ported" to those systems.
> I'd prefer to leave it in. Upstream's opinions
Steve Langasek writes:
> On Fri, Jan 03, 2014 at 04:40:54PM -0800, Russ Allbery wrote:
>> I'd prefer to leave it in. Upstream's opinions aside, systemd is free
>> software and if someone wants to try to port it (or, possibly more
>> likely, "port" it by writing something native that provides the
On Sat, Jan 04, 2014 at 06:14:30PM +, Ian Jackson wrote:
> > ... (Note that the latter would work better if upstart stopped
> > conflicting with sysvinit, similar to how systemd can be installed
> > without being init.)
> There does seem to need to be some work there.
That has already been r
]] Russ Allbery
> 2. Package logind separately from systemd, get it working with sysvinit.
>The problems with doing this, as I understand it, is that we'd not be
>able to upgrade such a separately-packaged logind beyond 204 for
>jessie. I'm not sure how much impact that would have.
Russ Allbery writes ("Bug#727708: init system discussion status"):
> I thought that was already resolved? I objected to the "should" in the
> original language regarldess of which init system we choose, and Ian said
> that he'd reworded it already to something akin to mine, which just says
> that
]] Dimitri John Ledkov
> Also which upstream are staying with? systemd upstream git history[4]
> has only one branch, which is linear with linear version number
> increments, without any stable release branches or other indications
> of which patches are stable (or possibly security) bugfixes.
T
On Sat, Jan 04, 2014 at 11:08:36AM -0800, Russ Allbery wrote:
> Steve Langasek writes:
> > On Fri, Jan 03, 2014 at 04:40:54PM -0800, Russ Allbery wrote:
> >> I'd prefer to leave it in. Upstream's opinions aside, systemd is free
> >> software and if someone wants to try to port it (or, possibly m
On Sat, Jan 04, 2014 at 06:14:30PM +, Ian Jackson wrote:
> (Josh, is there some reason why you replied to the TC list directly
> rather than the bug report ? You should send your messages to the bug
> so they are filed, displayed and archived there. Thanks.)
I don't subscribe to debian-ctte@
On Sat, Jan 04, 2014 at 11:27:26AM -0800, Steve Langasek wrote:
> On Sat, Jan 04, 2014 at 06:14:30PM +, Ian Jackson wrote:
> > > ... (Note that the latter would work better if upstart stopped
> > > conflicting with sysvinit, similar to how systemd can be installed
> > > without being init.)
>
On Tue, Dec 31, 2013 at 09:09:52PM +0100, Tollef Fog Heen wrote:
> ]] Ian Jackson
> > I think you have misunderstood. Or perhaps I hae misunderstood you.
> > The "work" that I'm saying needs to be done anyway is the work to
> > disentange the parts of systemd which are required by (say) GNOME fr
]] Steve Langasek
> On Tue, Dec 31, 2013 at 09:09:52PM +0100, Tollef Fog Heen wrote:
> > ]] Ian Jackson
>
> > > I think you have misunderstood. Or perhaps I hae misunderstood you.
> > > The "work" that I'm saying needs to be done anyway is the work to
> > > disentange the parts of systemd whic
On 01/04/2014 12:07 PM, Russ Allbery wrote:
Cory writes:
If Debian go's with systemd they need to use systemd 207 as its
supported in RHEL 7 so we know it's going to be supported for around 10
years also why does Debian have systemd 204 in it's repos?? systemd 207
is way better
Because it's t
On Sat, 2014-01-04 at 09:56 -0800, Russ Allbery wrote:
> Sjoerd Simons writes:
> > Not having the logind interface is a lot harder to cope with and
> > something that will not only impact Gnome. So essentially the most
> > likely impact of using sysvinit _without_ a provider of the logind
> > int
On Sat, Jan 04, 2014 at 06:59:46PM +, Dimitri John Ledkov wrote:
> Also it is sad that systemd upstream is actively promoting for
> everyone to execute runtime checks of is systemd-init pid1,...
This is done public systemd libraries to become NOPs if not running on
or not compiled for systemd,
Uoti Urpala writes:
> On Fri, 2014-01-03 at 20:26 -0800, Nikolaus Rath wrote:
>> Clint Adams writes:
>> > On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote:
>> >> or alternatively
>> >>
>> >> 4. Packages may, however, depend on a specific init system (which may
>> >>not be the
On 4 January 2014 23:16, Zbigniew Jędrzejewski-Szmek wrote:
> On Sat, Jan 04, 2014 at 06:59:46PM +, Dimitri John Ledkov wrote:
>> Also it is sad that systemd upstream is actively promoting for
>> everyone to execute runtime checks of is systemd-init pid1,...
> This is done public systemd libra
On 5 January 2014 00:07, Nikolaus Rath wrote:
> Uoti Urpala writes:
>> On Fri, 2014-01-03 at 20:26 -0800, Nikolaus Rath wrote:
>>> Clint Adams writes:
>>> > On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote:
>>> >> or alternatively
>>> >>
>>> >> 4. Packages may, however, depend on a
Dimitri John Ledkov writes:
> This confirms that systemd is not generic across all upstreams and all
> distributions, and everyone is maintaining their own (in part influenced
> by release cadence, and well distro-specific integration) Having git
> repos, or even distro specific branches on Freed
On 4 January 2014 23:13, Sjoerd Simons wrote:
> On Sat, 2014-01-04 at 09:56 -0800, Russ Allbery wrote:
>> Sjoerd Simons writes:
>
>> > Not having the logind interface is a lot harder to cope with and
>> > something that will not only impact Gnome. So essentially the most
>> > likely impact of usi
Dimitri John Ledkov writes:
> On 5 January 2014 00:07, Nikolaus Rath wrote:
>> I think that if a program functionally depends on another, but the
>> package does not declare this dependency, then it's a bug. So in this
>> context I consider functional dependencies and package dependencies to
>>
On 5 January 2014 01:26, Russ Allbery wrote:
> Dimitri John Ledkov writes:
>
>> This confirms that systemd is not generic across all upstreams and all
>> distributions, and everyone is maintaining their own (in part influenced
>> by release cadence, and well distro-specific integration) Having gi
Dimitri John Ledkov writes:
> Imho that's a gross overstatement. Over more than a year, an Ubuntu
> GNOME team was established and became official ubuntu flavour with so
> goal and purpose of shipping GNOME3 in it's full glory. If distro watch
> is any indication they are fast growing ubuntu flav
Dimitri John Ledkov writes:
> On 5 January 2014 01:26, Russ Allbery wrote:
>> I'm amused by this comment given that one of the points of criticism of
>> systemd prior to this (by people other than yourself, to be clear) was
>> that the systemd maintainers were unwilling to apply and carry
>> nec
On 4 January 2014 19:42, Tollef Fog Heen wrote:
> ]] Dimitri John Ledkov
>
>> Also which upstream are staying with? systemd upstream git history[4]
>> has only one branch, which is linear with linear version number
>> increments, without any stable release branches or other indications
>> of which
On 5 January 2014 01:46, Russ Allbery wrote:
> Dimitri John Ledkov writes:
>
>> Imho that's a gross overstatement. Over more than a year, an Ubuntu
>> GNOME team was established and became official ubuntu flavour with so
>> goal and purpose of shipping GNOME3 in it's full glory. If distro watch
>
On Jan 5, 2014 2:39 AM, "Russ Allbery" wrote:
> I'm doubtful that either of us are going to convince the other on this
> point. I don't consider it comparable to the other examples you're
> citing, and I think it's inobvious that raise(SIGSTOP) is a good technical
> choice. Simple, yes, but that
Dimitri John Ledkov writes:
> I see thanks. I guess the only relevant addition, is that there is a
> pool of self-selected developers that are working on the similar type of
> integration issues: GNOME3 with logind without systemd-init. The Ubuntu
> GNOME team (packaging team is 18 people at the
Anthony Towns writes:
> On Jan 5, 2014 2:39 AM, "Russ Allbery" wrote:
>> I'm doubtful that either of us are going to convince the other on this
>> point. I don't consider it comparable to the other examples you're
>> citing, and I think it's inobvious that raise(SIGSTOP) is a good
>> technical
Le Sun, Jan 05, 2014 at 02:11:41AM +, Dimitri John Ledkov a écrit :
>
> at least following any of the practices adviced by the debian policy - patch
> target, 3.0 (quilt) format
Dear Dimitri,
the Debian Policy does not recommend one source format over another.
Have a nice day,
--
Charles
Dimitri John Ledkov wrote:
>On 4 January 2014 19:42, Tollef Fog Heen wrote:
>> ]] Dimitri John Ledkov
>>> Fedora/RPM based distributions are significantly different, thus it is
>>> inevitable that we'll have to maintain a fork of systemd for best
>>> integration into Debian. This does not seem evi
On Jan 5, 2014 10:40 AM, "Russ Allbery" wrote:
> Anthony Towns writes:
> > How hard would it be to write an external wrapper that converts the
> > systemd style socket activation to the SIGSTOP protocol (for upstart
> > invoking a systemd compatible daemon)?
On second thoughts, I think I meant t
Anthony Towns writes:
> On Jan 5, 2014 10:40 AM, "Russ Allbery" wrote:
>> Anthony Towns writes:
>>> How hard would it be to write an external wrapper that converts the
>>> systemd style socket activation to the SIGSTOP protocol (for upstart
>>> invoking a systemd compatible daemon)?
> On secon
Russ Allbery writes:
> This, sadly, is slightly harder, since you can't use this hack:
>>> The wrapper could fork and then exec the daemon in the *parent*, and
>>> have the *child* listen for the notification message and then
>>> kill(SIGSTOP) its parent and immediately exit. I wonder if that w
On Sun, Jan 05, 2014 at 12:54:04AM +, Dimitri John Ledkov wrote:
> So components inside systemd-source tree do not follow what's advised
> to all other projects: e.g. link or statically include sd_* helper
> files, and perform runtime checks?
The advice for other projects assumes that systemd i
On Sun, Jan 05, 2014 at 02:11:41AM +, Dimitri John Ledkov wrote:
> > Were you unable to find
> > http://pkgs.fedoraproject.org/cgit/systemd.git/log/?h=f19 ? It's where
> > Fedora has all of their packaging..
>
> As explained by Zbigniew Jędrzejewski-Szmek, that is not actually
> where that hap
Le Sat, Jan 04, 2014 at 10:28:37AM -0800, Russ Allbery a écrit :
>
> It's been obvious to me that desktop files are a better (and, more
> importantly, more widely supported) representation of this information for
> over six years now, but given that I, as a Policy Editor, don't know how to
> effec
Russ Allbery wrote:
> Oh, hm, actually... the systemd notification protocol allows you to tell
> systemd what the actual PID of the process to manage is, using the MAINPID
> variable. So I think you actually could write a wrapper that starts the
> actual daemon as a child, waits for it to stop usi
62 matches
Mail list logo
