* 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
* 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
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
]] Josselin Mouette
> It is possible to handle the situation with udev or with systemd,
> because they do not make sense in a chroot environment, but they are the
> exception, not the rule. And unless things go hectic, we *will* be able
> to treat them normally and provide an upgrade path that do
]] 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 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 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 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
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
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
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 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
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
41 matches
Mail list logo
