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
l
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
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.
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 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 un
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 ar
]] 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
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
htt
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.c
Hello,
On Tue, 31 Dec 2013 13:07:22 -0800
Steve Langasek 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 would be ridicu
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 cu
Christoph Anton Mitterer 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 trouble.
> Do yo
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 syst
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?
]] 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 syst
Christoph Anton Mitterer 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 (dm-crypt->LVM)...
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 infor
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 righ
* Raphael Hertzog , 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 maintainer of that pac
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 solu
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
Hi,
Tollef Fog Heen 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-
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 s
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
]] 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 syst
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
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 maintai
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 ot
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 sc
Steve Langasek 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', preventing us from
* 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 ac
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 bein
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
]] 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
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 i
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 D
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
--
.''`. Pau
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
Steve Langasek 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.
I think it
Steve Langasek writes:
> On Sun, Dec 29, 2013 at 12:42:24AM +0100, Vincent Bernat wrote:
>> Ian Jackson writes:
>>> 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 t
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 i
On Sun, Dec 29, 2013 at 12:42:24AM +0100, Vincent Bernat wrote:
> ❦ 28 décembre 2013 23:46 CET, Ian Jackson :
> > 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
Russ Allbery 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 synchronization required
Ian Jackson 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 into detail about what I foun
Ian Jackson 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 author.
> * systemd's readine
❦ 28 décembre 2013 23:46 CET, Ian Jackson :
> 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 scripts, so I had to switch the
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 repo
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
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 s
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 inte
#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 certainl
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 guideli
* 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
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 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
> >
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, whic
On Thu, Dec 19, 2013 at 09:53:01AM -0800, Russ Allbery wrote:
> Adrian Bunk 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
Adrian Bunk 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 of
logind. Th
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 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 desperat
On Wed, Dec 18, 2013 at 02:53:39PM -0800, Russ Allbery wrote:
> Adrian Bunk 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
On Wed, Dec 18, 2013 at 02:44:03PM -0800, Russ Allbery wrote:
> Adrian Bunk 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 will also
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_STAR
Adrian Bunk 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 warning: ri
Adrian Bunk 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 we also ha
]] 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
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, 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
On Wed, Dec 18, 2013 at 04:10:19PM +0100, Ansgar Burchardt wrote:
> Hi,
>
> Adrian Bunk 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 d
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 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 arg
Hi,
Adrian Bunk 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 apart
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
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
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 j
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 c
]] 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
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.
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
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
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 migh
On Tue, Dec 17, 2013 at 06:02:50PM -0500, Sam Hartman wrote:
> > "Adrian" == Adrian Bunk 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
Sam Hartman 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 but systemd is v
> "Adrian" == Adrian Bunk 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 uniq
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 depen
On Tue, Dec 17, 2013 at 10:29:35AM -0800, Russ Allbery wrote:
> Adrian Bunk 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
Adrian Bunk 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 explicit commi
Kurt Roeckx 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 not going t
Adrian Bunk 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 to support
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 writes:
> >
> > > this hits exactly the core of the problem:
> >
> > > The minimum supported Linux kernel version in glibc is currently 2.6.16,
> > > relea
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 p
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 sim
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 fe
On Sat, Dec 14, 2013 at 11:53:42PM +0100, Michael Stapelberg wrote:
> Ian Jackson 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.
> Helmut Grohne has done so
Hi Ian,
[still sending this after Uoti’s reply, because my version has some more
detail]
Ian Jackson 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 from sd-daemon.h, not an enviro
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
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 of
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 t
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 LI
On Sun, Dec 01, 2013 at 12:11:11PM -0600, Steve Langasek wrote:
> > More review and more usage will lead to more bugs being found, we should
> > rather applaud Red Hat for investing resources and be diligent. After all
> > Red Hat is the only distro staffing a proactive product security team
> > (f
On Tue, 03 Dec 2013, Tollef Fog Heen wrote:
> ]] Russ Allbery
> > Don Armstrong 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
> > >
1 - 100 of 148 matches
Mail list logo
