+1

(I'd still like to see gcc-rs available with this upgrade...)

+1

+1

As with @ngompa I am interested in the progress of gcc-rs, but given the state I think it's better to exclude it from Fedora right now. We could have a Copr repo providing experimental builds based on the official packages in Fedora and then just enable gcc-rs for those builds. I am mostly curious about the usability and how that's progressing.

If we have at least some kind of bcond for it and have it set up to be enabled when building in a particular COPR automatically (which is possible, see https://src.fedoraproject.org/rpms/webkitgtk/c/c49438eba25ae6b545ccf2d97c85748b58736714), then I'd be satisfied as well.

Ultimately, I want exposure to gcc-rs so that tools can start adapting to support its command-line syntax as it "grows up" and becomes useful.

+1

Update the Fedora 38 GNU Toolchain to gcc 13.0, binutils 2.39, and glibc 2.37.

...

GNU Binary Utilities 2.39

Is it 2.39 and not 2.40 intentionally? Just curious what were the reasons to ship older binutils than the latest (2.40).

Owners, do not implement this work until the FESCo vote has explicitly ended.

GCC 13 already landed in Rawhide :/

+1 too

Is it 2.39 and not 2.40 intentionally?

GCC 13 already landed in Rawhide :/

Both good points.

Meh. I would like to know why binutils will stay at 2.39 instead of the recently released 2.40 as well.

Either way, GCC 13 already landed and broke stuff in rawhide, so I guess have my reluctant +1 vote ...

I abstain. There is no chance this is not happening and the change owners apparently don't care about the vote or other rules anyway.

I agree we should update GCC. I disagree about how this was done (again). This makes me sad.

I abstain. There is no chance this is not happening and the change owners apparently don't care about the vote or other rules anyway.

I agree we should update GCC. I disagree about how this was done (again). This makes me sad.

Miro,

As the change proposal owner let me say that it is not my intent to undermine FESCo and the voting rules, and that I take these decisions seriously and that we engage and participate in good faith because we want to improve.

It was with Fedora 35 that we started filling system-wide change requests specifically to raise the visibility of the annual system toolchain update and the required changes that must happen for Fedora to have a supported and maintained toolchain.

Sticking to the process means engaging in broader discussions about Fedora process and how to improve with each release. I'm sorry that you are disappointed, what can we do in Fedora 40 to improve this?

For Fedora 40 I want to see us use mass-prebuild earlier to see if we can detect and correct issues related to the compiler upgrade. Not all issues will be caught thought, and some are difficult to coordinate e.g. SONAME bumps, runtime/debuginfo issues affecting Sanitizers or Valgrind.

I agree with you that the Ada SONAME bump can be handled better. It wasn't even on my list of things to consider, but we should be coordinating better with the Ada package maintainers. I think a possible solution would be to announce early the availability of a side-tag into which developers can start building their packages?

The toolchain update is something we have historically always done in Fedora, and the intent of filling the system-wide change request is to get FESCo's attention, and input, and feedback. I appreciate that you provided candid feedback.

Concrete take away:
* Start mass-prebuild testing the new compiler earlier to discover and diagnose build issues with the goal to have a smoother transition.
* Announce and maintaining a side-tag and coordinate with Ada maintainers for SONAME bump and eventual side-tag merge.

I've updated https://fedoraproject.org/wiki/Changes/GNUToolchainFXX with the Ada notes from this discussion. We also have a redhat-rpm-config sync point there too because we update config.guess and config.sub from upstream, which came out of actually reviewing what we do every year.

Thank you all for the time and effort you put into reviewing change proposals.

Meh. I would like to know why binutils will stay at 2.39 instead of the recently released 2.40 as well.

Either way, GCC 13 already landed and broke stuff in rawhide, so I guess have my reluctant +1 vote ...

I like to see this kind of issue revisited as we file a system-wide change request every 6 months of the GNU Toolchain update. It means that the system-wide change request has raised the visibility of what we are doing and how we might improve.

Static linker and assembler changes, like compiler changes, impact generated binaries and the capacity for developers to build their packages or applications. To reduce the impact and risk we ship the N-1 release of binutils in the stable release of the distribution. The 2.40 release only happened 3 days ago, and the reality is that it has not seen enough testing to be used in Fedora 38. The binutils 2.40 release weill be put into Rawhide after branching and used for Fedora 39.

We don't do this for the compiler because it would delay the use of the new compiler by a full year, and the compiler sees more testing than the binutils release.

The RISC-V port developers expressed an interest in having a newer binutils so they did not have to wait 6 months for the newer release to land in Fedora. I don't know how to meet such a requirement without increased effort, like tracking binutils development directly in Rawhide, making the release a smoother transition (like we do for glibc). The problem with doing this for the static linker and assembler is that any defect along the way in Rawhide could potentially lead to the need for mini mass rebuilds in Rawhide to clear out ABI or binary artifacts that are incorrect (could lead to less stable rawhide).

So for now we continue with the following plan:

• binutils update is delayed by 6 months.
• gcc release candidate is integrated directly.
• glibc tracks upstream in Rawhide at all times (https://fedoraproject.org/wiki/Glibc#Usage_of_Fedora_Rawhide)
• gdb is integrated directly into all non-EOL Fedora when ready

Does that answer that question?

I like to see this kind of issue revisited as we file a system-wide change request every 6 months of the GNU Toolchain update. It means that the system-wide change request has raised the visibility of what we are doing and how we might improve.

Static linker and assembler changes, like compiler changes, impact generated binaries and the capacity for developers to build their packages or applications. To reduce the impact and risk we ship the N-1 release of binutils in the stable release of the distribution. The 2.40 release only happened 3 days ago, and the reality is that it has not seen enough testing to be used in Fedora 38. The binutils 2.40 release weill be put into Rawhide after branching and used for Fedora 39.

We don't do this for the compiler because it would delay the use of the new compiler by a full year, and the compiler sees more testing than the binutils release.

This answers my question, thank you. Now that you mention it, I remember us talking about the same issue a year ago, so I apologize for being an old forgetful grumpy man :)

I abstain. There is no chance this is not happening and the change owners apparently don't care about the vote or other rules anyway.

I agree we should update GCC. I disagree about how this was done (again). This makes me sad.

Miro,

As the change proposal owner let me say that it is not my intent to undermine FESCo and the voting rules, and that I take these decisions seriously and that we engage and participate in good faith because we want to improve.

Thanks. Sorry if my comment went out a bit snarky, but this has already happened with GCC 12, which landed before that change was approved and now it happened again.

It was with Fedora 35 that we started filling system-wide change requests specifically to raise the visibility of the annual system toolchain update and the required changes that must happen for Fedora to have a supported and maintained toolchain.

Sticking to the process means engaging in broader discussions about Fedora process and how to improve with each release. I'm sorry that you are disappointed, what can we do in Fedora 40 to improve this?

Please:

• Ship the update after it is approved, not before. If you need to ship it before the mass rebuild and waiting for FESCo approval puts that at risk, consider proposing the change sooner.
• Announce the update on the devel list when it is about to happen to avoid surprises.
• Use a side tag to rebuild dependent packages that need to be rebuilt to be installable.

For Fedora 40 I want to see us use mass-prebuild earlier to see if we can detect and correct issues related to the compiler upgrade. Not all issues will be caught thought, and some are difficult to coordinate e.g. SONAME bumps, runtime/debuginfo issues affecting Sanitizers or Valgrind.

I agree with you that the Ada SONAME bump can be handled better. It wasn't even on my list of things to consider, but we should be coordinating better with the Ada package maintainers. I think a possible solution would be to announce early the availability of a side-tag into which developers can start building their packages?

Ideally, the change owners would handle the rebuilds, see https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages

The toolchain update is something we have historically always done in Fedora, and the intent of filling the system-wide change request is to get FESCo's attention, and input, and feedback. I appreciate that you provided candid feedback.

Concrete take away:
* Start mass-prebuild testing the new compiler earlier to discover and diagnose build issues with the goal to have a smoother transition.

This is a very good goal, thanks.

• Announce and maintaining a side-tag and coordinate with Ada maintainers for SONAME bump and eventual side-tag merge.

Indeed.

I've updated https://fedoraproject.org/wiki/Changes/GNUToolchainFXX with the Ada notes from this discussion. We also have a redhat-rpm-config sync point there too because we update config.guess and config.sub from upstream, which came out of actually reviewing what we do every year.

Thank you all for the time and effort you put into reviewing change proposals.

Once again, sorry for my attitude, I was frustrated when I sent that comment.

+1 for the change

After a week, the vote is
APPROVED (+6,0,-0)

Announced.