Just saying ..
> An admin who is upgrading to a new version of the operating system
> will run lots of tests before actually deploying which is
> how these things are usually caught.
Exactly, I do check if a screen is still up after disconnect, before
pushing every update in production. I do chec
Package: systemd-cron
Version: 1.5.4-2
Severity: normal
File: /usr/bin/crontab
When I try to edit my crontab I get the following error. It seems to be
confusing the 0 for minute/hour in the crontab with month/day.
pabs@chianamo ~ $ crontab -e
crontab: month and day can't be 0 in /tmp/crontab_...:
If there were ever any doubt, this surely settles it:
systemd truly is the pulseaudio of process control!
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pk
On Mon, 30 May 2016 22:19:48 +0200 John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:
> Hi!
>
> > don't think the right response should be to just fix it one way
> > for everyone, especially not since those people in charge of hundreds
> > of systems have exactly one vote, similar to
Processing commands for cont...@bugs.debian.org:
> merge 748086 825858
Bug #748086 [systemd] insserv-generator should ignore masked and native services
Bug #748086 [systemd] insserv-generator should ignore masked and native services
Marked as found in versions systemd/230-1.
Bug #825858 [systemd]
On 30 May 2016 at 16:25, Laurent Bigonville wrote:
> Hi,
>
> rpcbind is now providing a .service file, but the
> systemd-insserv-generator is still creating dependency information base
> on it:
Indeed. The long term solution is to drop insserv-generator (bugs
missing, I should finally sit and fil
also sprach John Paul Adrian Glaubitz
[2016-05-30 23:30 +0200]:
> Well, come on. Look what the usual arguments against it are: "This
> has been the default for the past 30 years and now it has changed
> and I am forced to change two options." This is not, by any
> stretch, a technical argument. T
On 05/30/2016 10:52 PM, Iustin Pop wrote:
> As long as they know about it. In an ideal world, yes, every such admin
> would read in detail all release notes. In the real world, you've just
> added more trouble for the (usually overworked) admins.
An admin who is upgrading to a new version of the o
also sprach John Paul Adrian Glaubitz
[2016-05-30 22:19 +0200]:
> I'm sorry, but this is a very bad argument. People who are in
> charge of hundreds of systems almost never use the default
> settings but use something like FAI, …
In this case: agreed. In general, I just wanted to point out that
On 2016-05-30 22:19:48, John Paul Adrian Glaubitz wrote:
> Hi!
>
> > don't think the right response should be to just fix it one way
> > for everyone, especially not since those people in charge of hundreds
> > of systems have exactly one vote, similar to those who just develop
> > for their own h
On Mon, 30 May 2016 22:25:25 +0200 Laurent Bigonville
wrote:
> Hi,
>
> rpcbind is now providing a .service file, but the
> systemd-insserv-generator is still creating dependency information base
> on it:
>
> # /run/systemd/generator/rpcbind.service.d/50-rpcbind-$portmap.conf
> # Automatically g
Package: systemd
Version: 230-1
Severity: normal
Hi,
rpcbind is now providing a .service file, but the
systemd-insserv-generator is still creating dependency information base
on it:
# /run/systemd/generator/rpcbind.service.d/50-rpcbind-$portmap.conf
# Automatically generated by systemd-insserv-g
Hi!
> don't think the right response should be to just fix it one way
> for everyone, especially not since those people in charge of hundreds
> of systems have exactly one vote, similar to those who just develop
> for their own home workstation.
I'm sorry, but this is a very bad argument. People
Processing commands for cont...@bugs.debian.org:
> reassign 763315 rpcbind
Bug #763315 [systemd] systemd: Dependency loop between basic.target,
nfs-common, rpcbind,...
Bug reassigned from package 'systemd' to 'rpcbind'.
No longer marked as found in versions systemd/215-5.
Ignoring request to alte
Package: systemd
Version: 230-1
Severity: normal
--- Please enter the report below this line. ---
Dear maintainer:
After 229.6 (I waited that 230-1 fix it, but it is the same) update I
have a strange issue. First, as you can see the accounts-daemon.service
takes a lot of time to load:
also sprach Martin Pitt [2016-05-29 11:13 +0200]:
> I believe this *is* it the expected thing to do on personal
> computers. This is certainly different in environments like
> universities where one often does put long-running stuff in the
> background, but this doesn't appeal to me as being the b
This bug is still active in Jessie Mar 2016.
The workaround mentioned here does not work for me.
Any news on any progress?
On Mon, 4 Jan 2016 15:25:21 +0100 =?UTF-8?B?VGlsbWFubiBCw7bDnw==?= <
t...@velotiger.de> wrote:
> Hi,
>
> I solved this problem for me by changing the runlevels in
> "/etc/i
Your message dated Mon, 30 May 2016 16:24:11 +
with message-id
and subject line Bug#820359: fixed in init-system-helpers 1.34
has caused the Debian Bug report #820359,
regarding init-system-helpers: Handle \ escape in systemd unit names
to be marked as done.
This means that you claim that the
Your message dated Mon, 30 May 2016 16:24:11 +
with message-id
and subject line Bug#825075: fixed in init-system-helpers 1.34
has caused the Debian Bug report #825075,
regarding deb-systemd-invoke: incomplete handling of policy-rc.d status codes
to be marked as done.
This means that you claim
Your message dated Mon, 30 May 2016 16:24:11 +
with message-id
and subject line Bug#756023: fixed in init-system-helpers 1.34
has caused the Debian Bug report #756023,
regarding init: move "Essential: yes" from init to init-system-helpers
to be marked as done.
This means that you claim that t
Your message dated Mon, 30 May 2016 16:24:11 +
with message-id
and subject line Bug#756023: fixed in init-system-helpers 1.34
has caused the Debian Bug report #756023,
regarding init: Move "Essential: yes" from init to init-system-helpers
to be marked as done.
This means that you claim that t
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Mon, 30 May 2016 15:52:48 +0200
Source: init-system-helpers
Binary: init-system-helpers dh-systemd init
Architecture: source all amd64
Version: 1.34
Distribution: unstable
Urgency: medium
Maintainer: Debian systemd Main
Hello all,
Pretty please stop all the ranting and "me too"s. The option has
already be reverted in the packaging git. This isn't an exercise in
"who shouts the loudest".
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Deve
On 05/30/2016 09:59 AM, Vitaliyi wrote:
ROFLCOPTER.
This is the funnies bug that I remember in Debian.
Debian, please get rid of that crap systemd.
Please try to be constructive and contribute to useful, mature discourse
when making comments here.
_
What a pain! Turn this "feature" off, an application should not try to fix
errors from other applications, what a mess
Cheers
Lars
smime.p7s
Description: S/MIME cryptographic signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@li
ROFLCOPTER.
This is the funnies bug that I remember in Debian.
Debian, please get rid of that crap systemd.
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/
init-system-helpers_1.34_amd64.changes uploaded successfully to localhost
along with the files:
init-system-helpers_1.34.dsc
init-system-helpers_1.34.tar.xz
dh-systemd_1.34_all.deb
init-system-helpers_1.34_all.deb
init_1.34_amd64.deb
Greetings,
Your Debian queue daemon (running
On 05/30/2016 05:46 AM, Shish wrote:
`mosh-server` should be added to the list of processes which should be
exempt from this behaviour, as it is based on the principle of "ssh
into remote host, start daemon, exit ssh, continue speaking to
daemon".
As a workaround, I'm running it in a new session
`mosh-server` should be added to the list of processes which should be
exempt from this behaviour, as it is based on the principle of "ssh
into remote host, start daemon, exit ssh, continue speaking to
daemon".
As a workaround, I'm running it in a new session explicitly:
mosh --server "systemd-
>
> It may be a minority, but I'm sure it's
> a significant amount of people
>
>
Agree, I think this should remain to be considered a bug, even a critical
bug. And I am sure users of screen/nohup/tmux or others "daemons" which
could be affected are not a small minority, but even the majority. So
p
30 matches
Mail list logo
