Bug 1627091

Summary: perl-Tk-804.034-4.fc29 will FTBFS with perl 5.32
Product: [Fedora] Fedora Reporter: Petr Pisar <ppisar>
Component: perl-TkAssignee: Andreas Bierfert <andreas.bierfert>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 31CC: andreas.bierfert, jplesnik, perl-devel, tremble, xavier
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://rt.perl.org/Public/Bug/Display.html?id=133347
Whiteboard:
Fixed In Version: perl-Tk-804.035-1.fc33 perl-Tk-804.035-1.fc32 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-06-30 11:57:17 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:

Description Petr Pisar 2018-09-10 12:12:58 UTC
perl-Tk-804.034-4.fc29 uses deprecated Perl functions for processing UTF-8 (to_utf8_lower() etc.). These are warn at build time. There is known to the upstream (CPAN RT#125854).

The deprecated functions won't be available in Perl 5.30.0. They actually were removed from developmental 5.29 tree and Tk fails to build now. This also know to Tk upstream (CPAN RT#125665).

There was an attempt to port Tk to the new Perl API, but it failed (Perl RT#133347) because Tk assumes an upper-cased string occupies the same amount of bytes as a lower-cased one and that's not true for UTF-8.

Independently I applied a Perl fix to perl-5.28.0 in Fedora ≥ 29:

commit aa3c16bd709ef9b9c8c785af48f368e08f70c74b
Author: Karl Williamson <khw>
Date:   Tue Jul 17 13:57:54 2018 -0600

    Make utf8_to_uvchr() safer
    
    This function is deprecated because the API doesn't allow it to
    determine the end of the input string, so it can read off the far end.
    But I just realized that since many strings are NUL-terminated, so we
    can forbid it from reading past the next NUL, and hence make it safe in
    many cases.

that exposed this Tk issue and caused all perl-Tk applications to crash.

I will revert the fix to stop perl-Tk from crashing, but this is not a long-term solution, as Tk won't be able to built with Perl 5.30 unless a proper perl-Tk fix will be delivered.

This bug report is a warning that this problem exist. And also to track why the Perl fix was reverted.

Comment 1 Petr Pisar 2019-01-09 05:51:53 UTC
This perl change was delayed to Perl 5.32. See upstream perl commit:

commit 5203d63deea0ef134714a48c272a928fbbe64ce1 (HEAD -> blead, origin/blead, origin/HEAD)
Author: Karl Williamson <khw>
Date:   Tue Jan 8 21:04:36 2019 -0700

    Delay fatalization of deprecation of unsafe UTF-8 macros from XS
    
    Trying to earlier make this fatal led to some issues in primarily Tk,
    which I haven't had a chance to address, and it's getting to late in the
    development cycle to do it now.

Comment 2 Petr Pisar 2019-04-03 13:37:49 UTC
A new commit in Perl upstream:

commit b7502288af31c8825a7da7573538e6ce58a641c3
Author: Karl Williamson <khw>
Date:   Thu Mar 28 18:22:11 2019 -0600

    PATCH: [perl #133347] Tk broken
    
    This was caused by utf8_to_uvchr() failing to set the returned ptr
    in some circumstances, leading to reading uninitialized memory.
    
    A test failure remains, and I'll wait for Slaven's feedback before
    looking further into that.  It is in t/photo.t
    
     couldn't recognize image data at blib/lib/Tk/Image.pm line 21.
     # Looks like your test exited with 255 just after 100
    
    And it's trying at that point to look at 'Xcamel.gif'

Comment 3 Ben Cotton 2019-08-13 16:53:03 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

Comment 4 Ben Cotton 2019-08-13 19:28:57 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.