I have been a long time debian user. Please do not implement systemd. I
don't want to switch to another OS but I will.
Hi,
Brandon:
I have been a long time debian user. Please do not implement systemd. I
don't want to switch to another OS but I will.
So?
*I* will switch to another OS if Debian decides _not_ to switch to systemd.
:-P
Can we move on please? Anybody who does not like this choice has had ample
On 12/02/14 19:43, Brandon wrote:
I have been a long time debian user. Please do not implement systemd. I
don't want to switch to another OS but I will.
For the jessie release, it should be possible to uninstall systemd on
GNU/Linux and still have most functionality. The non-Linux ports are
On Tue, Dec 31, 2013 at 07:08:34PM -0800, Steve Langasek wrote:
On Tue, Dec 31, 2013 at 11:15:33AM -0800, Russ Allbery wrote:
Similarly, I'm not sure why the focus on only adding necessary tools to
the initramfs image. Surely this doesn't matter much if the tools are
harmless when
On Wed, 2014-01-01 at 05:48 +0100, Mourad De Clerck wrote:
So last time I tried, this just worked - my rootfs got mounted using a
keyscript in the initramfs, and there were no problems, not a peep from
systemd when it took over, no re-setup or anything.
Sure... but that applies, AFAIU, only
On Mon, Dec 30, 2013 at 09:52:37PM +0100, Tollef Fog Heen wrote:
]] Ian Jackson
Steve Langasek writes (Bug#727708: systemd-shim uploaded to NEW):
So I repeat here my request that the systemd maintainers make a suitable
split of the systemd binary package, so that systemd-shim
Steve Langasek wrote:
Looking more closely, I find that one of the conflicting files is a conffile
(/etc/dbus-1/system.d/org.freedesktop.systemd1.conf). diversions and
conffiles still don't mix, AFAIK (and according to current policy). So that
seems to still leave us without a proper
* Raphael Hertzog hert...@debian.org, 2013-12-30, 19:42:
dpkg-divert is the usual answer when you need/want to replace something
without the consent of the other side.
FWIW, Policy §3.9 reads:
“You should not use ‘dpkg-divert’ on a file belonging to another package
without consulting the
Steve Langasek writes (Bug#727708: systemd-shim uploaded to NEW):
On Mon, Dec 30, 2013 at 06:29:10PM +, Ian Jackson wrote:
This would be quite wrong; Replaces is not supposed to be used like
that (but you apparently know that).
Yes. Raphaël rightly points out that dpkg-divert can
Hi.
Now that systemd could become default in Debian (well at least I favour
it over upstream)... I started wondering how well it supports booting
from a root fs on top of multiple block device layers?
Some time ago I wrote [0] (with some contributions from others
AFAICS)...
So is there any
Christoph Anton Mitterer cales...@scientia.net writes:
Right now there is a rather fixed order in which things work (i.e.
phys-MD-LVM-dm-crypt-rootfs) out of the box (well in some cases at
least) and IIRC, due to some obscure code in the cryptsetup initramfs
scripts it works also with
]] Christoph Anton Mitterer
Now that systemd could become default in Debian (well at least I favour
it over upstream)... I started wondering how well it supports booting
from a root fs on top of multiple block device layers?
That's handled by the initramfs where we currently don't use
On Tue, 2013-12-31 at 11:15 -0800, Russ Allbery wrote:
For whatever it's worth, I've been using systemd on a system with LVM and
dm-crypt (with LUKS) for about a month now, in the dm-crypt - LVM -
filesystem mode, and haven't had any trouble.
Do you use it on your root-fs? With keyscripts?
On Tue, 2013-12-31 at 21:07 +0100, Tollef Fog Heen wrote:
That's handled by the initramfs where we currently don't use systemd.
(It's supported upstream to do so and we might eventually investigate
that, but I don't believe anybody has done any work on it for Debian.)
Sure... but
- using
Christoph Anton Mitterer cales...@scientia.net writes:
On Tue, 2013-12-31 at 11:15 -0800, Russ Allbery wrote:
For whatever it's worth, I've been using systemd on a system with LVM and
dm-crypt (with LUKS) for about a month now, in the dm-crypt - LVM -
filesystem mode, and haven't had any
On Tue, Dec 31, 2013 at 01:16:32AM -0800, Josh Triplett wrote:
Steve Langasek wrote:
Looking more closely, I find that one of the conflicting files is a conffile
(/etc/dbus-1/system.d/org.freedesktop.systemd1.conf). diversions and
conffiles still don't mix, AFAIK (and according to current
Hello,
On Tue, 31 Dec 2013 13:07:22 -0800
Steve Langasek vor...@debian.org wrote:
For the record, logind is not the only issue here. It's logind,
timedated, hostnamed, localed which are needed by GNOME. This
doesn't actually change the work involved in forking the package; but
I think it
On Tue, Dec 31, 2013 at 01:07:22PM -0800, Steve Langasek wrote:
On Tue, Dec 31, 2013 at 01:16:32AM -0800, Josh Triplett wrote:
Steve Langasek wrote:
Looking more closely, I find that one of the conflicting files is a
conffile
(/etc/dbus-1/system.d/org.freedesktop.systemd1.conf).
Hello all,
I did not see it linked yet, and thought it pertinent to the
discussion: some kde plasma desktop developers described their
possible intentions to utilize systemd functionality (while keeping
their existing shell script based startup for non systemd systems) in
a future release here
]] Christoph Anton Mitterer
On Tue, 2013-12-31 at 21:07 +0100, Tollef Fog Heen wrote:
That's handled by the initramfs where we currently don't use systemd.
(It's supported upstream to do so and we might eventually investigate
that, but I don't believe anybody has done any work on it for
On Tue, Dec 31, 2013 at 11:15:33AM -0800, Russ Allbery wrote:
Similarly, I'm not sure why the focus on only adding necessary tools to
the initramfs image. Surely this doesn't matter much if the tools are
harmless when unneeded?
In this context I'm not sure how applicable it is; but there are
Hi,
Tollef Fog Heen tfh...@err.no writes:
]] Ian Jackson
Steve Langasek writes (Bug#727708: systemd-shim uploaded to NEW):
So I repeat here my request that the systemd maintainers make a suitable
split of the systemd binary package, so that systemd-shim will be
coinstallable
On Mon, Dec 02, 2013 at 02:48:52PM -0800, Russ Allbery wrote:
Sure. Both systemd and upstart manage to avoid the problem of
inconsistent behavior due to tainted admin environments, because daemons
are always started as children of init and not of the admin's login
shell. That being the
* Josselin Mouette:
Le mardi 17 décembre 2013 à 12:26 -0800, Russ Allbery a écrit :
Is there actually any implementation other than glib2.0 and libdbus that
would be affected by a switch to kdbus?
This is an interesting question. Josselin, is GNOME (for example) likely
to acquire a hard
Steve Langasek vor...@debian.org writes:
On Mon, Dec 02, 2013 at 02:48:52PM -0800, Russ Allbery wrote:
I have never seen a gratuitous incompatibility caused by this. Do you
have any examples?
I would argue that every single result returned by 'ls -l /usr/sbin/
/usr/bin|grep /bin',
Steve Langasek writes (Bug#727708: systemd and upstart, a view from a daemon
Debian maintainer):
I also think that the extensive maintainer script changes required for any
upstart-using package are quite deplorable (whether or not they're wrapped
in a helper script + debhelper snippet
Steve Langasek writes (Bug#727708: systemd-shim uploaded to NEW):
So I repeat here my request that the systemd maintainers make a suitable
split of the systemd binary package, so that systemd-shim will be
coinstallable with the systemd-provided implementations of the other dbus
services
On Mon, 30 Dec 2013, Ian Jackson wrote:
The only alternative I see is for systemd-shim to declare a
Replaces: against systemd without a Conflicts,
This would be quite wrong; Replaces is not supposed to be used like
that (but you apparently know that).
How do the systemd maintainers
On Mon, Dec 30, 2013 at 04:51:55PM +, Ian Jackson wrote:
Steve Langasek writes (Bug#727708: systemd and upstart, a view from a daemon
Debian maintainer):
I also think that the extensive maintainer script changes required for any
upstart-using package are quite deplorable (whether
]] Ian Jackson
Steve Langasek writes (Bug#727708: systemd-shim uploaded to NEW):
So I repeat here my request that the systemd maintainers make a suitable
split of the systemd binary package, so that systemd-shim will be
coinstallable with the systemd-provided implementations of the other
On Mon, Dec 30, 2013 at 06:29:10PM +, Ian Jackson wrote:
Steve Langasek writes (Bug#727708: systemd-shim uploaded to NEW):
So I repeat here my request that the systemd maintainers make a suitable
split of the systemd binary package, so that systemd-shim will be
coinstallable
On Mon, Dec 30, 2013 at 01:03:48PM -0800, Steve Langasek wrote:
This would be quite wrong; Replaces is not supposed to be used like
that (but you apparently know that).
Yes. Raphaël rightly points out that dpkg-divert can be used for this; if
necessary, that's what I'll do.
But I still
On Sat, Dec 28, 2013 at 03:56:49PM -0800, Russ Allbery wrote:
Also, the approach to the systemd integration introduces a new runtime
package dependency on init-system-helpers, which despite its
generic-sounding name actually contains only helpers for systemd and is
maintained in Debian by
On Sun, Dec 29, 2013 at 05:56:30AM +0200, Uoti Urpala wrote:
On Thu, 2013-12-26 at 21:42 +, Colin Watson wrote:
The first reason is, I suppose, rather selfish: I've been working on
this on and off for fourteen years and it seems a bit rude for systemd
to turn up and declare that it's
]] Colin Watson
On Thu, Dec 26, 2013 at 08:49:11AM +0100, Tollef Fog Heen wrote:
As I explain in the bug [1], I think that the facilities provided by
binfmt-support are objectively superior; and even if they were broadly
equivalent, I'd still question the utility of converting packages
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
Firstly: a warning note. Throughout this exercise I have been
persistently typing upstart when I mean userv and userv when I
mean upstart. If something I say make no sense, please try reading
it the other way :-). (At least it gave me some extra bugs to
experience debugging...)
I have spent a
As I have mentioned, I tried adapting userv to systemd and upstart. I
have already reported on my experience with the core daemon code.
In this message I'll deal with the config fragments (units and jobs
as they call them), and the Debian-specific packaging.
I'm treating the config fragments as
Hi,
Le samedi 28 décembre 2013 à 22:46 +, Ian Jackson a écrit :
In this message I'll deal with the config fragments (units and jobs
as they call them), and the Debian-specific packaging.
It is probably needless to say that I disagree with about 99% of what
you wrote in tonight’s reports.
❦ 28 décembre 2013 23:46 CET, Ian Jackson ijack...@chiark.greenend.org.uk :
The package maintainer scripts exposed more complexity too. It was
necessary to add new systemd-specific calls to deb-systemd-helper.
The boilerplate required here was too much to simply include in my
existing
Ian Jackson ijack...@chiark.greenend.org.uk writes:
So overall my conclusions at this level are:
* socket activation is an attractive implementation target for an
upstream daemon author.
* upstart's SIGSTOP protocol is an attractive implementation target
for an upstream daemon
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I found configuring upstart to be utterly trivial. There was little
opportunity for error. More guidance in debian-policy would be a good
idea, including perhaps a reference to some example packages.
I have a much longer message that goes
Russ Allbery r...@debian.org writes:
For comparison purposes, the *total* burden, from my upstream
perspective, of the two options was:
* systemd: 14 lines (8 lines of code, 6 lines of build system)
* upstart: 12 lines (6 lines of code, 6 lines of documentation)
Since upstart
On Sun, Dec 29, 2013 at 12:42:24AM +0100, Vincent Bernat wrote:
❦ 28 décembre 2013 23:46 CET, Ian Jackson ijack...@chiark.greenend.org.uk :
The package maintainer scripts exposed more complexity too. It was
necessary to add new systemd-specific calls to deb-systemd-helper.
The
On Sun, Dec 29, 2013 at 12:29:50AM +0100, Josselin Mouette wrote:
But this is even more troubling:
There was less support from the Debian policy manual. Perhaps there
is some other systemd Debian packaging guidance somewhere which I
didn't find.
Incorporating upstart packaging in the
Steve Langasek vor...@debian.org writes:
On Sun, Dec 29, 2013 at 12:42:24AM +0100, Vincent Bernat wrote:
Ian Jackson ijack...@chiark.greenend.org.uk writes:
The package maintainer scripts exposed more complexity too. It was
necessary to add new systemd-specific calls to deb-systemd-helper.
Steve Langasek vor...@debian.org writes:
Packages are shipping systemd units in the archive today, and Policy
*should* cover this case. Currently, it covers this by saying you can
integrate with systemd, but must still provide compatibility with
sysvinit, which I think is fine at this stage.
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, Dec 28, 2013 at 07:50:11PM -0800, Steve Langasek wrote:
I've just uploaded the systemd-shim package to the NEW queue.
This package has been marked for ACCEPT. Please feel free to test it
once dinstall runs and it gets sync'd to your local friendly mirror.
Cheers,
Paul
--
.''`.
On Thu, Dec 26, 2013 at 08:49:11AM +0100, Tollef Fog Heen wrote:
As I explain in the bug [1], I think that the facilities provided by
binfmt-support are objectively superior; and even if they were broadly
equivalent, I'd still question the utility of converting packages from
an interface
#716812 asks for binfmt-support to be disabled when systemd is present,
because systemd-binfmt exists. The two have a sort of soft conflict;
I'm sure it's possible to run both, but having two programs configure
the same kernel facility is bound to be confusing sooner or later, so it
would
Hi Andreas,
Le samedi 21 décembre 2013 à 08:48 +0100, Andreas Barth a écrit :
1. Does systemd (or a part of the systemd project) need to be the
single cgroup writer and if so, why?
It does not… so far. The only thing currently required is for cgroups
consumers to adhere to the shared
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 :
The reasons for not upgrading to the current version of logind aren't to do
with any fragility of the existing glue code (the systemd-shim package), but
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 it's
* Steve Langasek (vor...@debian.org) [131220 16:57]:
The design which claims this role for systemd-as-pid-1, and which does not
adequately address use cases of other existing cgroups consumers in the
ecosystem (lmctfy, lxc) is broken by design.
Having a single cgroup writer in userspace is
On Thu, Dec 19, 2013 at 09:43:05AM +0200, Adrian Bunk wrote:
On Wed, Dec 18, 2013 at 02:53:39PM -0800, Russ Allbery wrote:
Adrian Bunk b...@stusta.de writes:
[1] Personally, I am sceptical whether it is a good idea to switch to a
different init system for jessie. But I am not on a
Adrian Bunk b...@stusta.de writes:
Ubuntu is also using udev and logind without using systemd, so they are
and will continue to be available stand-alone.
Ubuntu is maintaining a variety of moderately fragile glue in order to
make this happen and currently can't upgrade to the current version
On Thu, Dec 19, 2013 at 09:53:01AM -0800, Russ Allbery wrote:
Adrian Bunk b...@stusta.de writes:
Ubuntu is also using udev and logind without using systemd, so they are
and will continue to be available stand-alone.
Ubuntu is maintaining a variety of moderately fragile glue in order to
Le jeudi 19 décembre 2013 à 12:35 -0800, Steve Langasek a écrit :
The reasons for not upgrading to the current version of logind aren't to do
with any fragility of the existing glue code (the systemd-shim package), but
because logind 205 has a new dependency on systemd as cgroup manager, which
On Tue, Dec 17, 2013 at 06:02:50PM -0500, Sam Hartman wrote:
Adrian == Adrian Bunk b...@stusta.de writes:
Adrian Yes, it is speculation that other new features (or even
Adrian bugfixes) might appear in the kernel and might become
Adrian mandatory in systemd between jessie and
Hi Adrian,
Le mercredi 18 décembre 2013 à 13:34 +0200, Adrian Bunk a écrit :
That point you bring up is semi-orthogonal to the upgrade decision,
but it also brings up two important points that have to be considered:
1. What is the governance model of the systemd community?
This might be
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 could
On Wed, Dec 18, 2013 at 03:10:19PM +0200, Uoti Urpala wrote:
In the kdbus case, systemd upstream already mentioned the possibility of
shipping kdbus as a new module for older kernels. More generally, you
can have solutions like applying some upgrades at boot rather than
trying to switch parts
Adrian, I'm frustrated when I read your message because you put words in
my mouth that I did not speak.
I never said that Debian should allow systemd to dictate policy for
multiple distributions nor did I say that Debian should allow one
upstream systemd maintainer to dictate decisions for Debian.
]] Uoti Urpala
In the kdbus case, systemd upstream already mentioned the possibility of
shipping kdbus as a new module for older kernels. More generally, you
can have solutions like applying some upgrades at boot rather than
trying to switch parts from under a fully live system. This does
On Wed, Dec 18, 2013 at 01:19:48PM +0100, Josselin Mouette wrote:
Hi Adrian,
Hi Josselin,
Le mercredi 18 décembre 2013 à 13:34 +0200, Adrian Bunk a écrit :
That point you bring up is semi-orthogonal to the upgrade decision,
but it also brings up two important points that have to be
On Wed, Dec 18, 2013 at 04:26:44PM +0200, Adrian Bunk wrote:
the *so far* is the worrisome part, considering how much power to
enforce policy whoever controls systemd has.
Switching to systemd also implies to trust that Lennart will do the
right things.
I am not in a position to judge
On Wed, Dec 18, 2013 at 08:53:04AM -0500, Sam Hartman wrote:
Adrian, I'm frustrated when I read your message because you put words in
my mouth that I did not speak.
Hi Sam,
I never said that Debian should allow systemd to dictate policy for
multiple distributions nor did I say that Debian
Hi,
Le mercredi 18 décembre 2013 à 16:26 +0200, Adrian Bunk a écrit :
We already seem to agree that the statement in the systemd position
statement that does not have any impact on the ability to upgrade
systems is not correct.
No, we do not. I have already explained why I believe the
Hi,
Adrian Bunk b...@stusta.de writes:
On Wed, Dec 18, 2013 at 01:19:48PM +0100, Josselin Mouette wrote:
And now you bring up the point that Debian should reconsider the
lenght of it's release cycles if systemd upstream decides to not
support upgrades between distribution releases as far
On Wed, Dec 18, 2013 at 03:10:19PM +0200, Uoti Urpala wrote:
On Wed, 2013-12-18 at 13:34 +0200, Adrian Bunk wrote:
...
When not using systemd as pid 1, that risk would be confined to the
parts of systemd Debian would be using (currently only udev).
I think you still misread the argument:
Hi Uorti,
Le mercredi 18 décembre 2013 à 15:10 +0200, Uoti Urpala a écrit :
I don't think anyone said that. Nobody talked about long release cycles
not being supported, and nobody said that upgrades would not be
supported either. However, supporting upgrade from the old release
does not
On Wed, Dec 18, 2013 at 04:10:19PM +0100, Ansgar Burchardt wrote:
Hi,
Adrian Bunk b...@stusta.de writes:
On Wed, Dec 18, 2013 at 01:19:48PM +0100, Josselin Mouette wrote:
And now you bring up the point that Debian should reconsider the
lenght of it's release cycles if systemd upstream
On Wed, Dec 18, 2013 at 03:50:33PM +0100, Josselin Mouette wrote:
Hi,
Hi Josselin,
...
I do not consider keeping an arbitrary number of packages at the wheezy
version an appropriate answer, regardless of the choice of init systems.
...
how many and which packages would have to be kept at the
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 for
]] Adrian Bunk
You're mixing two separate issues (or at least not clearly indicating
which one you're talking about). Systemd fully supports having a
separate /usr partition, and that is in no way deprecated AFAIK. What
has changed compared to old practice is that /usr needs to be
Adrian Bunk b...@stusta.de writes:
I was misreading that as referring to the headaches udev had caused in
the past for Debian upgrades, not that the systemd udev might be the
cause of future upgrade headaches.
But I do not buy this We already switched to systemd as upstream of
udev, so
Adrian Bunk b...@stusta.de writes:
[1] Personally, I am sceptical whether it is a good idea to switch to a
different init system for jessie. But I am not on a desperate rant
against systemd, and if something I bring up can be addressed that
is positive for me.
Just to give fair
Uoti Urpala writes (Bug#727708: systemd socket activation protocol rationale):
On Sat, 2013-12-14 at 21:45 +, Ian Jackson wrote:
Why do only some of the environment variables start SD_ ?
We have LISTEN_PID and LISTEN_FDS but SD_LISTEN_FDS_START.
You misread it: there is no environment
On Wed, Dec 18, 2013 at 02:44:03PM -0800, Russ Allbery wrote:
Adrian Bunk b...@stusta.de writes:
...
When not using systemd as pid 1, that risk would be confined to the
parts of systemd Debian would be using (currently only udev).
There appears to be near-unanimous agreement that Debian
On Wed, Dec 18, 2013 at 02:53:39PM -0800, Russ Allbery wrote:
Adrian Bunk b...@stusta.de writes:
[1] Personally, I am sceptical whether it is a good idea to switch to a
different init system for jessie. But I am not on a desperate rant
against systemd, and if something I bring up
Hi Adrian,
Le lundi 16 décembre 2013 à 17:52 +0200, Adrian Bunk a écrit :
Can you give a pointer to what guarantees systemd upstream makes
regarding supporting older kernels?
Systemd is a userspace program. As such, it can has the same problems as
any other userspace programs. A notable
On Tue, Dec 17, 2013 at 12:38:50PM +0100, Josselin Mouette wrote:
Hi Adrian,
Hi Josselin,
Le lundi 16 décembre 2013 à 17:52 +0200, Adrian Bunk a écrit :
Can you give a pointer to what guarantees systemd upstream makes
regarding supporting older kernels?
Systemd is a userspace program.
On Tue, Dec 17, 2013 at 09:38:56PM +0200, Adrian Bunk wrote:
On Tue, Dec 17, 2013 at 10:29:35AM -0800, Russ Allbery wrote:
Adrian Bunk b...@stusta.de writes:
this hits exactly the core of the problem:
The minimum supported Linux kernel version in glibc is currently 2.6.16,
Adrian Bunk b...@stusta.de writes:
The holding back upstream packages would only be true for Linux-only
software that additionally chooses to drop the non-kdbus codepaths.
As I already explained, software like glib2.0 and libdbus that supports
non-Linux kernels will anyway have to continue
Kurt Roeckx k...@roeckx.be writes:
We release about every 2 years, but the kernel we have in wheezy was
already about 16 months old when wheezy was released. Jessie will
freeze in november 2014, so that the kernel will then be about 3 years
old. I'm going to assume that the release team is
Adrian Bunk b...@stusta.de writes:
this hits exactly the core of the problem:
The minimum supported Linux kernel version in glibc is currently 2.6.16,
released in 2006. And I'd trust glibc upstreamt that this requirement
won't suddenly be bumped to a quite recent version.
Is there any
On Tue, Dec 17, 2013 at 10:29:35AM -0800, Russ Allbery wrote:
Adrian Bunk b...@stusta.de writes:
this hits exactly the core of the problem:
The minimum supported Linux kernel version in glibc is currently 2.6.16,
released in 2006. And I'd trust glibc upstreamt that this requirement
Hi Russ,
Le mardi 17 décembre 2013 à 12:26 -0800, Russ Allbery a écrit :
Is there actually any implementation other than glib2.0 and libdbus that
would be affected by a switch to kdbus?
This is an interesting question. Josselin, is GNOME (for example) likely
to acquire a hard dependency
Adrian == Adrian Bunk b...@stusta.de writes:
Adrian Yes, it is speculation that other new features (or even
Adrian bugfixes) might appear in the kernel and might become
Adrian mandatory in systemd between jessie and jessie+1.
Adrian But that is a risk, and it is a risk that is
Sam Hartman hartm...@debian.org writes:
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 could avoid systemd entirely. It sounds like
we may be able to avoid systemd as pid 1
Hi Josselin,
reading through the systemd position statement [1], I ran into a
statement that is either incomplete or incorrect:
The upstart position statement [2] states:
-- snip --
systemd is hasty. ... While we are committed to having sane upgrade
paths and not depend on such kernel
On Sat, Dec 14, 2013 at 11:53:42PM +0100, Michael Stapelberg wrote:
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I think it would be good, regardless of what the TC decides on the
init system question for Debian, for systemd and upstart to converge
on a single reasonable protocol.
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 of the environment variables start SD_ ?
We have LISTEN_PID and
I've been RTFMing upstart and systemd. This has generated a number of
bug reports. In case these are at of any interest here's a list. If
anything particularly interesting happens in them, I'll mention it.
#732127 [n| ] Does setuid also set the group(s) ? It should.
#732122 [m| ] semantics
Ian Jackson writes (systemd and upstart (mostly docs) bugs submitted):
I've been RTFMing upstart and systemd. This has generated a number of
bug reports. In case these are at of any interest here's a list. If
anything particularly interesting happens in them, I'll mention it.
I missed two:
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 of the
Hi Ian,
[still sending this after Uoti’s reply, because my version has some more
detail]
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Why do only some of the environment variables start SD_ ?
We have LISTEN_PID and LISTEN_FDS but SD_LISTEN_FDS_START.
SD_LISTEN_FDS_START is a #define
]] Russ Allbery
Don Armstrong d...@debian.org writes:
Projects which have multiple components, each of which has different
security/interface surfaces without stable defined interfaces, can lead
to problems when one set of developers doesn't understand the security
implications of the
]] Russ Allbery
My question here is: am I missing something in systemd? Did I just look
at the wrong files, or not look deeply enough, or is there orientation
documentation somewhere else where I didn't see it? Is there something
about this comparison that's unfair?
Did you see the
1 - 100 of 148 matches
Mail list logo
