Thanks to alebastr from IRC for the explanation:

alebastr
`%[0%{?_package_note_status} ? "-Clink-arg=%_package_note_flags" : ""]` in macros.rust doesn't work with the opt-out mechanism suggested in macros.package-notes-srpm
alebastr
i.e. firefox.spec undefines _flags, but _status is still 1

I can have firefox.spec also undefine _status, but it sounds like the mechanism needs rethinking...

This is a bug in Mozilla's bespoke build system. Setting RUSTFLAGS is the canonical way of setting rustc fflags (similar to CFLAGS etc.), but their build system chokes on it for some reason. The only workaround I know of is to "unset RUSTFLAGS" (which was also necessary in thunderbird).

This is also the reason why Rust code in Firefox, Thunderbird, mozjs* etc. is built in a way that doesn't honor default Fedora compiler flags ...

I've heard that before, but honestly, a literal macro in the falgs can hardly be Firefox fault. The comment in https://src.fedoraproject.org/rpms/package-notes/blob/rawhide/f/macros.package-notes-srpm says the way Firefox uses to opt-out is correct. Hence I really think %build_rustflags need a fix.

Using the status to see if we should set the flags is not enough, because the way the opt-out works leaves the status set it seems.

Either %build_rustflags needs to check if the %_package_note_flags macro is defined before using it, or better yet, %_package_note_status should do the check.

Sure, but that's a different problem, and solving it won't fix the Firefox build. It chokes when RUSTFLAGS is set at all, even if there's no unexpanded macros in there.

Ack.

---


Back to the problem reported here.

Default (name has to be set, consider it implementation detail):

<mock-chroot> sh-5.2# rpm --define 'name xxx' --eval '%build_rustflags'
-Copt-level=3 -Cdebuginfo=2 -Ccodegen-units=1 -Cforce-frame-pointers=yes -Clink-arg=-Wl,-z,relro -Clink-arg=-Wl,-z,now -Clink-arg=-specs=/usr/lib/rpm/redhat/redhat-package-notes --cap-lints=warn

The documented opt-out:

<mock-chroot> sh-5.2# rpm --define 'name xxx' --undefine '_package_note_flags' --eval '%build_rustflags'
-Copt-level=3 -Cdebuginfo=2 -Ccodegen-units=1 -Cforce-frame-pointers=yes -Clink-arg=-Wl,-z,relro -Clink-arg=-Wl,-z,now -Clink-arg=%_package_note_flags --cap-lints=warn

Bam!


Change in /usr/lib/rpm/macros.d/macros.package-notes-srpm:

-%_package_note_status   %[0%{?_package_note_file:1} && 0%{?name:1} && "%_target_cpu" != "noarch" && "%{toolchain}" != "clang" ? 1 : 0]
+%_package_note_status   %{!?_package_note_flags:0}%{?_package_note_flags:%[0%{?_package_note_file:1} && 0%{?name:1} && "%_target_cpu" != "noarch" && "%{toolchain}" != "clang" ? 1 : 0]}

Default:

<mock-chroot> sh-5.2# rpm --define 'name xxx' --eval '%build_rustflags'
-Copt-level=3 -Cdebuginfo=2 -Ccodegen-units=1 -Cforce-frame-pointers=yes -Clink-arg=-Wl,-z,relro -Clink-arg=-Wl,-z,now -Clink-arg=-specs=/usr/lib/rpm/redhat/redhat-package-notes --cap-lints=warn

<mock-chroot> sh-5.2# rpm --define 'name xxx' --eval '%build_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 -specs=/usr/lib/rpm/redhat/redhat-package-notes 


Opt-out:

<mock-chroot> sh-5.2# rpm --define 'name xxx' --undefine '_package_note_flags' --eval '%build_rustflags'
-Copt-level=3 -Cdebuginfo=2 -Ccodegen-units=1 -Cforce-frame-pointers=yes -Clink-arg=-Wl,-z,relro -Clink-arg=-Wl,-z,now --cap-lints=warn

<mock-chroot> sh-5.2# rpm --define 'name xxx' --undefine '_package_note_flags' --eval '%build_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

Alternatively, %build_rustflags can check if %_package_note_flags is not empty/undefined to determine if it should use it instead of checking the status macro. But I belive that what I propose is the proper place to fix this. The status should be 0 when %_package_note_flags was undefined.

Fabio: I'm tracking the "It chokes when RUSTFLAGS is set at all" part elsewhere, currently in https://bugzilla.redhat.com/show_bug.cgi?id=2184549 but I'll file a new bug now. (A more accurate description is "It chokes when RUSTFLAGS is set to a string with a comma in it").

To be clear, this bug is now for making %build_rustflags handle %_package_note_flags being undefined, as recommended at https://src.fedoraproject.org/rpms/package-notes/blob/rawhide/f/macros.package-notes-srpm#_10 .

FEDORA-2023-e9e51c65b5 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-e9e51c65b5

FEDORA-2023-88d0260bcb has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-88d0260bcb

FEDORA-2023-88d0260bcb has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-88d0260bcb`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-88d0260bcb

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-e9e51c65b5 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-e9e51c65b5`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-e9e51c65b5

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-88d0260bcb has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2023-e9e51c65b5 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.