Fixed eu-unstrip for gcc5/binutils separate debuginfo files. Unbreak elfutils-libs ptrace attach with default-yama-scope.
Updates may require up to 24 hours to propagate to mirrors. If the following command doesn't work, please retry later:
sudo dnf upgrade --refresh --advisory=FEDORA-2015-13224Please log in to add feedback.
This update has been submitted for testing by mjw. This critical path update has not yet been approved for pushing to the stable repository. It must first reach a karma of 2, consisting of 0 positive karma from proventesters, along with 2 additional karma from the community. Or, it must spend 14 days in testing without any negative feedback
Taskotron: depcheck test PASSED on i386. Result log: https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/115506/steps/runtask/logs/stdio (results are informative only)
Taskotron: depcheck test PASSED on x86_64. Result log: https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/115506/steps/runtask/logs/stdio (results are informative only)
This update is currently being pushed to the Fedora 22 testing updates repository.
This update has been pushed to testing
Works for me.
seems to work OK
Critical path update approved
This update has reached the stable karma threshold and will be pushed to the stable updates repository
Taskotron: upgradepath test FAILED on noarch. Result log: https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/116291/steps/runtask/logs/stdio (results are informative only)
Automatic push to stable based on karma has been disabled for this update due to failure of an AutoQA test. Update submitter, please check the AutoQA test result and see if there is a valid problem to be fixed here, and fix it if so. If the failure is a mistake on AutoQA's part, you can re-enable the automatic push feature for this update if you like, or push it stable manually once it reaches the requirements under the Updates Policy.
The upgradepath test FAILED because the matching f23 update hasn't been approved yet: https://admin.fedoraproject.org/updates/FEDORA-2015-13063/elfutils-0.163-3.fc23 If people could test f23 and supply karma that would be appreciated. Once it goes into f23 it can also go into f22.
Taskotron: upgradepath test PASSED on noarch. Result log: https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/116319/steps/runtask/logs/stdio (results are informative only)
This update is currently being pushed to the Fedora 22 stable updates repository.
Taskotron: upgradepath test PASSED on noarch. Result log: https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/116360/steps/runtask/logs/stdio (results are informative only)
Taskotron: depcheck test PASSED on i386. Result log: https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/116361/steps/runtask/logs/stdio (results are informative only)
Taskotron: depcheck test PASSED on x86_64. Result log: https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/116361/steps/runtask/logs/stdio (results are informative only)
This update is currently being pushed to the Fedora 22 stable updates repository.
This update has been pushed to stable
Got this on both machines where I updated this package: systemd-sysctl[415]: Failed to write '0' to '/proc/sys/kernel/yama/ptrace_scope': Operation not permitted. Coming from file 10-default-yama-scope.conf in /usr/lib/sysctl.d.
SELinux denial: Aug 15 22:42:34 <machine> audit[663]: <audit-1400> avc: denied { sys_ptrace } for pid=663 comm="systemd-sysctl" capability=19 scontext=system_u:system_r:systemd_sysctl_t:s0 tcontext=system_u:system_r:systemd_sysctl_t:s0 tclass=capability permissive=0
This comes from the fact that elfutils-libs now pulls in default-yama-scope which installs /usr/lib/sysctl.d/10-default-yama-scope.conf which systemd-sysctl tries to execute. But systemd-sysctl is blocked by selinux from setting that sysctl. I assume this was only tested with selinux disabled. Hohum. Not good. With selinux enabled you can easily reproduce: $ systemctl start systemd-sysctl.service Job for systemd-sysctl.service failed. See "systemctl status systemd-sysctl.service" and "journalctl -xe" for details. $ systemctl status systemd-sysctl.service â systemd-sysctl.service - Apply Kernel Variables Loaded: loaded (/usr/lib/systemd/system/systemd-sysctl.service; static; vendor preset: disabled) Active: failed (Result: exit-code) since Sat 2015-08-15 15:59:19 CEST; 35min ago Docs: man:systemd-sysctl.service(8) man:sysctl.d(5) Process: 728 ExecStart=/usr/lib/systemd/systemd-sysctl (code=exited, status=1/FAILURE) Main PID: 728 (code=exited, status=1/FAILURE) Aug 15 15:59:19 blokker systemd[1]: Starting Apply Kernel Variables... Aug 15 15:59:19 blokker systemd[1]: systemd-sysctl.service: main process exited, code=exited, status=1/FAILURE Aug 15 15:59:19 blokker systemd[1]: Failed to start Apply Kernel Variables. Aug 15 15:59:19 blokker systemd[1]: Unit systemd-sysctl.service entered failed state. Aug 15 15:59:19 blokker systemd[1]: systemd-sysctl.service failed. The logs also show a workaround: Aug 15 16:36:11 blokker python[2930]: SELinux is preventing /usr/lib/systemd/systemd-sysctl from using the sys_ptrace capability. * Plugin catchall (100. confidence) suggests ****** If you believe that systemd-sysctl should have the sys_ptrace capability by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep systemd-sysctl /var/log/audit/audit.log | audit2allow -M mypol
semodule -i mypol.pp That policy allows things to work again. So it would
be good to get this fixed in the selinux policy for systemd_sysctl_exec_t. But before that is fixed it might be good to comment out the setting in the default-yama-scope
Filed a bug report with a simple reproducer that doesn't require any updated package: https://bugzilla.redhat.com/show_bug.cgi?id=1253926 It is strange though. I am sure this used to work. It must be some other update that triggered this change in behavior.