Bas Wijnen wrote:
On Mon, May 12, 2014 at 09:19:40AM -0700, Josh Triplett wrote:
Having libpam-systemd depend on systemd-shim | systemd-sysv will not
properly
handle systems that already have systemd installed but not systemd-sysv.
I don't think I understand what you mean. What does
On Mon, May 12, 2014 at 11:54:43AM +0200, Josselin Mouette wrote:
Le vendredi 09 mai 2014 à 21:13 +0200, Bas Wijnen a écrit :
I think it would be good for libpam-systemd to list systemd-shim first.
Certainly not.
Systemd is the default init system for jessie, and it should be listed
as
On Mon, May 12, 2014 at 11:21:15AM -0700, Josh Triplett wrote:
I don't think I understand what you mean. What does having systemd
installed mean, if not that it's being used as the init system? And if
it isn't used as the init system (presumably because the user chose no
to do that), why
On Mon, May 12, 2014 at 11:21:15AM -0700, Josh Triplett wrote:
In other words: what isn't handled properly? What should happen, and what
does
happen?
Consider a system which has systemd installed, systemd-sysv *not* installed,
and systemd used as PID 1 via init=/bin/systemd. Since
On Mon, 2014-05-12 at 21:16 +0200, Bas Wijnen wrote:
It's easy enough for any user who *does* care to select a different set of
installed packages.
It's not so much about caring which init system to use. It's about being in
control over your own computer. There are many packages that
Le Mon, May 12, 2014 at 11:21:15AM -0700, Josh Triplett a écrit :
There *is* a reason we should push our users away from the non-default
init: we want to make sure that only the users who specifically *want* a
non-default init run one, and those are exactly the users prepared to
deal with
El Mon, 12 de May 2014 a las 3:48 PM, Charles Plessy
ple...@debian.org escribió:
Le Mon, May 12, 2014 at 11:21:15AM -0700, Josh Triplett a écrit :
There *is* a reason we should push our users away from the
non-default
init: we want to make sure that only the users who specifically
*want* a
Charles Plessy ple...@debian.org writes:
Le Mon, May 12, 2014 at 12:16:48PM +0200, Andrew Shadura a écrit :
On 12 May 2014 11:54, Josselin Mouette j...@debian.org wrote:
Systemd is the default init system for jessie, and it should be listed
as the first alternative. The fact that an
Thorsten Glaser wrote:
On Sun, 11 May 2014, Marc Haber wrote:
[...]
On Sun, 11 May 2014, Cyril Brulebois wrote:
Marc Haber mh+debian-de...@zugschlus.de (2014-05-11):
Just curious as the maintainer of another package using su in an
init script since 2001, how am I supposed to start a
Steve Langasek wrote:
On Mon, May 12, 2014 at 11:21:15AM -0700, Josh Triplett wrote:
I don't think I understand what you mean. What does having systemd
installed mean, if not that it's being used as the init system? And if
it isn't used as the init system (presumably because the user
On Mon, May 12, 2014 at 04:21:56PM -0700, Josh Triplett wrote:
Consider a system which has systemd installed, systemd-sysv *not*
installed, and systemd used as PID 1 via init=/bin/systemd. Since
systemd-sysv is not already installed, systemd-shim | systemd-sysv will
pull in
On Fri, May 09, 2014 at 08:30:22PM +0200, Michael Biebl wrote:
Am 09.05.2014 19:56, schrieb Steve Langasek:
I don't think systemd integration is in a state today that this is ready to
become the default.
What are you missing?
Bug #746587 is a prime example. But more generally, I'm
On Mon, 12 May 2014, Steve Langasek wrote:
Bug #746587 is a prime example. But more generally, I'm looking for
evidence that we're being systematic about making sure the packages that
hook into early boot, either via /etc/rcS.d or /etc/network/if-up.d, will
still work correctly after the
On 13 May 2014 11:11, Norbert Preining prein...@logic.at wrote:
#743265: systemd: booting with init=/bin/systemd drops into emergency mode
If a device is not available but listed without noauto or nofail
in /etc/fstab, systemd drops into emergency mode.
Maybe I am mistaken, however I
Norbert Preining prein...@logic.at writes:
This can happen on *any* server that has been booting happily since many
many years. Thus, systemd is *not* a drop-in replacement for now.
We should be realistic about this: it's not going to be, either, at least
for a definition of drop-in
On Mon, 12 May 2014, Russ Allbery wrote:
In this case, maybe we can add some transitional smarts to the same
package that takes responsibility for upgrade prompting. What comes to
mind is scanning /etc/fstab and look for filesystems that aren't set
noauto or nofail but that aren't mounted and
If a device is not available but listed without noauto or nofail
in /etc/fstab, systemd drops into emergency mode.
Maybe I am mistaken, however I thought this was standard behaviour for SYSV
boot systems too
No, it is not standard behaviour. It warns you, but continues booting.
On 13 May 2014 12:47, Norbert Preining prein...@logic.at wrote:
Yes, that is true, because at that time it was about booting with
init=/bin/systemd
and *not* about automatic upgrade to systemd without any checking back.
No, the title of the bug was changed to systemd drops into
On Sat, 10 May 2014 17:49:46 +0100, Dimitri John Ledkov
x...@debian.org wrote:
Users of sysvinit, are of two categories, those that reverted to or
wish to stay with sysvinit or those that simply use the default.
It is desired to migrate simply use the default to the new default,
systemd, if that
On Sat, 10 May 2014 11:55:19 +0200, Matthias Urlichs
matth...@urlichs.de wrote:
Marc Haber:
Will it be the norm that the binaries replacing well-used shell
scripts on early boot only implement the features that Lennart deemed
useful? That would be a major turn-off, adding to the fact that early
On Sat, 10 May 2014 15:28:34 +0200, Martin Steigerwald
mar...@lichtvoll.de wrote:
I did not make a technical statement about systemd. I understand the reasons
why Tech-CTTE chose it and while I am skeptical about the attitude of some
upstream and Debian developers regarding handling bug reports
On Sat, 10 May 2014 18:00:02 +0200, Laurent Bigonville
bi...@debian.org wrote:
Le Sat, 10 May 2014 16:00:39 +0200,
Yet: I do think its about high time systemd developers and packagers
adopt an attitude of never break userspace like the kernel
developers do.
Sure that the attitude I don't care
On Sat, 10 May 2014 19:13:01 +0200, Matthias Urlichs
matth...@urlichs.de wrote:
Every compiler toolchain upgrade breaks a bunch of packages, sometimes in
subtle ways, and mostly because the code was in some way non-standard.
You don't complain about that, do you? So why is systemd different?
On Sat, 10 May 2014 20:57:28 +0100, Ben Hutchings
b...@decadent.org.uk wrote:
On Sat, 2014-05-10 at 19:53 +0200, Jakub Wilk wrote:
* Matthias Urlichs matth...@urlichs.de, 2014-05-10, 19:13:
Every compiler toolchain upgrade breaks a bunch of packages,
For end users? I don't think so.
If a
On Sat, 10 May 2014 22:13:01 +0200, Matthias Urlichs
matth...@urlichs.de wrote:
I also would not expect an end user to add su foo -c /do/whatever to
/etc/rc.local. Your opinion may differ, that's OK.
Especially people who are not as Debian-centric as we are tend to do
exactly this. Simply because
On Sat, 10 May 2014 15:38:24 -0700, Steve Langasek vor...@debian.org
wrote:
I consider it of the highest importance that the transition to systemd not
break running systems.
+1
Some of the regressions introduced are going to turn out to be bugs in
systemd. Some of them are going to turn out to
On Sat, 10 May 2014 16:27:00 +0200, Bas Wijnen wij...@debian.org
wrote:
This is the part you should _NEVER_ do. It is YOUR responsibitiliy, as a
maintainer (you are the maintainer, right?), to make sure that a bug that is
reported in the wrong place gets sent to the right place. It is GOOD that
Marc Haber mh+debian-de...@zugschlus.de (2014-05-11):
Just curious as the maintainer of another package using su in an init
script since 2001, how am I supposed to start a non-root process from
an init script?
start-stop-daemon has:
-c, --chuid username|uid[:group|gid]
Mraw,
KiBi.
Am Sonntag, 11. Mai 2014, 08:57:29 schrieb Marc Haber:
IMVHO opening a PAM session in an initscript is a bad idea from day
one, as you don't know which modules are being called, as it can create
bogus audit trails or cause other subtile issues.
Just curious as the maintainer of another
Hi,
Marc Haber:
systemctl status tells you quite clearly what went wrong, journalctl
shows you what the program printed in case it did get started … and so on.
If the system boots.
If it does not, you cannot stick '-x' into an init script either.
I haven't yet seen a system where booting
Am Samstag, 10. Mai 2014, 21:36:42 schrieb Laurent Bigonville:
Le Sat, 10 May 2014 19:13:01 +0200,
Matthias Urlichs matth...@urlichs.de a écrit :
Hi,
[...]
Telling Go away, the bug is elsewhere is just not an approbiate
reaction for developers of a low level system component.
Am Samstag, 10. Mai 2014, 15:38:24 schrieb Steve Langasek:
On Sat, May 10, 2014 at 04:00:39PM +0200, Martin Steigerwald wrote:
The root cause of this bug is in the initscript of dirmngr that us using
su instead of start-stop-daemon.
su is starting a PAM session which then call
Am Sonntag, 11. Mai 2014, 00:55:43 schrieb Kevin Chadwick:
previously on this list Steve Langasek contributed:
Using systemd breaks something that worked for probably a decade or
longer
before however long that su is in that init script. So on what account
do
you call calling su
Am Sonntag, 11. Mai 2014, 09:13:09 schrieb Marc Haber:
On Sat, 10 May 2014 16:27:00 +0200, Bas Wijnen wij...@debian.org
wrote:
This is the part you should _NEVER_ do. It is YOUR responsibitiliy, as a
maintainer (you are the maintainer, right?), to make sure that a bug that
is reported in
❦ 11 mai 2014 08:58 +0200, Marc Haber mh+debian-de...@zugschlus.de :
Mind you, I am not defending the handling of this specific bug; certainly
the systemd people's attitude is somewhat … let's call it abrasive …
at times.
And this abrasive attitude is hurting. It's hurting systemd, it's
On Sun, 11 May 2014 10:22:02 +0200, Matthias Urlichs
matth...@urlichs.de wrote:
That is true, but it's even simpler if there's no script to stick '-x' into
in the first place, because PID1 knows perfectly well how to do it on its
own and will give you a complete status, including failed
On Sun, 11 May 2014 10:04:15 +0200, Cyril Brulebois k...@debian.org
wrote:
Marc Haber mh+debian-de...@zugschlus.de (2014-05-11):
Just curious as the maintainer of another package using su in an init
script since 2001, how am I supposed to start a non-root process from
an init script?
On Sun, 11 May 2014 11:54:37 +0200, Vincent Bernat ber...@debian.org
wrote:
? 11 mai 2014 08:58 +0200, Marc Haber mh+debian-de...@zugschlus.de :
Mind you, I am not defending the handling of this specific bug; certainly
the systemd people's attitude is somewhat … let's call it abrasive …
at
Am Sonntag, 11. Mai 2014, 12:53:39 schrieb Marc Haber:
On Sun, 11 May 2014 10:04:15 +0200, Cyril Brulebois k...@debian.org
wrote:
Marc Haber mh+debian-de...@zugschlus.de (2014-05-11):
Just curious as the maintainer of another package using su in an init
script since 2001, how am I
Marc Haber wrote:
On Sun, 11 May 2014 10:04:15 +0200, Cyril Brulebois k...@debian.org
wrote:
Marc Haber mh+debian-de...@zugschlus.de (2014-05-11):
Just curious as the maintainer of another package using su in an
init script since 2001, how am I supposed to start a non-root
process from an
]] Martin Steigerwald
DESCRIPTION
The su command is used to become another user during a login
session. Invoked without a username, su defaults to becoming the
superuser. The optional argument - may be used to provide an
environment similar to what the user
Hi,
Martin Steigerwald:
Yet the su manpage clearly states that su doesn´t open a new login session.
Does not.
The manpage states that su is meant to change your UID _during_ a login session.
If there is no such thing, the fact that it creates a new session for you
should not be too surprising.
Hi,
Marc Haber:
start-stop-daemon has:
-c, --chuid username|uid[:group|gid]
Will a script doing this be portable to other Linuxes or even BSD
Unices?
No. BSD has daemon(8). If you want portability, you probably need to check
what's available. (start-stop-daemon, daemon (on BSDs),
On Sun, 11 May 2014 13:16:43 +0200, Martin Steigerwald
mar...@lichtvoll.de wrote:
Am Sonntag, 11. Mai 2014, 12:53:39 schrieb Marc Haber:
On Sun, 11 May 2014 10:04:15 +0200, Cyril Brulebois k...@debian.org
wrote:
Marc Haber mh+debian-de...@zugschlus.de (2014-05-11):
Just curious as the
On Sun, 11 May 2014 13:47:39 +0200, Laurent Bigonville
bi...@debian.org wrote:
For other distributions (and other Unix based OS) most of (all?) the
initscripts are already different anyway.
Is it right to force that?
Greetings
Marc
--
-- !! No courtesy
* Marc Haber mh+debian-de...@zugschlus.de [140511 16:09]:
On Sun, 11 May 2014 13:16:43 +0200, Martin Steigerwald
mar...@lichtvoll.de wrote:
Am Sonntag, 11. Mai 2014, 12:53:39 schrieb Marc Haber:
On Sun, 11 May 2014 10:04:15 +0200, Cyril Brulebois k...@debian.org
wrote:
Marc Haber
* Marc Haber mh+debian-de...@zugschlus.de [140511 16:12]:
On Sun, 11 May 2014 13:47:39 +0200, Laurent Bigonville
bi...@debian.org wrote:
For other distributions (and other Unix based OS) most of (all?) the
initscripts are already different anyway.
Is it right to force that?
This is already
Marc Haber wrote:
On Sun, 11 May 2014 13:16:43 +0200, Martin Steigerwald
mar...@lichtvoll.de wrote:
Am Sonntag, 11. Mai 2014, 12:53:39 schrieb Marc Haber:
On Sun, 11 May 2014 10:04:15 +0200, Cyril Brulebois
k...@debian.org
wrote:
Marc Haber mh+debian-de...@zugschlus.de (2014-05-11):
On Sat, May 10, 2014 at 03:38:24PM -0700, Steve Langasek wrote:
As the maintainer of the pam package in Debian, I assure you: this is a bug
in dirmngr. System services should not (must not) call interfaces that
launch pam sessions as part of their init scripts. su is one of those
interfaces.
On Sun, 11 May 2014 18:48:46 +0200, Laurent Bigonville
bi...@debian.org wrote:
Marc Haber wrote:
This will also cause double effort since Debian needs special handling
that no other distribution obviously needs.
Could you please explain me how it could cause double effort as the
initscript the
severity 747535 serious
thanks
Please Tollef :(
On Sun, 2014-05-11 at 09:00 +0200, Marc Haber wrote:
On Sat, 10 May 2014 20:57:28 +0100, Ben Hutchings
b...@decadent.org.uk wrote:
On Sat, 2014-05-10 at 19:53 +0200, Jakub Wilk wrote:
* Matthias Urlichs matth...@urlichs.de, 2014-05-10, 19:13:
On Sun, 2014-05-11 at 18:48 +0200, Laurent Bigonville wrote:
Marc Haber wrote:
On Sun, 11 May 2014 13:16:43 +0200, Martin Steigerwald
mar...@lichtvoll.de wrote:
Am Sonntag, 11. Mai 2014, 12:53:39 schrieb Marc Haber:
On Sun, 11 May 2014 10:04:15 +0200, Cyril Brulebois
k...@debian.org
previously on this list Matthias Urlichs contributed:
I haven't yet seen a system where booting with init=/bin/bash works but
booting systemd in emergency mode does not.
Have you added me to a killfile?
I mentioned such a bug as happened in Arch testing in this very thread
or do you mean a
previously on this list Matthias Urlichs contributed:
Will a script doing this be portable to other Linuxes or even BSD
Unices?
No. BSD has daemon(8). If you want portability, you probably need to check
what's available. (start-stop-daemon, daemon (on BSDs), sudo)
I can tell you
Am 11.05.2014 19:37, schrieb Helmut Grohne:
I trust you to be technically right on this. Still the number of
packages getting this wrong is stunning[1]. Therefore I'd argue that
[1] http://codesearch.debian.net/search?q=su+-c+path%3Adebian%2F+path%3Ainit
If I counted correctly, there are 5
Am 10.05.2014 08:06, schrieb Norbert Preining:
One of the things that systemd breaks (not checked on Debian, but
on other systems), is that screen session are killed when logging out
of the ssh session.
This is a *fundamental* change in behaviour, and does break a lot
of setups and systems.
El Sun, 11 de May 2014 a las 1:49 PM, Michael Biebl bi...@debian.org
escribió:
Am 11.05.2014 19:37, schrieb Helmut Grohne:
I trust you to be technically right on this. Still the number of
packages getting this wrong is stunning[1]. Therefore I'd argue that
[1]
Am 11.05.2014 22:49, schrieb Michael Biebl:
Am 11.05.2014 19:37, schrieb Helmut Grohne:
I trust you to be technically right on this. Still the number of
packages getting this wrong is stunning[1]. Therefore I'd argue that
[1]
On 10/05/14 00:50, Russ Allbery wrote:
we should also prepare for that situation
and ensure that any switch of an init system via package installation
results in a critical debconf warning so that no one is caught by
surprise.
This has the advantage of future-proofing against any later
Carlos Alberto Lopez Perez clo...@igalia.com writes:
On 10/05/14 00:50, Russ Allbery wrote:
we should also prepare for that situation and ensure that any switch of
an init system via package installation results in a critical debconf
warning so that no one is caught by surprise.
This has
On Sun, May 11, 2014 at 08:06:14PM -0700, Russ Allbery wrote:
One of the maintainers of systemd says that otherwise he don't thinks
this behavior is unsuitable for release: https://bugs.debian.org/747535#46
This, however, *is* the wrong way to have this discussion. Arguing over
whether
Steve Langasek vor...@debian.org writes:
RC bug severity has an important function in blocking package migrations
to testing. If someone is concerned that a particular regression in
behavior is sufficiently severe that it should block the new version of
the package from testing, they
On Sun, May 11, 2014 at 09:10:21AM +0200, Marc Haber wrote:
The plain fact:
Using systemd breaks something that worked for probably a decade or longer
before however long that su is in that init script. So on what account do
you call calling su in an init script a bug? It may not be the
Hi
On Fri, 09 May 2014, Josh Triplett wrote:
debconf prompt on every Debian user; we should not assume that because
*we* care, *they're* required to care. In practice, people will test
I strongly disagree with this opinion. From personal experience
I know several people who are not developers
On 2014-05-09, Steve Langasek vor...@debian.org wrote:
I don't think systemd integration is in a state today that this is ready to
become the default.
I don't think I have an opinion of the exact state today other than
'works for me in most cases', but I do think we are quite late in the
#secure method=pgpmime mode=sign
On Fri, May 09 2014, Russ Allbery wrote:
Josh Triplett j...@joshtriplett.org writes:
Russ Allbery wrote:
I think we need some sort of critical debconf prompt here for the
jessie release, similar to how we handled the change of /bin/sh to dash
and how we
]] Michael Biebl
i.e. does /etc/default/rcS exist on a clean jessie install?
That file is owned by initscripts, so no, that doesn't work.
We could check if /sbin/init is a symlink to systemd (or if /proc/1/exe
points to systemd) and if not warn. I think that will catch the normal
cases.
On Fri, 09 May 2014 20:30:22 +0200, Michael Biebl bi...@debian.org
wrote:
Am 09.05.2014 19:56, schrieb Steve Langasek:
I don't think systemd integration is in a state today that this is ready to
become the default.
What are you missing?
For example, keyscript= in /etc/crypttab. I got systemd
On Fri, 09 May 2014 13:09:24 +0200, Ansgar Burchardt
ans...@debian.org wrote:
On 05/09/2014 12:35, Svante Signell wrote:
Well, I've not been asked if I wanted to switch to systemd based boot
when upgrading. I think this is a bug in init system choice and should
be reported. How to go back to
On Sat, 10 May 2014, Marc Haber wrote:
boot will become undebuggable since one will not be able any more to
dump -x'es in shell scripts to see what's going on.
+10^20
Norbert
PREINING, Norbert
What are you missing?
I am still missing the part of my logs that gets chopped off.
#746351
(I know it's fixed in experimental, but I don't want to get important stuff
from experimental).
--
Salvo Tomaselli
Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso,
Hi,
Marc Haber:
Will it be the norm that the binaries replacing well-used shell
scripts on early boot only implement the features that Lennart deemed
useful? That would be a major turn-off, adding to the fact that early
boot will become undebuggable since one will not be able any more to
On Fri, 2014-05-09 at 20:39 -0700, Josh Triplett wrote:
Russ Allbery wrote:
...
I think we need some sort of critical debconf prompt here for the jessie
release, similar to how we handled the change of /bin/sh to dash and how
we handled the switch to startpar. Probably in systemd-sysv,
severity 747535 serious
thanks
Why did you downgrade bug #747535 to wishlist? The discussion is
ongoing, and no solution has found consensus yet.
I agree, raising the severity.
If one (Josh) thinks that is fine, that doesn't mean it is fine.
Norbert
Am Freitag, 9. Mai 2014, 20:30:22 schrieb Michael Biebl:
Am 09.05.2014 19:56, schrieb Steve Langasek:
I don't think systemd integration is in a state today that this is ready
to
become the default.
What are you missing?
Suitable explaination and reaction to bug reports like:
Hi Martin, hi all,
being told Go away just doesn´t match the responsibility for dealing with
issues with something that is a default for all users who don´t change it.
Indeed, and that is the feeling all around. Systemd developers
often (by default?) tell people to go away - you don't have
[I kept your Cc, I don´t need to be Cc´d tough as I am subscribed to the
list.)
Am Samstag, 10. Mai 2014, 21:21:30 schrieb Norbert Preining:
Hi Martin, hi all,
being told Go away just doesn´t match the responsibility for dealing
with
issues with something that is a default for all users
Martin Steigerwald wrote:
Am Freitag, 9. Mai 2014, 20:30:22 schrieb Michael Biebl:
Am 09.05.2014 19:56, schrieb Steve Langasek:
I don't think systemd integration is in a state today that this
is ready to
become the default.
What are you missing?
Suitable explaination and
Hi,
On Samstag, 10. Mai 2014, Matthias Urlichs wrote:
Will it be the norm that the binaries replacing well-used shell
scripts on early boot only implement the features that Lennart deemed
useful? That would be a major turn-off, adding to the fact that early
boot will become undebuggable
On Sat, 10 May 2014, Martin Steigerwald wrote:
[I kept your Cc, I don´t need to be Cc´d tough as I am subscribed to the
list.)
[So am I ;-)]
I did not make a technical statement about systemd. I understand the reasons
Neither did I. My statement was about the attitude of (especially,
but
Am Samstag, 10. Mai 2014, 15:36:26 schrieben Sie:
Martin Steigerwald wrote:
Am Freitag, 9. Mai 2014, 20:30:22 schrieb Michael Biebl:
Am 09.05.2014 19:56, schrieb Steve Langasek:
I don't think systemd integration is in a state today that this
is ready to
become the default.
I think this is a good example of how not to respond to reports, as we recently
discussed on this list. Even though most parts are excellent. :-)
On Sat, May 10, 2014 at 03:36:26PM +0200, Laurent Bigonville wrote:
The root cause of this bug is [...]
This part is useful.
So please get dirmngr
On Saturday 10 May 2014 09:57:25 Marc Haber wrote:
On Fri, 09 May 2014 20:30:22 +0200, Michael Biebl wrote:
Am 09.05.2014 19:56, schrieb Steve Langasek:
I don't think systemd integration is in a state today that this is ready
to become the default.
What are you missing?
For example,
Le Sat, 10 May 2014 16:00:39 +0200,
Martin Steigerwald mar...@lichtvoll.de a écrit :
[...]
Thats exactly the kind of reaction I meant:
Frankly, I just *don´t* care where it is fixed. If its in dirmngr,
fine.
Yet: I do think its about high time systemd developers and packagers
adopt an
Hi,
Holger Levsen:
systemctl is not mentioned on https://wiki.debian.org/systemd - maybe it
should?
Actually, this is hardly Debian specific, so a pointer to the generic page
for debugging startup/shutdown with systemd would probably be more useful
than duplicating information that's
On 9 May 2014 23:50, Russ Allbery r...@debian.org wrote:
Bas Wijnen wij...@debian.org writes:
On Fri, May 09, 2014 at 10:37:03PM +0200, Tollef Fog Heen wrote:
It and upstart (and any other providers of /sbin/init) should also grow
critical debconf warnings if you install them and you were
Am Samstag, 10. Mai 2014, 18:00:02 schrieb Laurent Bigonville:
Le Sat, 10 May 2014 16:00:39 +0200,
Martin Steigerwald mar...@lichtvoll.de a écrit :
[...]
Thats exactly the kind of reaction I meant:
Frankly, I just *don´t* care where it is fixed. If its in dirmngr,
fine.
Hi,
Martin Steigerwald:
Yet: I do think its about high time systemd developers and packagers adopt an
attitude of never break userspace like the kernel developers do.
I beg to differ. At least in this case.
su does a bunch of things that are perfectly appropriate for something
that creates
Am Samstag, 10. Mai 2014, 19:13:01 schrieb Matthias Urlichs:
Hi,
Martin Steigerwald:
Yet: I do think its about high time systemd developers and packagers adopt
an attitude of never break userspace like the kernel developers do.
I beg to differ. At least in this case.
su does a bunch of
]] Norbert Preining
So I *strongly* advise to inform *and* ask the users!!
I would strongly advise you to stop spreading FUD as well as conserving
the global supply of exclamation marks.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To
* Matthias Urlichs matth...@urlichs.de, 2014-05-10, 19:13:
Every compiler toolchain upgrade breaks a bunch of packages,
For end users? I don't think so.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Le Sat, 10 May 2014 19:13:01 +0200,
Matthias Urlichs matth...@urlichs.de a écrit :
Hi,
[...]
Telling Go away, the bug is elsewhere is just not an approbiate
reaction for developers of a low level system component.
For the record: I do not disagree with this statement.
I think there are
On Sat, 2014-05-10 at 19:53 +0200, Jakub Wilk wrote:
* Matthias Urlichs matth...@urlichs.de, 2014-05-10, 19:13:
Every compiler toolchain upgrade breaks a bunch of packages,
For end users? I don't think so.
If a package is not changed to fix the FTBFS, then it will be removed
from testing and
Hi,
Jakub Wilk:
* Matthias Urlichs matth...@urlichs.de, 2014-05-10, 19:13:
Every compiler toolchain upgrade breaks a bunch of packages,
For end users? I don't think so.
The typical end user does not recompile some system-supplied package with a
newer GCC; neither does the typical end user
On Sat, May 10, 2014 at 04:00:39PM +0200, Martin Steigerwald wrote:
The root cause of this bug is in the initscript of dirmngr that us using
su instead of start-stop-daemon.
su is starting a PAM session which then call pam_systemd. This
should not happen for daemons.
Again here systemd
previously on this list Matthias Urlichs contributed:
I also would not expect an end user to add su foo -c /do/whatever to
/etc/rc.local. Your opinion may differ, that's OK.
My opinion certainly does differ as I'm sure is already apparent ;-)
especially that pid1 and single user should most
On Sat, 10 May 2014, Tollef Fog Heen wrote:
I would strongly advise you to stop spreading FUD as well as conserving
? Could you be so kind and explain your insinuation?
Norbert
PREINING, Norbert
previously on this list Steve Langasek contributed:
Using systemd breaks something that worked for probably a decade or longer
before however long that su is in that init script. So on what account do
you call calling su in an init script a bug? It may not be the most
elegant solution
On Thu, 2014-05-08 at 18:42 -0700, Russ Allbery wrote:
Svante Signell svante.sign...@gmail.com writes:
I'm trying to install as little as possible of systemd stuff, and guess
what happens: When booting one of the laptops boot starts with:
systyemd-fsck disks
Is systemd taking over
Hi,
On 05/09/2014 12:35, Svante Signell wrote:
Well, I've not been asked if I wanted to switch to systemd based boot
when upgrading. I think this is a bug in init system choice and should
be reported. How to go back to sysvinit?
Please ask on one of the support mailing lists (CC'ed).
101 - 200 of 236 matches
Mail list logo
