#2751 RFC: Invoke Contingency Mechanism for "F36 Change: Package information on ELF objects"?
Closed: Rejected 2 years ago by ngompa. Opened 2 years ago by decathorpe.

Alright, I'm going to do "the unpopular thing" apparently nobody wanted to do yet. I think it's time we discuss invoking the contingency mechanism for this F36 change before it's too late.

  • it is causing massive amounts of breakage across the whole distro (Python stack, Ruby stack, R stack, every OCaml package, etc.)
  • it's unclear to me whether this will get worse and worse the more packages get rebuilt and re-rebuilt with the new linker flags, and I don't want this to get progressively worse, possibly even after F36 is GA

EDIT: The Python stack is perfect and never broken, I apologize.


I've been somewhat uncomfortable about the scale of problems that package notes has caused. I think we should strongly consider reverting it and doing a mass build to pull it all out. And defer it to F37 to try again.

For reference, here's the contingency plan from the change proposal:

  • Contingency mechanism: Remove the new compilation flags. Rebuild any packages that were build with the new flags.
  • Contingency deadline: Beta freeze.

Given that we're branching on Tuesday, I wonder if we should (assuming FESCo approves this) wait until after the branch point to do a rebuild (practically speaking, that'd probably be the case anyway).

Metadata Update from @bcotton:
- Issue set to the milestone: Fedora Linux 36

2 years ago

And for what it's worth, given the potential risk this poses to the release schedule, I am in favor of invoking the contingency plan earlier than the listed deadline.

Where is the massive breakage in the Python stack?

