I have untagged new iptables to prevent this breakage.

Phil,

please please please, check things before you upgrade packages. Whether it will break anything else or not.

With iptables untagged, systemd install and builds. However there must be some kind of bootstrap to allow the update.

(In reply to Miro Hrončok from comment #3)
> With iptables untagged, systemd install and builds. However there must be
> some kind of bootstrap to allow the update.

The culprit here I think is gnutls which started to depend on unbound...

Hi,

(In reply to Igor Gnatenko from comment #2)
> please please please, check things before you upgrade packages. Whether it
> will break anything else or not.

Sorry for the mess. The goal was to rebuild iptables to cover for libnftnl rebase in Rawhide and rebasing while doing so seemed like a good idea.

To avoid such mess in the future, I suggest reading

https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master

and

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_listing_shared_library_files

(In reply to Miro Hrončok from comment #3)
> With iptables untagged, systemd install and builds. However there must be
> some kind of bootstrap to allow the update.

For so-name bump bootstrapping packages that are Requires within minimal buildroot package, you need to keep the libraries with the old so-name available in an intermediate bootstrap build of the package.  See [1] for an example.

I'm open to offer some provenpackager help here, if needed.


[1]  https://src.fedoraproject.org/rpms/json-c/blob/master/f/json-c.spec

Hi Björn,

(In reply to Björn 'besser82' Esser from comment #7)
> (In reply to Miro Hrončok from comment #3)
> > With iptables untagged, systemd install and builds. However there must be
> > some kind of bootstrap to allow the update.
> 
> For so-name bump bootstrapping packages that are Requires within minimal
> buildroot package, you need to keep the libraries with the old so-name
> available in an intermediate bootstrap build of the package.  See [1] for an
> example.
> 
> I'm open to offer some provenpackager help here, if needed.

Thanks for your help, I'll copy the example from json-c to provide a build which provides both old and new libip{4,6}tc.so libs. If possible, I'll then trigger a rebuild of systemd package.

Hi Phil,

sounds good to me.

Don't forget to disable bootstrap after finishing the systemd rebuild and build iptables another time then.

The follwing packages need a rebuild after finishing the bootstrap process as well:

collectd
connman
keepalived
miniupnpd
perl-IPTables-libiptc

Allrighty, I've rebuilt iptables without bootstrap and the listed consumers successfully.  Closing here, as the issue is solved.

I now get: nothing provides libqrencode.so.3()(64bit) needed by systemd-242-4.git7a6d834.fc31.x86_64

And this when I attempt to build:

Error: 
 Problem 1: package gnutls-dane-3.6.8-1.fc31.x86_64 requires libunbound.so.8()(64bit), but none of the providers can be installed
  - package gnutls-devel-3.6.8-1.fc31.x86_64 requires libgnutls-dane.so.0()(64bit), but none of the providers can be installed
  - package gnutls-devel-3.6.8-1.fc31.x86_64 requires gnutls-dane(x86-64) = 3.6.8-1.fc31, but none of the providers can be installed
  - package unbound-libs-1.8.3-4.fc30.x86_64 requires systemd, but none of the providers can be installed
  - conflicting requests
  - nothing provides libqrencode.so.3()(64bit) needed by systemd-242-4.git7a6d834.fc31.x86_64
 Problem 2: package cryptsetup-libs-2.2.0-0.2.fc31.x86_64 requires libdevmapper.so.1.02()(64bit), but none of the providers can be installed
  - package cryptsetup-libs-2.2.0-0.2.fc31.x86_64 requires libdevmapper.so.1.02(Base)(64bit), but none of the providers can be installed
  - package cryptsetup-libs-2.2.0-0.2.fc31.x86_64 requires libdevmapper.so.1.02(DM_1_02_97)(64bit), but none of the providers can be installed
  - package device-mapper-libs-1.02.158-1.fc31.x86_64 requires device-mapper = 1.02.158-1.fc31, but none of the providers can be installed
  - package cryptsetup-devel-2.2.0-0.2.fc31.x86_64 requires libcryptsetup.so.12()(64bit), but none of the providers can be installed
  - package device-mapper-1.02.158-1.fc31.x86_64 requires systemd >= 189-3, but none of the providers can be installed
  - conflicting requests
  - nothing provides libqrencode.so.3()(64bit) needed by systemd-242-4.git7a6d834.fc31.x86_64
 Problem 3: package gnutls-devel-3.6.8-1.fc31.x86_64 requires libgnutls-dane.so.0()(64bit), but none of the providers can be installed
  - package gnutls-devel-3.6.8-1.fc31.x86_64 requires gnutls-dane(x86-64) = 3.6.8-1.fc31, but none of the providers can be installed
  - package gnutls-dane-3.6.8-1.fc31.x86_64 requires libunbound.so.8()(64bit), but none of the providers can be installed
  - package libmicrohttpd-devel-1:0.9.64-1.fc31.x86_64 requires pkgconfig(gnutls), but none of the providers can be installed
  - package unbound-libs-1.8.3-4.fc30.x86_64 requires systemd, but none of the providers can be installed
  - conflicting requests
  - nothing provides libqrencode.so.3()(64bit) needed by systemd-242-4.git7a6d834.fc31.x86_64

Can somebody please untag the qrencode update?

qrencode and all its consumers have been successfully rebuilt against the new so version.  [1]


[1]  https://koji.fedoraproject.org/koji/taskinfo?taskID=35827273

So since we reuse this bug for multiple things, let me do it once more :)

gnutls-dane did not depend on unbound at some point so all this issues would not appear. Also people probably should not get unbound on their systems by default.

All the dependencies in this loop should be carefully minimized.
gnutls-dane depends on unbound-libs, so removing the dependency might not be easy.
But gnutls-libs does not need to depend on systemd at all:
https://src.fedoraproject.org/rpms/unbound/pull-request/2.

Hi Björn,

(In reply to Björn 'besser82' Esser from comment #10)
> Allrighty, I've rebuilt iptables without bootstrap and the listed consumers
> successfully.  Closing here, as the issue is solved.

Thanks for helping out! I had to leave yesterday while analyzing the cause for
the extra libiptc.so files. Upstream has dropped that and I wanted to check if
perl-IPTables-libiptc (the only direct user) builds without it. It does, but
I'll leave removal of that shared object to another day.

Thanks, Phil

> So since we reuse this bug for multiple things, let me do it once more :)
> gnutls-dane did not depend on unbound at some point so all this issues would not appear. Also people probably should not get unbound on their systems by default.

Hi,
 gnutls-dane depends on unbound libraries for dnssec but not unbound itself. That dependency was always there.

Being unable to install systemd would definitely violate release criteria, so +1 blocker.

Discussed during the 2019-07-15 blocker review meeting: [1]

The decision to classify this bug as a "RejectedBlocker" was made as our understanding is that the initial problem covered by this bug indeed was a blocker (it would've prevented composes), but that issue was resolved and now the bug has been re-opened for a different and less critical reason (see comment #14). As we understand the current issue, it does not violate any criteria.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-07-15/f31-blocker-review.2019-07-15-16.05.txt

I built unbound without the build-time and installation-time deps on systemd. I'm leaving this open since there might be other things to fix.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

Dear Maintainer,

your package has not been built successfully in 31. Action is required from you.

If you can fix your package to build, perform a build in koji, and either create
an update in bodhi, or close this bug without creating an update, if updating is
not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to
acknowledge this. Following the latest policy for such packages [2], your package
can be orphaned if this bug remains in NEW state more than 8 weeks.

A week before the mass branching of Fedora 32 according to the schedule [3],
any packages which still have open FTBFS bugs from Fedora 31 will be retired.

[1] https://fedoraproject.org/wiki/Updates_Policy
[2] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
[3] https://fedoraproject.org/wiki/Releases/32/Schedule

Unblocking F31FTBFS to avoid being tracked as such.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #20)
> I built unbound without the build-time and installation-time deps on
> systemd. I'm leaving this open since there might be other things to fix.

unbound-libs in fact provides not only libraries. It also provides unbound-anchor binary and corresponding unbound-anchor.service. They need systemd to maintain valid DNS root trust key. Because every validation done by unbound-libs requires also valid root trust anchor, it has to stay with libs. But in default case, it should validate also without working unbound-anchor.service if recent enough.

But unbound has some support for systemd, which might be eventually compiled in. That would affect also unbound-libs, if that was the case.

Would it help, if gnutls was built in bootstrap mode without DANE support? unbound-libs are required just for DANE, which might not be useful for very basic bootstrap builds. This dependency is there just for gnutls-dane, which is used by gnutls-utils only. I think that might be omitted. It already supports building --without dane. Would turning it off help in bootstrap mode? What do you think?

This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.

This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.