Bug 1675089

Summary: guile: FTBFS in Fedora rawhide/f30
Product: [Fedora] Fedora Reporter: Fedora Release Engineering <releng>
Component: guileAssignee: Miroslav Lichvar <mlichvar>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: jsynacek, lslebodn, mlichvar
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: guile-2.0.14-16.fc30 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-02-19 15:46:49 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: 1674516    
Attachments:
Description Flags
build.log
none
root.log
none
state.log none

Description Fedora Release Engineering 2019-02-11 19:40:04 UTC
guile failed to build from source in Fedora rawhide/f30

https://koji.fedoraproject.org/koji/taskinfo?taskID=32398919


For details on the mass rebuild see:

https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
Please fix guile at your earliest convenience and set the bug's status to
ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks,
guile will be orphaned. Before branching of Fedora 31,
guile will be retired, if it still fails to build.

For more details on the FTBFS policy, please visit:
https://fedoraproject.org/wiki/Fails_to_build_from_source

Comment 1 Fedora Release Engineering 2019-02-11 19:40:07 UTC
Created attachment 1530429 [details]
build.log

file build.log too big, will only attach last 1024 bytes

Comment 2 Fedora Release Engineering 2019-02-11 19:40:08 UTC
Created attachment 1530430 [details]
root.log

file root.log too big, will only attach last 1024 bytes

Comment 3 Fedora Release Engineering 2019-02-11 19:40:09 UTC
Created attachment 1530431 [details]
state.log

Comment 4 Lukas Slebodnik 2019-02-19 09:00:59 UTC
This bug is quite critical because of "Rebuild for readline 8.0" (5:2.0.14-15)
Previously(5:2.0.14-14) there were not any conflicts when updating packages.


mock-build                                                                                                
DEBUG util.py:490:  BUILDSTDERR: Error:                                                                   
DEBUG util.py:490:  BUILDSTDERR:  Problem: problem with installed package guile-:2.0.14-13.fc30.x86_64   
DEBUG util.py:490:  BUILDSTDERR:   - package guile-5:2.0.14-13.fc30.x86_64 requires libreadline.so.7()(64bit), but none of the providers can be installed                                    
DEBUG util.py:490:  BUILDSTDERR:   - cannot install both readline-8.0-2.fc30.x86_64 and readline-7.0-13.fc30.x86_64                                                                              
DEBUG util.py:490:  BUILDSTDERR:   - package python3-libs-3.7.2-7.fc30.x86_64 requires libreadline.so.8()(64bit), but none of the providers can be installed                                    
DEBUG util.py:490:  BUILDSTDERR:   - package python3-devel-3.7.2-7.fc30.x86_64 requires python3-libs(x86-64) = 3.7.2-7.fc30, but none of the providers can be installed
...

I can see that build failed just on 2 architectures.
Is there some plan to temporary "whitelist" known good architectures? or fix problematic architectures?

Comment 5 Miroslav Lichvar 2019-02-19 09:09:55 UTC
On one arch the build seems to be failing in assembler. The error is
   Error: bad immediate value for offset (4096)

I guess that means some generated code is too large? Maybe adding or removing some CFLAGS would help?

Comment 6 Miroslav Lichvar 2019-02-19 15:46:49 UTC
After several attempts with different CFLAGS, it turned out replacing -O2 with -Os is enough to make the package build again. I'm not sure what is the proper fix, but should be good at least for now.

Comment 7 Lukas Slebodnik 2019-02-19 23:22:34 UTC
Thank you very much for unblocking rawhide.

Is there any other BZ which will track removing of workaround
https://src.fedoraproject.org/rpms/guile/c/da333a25d0bd26590a22e28af5f507464b053cea?branch=master.
If no; then even this BZ can be used for such purpose.

Comment 8 Miroslav Lichvar 2019-02-21 10:15:44 UTC
This should be reported to upstream. However, the 2.0 branch of guile doesn't seem to maintained anymore, so I'm not sure if anyone will care enough to investigate and provide a fix.

Comment 9 Lukas Slebodnik 2019-02-21 11:30:42 UTC
(In reply to Miroslav Lichvar from comment #8)
> This should be reported to upstream. However, the 2.0 branch of guile
> doesn't seem to maintained anymore, so I'm not sure if anyone will care
> enough to investigate and provide a fix.

Or you can try to use newer version of guile in rawhide.

And I can see that quite a log of important packages depends on it (make, autogen)
sh# dnf repoquery --whatrequires guile
Last metadata expiration check: 2:08:35 ago on Thu 21 Feb 2019 10:16:59 AM CET.
aisleriot-1:3.22.7-2.fc30.x86_64
autogen-0:5.18.16-1.fc30.x86_64
denemo-0:2.2.0-5.fc30.x86_64
gdb-headless-0:8.2.50.20190120-15.fc30.x86_64
gnubik-0:2.4.3-3.fc30.x86_64
gnucash-0:3.4-1.fc30.x86_64
gnutls-guile-0:3.6.6-1.fc30.x86_64
graphviz-guile-0:2.40.1-44.fc30.x86_64
guile-NLopt-0:2.5.0-2.fc30.x86_64
guile-cairo-0:1.4.0-23.fc30.i686
guile-cairo-0:1.4.0-23.fc30.x86_64
guile-devel-5:2.0.14-13.fc30.i686
guile-devel-5:2.0.14-13.fc30.x86_64
guile-lib-0:0.2.5.1-3.fc29.x86_64
insight-0:8.2.50.20190118-2.fc30.x86_64
make-1:4.2.1-11.fc30.x86_64
mdk-0:1.2.9-8.fc30.x86_64
weechat-0:2.3-3.fc30.i686
weechat-0:2.3-3.fc30.x86_64
xbindkeys-0:1.8.5-15.fc30.x86_64

Maybe it is a time to from "Guile's legacy 2.0.x series"
to the latest stable release 2.2.4.

Comment 10 Miroslav Lichvar 2019-02-21 11:36:06 UTC
(In reply to Lukas Slebodnik from comment #9)
> Maybe it is a time to from "Guile's legacy 2.0.x series"
> to the latest stable release 2.2.4.

That's in the guile22 package. guile is for applications that have not been ported yet. When they are all ported, it can be dropped or possibly updated to 3.x, but it depends on how easy will be porting from 2.2 to 3.0.

Comment 11 Lukas Slebodnik 2019-02-21 11:37:44 UTC
Thank you very much for answers and your time.
Now it make a sense to me.