The main issue here is that this has happened incredibly late before the mass rebuild :(

I suppose if we postpone this to Fedora 37, I'd rather do the mass rebuild before we branch. Doing a mass rebuild after branching will be ugly.

Instead of a full rebuild, It might be easier to identify packages that have the reference to the package notes file flag in them (e.g. by download-unpack-grep every package) and rebuild juts those. The rest of the packages can most likely keep the notes in them, as I have not yet seen a problem with the actual notes, only with packages exposing their ldflags further down the stack.

Are the notes causing runtime issues or just build-time issues? I'm wondering if it's really necessary to remove notes from packages that have already been built.

I have seen no mention of runtime issues, so I don't think a mass rebuild of everything would be necessary.

But I also think stopping to use those linker flags for future builds would be a good idea, until the resulting breakages can be considered more thoroughly, especially without time pressure (practically, between "one day before the mass rebuild started" and "branch point", was a very short time to figure all this out).

I think we should also consider moving the "Changes requiring mass rebuild" deadline earlier in the release schedule, like maybe 8 weeks before the mass rebuild instead of 3.

Is there a tracker or list of bugs this is causing? I know it's causing some FTBFS, but many of them seemed workaroundable?

Another mass rebuild after branching only in the branch would be quite messy, and I would very much prefer to avoid that.

I think we should also consider moving the "Changes requiring mass rebuild" deadline earlier in the release schedule, like maybe 8 weeks before the mass rebuild instead of 3.

It is too early as it is. The justification for gcc12 being pushed in earlier than it really should have was having to get it in before the mass rebuild. I think it may have saved a whole lot of headache had gcc12 and the mass rebuild been just a bit later. If people are rushing changes in before they are really ready to hit the current schedule, make that schedule shorter will not benefit anyone.

I think we should also consider moving the "Changes requiring mass rebuild" deadline earlier in the release schedule, like maybe 8 weeks before the mass rebuild instead of 3.

It is too early as it is. The justification for gcc12 being pushed in earlier than it really should have was having to get it in before the mass rebuild. I think it may have saved a whole lot of headache had gcc12 and the mass rebuild been just a bit later. If people are rushing changes in before they are really ready to hit the current schedule, make that schedule shorter will not benefit anyone.

I think that moving the mass rebuild later would be an option too. The reason things are rushed is it often can take almost the full 3 week window for proposals to work their way through the approval process, so even if the actual code change is done early it doesn't end up being committed until right before the mass rebuild.

Do note that while the mass rebuild itself only takes a few days, the fallout from it takes much longer. If there's not enough time after the mass rebuild to fix things, thats going to make beta difficult.

So, what are our options here? I guess it depends on whether we want to have this feature enabled or not in rawhide and / or f36 after the branch point ... I'm not really sure if I'm comfortable with leaving it enabled for f36 though, as it might have negative knock-on effects later in the release cycle. Because the change landed in rawhide so late before the start of the mass rebuild, there really wasn't much time to fix things ... Is there even time to do a targeted rebuild (for example, skipping all noarch packages?) of F36 between the branch point and the beta freeze?

Any mass rebuild taking place after branching and not in rawhide would require a number of changes to the mass rebuild scripting. For example, it would have to try and use 'rpmdev-bumpspec --rightmost' to avoid making all the branched packages 'newer' than rawhide (and I am sure it would fail on some). rpmautospec ones would just get the higher number I suppose. There would then be a git commit only in branched, causing everyone who merges back from rawhide to get a merge commit. I guess for noarch you mean packages that only produce noarch subpackages, because there's a bunch that have just some noarch packages. I mean it's all doable, just a lot of work and something we haven't done before so I suspect there will be bugs in it too. :)

I thought the affected stacks had worked around this, but I guess thats not the case? Is there a tracker for this? a list of broken things? I don't doubt that it is causing breakage, but I don't get a sense for how bad it is.

Either way, if we want to make any decision at all, we need to make it fast.

Branching happens tomorrow.

My proposal:

  • we write a script that for each "binary" package we have:
    1. downloads the package
    2. unpacks the package (or alternatively pipes the content to (3) if possible)
    3. greps the content for -Wl,\S*package_note\S*
    4. logs the source name if (3) found anything
  • we opt out all packages listed in (4) and rebuild them
  • we hold off with branching until we are done

Alternatively, we could disable the feature (make it opt-in) and rebuild the packages without changes in spec files other than bumps.

The problem of course is that somebody needs to write this script and that it might run for a long time.

Example for Ruby, before it opted out:

$ koji download-build ruby-3.0.3-157.fc36 --arch noarch --arch x86_64
Downloading: ruby-doc-3.0.3-157.fc36.noarch.rpm
[====================================] 100% 4.95 MiB / 4.95 MiB
Downloading: rubygem-rbs-1.4.0-157.fc36.noarch.rpm
[====================================] 100% 472.12 KiB / 472.12 KiB
Downloading: rubygem-rdoc-6.3.3-157.fc36.noarch.rpm
[====================================] 100% 400.56 KiB / 400.56 KiB
Downloading: rubygem-bundler-2.2.32-157.fc36.noarch.rpm
[====================================] 100% 373.33 KiB / 373.33 KiB
Downloading: rubygems-3.2.32-157.fc36.noarch.rpm
[====================================] 100% 254.99 KiB / 254.99 KiB
Downloading: rubygem-typeprof-0.15.2-157.fc36.noarch.rpm
[====================================] 100% 527.73 KiB / 527.73 KiB
Downloading: rubygem-rss-0.2.9-157.fc36.noarch.rpm
[====================================] 100% 102.71 KiB / 102.71 KiB
Downloading: rubygem-test-unit-3.3.7-157.fc36.noarch.rpm
[====================================] 100% 123.58 KiB / 123.58 KiB
Downloading: rubygem-rexml-3.2.5-157.fc36.noarch.rpm
[====================================] 100% 94.97 KiB / 94.97 KiB
Downloading: rubygem-minitest-5.14.2-157.fc36.noarch.rpm
[====================================] 100% 80.96 KiB / 80.96 KiB
Downloading: rubygem-rake-13.0.3-157.fc36.noarch.rpm
[====================================] 100% 91.54 KiB / 91.54 KiB
Downloading: rubygem-irb-1.3.5-157.fc36.noarch.rpm
[====================================] 100% 73.57 KiB / 73.57 KiB
Downloading: ruby-default-gems-3.0.3-157.fc36.noarch.rpm
[====================================] 100% 32.68 KiB / 32.68 KiB
Downloading: rubygem-power_assert-1.2.0-157.fc36.noarch.rpm
[====================================] 100% 23.87 KiB / 23.87 KiB
Downloading: rubygems-devel-3.2.32-157.fc36.noarch.rpm
[====================================] 100% 14.75 KiB / 14.75 KiB
Downloading: ruby-libs-3.0.3-157.fc36.x86_64.rpm
[====================================] 100% 3.19 MiB / 3.19 MiB
Downloading: ruby-devel-3.0.3-157.fc36.x86_64.rpm
[====================================] 100% 269.47 KiB / 269.47 KiB
Downloading: rubygem-json-2.5.1-157.fc36.x86_64.rpm
[====================================] 100% 54.80 KiB / 54.80 KiB
Downloading: rubygem-psych-3.3.2-157.fc36.x86_64.rpm
[====================================] 100% 51.26 KiB / 51.26 KiB
Downloading: rubygem-bigdecimal-3.0.0-157.fc36.x86_64.rpm
[====================================] 100% 54.67 KiB / 54.67 KiB
Downloading: ruby-3.0.3-157.fc36.x86_64.rpm
[====================================] 100% 41.15 KiB / 41.15 KiB
Downloading: rubygem-io-console-0.5.7-157.fc36.x86_64.rpm
[====================================] 100% 25.72 KiB / 25.72 KiB

$ for rpm in *.rpm; do rpm2cpio $rpm | cpio -idmv; done

$ rg --hidden -- '-Wl,\S*package_note\S*'
usr/lib64/ruby/rbconfig.rb
47:  CONFIG["configure_args"] = " '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-rubylibprefix=/usr/share/ruby' '--with-archlibdir=/usr/lib64' '--with-rubyarchprefix=/usr/lib64/ruby' '--with-sitedir=/usr/local/share/ruby/site_ruby' '--with-sitearchdir=/usr/local/lib64/ruby/site_ruby' '--with-vendordir=/usr/share/ruby/vendor_ruby' '--with-vendorarchdir=/usr/lib64/ruby/vendor_ruby' '--with-rubyhdrdir=/usr/include' '--with-rubyarchhdrdir=/usr/include' '--with-sitearchhdrdir=$$(sitehdrdir)/$$(arch)' '--with-vendorarchhdrdir=$$(vendorhdrdir)/$$(arch)' '--with-rubygemsdir=/usr/share/rubygems' '--with-ruby-pc=ruby.pc' '--with-compress-debug-sections=no' '--disable-rpath' '--enable-shared' '--with-ruby-version=' '--enable-multiarch' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CC=gcc' 'CXX=g++' 'CFLAGS=-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 -Wl,-dT,/builddir/build/BUILD/.package_note-ruby-0.15.2-157.fc36.x86_64.ld' 'CXXFLAGS=-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'"
135:  CONFIG["DLDFLAGS"] = "-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 -Wl,-dT,/builddir/build/BUILD/.package_note-ruby-0.15.2-157.fc36.x86_64.ld"
177:  CONFIG["LDFLAGS"] = "-L. -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 -Wl,-dT,/builddir/build/BUILD/.package_note-ruby-0.15.2-157.fc36.x86_64.ld -fstack-protector-strong -rdynamic -Wl,-export-dynamic"

usr/lib64/pkgconfig/ruby.pc
52:DLDFLAGS=-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 -Wl,-dT,/builddir/build/BUILD/.package_note-ruby-0.15.2-157.fc36.x86_64.ld

This took 27 seconds on my computer for ruby which is not the smallest nor biggest package we have. With 23 thousand rubies, it would take a week to finish if not parallelized.

Metadata Update from @churchyard:
- Issue tagged with: fast track

2 years ago

I'm obviously biased, but I think any kind of revert would be counter-productive.
As was already said before:
- it is completely fine if some coverage over packages is incomplete, thus ocaml/perl/r/ruby opting out is OK.
- if the link flag leaks into some package, then usually it is a sign of pre-existing brokenness in the package, in particular it was most likely already exporting flags like -Wl,-z,relro to extensions. So fixing the package to not export non-library flags in ldflags would be generally beneficial. If that cannot be done, just opt-out of the package notes.

I don't know the whole scope of broken things, but it doesn't look good - some pretty big package ecosystems are already completely opting out (for both the compilers / interpreters and extension modules), so I would say that counts as "pretty bad":

With the opt-outs implemented, there shouldn't be any build-time or run-time issues, either in the language package or in the extension packages.

we write a script that for each "binary" package we have:

I'll try to do that now.

Note that if we only need to rebuild several packages that will be discovered by the script, it can happen after branching, manually.

It turns out dnf handles this very neatly.
I installed 'ruby*' 'perl*' 'R*' 'ocaml*' '/usr/lib64/pkgconfig/*.pc' '/usr/lib/pkgconfig/*.pc'. Some packages are uninstallable. I assume that's usually because they haven't been rebuilt successfully [1]. This gives 7467 packages, since various dependencies were pulled in [2].

There is a bunch of ruby Makefile.html that match the pattern, e.g.
/usr/share/gems/doc/json-2.6.1/rdoc/ext/json/ext/generator/Makefile.html
(68 files in total). Since those are docs, I assume it serves as a kind of information about the build… Those could be rebuild easily if appropriate.

Other matches:
/usr/lib/rpm/redhat/macros <--- expected
/usr/lib/rpm/macros.d/macros.package-notes-srpm <--- expected

/usr/bin/net-snmp-config-x86_64
/usr/include/net-snmp/net-snmp-config-x86_64.h <--- those two are OK, I think, after the latest patches. I removed the notes flags from the .pc file, and it's much better to use that anyway. net-snmp-config --libs and --agent-libs does not contain the notes flags. net-snmp-config has a bunch of other flags and it's not clear what their meaning is. If there are any users, it should be trivial to extend the patch to adjust those flags too.

/usr/lib64/pkgconfig/libcurl.pc <-------- this is in configure_options variable, which seems to be just information about the build, including things like the name of the build directory. Libs and Libs.private are clean.

/usr/lib64/gems/ruby/mysql2-0.5.3/mkmf.log <---- a log file, should be OK

/usr/lib64/tclConfig.sh:

# Flags to pass to the compiler when linking object files into
# an executable tclsh or tcltest binary.
TCL_LD_FLAGS='-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 -Wl,-dT,/usr/include/tcl-private/.package_note-tcl-8.6.12-2.fc36.x86_64.ld -Wl,--export-dynamic '

I have no idea if this should be patched. If yes, then most likely all of the flags here are wrong, possibly with the exception of the last one.

/usr/lib64/python3.10/_sysconfigdata_d_linux_x86_64-linux-gnu.py
/usr/lib64/python3.10/_sysconfigdata__linux_x86_64-linux-gnu.py
<---- those are build_time_vars. Seems OK at first sight.

/usr/lib64/python3.10/config-3.10-x86_64-linux-gnu/Makefile
<---- "Top-level Makefile for Python". The pattern is matched in CONFIGURE_LDFLAGS_NODIST, documented as "Use it when a linker flag should not be part of the distutils LDFLAGS", so this seems OK too.

/usr/share/doc/libpari23/pari.cfg <--- docs, so should not matter

No idea:
/usr/lib64/icu/69.1/pkgdata.inc
/usr/lib64/ImageMagick-6.9.12/config-Q16/configure.xml

Please let me know if you think any of those should be patched and/or rebuild, I'll be happy to do it.

I'm installing also '*-devel' now, but that pulls in pretty much the whole distro, so it'll take a bit longer.

[1] Uninstallable:
ruby-libguestfs-1:1.47.2-2.fc36.x86_64
rubygem-apipie-rails-0.5.18-5.fc36.noarch
rubygem-cucumber-rails-1.8.0-5.fc33.noarch
rubygem-declarative_authorization-doc-0.5.7-17.fc36.noarch
rubygem-rails-1:6.1.4.1-2.fc36.noarch
rubygem-websocket-driver-0.7.5-3.fc36.x86_64
rubygem-actioncable-6.1.4.1-1.fc36.noarch
rubygem-apipie-rails-doc-0.5.18-5.fc36.noarch
rubygem-cucumber-rails-doc-1.8.0-5.fc33.noarch
rubygem-hiredis-0.6.3-9.fc35.x86_64
rubygem-rails-doc-1:6.1.4.1-2.fc36.noarch
rubygem-websocket-driver-doc-0.7.5-3.fc36.noarch
rubygem-actioncable-doc-6.1.4.1-1.fc36.noarch
rubygem-bundler-doc-1.16.1-11.fc36.noarch
rubygem-declarative_authorization-0.5.7-17.fc36.noarch
rubygem-hiredis-doc-0.6.3-9.fc35.noarch
rubygem-rdoc-doc-6.3.2-201.fc36.noarch
rubygems-doc-3.2.14-202.fc35.noarch
perl-Crypt-PWSafe3-1.22-17.fc34.noarch
perl-MouseX-App-Cmd-0.30-20.fc34.noarch

[2] Full list: https://in.waw.pl/~zbyszek/fedora/f36-package-grep-1.txt

Python's _sysconfigdata and Makefile should indeed be OK. It records the flags used at build time, but only uses %extension_*flags to build other stuff.

CC: @humaton please check this ticket before starting mass branching tomorrow. :)

