On Sun, 27 Jul 2014, Michael Biebl wrote:
Am 26.07.2014 23:59, schrieb Henrique de Moraes Holschuh:
On Sat, 26 Jul 2014, Michael Biebl wrote:
If invoke-rc.d by default stops both .socket and .service, the package
maintainer no longer has this option.
This is incorrect.
You can
On Sat, 02 Aug 2014, Russ Allbery wrote:
Jonathan de Boyne Pollard j.deboynepollard-newsgro...@ntlworld.com
writes:
And bugs #734766 and #734848 tell one the answer, which is that in order
to preserve its existing conceptual model that there is just the one
thing (named simply acpid)
On Sat, 02 Aug 2014, Russ Allbery wrote:
Henrique de Moraes Holschuh h...@debian.org writes:
Services being subject to a package update can be down for extended
amounts of time (think package update that requires manual intervention,
or even a full manual reconfiguration, etc), or may
On Sun, 10 Aug 2014, Russ Allbery wrote:
To take a step back, I think this is a fair summary of the discussion.
Please let me know if you disagree:
...
I agree to all points. It is a fair summary.
I think you've convinced me that the approach of stopping a socket by the
same name when
On Mon, 11 Aug 2014, Cyril Brulebois wrote:
Michael Biebl bi...@debian.org (2014-08-11):
That is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754987
https://lists.debian.org/debian-user/2014/07/msg01509.html
I know a workaround, but haven't figured out the underlying cause yet.
On Wed, 03 Sep 2014, Ritesh Raj Sarraf wrote:
My inclination is to ship both, the systemd service files and the
init scripts, in their current form along with whatever
limitations each may have, and let the user choose.
I did not get any comment on this. How are others doing similar
stuff
On Mon, 17 Nov 2014, Anthony Towns wrote:
Having a single tool that does the basic stuff admins and maintainers need
independent of init system seems like the right approach to me. *-rc.d
is a terrible name for such a tool, though :(
Err, yes. There were complains about the -rc.d prefix way
On Mon, 15 Dec 2014, Tollef Fog Heen wrote:
]] Henrique de Moraes Holschuh
On Thu, 11 Dec 2014, Gerrit Pape wrote:
On Tue, Dec 09, 2014 at 11:24:11AM +, Gerrit Pape wrote:
On Mon, Nov 24, 2014 at 10:08:49PM +, Simon McVittie wrote:
On 24/11/14 21:41, Gerrit Pape wrote
is fixed by removing intel-microcode, I will ask for
further details to narrow the issue down.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique de
enough information to track the issue, and we
should close this bug...
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique de Moraes Holschuh h
Package: systemd
Version: 215-17
Severity: grave
Tags: upstream fixed-in-experimental
Justification: causes non-serious data loss
As reported in other distros:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1448259
https://bugzilla.redhat.com/show_bug.cgi?id=1183194
is currently broken that it fails
to, by default, also stop related socket units, thus ensuring chaos if
activated midway during the unpack/configure steps. A bug is already
open about it, but stalled.
--
Henrique de Moraes Holschuh <h...@debian.
12 matches
Mail list logo