Bug 2330362 - Broken "sed" invocation in %prep
Summary: Broken "sed" invocation in %prep
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: rawhide
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-12-04 15:28 UTC by Dave Malcolm
Modified: 2025-08-13 14:54 UTC (History)
12 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2025-05-20 20:17:13 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Dave Malcolm 2024-12-04 15:28:14 UTC
I noticed that Fedora's gcc.spec's %prep has this line:

sed -i -e 's/context->report_bug = false;/context->report_bug = true;/' gcc/diagnostic.cc

However I've changed the line this is aimed at changing in this upstream commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=8200cd97c9c57de582e81a68a6cb2046fa8decb2

aka r14-5117-g8200cd97c9c57d

from:
  context->report_bug = false;
to:
  m_report_bug = false;

so I'm guessing that this part of %prep has been silently failing since the switch to GCC 14 in Fedora 40.

Should this perhaps be an upstream configure option?  Is this something we keep enabled throughout the lifetime of Fedora?  similarly for downstream in CentOS/RHEL.

Should the various sed commands in %prep be updated to fail the build immediately if they fail to change anything?

Reproducible: Didn't try

Comment 1 Dave Malcolm 2024-12-04 15:31:30 UTC
The "sed" line seems to have been added by Jakub in 12.0.1-0.9:
https://src.fedoraproject.org/rpms/gcc/c/b0dddd2d05f29e68631c9155f3eee6a9536c0cf1

Comment 2 Jakub Jelinek 2024-12-04 16:10:16 UTC
(In reply to Dave Malcolm from comment #0)
> I noticed that Fedora's gcc.spec's %prep has this line:
> 
> sed -i -e 's/context->report_bug = false;/context->report_bug = true;/'
> gcc/diagnostic.cc
> 
> However I've changed the line this is aimed at changing in this upstream
> commit:
> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;
> h=8200cd97c9c57de582e81a68a6cb2046fa8decb2
> 
> aka r14-5117-g8200cd97c9c57d
> 
> from:
>   context->report_bug = false;
> to:
>   m_report_bug = false;

Ouch.

> so I'm guessing that this part of %prep has been silently failing since the
> switch to GCC 14 in Fedora 40.
> 
> Should this perhaps be an upstream configure option?  Is this something we

Maybe.

> keep enabled throughout the lifetime of Fedora?  similarly for downstream in
> CentOS/RHEL.

Certainly, we want -freport-bug to be on by default.  Initially it was a matter
of just tweaking the *.opt files, but later on it stopped working, so I had to
add another hack, which now stopped working as well.

Guess I could add a testcase that -freport-bug is on by default, but one can hardly rely on
some specific ICE to be unfixed for years, so it would likely need to be a plugin...

> Should the various sed commands in %prep be updated to fail the build
> immediately if they fail to change anything?

How?  sed can do q, but that exits immediately, we'd want exit if nothing has been
changed, or stop using -i and cmp old/new, or grep for the same pattern first?

Comment 3 Dave Malcolm 2024-12-04 17:29:08 UTC
(In reply to Jakub Jelinek from comment #2)
> (In reply to Dave Malcolm from comment #0)
[...]

> Guess I could add a testcase that -freport-bug is on by default, but one can
> hardly rely on
> some specific ICE to be unfixed for years, so it would likely need to be a
> plugin...

The upstream testsuite has a plugin for testing crash-handling:
  gcc/testsuite/gcc.dg/plugin/crash_test_plugin.cc
and the cases:
  crash-test-ice-stderr.c
  crash-test-write-though-null-stderr.c
verify aspects of the text output on stderr, though both use dg-additional-options to specify -fno-report-bug.

So potentially we could add a test case that verifies the default behavior (potentially different ones upstream and downstream)

Comment 4 Aoife Moloney 2025-04-28 15:25:28 UTC
This message is a reminder that Fedora Linux 40 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-13.
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
'version' of '40'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 40 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 Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 5 Aoife Moloney 2025-05-20 20:17:13 UTC
Fedora Linux 40 entered end-of-life (EOL) status on 2025-05-13.

Fedora Linux 40 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 6 Dave Malcolm 2025-08-13 14:51:45 UTC
Reopening; looks like Jakub fixed the issue in:
   https://src.fedoraproject.org/rpms/gcc/c/806e75093dd637270102e8d2896b9c6c40015166

but for GCC 16 note that I've moved the upstream code in question from gcc/diagnostic.cc to gcc/diagnostics/context.cc

So when it becomes time to ship GCC 16 in Fedora we'll need to update this again.

In the meantime, perhaps we could convert it to a patch, so that it fails hard during %prep if there's a problem?  I tried doing this myself, but "fedpkg prep" is currently failing for me:

+ /usr/bin/cat /home/david/coding-3/fedora-packages/gcc/gcc15-hack.patch
+ /usr/bin/patch -p0 -s --fuzz=0 --no-backup-if-mismatch
Reversed (or previously applied) patch detected!  Assume -R? [n] y

Comment 7 Dave Malcolm 2025-08-13 14:54:09 UTC
Or I could try adding a configure option for this upstream


Note You need to log in before you can comment on or make changes to this bug.