systemd bugs in F20/F21 -> bug against the distribution?

Reindl Harald h.reindl at
Thu Apr 3 20:41:58 UTC 2014

Am 03.04.2014 22:32, schrieb Adam Williamson:
> On Thu, 2014-04-03 at 19:31 +0200, Reindl Harald wrote:
>> will that below ever get fixed in F20?
> The developer does not consider it to be a bug. You may disagree, but so
> far, you don't seem to have convinced him or any other systemd
> developers or, well, anyone else.

than the developer should explain his point of view and
ask for further input instead react with WONT FIX

> This is an entirely trivial issue: a failed attempt to access something
> with no apparent negative consequences. Doesn't seem like it'd be a high
> priority. It also doesn't seem like it would be too difficult to track
> down and propose a fix, if it's bugging you so much.

i expect from a serious developer to face that message because i
expect that he reads his syslogs, if it is meaningless than the
code around of that is also meaningless and has to be removed
for the sake of clean software

> You yourself have reported in
> that this is
> fixed on the systemd 208 branch, which F20 is tracking. Then you went
> nuts and started yelling at people, which as you've been told fifty six
> thousand goddamn times by now, never ever helps. From the latest
> comments it sounds like whenever f20 is updated to the latest
> systemd-208 code, this fix will come in. It's up to the package
> maintainer when they want to do that.

well, if someone reports problems and even has testing environments
as well is willing to verify and test he can expect respect in form
of a scratch build

> Apparently fixed in 20 and Rawhide, you just want a backport to 19?

since the "no distributeable systemctl reboot" and much more the scary
fact that a workaround is based ona typo prevents from update any
production server to F20 i will face that until F20 is useable in
production which is not the case caused by systemd - chicken/egg problem

> Is another extremely trivial one: you're throwing your toys out of the
> pram over slightly sub-optimal autocomplete? Really?

it's anotehr drop into a full sea and affects my workload all the time
because i distribute commands from one machine having all packages

systemctl stop whatever.service; do something; do something; systemctl start whatever.service

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the devel mailing list