weechat failed to build from source in Fedora rawhide/f39 https://koji.fedoraproject.org/koji/taskinfo?taskID=103752472 For details on the mass rebuild see: https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild Please fix weechat 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, weechat will be orphaned. Before branching of Fedora 40, weechat will be retired, if it still fails to build. For more details on the FTBFS policy, please visit: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
Created attachment 1979852 [details] build.log file build.log too big, will only attach last 32768 bytes
Created attachment 1979853 [details] root.log file root.log too big, will only attach last 32768 bytes
Created attachment 1979854 [details] state.log
I've been working on this and I have a package for the latest 4.0.3 that builds but fails the tests under F39 and F40. From the upstream bug report [1], it sounds like any non-ascii characters will not display correctly even if I disabled the tests. It seems like there was a change in perl 5.38 which forces a locale change when embedding perl in C [2] like weechat does. I've confirmed this by building in F38 and F37 (perl 5.36) - the test suite passes with no issues. It only fails with F39 and F40 as those have perl 5.38. If I build with -DENABLE_PERL=NO, the build and test also finish under F40. It seems like we're left with some less than ideal options: 1. Leave the weechat package as FTBFS until the upstream issue is solved 2. Solve the issue in weechat code even though they seem to want to wait for upstream perl to fix it 3. Ask the perl packagers to patch out the upstream change [3] and hope that doesn't break anything. 4. Disable the tests and ship something that can't handle more than ASCII and will fail in strange ways if weechat ever sees a non-ASCII character 5. Disable the perl bindings until the upstream issue has been resolved My instinct is to go with 5 and try to figure out how to announce this change in the build for anyone who uses the perl bindings. Are there other thoughts or suggestions? I still need to do more testing of the perl-disabled build to be more sure there aren't big side-effects but wanted to get the question out there for more opinions. [1] https://github.com/weechat/weechat/issues/1996 [2] https://github.com/Perl/perl5/issues/21366 [3] https://github.com/Perl/perl5/commit/7af2d2037375d58e700f9e1b217efb2c4db66133
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle. Changing version to 39.
Note that there is perl5_38 issue (wrt LC_CTYPE) on F-40/39, even if trying to build weechat 4.0.3 on F-38, I see test failure on i686 and aarch64. Tim, does your srpm builds on i686 / aarch64?
(In reply to Mamoru TASAKA from comment #6) > Note that there is perl5_38 issue (wrt LC_CTYPE) on F-40/39, even if trying > to build weechat 4.0.3 on F-38, > I see test failure on i686 and aarch64. > > Tim, does your srpm builds on i686 / aarch64? It turns out that my srpm does not pass tests on i686 or aarch64 [1]. Is this something you're tracking or working on? [1] https://copr.fedorainfracloud.org/coprs/tflink/weechat-testing/build/6306016/
Yes, these failures on i686 or aarch64 in [1] are the same failures I am also seeing, however I have not tried to investigate the cause yet.
Current status: * For F-40/F-39 perl5_38 issue, if we only care for making test pass, I wrote the workaround as https://github.com/weechat/weechat/issues/1996#issuecomment-1680146238 * For F-38 aarch64 test failure, the cause is now identified, with possible solution: https://github.com/weechat/weechat/issues/1997 * For F-38 i686 test failure, well, firstly I am not sure if weechat on Fedora is going to updated to 4.0.3 on stable branches (i.e. on F-38 and below). Then if we are to upgrade to 4.0.3 on Fedora on F-39/40 only, then I am not sure if we should investigate i686 test failure. Currently Fedora encourages to drop i686 support: https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval and the upstream probably is not interested on 32bit.