FYI, the Haskell stack is also affected.
@petersen opted out of the notes [1] but may have not rebuilt every Haskell package [2].
You may consider the ghc prefix in your scripting.

[1] https://src.fedoraproject.org/rpms/ghc-rpm-macros/c/22d34de16e18a692f6672c121dd7b481238ed7fd?branch=rawhide

[2] https://bugzilla.redhat.com/show_bug.cgi?id=2043092#c18

@zbyszek do you think you'll be able to work with package maintainers to work around breakages in F36 before the beta freeze?

Assuming that is the case, I have a proposal: The feature stays enabled on F36 + Rawhide. The Change owner(s) will work with maintainers of negatively affected packages to (1) work around bugs in the f36 branch (before the beta freeze, if possible). (2) Working on moving packages to use something like the existing %extension_fooflags mechanism for building extension modules instead of opting out entirely is targeted at Rawhide, and can be merged to F36, if needed.

do you think you'll be able to work with package maintainers to work around breakages in F36 before the beta freeze?

Well, I think I have been doing exactly that since the change was introduced. I have applied fixes to dozens of packages, and I have worked with other maintainers, and discussed various solutions extensively in tickets and on the mailing list.

proposal

This proposal describes status quo. But I'm not against it. Maybe it'll clarify things a bit.

