Bug 1467347 is fixed. Thanks for the quick fix!

BZ#1467347 /usr/bin/python3 /usr/share/java-utils/ pom_remove_parent causes traceback in F24

Hi Steve. Could you push this so that the broken deps warnings will stop:

nordugrid-arc has broken dependencies in the rawhide tree:
On x86_64:
       nordugrid-arc-arex-5.3.0-1.fc26.x86_64 requires python2-stomppy

This fixes the misspelled Provides/Obsoletes.

BZ#1435744 Misspelled Provides/Obsoletes

Minor typo - the summary for the python2 subpackage says python3:

$ dnf search stomppy
============================= N/S Matched: stomppy =============================
python2-stomppy.noarch : Python stomp client for messaging for python3
python3-stomppy.noarch : Python stomp client for messaging for python3

This update changes the name of the binary package, and hence breaks dependencies in other packages that declare a dependency on it. There is an attempt at a provides for the old name, but unfortunately it is misspelled so it is not useful for backward compatibility with the old name (see rhbz #1435744). In order to fix the broken dependency in my package I adapted it to require the new name of the binary package, which stopped the complaints about the broken deps in F27. Now after the freeze is lifted for F26 my update for F26 was pushed to stable too, but now this update is not pushed yet and the new name is not available in F26 so now I got notifications of broken dependencies in F26.


WaylandEnable=false in /etc/gdm/custom.conf works again.

The originally reported problem (that was fixed) reappeared again:

Thank you for the report. I forwarded it upstream and a fix was committed to upstream's git. I have applied the fix as an additional patch in xrootd-4.6.0-7.

Resolves broken upgrade path for iptables.

@nucleo: I hadn't seen the error message because it only happens with legacy proxies, and I mostly uses RFC proxies (unless I explicitly test compatibility with something else). xrootd-4.6.0-4 should address your issue. Also reported upstream:

Thank you for your detailed logs. I can see that on your system you do not have the CRLs installed. An absent CRL should mean "do not check" the CRL, and hence not be a source of an error. If I move the CRLs out of the way on my system I can reproduce the problem.

Looking at the code it looks like the 4.6.0 CRL checking code treats an absent CRL the same as an expired CRL and triggers error, which is a bug.

I have reported this upstream:

I can not reproduce this:

$ rpm -q xrootd-client
$ xrdcp -f -d1 root:// /dev/null
[16MB/492.2MB][  3%][=>                                                ][2MB/s] 
[80MB/492.2MB][ 16%][========>                                         ][6.667MB
. . .

Can you provide more information?

See above...

BZ#1309785 Missing texlive components: mathdesign.sty texnansi.sty vmargin.sty