I've been using this for a few weeks without issue (I started testing it prior to submitting the update).
The package fails to install due to missing dependencies:
$ sudo dnf install --enablerepo=updates-testing --advisory=FEDORA-2021-f7c85ad7ff \*
Last metadata expiration check: 0:00:09 ago on Sat 08 May 2021 11:53:15 AM EDT.
Error:
Problem: package python3-fasjson-client-0.1.1-6.fc32.noarch requires (python3.8dist(bravado) < 12 with python3.8dist(bravado) >= 10.6), but none of the providers can be installed
- package centos-packager-0.7.0-6.fc32.noarch requires python3-fasjson-client, but none of the providers can be installed
- package python3-bravado-11.0.2-1.fc32.noarch requires python3.8dist(bravado-core) >= 5.16.1, but none of the providers can be installed
- conflicting requests
- nothing provides python3.8dist(jsonpointer) > 1.13 needed by python3-bravado-core-5.17.0-1.fc32.1.noarch
(try to add '--skip-broken' to skip uninstallable packages)
Confirmed that the issue with git maintenance
is resolved. Colors are reset properly after crontab -l
as well. And the test cases work as expected.
Thanks!
Thanks for testing everyone.
I was hoping to keep this in updates testing for a bit longer. The update is from 2.29 to 2.30 and while I don't anticipate any issues with that, there are a lot of use-cases I could miss.
The security issue being resolved does not affect the overwhelming majority of Fedora users and is not urgent enough warrant pushing this to stable after less than a full day in the testing repo.
In the future, i'd appreciate a heads up before an update is pushed to stable. I disabled the autopush explicitly. Thanks.
I tested with the gmp repo referenced in the update advisory as well as a couple of other repositories I'd cloned in the past. All were successful.
No issues noticed in various apps using freetype (terminal, firefox, gnome-shell, etc).
Running fine on a production system since Friday.
I tested that freshclam still successfully applies clamav database updates after applying the json-c update.
Yes. It's a bump from 2.23.0 to 2.24.1 (which was in the works before these issues arose). While 5 of the 9 issues fixed here are rated as high severity (per https://github.com/git/git/security/advisories), only one of those 5 has the potential to affect Linux users -- and even then only where git is cloning to an NTFS networked drive with short names enabled.
So the risk to Fedora users is considerably lower than it is to Windows git users. (The severity is set to high per the security team's initial bug assessments, but I suspect that after more thorough review that might be lowered -- but the Fedora updates should all be pushed to stable before then.)
Thus I feel comfortable letting this spend a few more days in testing to ensure we don't run into any issues in the 2.23.0 -> 2.24.1 bump. I really don't expect any thanks to the care which upstream takes to avoid regressions, but I'd rather not cause anyone trouble which can be avoided by a little more testing.
Thanks for the poke in any case. I appreciate the nudge to ensure this wasn't an unintentional delay!
Yes. It's a bump from 2.23.0 to 2.24.1 (which was in the works before these issues arose). While 5 of the 9 issues fixed here are rated as high severity (per https://github.com/git/git/security/advisories), only one of those 5 has the potential to affect Linux users -- and even then only where git is cloning to an NTFS networked drive with short names enabled.
So the risk to Fedora users is considerably lower than it is to Windows git users. (The severity is set to high per the security team's initial bug assessments, but I suspect that after more thorough review that might be lowered -- but the Fedora updates should all be pushed to stable before then.)
Thus I feel comfortable letting this spend a few more days in testing to ensure we don't run into any issues in the 2.23.0 -> 2.24.1 bump. I really don't expect any thanks to the care which upstream takes to avoid regressions, but I'd rather not cause anyone trouble which can be avoided by a little more testing.
Thanks for the poke in any case. I appreciate the nudge to ensure this wasn't an unintentional delay!
I've run this on a few nagios instances since it was released and haven't noticed any issues. The extraneous check_disk output and the check_disk_smb dependency issues are both resolved. Thanks!
FWIW, I did file a PR upstream to make the utf8::all
module dependency optional. Whether that will be accepted or not remains to be seen. I'm not a user of that plugin nor a regular perl coder (not for many years anyway), so the patch might need work even if the goal is agreeable to the folks upstream.
Unfortunately (for us on el6), upstream added a dependency on the perl utf8::all
module, which is not available on el6. With nagios-plugins-all
or nagios-plugins-disk_smb
installed, attempting to update results in:
Error: Package: nagios-plugins-disk_smb-2.2.2-1.20190919git00cff01.el6.x86_64 (epel-testing)
Requires: perl(utf8::all)
It's a relatively easy change to revert at this point (and the plugin may likely not change much before el6 goes EOL, so the revert patch will hopefully remain easily applicable).
I'll file that as a PR, after confirming on which branch(es) we want to apply the change. I mentioned this in the bugzilla entry for the check_disk issue.
Tested jgit to confirm it launches properly and that it's usage in the git test suite is successful (this includes jgit daemon
, jgit gc
, and jgit --version
calls). Thanks @mbooth!
No. Fedora 26 is EOL, so it no longer receives any updates. ;)
(Also, if F26 were not EOL, the better place to ask would be in bugzilla or reaching out to the package maintainers directly.)
This change removes the python2 asciidocapi, which seems undesirable in a stable release (and counter to the updates policy).