I'm installing also '*-devel' now, but that pulls in pretty much the whole distro, so it'll take a bit longer.

I took a look at the .pc files. The pattern matched in a few places, and they should be all fixed now:

/usr/lib64/mpich/lib/pkgconfig/mpich.pc FIXED-20220208
/usr/lib64/pkgconfig/ptlib.pc           FIXED-20220208
/usr/lib64/pkgconfig/redland.pc         Libs.private, can be ignored
/usr/lib64/pkgconfig/guile-1.8.pc       Libs.private, can be ignored
/usr/lib64/pkgconfig/ldns.pc            Libs.private, can be ignored
/usr/lib64/pkgconfig/zzipmmapped.pc     zziplib, FIXED-20220208 by Leigh Scott
/usr/lib64/pkgconfig/zziplib.pc         zziplib, FIXED-20220208 by Leigh Scott
/usr/lib64/pkgconfig/zzipfseeko.pc      zziplib, FIXED-20220208 by Leigh Scott
/usr/lib64/pkgconfig/julius-4.pc        julius, FIXED-20220208
/usr/lib64/pkgconfig/sent-4.pc          julius, FIXED-20220208
/usr/lib64/pkgconfig/guile-2.0.pc       Libs.private, can be ignored
/usr/lib64/pkgconfig/htslib.pc          static_ldflags, OK
/usr/lib64/pkgconfig/curlpp.pc          FIXED-20220208
/usr/lib64/pkgconfig/Coin3.pc           FIXED-20220208
/usr/lib64/pkgconfig/arprec.pc          configure_args, OK
/usr/lib64/pkgconfig/sane-backends.pc   ldflags only, OK
/usr/lib64/pkgconfig/libcurl.pc         configure_options, OK

