Is releng tracker the right forum for this to alert people?

I believe that just link to the change page is missing here :)

I believe that just link to the change page is missing here :)

True - but the change page cannot be created at the moment because the Fedora Project services are currently unavailable... I will add a link once the services are back and the page has been created.

@nickc Since I cannot see the change, do you expect a mass rebuild for this change?

@nickc Since I cannot see the change, do you expect a mass rebuild for this change?
Yes please. Since the binutils package contains the assembler and linker, a mass rebuild would be a good idea.

The change request has now been created:

https://fedoraproject.org/wiki/Changes/BINUTILS235

@nickc Whats the status on this? I dont see binutils-2.35 yet, mass rebuild is scheduled for next week.

The 2.35 release is this weekend. I should have the new version installed on Monday.

Thanks @nickc for the update, please keep us posted as we delayed the mass rebuild for Fri, we could delay it for Mon as well. Thanks again.

The rebase has now been completed.

Closing the ticket as the work here is done.

@nickc and others,

regarding

as well as support for DWARF-5 format line number tables

just recently I noticed some strange remarks wrt. decoding
DWARF in bt of gdb. This update solved this for me:

Upgrade gdb-10.1-4.fc34.x86_64 @rawhide
Upgraded gdb-9.1-5.fc33.x86_64 @@System
Upgrade gdb-headless-10.1-4.fc34.x86_64 @rawhide
Upgraded gdb-headless-9.1-5.fc33.x86_64 @@System

No idea how intertwined this is and whether it had any relevance to
this change, but my guess says: could be.

Don't we want to avoid official distro -debuginfo packages causing
this trouble and Recommends: appropriate minimal version of gdb?

Or would something like (gdb >= 10 if gdb) work?

Any other idea how to softly push for update of gdb for debugging
scenarios where desirable regarding the user experience?

FTR. there has been some change-detached ML thread:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KFMSEV2JO2TIHNHVJFGTI5ZIEM4GIFDG/

@jpokorny Isn't the only way this can happen the result of a partial upgrade to rawhide?

@fweimer Or living at Rawhide perpetually, and updating selectively,
which should be pretty valid, shouldn't it? Otherwise, there would
be no reason for up-to-version-resolution dependency tracking and such,
when you could say "you need to always update the full sync".

There are various reasons for this on my side, and that dnf is
unable to split the upgrade batch doesn't help.

Dependency systems are here to enforce sane boundaries to the otherwise
mix&match freedom, correct?

Also, specifically in Rawhide, it proved useful to me to rather update
piece-wise, it's much easier to identify the culprit and rollback.

Time-distant full-blown updates is sometimes a Russian roulette.

Also, I can imagine some people prioritize just security updates.

And tangential is also this issue as a fallout from not having
interdependencies of the whole toolchain credibly reflecting the
lockstep that is otherwise intrinsically assumed:

$ /usr/bin/gcc -Wall -g -c -o module.o module.c
> as: unrecognized option '--gdwarf-5'

$ /usr/bin/gcc -v |& grep specs
> Using built-in specs.

$ strace -e trace=file /usr/bin/gcc -dumpspecs \
  |& grep -v -e '\(.*at(.*\|/usr/.*/locale/.*\|/usr/bin/.*\|/lib64/lib.*\)' \
  | grep -B1 -e gdwarf -e '^[a-z].*('
> access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
> readlink("/usr", 0x7ffd69161870, 1023)  = -1 EINVAL (Invalid argument)
> readlink("/usr/bin", 0x7ffd69161870, 1023) = -1 EINVAL (Invalid argument)
> readlink("/usr", 0x7ffd69161870, 1023)  = -1 EINVAL (Invalid argument)
> readlink("/usr/bin", 0x7ffd69161870, 1023) = -1 EINVAL (Invalid argument)
> --
> *asm_debug_option:
> %{%:debug-level-gt(0):%{!gstabs*:%{g*:%{%:dwarf-version-gt(4):--gdwarf-5 ;%:dwarf-version-gt(3):--gdwarf-4 ;%:dwarf-version-gt(2):--gdwarf-3 ;:--gdwarf2 }}}}

(so indeed, gcc is not sourcing any specs from anywhere)

$ rpm -qf /usr/bin/{gcc,as}
> gcc-11.0.0-0.18.fc34.x86_64
> binutils-2.34-2.fc33.x86_64

Not constraining the dependencies truthfully leads to such "impedance
mismatches".