Comments
tmz
gThumb installs and runs without error.
https://bugzilla.redhat.com/show_bug.cgi?id=1579422 was filed for the traceback (and was marked as a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1579367, where the root issue is being addressed)
Definitely not working after dnf --enablerepo updates-testing upgrade fedpkg. Are there perhaps other updates in updates-testing which would make this work and simply aren't dependencies of fedpkg?
It's probably a little late to fix it now, but this update has a requirement on perl-libs-5.26.2, which is still in testing.
@ignatenkobrain, @walters, @kalev, I filed a PR which should restore the platform-python-gpg subpackage. Hopefully that helps save someone a little time. It definitely should be reviewed carefully, as I'm not terribly familiar with the platform-python bits.
The autopush should be disabled to prevent this from going to stable. While the update fixes the incompatibility issue with gnupg2-2.0.6 it includes unintended removal of the platform-python subpackages. That breaks dnf building as seen here: https://apps.fedoraproject.org/koschei/package/dnf?collection=f27
Tested with sudo dnf --enablerepo fedora-cisco-openh264 repolist to confirm dnf prompts to import the repo gpg key and successfully completes. A subsequent dnf upgrade upgraded 30 packages, which should further exercise gpgme.
FWIW, the dist.abicheck flags the removal of the 2 id3_compat_* symbols:
It looks to me like gperf is not a build requirement and with the patch to compat.gperf, the Makefile tries to use it to rebuild compat.c. This fails and creates an empty compat.c. Here's a snip from the build.log:
config.status: executing depfiles commands
+ make -j48 'CFLAGS=-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables'
cd . && \
gperf -tCcTonD -K id -N id3_compat_lookup -s -3 -k '*' \
compat.gperf | \
sed -e 's/\(struct id3_compat\);/\1/' | \
sed -e '/\$''Id: /s/\$//g' >compat.c
/bin/sh: line 1: gperf: command not found
make all-recursive
Unfortuantely, adding gperf causes the build to fail:
compat.gperf:116:1: error: conflicting types for 'id3_compat_lookup'
TSIZ, OBSOLETE /* Size [obsolete] */
^~~~~~~~~~~~~~~~~
In file included from compat.gperf:37:0:
compat.h:36:26: note: previous declaration of 'id3_compat_lookup' was here
struct id3_compat const *id3_compat_lookup(register char const *,
^~~~~~~~~~~~~~~~~
I haven't looked any further at how to resolve this yet, but thought I'd post what I've found in case someone else has time to work on this.
This update breaks bash-completion:
$ . /etc/bash_completion.d/fedpkg.bash
-bash: /etc/bash_completion.d/fedpkg.bash: line 196: syntax error near unexpected token `)'
-bash: /etc/bash_completion.d/fedpkg.bash: line 196: ` request-repo)'
PR filed: https://pagure.io/fedpkg/pull-request/182
The 1.31 tag in the git repo (https://pagure.io/fedpkg/releases) also seems to be missing.
I installed this early this afternoon on a pretty clean system and verified that the required dependencies are pulled in for bucky to start up. Then I updated a test system which receives a lot of updates. The upgrade was without issue as far as I can tell.
This update pulls in a dependency on perl(YAML::Any) in perl-Git-SVN. Since upstream made it optional, we can simply filter it out with no regression in functionality. I've got a build of 1.8.2.1 that I am testing locally now. I'll submit that soon to obsolete this update.
pbrady, if you could test https://admin.fedoraproject.org/updates/puppet-2.6.18-3.el6 once it lands in epel-testing, that would be most appreciated. Thanks!
I have run this in production as a master and client on a number of systems since its release and have seen no issues yet. I'm hesitant to +1 a package I pushed, but the meat of the changes were from the earlier 2.6.18-1 package which I did not push.
This has worked well for me. I'm new to graphite, so I haven't put it through extensive testing. But it hasn't caused me any grief. I'd love to see it graduate to stable soon, unless it's being held back for some reason.
This seems to have an unsatisfied dependency on python >= 2.6. I filed https://bugzilla.redhat.com/718376 for this. The update description and the rpm changelog both state that python >= 2.6 is for the 1.1 branch.
Filed https://bugzilla.redhat.com/show_bug.cgi?id=702671 on this. It seems to be due to a multilib issue.
With libguestfs installed, this update fails (this is likely a problem that needs fixed in libguestfs, but I didn't want it to go unmentioned). The error: Error: Missing Dependency: /usr/lib64/libntfs.so.9 is needed by package 1:libguestfs-1.2.14-1.el5.x86_64 (installed)
This change removes the python2 asciidocapi, which seems undesirable in a stable release (and counter to the updates policy).