FYI, the Haskell stack is also affected.
@petersen opted out of the notes [1] but may have not rebuilt every Haskell package [2].
You may consider the ghc prefix in your scripting.

I don't think Haskell is affected at this point.
I disabled package notes for Haskell (in ghc-rpm-macros) late in the first round of the mass rebuild, since the notes broke all Haskell builds with ghc, I believe.
After that all the initial notes failures went away with the second round of package rebuilding.

The remaining Haskell FTBFS package issues are nearly all missing symbol linking issues not related with notes. So I don't don't believe Haskell actually need to be involved here.
Though I admit I have not audited carefully.

I don't think Haskell is affected at this point.
I disabled package notes for Haskell (in ghc-rpm-macros) late in the first round of the mass rebuild, since the notes broke all Haskell builds with ghc, I believe.

All good, then!
Stricto sensu, though, any packages that opt out the change is affected IMO if we are to take this statement from the change's page at face value:

Upgrade/compatibility impact: No impact. [1]

Opting out the change seems to me to be a compatibility impact...

Though I admit I have not audited carefully.

The script discussed upthread could be the auditing tool to use for ghc* packages.

[1] https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects#Upgrade.2Fcompatibility_impact

I installed all ghc* and *-devel on top of the previous set, getting 18421 packages [1].
ghc* packages are all clean.
Two lists of matching files: [3] is all files matching /doc/, and [2] is the rest.
[2] can be classified as:
- include files (under /usr/include). Most probably don't matter. Some could matter, but I'll let them be for now, unless there's some report that this actually causes problems.
- python3.10 sysconfig files: can be ignored, see Miro's comment above
- pkgconfig files: those should all be fixed now, see my comment above
- various *-config executable helpers: those are an inferior alternative to pkgconfig. Hopefully people are using pkgconfig instead. Those would be a problem if their --libs or equivalent option matched the pattern. Unfortunately option naming is not standarized…

