On Sun, 24 Feb 2019 14:16:03 +0100 Johannes Schauer wrote:
> I found that some important arguments are still missing. A recent mail by
> Guillem [1] nicely summarizes also many of my own thoughts. I'm going to paste
> the relevant content into this mail for convenience of the reader:
I think thos
On Sat, 10 Dec 2016 06:54:17 +1030 Ron wrote:
> You then had the gall to angrily insist that while you thought he might
> be a better maintainer than me, it was still my responsibility to do the
> work to fix all the obvious things that others had missed in their fork
> (which he hadn't contribute
On Mon, 21 Nov 2016 17:16:34 +1030 Ron wrote:
> If we run with your proposal, what are you actually suggesting we tell
> the people who'd be upset by the loss of htags without notice in Stretch?
> Because I don't really see how you've addressed that here.
>
> AFAICS, there's just either an implic
On Tue, 8 Nov 2016 15:33:32 +1030 Ron wrote:
> On Mon, Nov 07, 2016 at 12:09:21PM -0800, Nikolaus Rath wrote:
> > It seems you're only interested in impartial and non-partisan voices
> > when they happen to back your position. I am impartial and non-partisan,
> > and formed my opinion by reading t
Note: this is written as an outsider who doesn't have any direct stake
in the issue.
On Sun, 6 Nov 2016 05:00:12 +1030 Ron wrote:
> > And I think the latter is basically what the "just ship multiple
> versions and hope the future gets clearer" option boils down to.
> All it really does is take th
On Mon, 18 Jul 2016 11:15:59 +0200 Philip Hands wrote:
> Uoti Urpala writes:
>
> > In what sense couldn't everyone modify the concatenated form?
>
> Perhaps if I frame my question from:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978#90
>
>
On Mon, 18 Jul 2016 09:02:08 +1000 Ben Finney wrote:
> On 17-Jul-2016, Uoti Urpala wrote:
> > If you want to argue "upstream convenience" as a reason for the
> > second,
>
> Maybe if that were the only justification offered. That's not the case
> though.
&
On Sat, 16 Jul 2016 00:02:55 +0100 Neil Williams
wrote:
> On Fri, 15 Jul 2016 23:45:01 +0530
> Pirate Praveen wrote:
>> If this argument is accepted, we will not be able to package a fork
>> because the original upstream won't accept a patch against the fork.
>> Similarly we'd be able to package
On Mon, 20 Oct 2014 10:06:31 -0400 Martin Pitt wrote:
> I'll leave this to the Debian maintainers, as I'm mostly responsible
> for the Ubuntu side, haven't really discussed this with the two
> Michaels/Tollef/Marco, and I don't feel qualified to speak for the
> Debian systemd team.
>
> My persona
On Thu, 2014-09-18 at 17:14 -0700, Cameron Norman wrote:
> On Thu, Sep 18, 2014 at 2:10 PM, Josh Triplett wrote:
> > Personally, in this case, I'd argue that the desirable dependency (which
> > we can't easily express) would be "sysvinit-core ? systemd-shim :
> > systemd-sysv".
>
> To be more pre
On Thu, 2014-09-18 at 12:23 -0700, Steve Langasek wrote:
> On Thu, Sep 18, 2014 at 11:36:54AM -0700, Josh Triplett wrote:
> > I agree completely that it doesn't make sense for the transition from
> > sysvinit to systemd to take place via libpam-systemd rather than via
> > some core package like "in
On Sat, 2014-02-08 at 22:52 +1100, Dmitry Smirnov wrote:
> Also I'd like to notice that shopping for most feature-rich init system
> might be not our goal after all. OpenRC may be the safest choice that might
> satisfy majority of developers as it appears to have the least number of
> objections
On Tue, 2014-02-04 at 16:53 +, Colin Watson wrote:
> On Sun, Feb 02, 2014 at 12:57:39PM +0100, Tollef Fog Heen wrote:
> > You mean, like installing the systemd-sysv package?
>
> Indeed; but people earlier in this thread have said that this isn't the
> preferred approach, so I was arguing that
On Sat, 2014-02-01 at 15:24 -0800, Steve Langasek wrote:
> While I think the Depends: systemd should be dropped (via a split of the
> systemd package), that's not required for fixing the present problem. That
> can be addressed by having gnome-settings-daemon Depends: systemd,
> systemd-shim | sys
On Sat, 2014-02-01 at 17:10 +, Ian Jackson wrote:
> Sébastien Villemot writes ("Bug#727708: TC resolution revised draft"):
> > P1: DT > UT > DL > UL
> > P2: DL > UL > DT > UT
> > P3: UT > UL > DL > DT
> > P4: UT > UL > DL > DT
>
> This is a nice example which actually demonstrates why these qu
On Tue, 2014-01-28 at 22:20 +0200, Adrian Bunk wrote:
> On Tue, Jan 28, 2014 at 12:08:19PM -0800, Don Armstrong wrote:
> > On Tue, 28 Jan 2014, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Tue, Jan 28, 2014 at 11:23:11AM -0800, Don Armstrong wrote:
> > > > The former. So :
> > > >
> > > >Where
On Thu, 2014-01-16 at 17:00 -0800, Russ Allbery wrote:
> Uoti Urpala writes:
> > I think the divergence has gone too far in things like non-Linux ports.
> > They have had an overall negative effect on people working on Linux
> > within Debian and people creating derivatives
On Fri, 2014-01-17 at 16:08 +0100, Ihar Filipau wrote:
> Uoti Urpala wrote:
> > Even the upstart proponents do not seem to have significant arguments
> > about upstart having better functionality, and there don't seem to be
> > all that many people who would have a reason
On Thu, 2014-01-16 at 17:52 +, Ian Jackson wrote:
> * Debian is a forum for cooperation and technical development.
> * Debian, as a piece of software, tries to be all things to all
> people (within reason).
> This flexibility and tolerance for divergence has made Debian an
> extremely attra
On Thu, 2014-01-16 at 19:12 +, Ian Jackson wrote:
> AFAICT we are all agreed that:
> * Applications which aren't part of the init system must not require a
> particular init to be pid 1. (So in particular a desktop
> environment may not require a particular pid 1.)
I read the log, and I
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 default init) for features t
On Fri, 2014-01-03 at 16:40 -0800, Russ Allbery wrote:
> Ian Jackson writes:
> > I've written a version of Niklaus's rule about dependencies:
>
> >Likewise, packages must not Depend on or Recommend (directly or
> >indirectly) a specific init(1). Violations of this are also an RC
> >b
On Fri, 2014-01-03 at 10:02 -0800, Nikolaus Rath wrote:
> Ian Jackson writes:
> > | 3. At least in jessie, unless a satisfactory compatibility approach is
> > |developed and deployed (see paragraph 10), packages must continue
> > |to provide sysvinit scripts. Lack of a sysvinit script (fo
On Thu, 2014-01-02 at 12:31 +, Colin Watson wrote:
> On Wed, Jan 01, 2014 at 08:15:46PM +0200, Uoti Urpala wrote:
> > You can simply not install any of these additional services if you don't
> > want them. This is completely trivial to do.
>
> It is indeed technic
On Wed, 2014-01-01 at 17:17 +, Colin Watson wrote:
> On Wed, Jan 01, 2014 at 05:52:03PM +0100, Ansgar Burchardt wrote:
> > Colin Watson writes:
> > > Basically, systemd would be more compelling to me if it tried to do
> > > less. I don't expect to persuade systemd advocates of this, as I thin
On Tue, 2013-12-31 at 02:55 +, Colin Watson wrote:
> My main concerns with systemd relate to its broad scope regarding units
> it provides for system initialisation tasks currently performed by other
> packages, and the potential for that to interfere with past and future
> work elsewhere in De
On Mon, 2013-12-30 at 18:58 +, Ian Jackson wrote:
> Also, I get the impression me that the "integration" of much of this
> functionality into the systemd source package has been done for
> political rather than technical reasons. Indeed to the extent that
> there is a problematically tight tec
On Sun, 2013-12-29 at 14:02 +, Colin Watson wrote:
> I was referring more to Tollef's position, really. Debian systemd
> maintenance ought to take into account matters of Debian integration,
> which includes whether it fits well into best-of-breed Debian practice.
>
> If it's easy enough to o
On Sun, 2013-12-29 at 10:37 -0800, Steve Langasek wrote:
> It's quite possible that I am doing something wrong, but I don't think this
> is it. Each of the .service units in question already had
> 'WantedBy=multi-user.target', and each of the .socket units had
> 'WantedBy=sockets.target'; on Fedor
On Sun, 2013-12-29 at 01:10 -0800, Steve Langasek wrote:
> However, I think this gets to the heart of why upstart upstream has avoided
> ever recommending the use of socket-based activation. There are some fairly
> fundamental problems that basically halted development of socket-based
> activation
On Sat, 2013-12-28 at 21:29 -0800, Russ Allbery wrote:
> Uoti Urpala writes:
> > Does sd_notify() actually give any positive effect compared to just
> > using type=simple, given that you already have socket activation? The
> > UDP socket should buffer packets until the daemon
On Sat, 2013-12-28 at 17:24 -0800, Russ Allbery wrote:
> * systemd synchronization support added via sd_notify.
> * systemd socket activation support.
Does sd_notify() actually give any positive effect compared to just
using type=simple, given that you already have socket activation? The
UDP socke
On Thu, 2013-12-26 at 21:42 +, Colin Watson wrote:
> On Thu, Dec 26, 2013 at 08:49:11AM +0100, Tollef Fog Heen wrote:
> > In this particular case, as you write, I hadn't really given it any
> > consideration before, but what I think would make sense is to extend
> > systemd to support the same
On Sat, 2013-12-21 at 08:49 -0800, Russ Allbery wrote:
> Tollef Fog Heen writes:
> > sd-daemon.c is also intentionally designed to not have dependencies on
> > the rest of the systemd source and to be portable to non-linux
> > architectures too (but basically just stubs then) just so people can pu
On Fri, 2013-12-20 at 07:53 -0800, Steve Langasek wrote:
> On Thu, Dec 19, 2013 at 11:26:19PM +0100, Josselin Mouette wrote:
> > Le jeudi 19 décembre 2013 à 12:35 -0800, Steve Langasek a écrit :
> > > ecosystem. This needs to be resolved before logind v205 can reasonably be
> > > adopted, because
On Wed, 2013-12-18 at 16:27 +0100, Josselin Mouette wrote:
> Such stances are untenable whenever the kernel is concerned. We need to
> be able to use a kernel from the previous stable distribution, or from
> the next one, to support proper chroots. This part of the support for
> upgrades is needed
On Wed, 2013-12-18 at 13:34 +0200, Adrian Bunk wrote:
> On Tue, Dec 17, 2013 at 06:02:50PM -0500, Sam Hartman wrote:
> > I'm confused, when I hear you say that this risk is unique to the
> > systemd option and not shared by other options. I would understand that
> > statement if we thought we coul
On Sat, 2013-12-14 at 21:45 +, Ian Jackson wrote:
> I've just been reading sd_listen_fds(3). It's vaguely similar to
> upstart's socket activation protocol. It supports multiple sockets
> (which is obviously important).
>
> But I have a few questions about the details:
>
> Why do only some
On Mon, 2013-12-02 at 15:32 -0800, Don Armstrong wrote:
> On Tue, 03 Dec 2013, Josselin Mouette wrote:
> > Le lundi 02 décembre 2013 à 13:41 -0700, Bdale Garbee a écrit :
> > > Josselin Mouette writes:
> > >
> > > > There are two implied assumptions here:
> > > > * that the same people ar
On Fri, 2013-11-29 at 12:37 +, Ian Jackson wrote:
> Uoti Urpala writes ("Bug#727708: systemd (security) bugs (was: init system
> question)"):
> > My guess is that most people do not consider that "exciting" or really
> > care - thinking of system st
Ian Jackson wrote:
> It isn't always 100% clear to me from reading these which of them
> apply to systemd's init replacement. But reading the systemd debate
> page makes it clear that the other components in the systemd upstream
> package are seen by systemd proponents as part of their offering, a
41 matches
Mail list logo
