Bug 2389629

Summary: openblas builds take almost two days with StaticLibraryPreserveDebuginfo
Product: [Fedora] Fedora Reporter: Yaakov Selkowitz <yselkowi>
Component: openblasAssignee: Ali Erdinc Koroglu <aekoroglu>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: aekoroglu, fche, nforro, orion, psimovec, susi.lehtola
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2026-01-19 03:47:39 UTC Type: Bug
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: 2383272    
Bug Blocks:    

Description Yaakov Selkowitz 2025-08-20 02:20:28 UTC 
openblas builds are now taking around 8-10 hours on most architectures, and 44 hours (!!) to complete on x86_64.  Given where the build is waiting, I believe the cause is the following change:

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

Earlier this year, the same version of openblas took 1-4 hours, with x86_64 again taking the longest.  Given that the builders are noticeably *faster* since the datacenter move, this is a huge regression in build times.

Please work with the owners of the above change to diagnose what is going wrong and mitigate it.
Comment 1 Frank Ch. Eigler 2025-08-21 19:04:38 UTC 
Suggest using %undefine _preserve_static_debuginfo in your package.

Similarly to the gdal situation, your built libopenblas.a files have tens of thousands of .o files, which are processed serially and take plenty of time overall (even with a 1-ish Hz .o processing rate).
Comment 2 Orion Poplawski 2025-08-22 00:07:28 UTC 
I filed https://bugzilla.redhat.com/show_bug.cgi?id=2390105 against debugedit
Comment 3 Yaakov Selkowitz 2026-01-19 03:47:39 UTC 
Looks like this is fixed in debugedit, the last build time was more reasonable.