/usr/share/ptlib/make/ptlib-config       should be fixed already
/usr/lib64/openmpi/bin/bout-config    BROKEN
/usr/lib64/mpich/bin/bout-config         BROKEN
/usr/bin/jemalloc-config                         --libs is unaffected
/usr/bin/ganglia-config                           --libs is unaffected
/usr/bin/yosys-config                              --ldlibs is unaffected
/usr/bin/staden-io_lib-config                BROKEN
/usr/bin/pthsem-config                         --libs is unaffected
/usr/bin/libjulius-config                         should be fixed already
/usr/bin/curlpp-config                           should be fixed already
/usr/bin/mm-config                                  --libs is unaffected
/usr/bin/qd-config                                    --libs is unaffected
/usr/bin/uuid-config                               --libs is unaffected
/usr/bin/net-snmp-config-x86_64      --libs is unaffected

I'll take a look at staden-io_lib and bout++.

There's about a 10k more archful packages that were not in [1]. I'll download and check them too, but since all -devel packages were already covered, I hope that there won't be many problems here.

[1] https://in.waw.pl/~zbyszek/fedora/f36-package-grep-2.txt
[2] https://in.waw.pl/~zbyszek/fedora/f36-notes-leak-no-doc.txt
[3] https://in.waw.pl/~zbyszek/fedora/f36-notes-leak-doc.txt

CC: @humaton please check this ticket before starting mass branching tomorrow. :)

I see f36 branches happening. I guess we've just passed a point of the "easy" revert option.

staden-io_lib is fixed now. bout++ unfortunately stopped building (some python error in tests…). I filed https://bugzilla.redhat.com/show_bug.cgi?id=2052520 to keep track of the issue.

The full (*) set of archful packages (28762 packages, **) shows 149 matches for paths with /doc/ [3] and 148 matches for other paths [2]. This includes various packages that were already fixed, so the real number is a bit smaller. I don't see anything in this list that would obviously break things.

[1] https://in.waw.pl/~zbyszek/fedora/f36-package-grep-3.txt
[2] https://in.waw.pl/~zbyszek/fedora/f36-notes-leak-no-doc-3.txt
[3] https://in.waw.pl/~zbyszek/fedora/f36-notes-leak-doc-3.txt

(*) There is surprising number of packages with duplicate paths that don't declare Conflicts and abort the transaction. I'll start a thread on devel about this.
(**) There are some repeats because I run out of disk space and had to restart the transaction, and package-cleanup doesn't work.

Metadata Update from @churchyard:
- Issue untagged with: fast track

2 years ago

Thanks for being so thorough, @zbyszek. From my POV, this RFC can be withdrawn. Should we close this ticket?

Metadata Update from @ngompa:
- Issue close_status updated to: Rejected
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata