Bug 2046737
| Summary: | micropython: FTBFS in Fedora rawhide/f36 | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Fedora Release Engineering <releng> | ||||||||
| Component: | micropython | Assignee: | Charalampos Stratakis <cstratak> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 36 | CC: | cstratak, mhroncok, python-sig | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | micropython-1.18-1.fc37 micropython-1.18-1.fc36 | Doc Type: | If docs needed, set a value | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2022-03-17 10:56:00 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 1992484, 2045102, 2050761 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Fedora Release Engineering
2022-01-27 09:23:15 UTC
Created attachment 1855841 [details]
build.log
file build.log too big, will only attach last 32768 bytes
Created attachment 1855842 [details]
root.log
file root.log too big, will only attach last 32768 bytes
Created attachment 1855843 [details]
state.log
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle. Changing version to 36. micropython started failing to build since that change in redhat-rpm-config: https://fedoraproject.org/wiki/Changes/SetBuildFlagsBuildCheck https://src.fedoraproject.org/rpms/redhat-rpm-config/c/9183c1c8d46f7b30514e478f9bf0e354621a50d3?branch=rawhide Apparently gcc errors out if -Wformat-security is used without -Wformat and unfortunately the proper build flags were not passed on to the build before the redhat-rpm-config change. The addition of that option was discussed in this bugzilla and fesco ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1043495 https://pagure.io/fesco/issue/1185 My proposal is to set -Wformat by default as well through the redhat-rpm-config: https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros#_350 Other workarounds for it would be to use %undefine _auto_set_build_flags in the micropython SPEC which would use a different set of CFLAGS, hack the SPEC to add -Wformat to CFLAGS or modify the Makefiles to do the same thing. > Apparently gcc errors out if -Wformat-security is used without -Wformat... Why does this only affect micropython and not other packages? > %undefine _auto_set_build_flags in the micropython SPEC which would use a different set of CFLAGS That would probably be the wrong fix here, reverting back to *not* following the packaging guidelines :) > hack the SPEC to add -Wformat to CFLAGS That should be as easy as: %global _warning_options %_warning_options -Wformat (In reply to Miro Hrončok from comment #6) > > Apparently gcc errors out if -Wformat-security is used without -Wformat... > > Why does this only affect micropython and not other packages? > It has affected other packages in the past, notably when gcc started treating the lack of Wformat in conjunction with the use of Wformat-security as an error. There were some bugs reported and packages took different approaches to fixing it: https://src.fedoraproject.org/rpms/net-snmp/c/fd2028db3f5e32152c4c339d1a0fa8fba93ed59b?branch=f23 https://src.fedoraproject.org/rpms/csound/c/702c157ef8eff133b699a82872ab0889e2154105?branch=f28 https://src.fedoraproject.org/rpms/cvc4/c/ff83d75d680786614251604e04340108435ffbba?branch=f26 https://src.fedoraproject.org/rpms/qpid-proton/c/623a55c07cfa3209ba2eb529ff6edcc1593e6e8a?branch=f26 https://bugzilla.mozilla.org/show_bug.cgi?id=1388681 The reason is possibly some weird interaction with the Makefile of micropython that I didn't dive yet into, the main point is that the CFLAGS used were not the ones set by the buildroot environment before the redhat-rpm-config change. > > > %undefine _auto_set_build_flags in the micropython SPEC which would use a different set of CFLAGS > > That would probably be the wrong fix here, reverting back to *not* following > the packaging guidelines :) > > > > hack the SPEC to add -Wformat to CFLAGS > > That should be as easy as: > > %global _warning_options %_warning_options -Wformat When injecting the appropriate flags, compilation moves forward properly, however all the tests fail and at some point the build hangs. I'll need to investigate it more. Interestingly enough, it builds fine on i686 but not on x86_64: https://koji.fedoraproject.org/koji/taskinfo?taskID=83805406 PR's: https://src.fedoraproject.org/rpms/micropython/pull-request/10 https://src.fedoraproject.org/rpms/micropython/pull-request/11 FEDORA-2022-fdade6d208 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-fdade6d208 FEDORA-2022-fdade6d208 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2022-963ea9ec9a has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-963ea9ec9a FEDORA-2022-963ea9ec9a has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-963ea9ec9a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-963ea9ec9a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2022-963ea9ec9a has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report. |