After upgrading perl to 5.18.2-r2 OTRS 3.2.12 no longer handles non latin-1 characters in emails. otrs.PendingJobs.pl reports the following error, this is error is also logged in the apache error_log when replying to an email containing non latin-1 characters. open body: Invalid argument at /var/lib/otrs/Kernel/cpan-lib/MIME/Entity.pm line 1878. This issue was also reported in Debian Bug #726600 which contains a command to reproduce the issue: " It can be reduced to this: % perl -w -MMIME::Entity -e 'print MIME::Entity->build(Data => "\x{2660}")->body_as_string' Strings with code points over 0xFF may not be mapped into in-memory file handles open body: Invalid argument at /usr/share/perl5/MIME/Entity.pm line 1878. or just % perl -w -MMIME::Body -e 'MIME::Body::InCore->new("\x{2660}")->open("r") or die "open failed: $!"' Strings with code points over 0xFF may not be mapped into in-memory file handles open failed: Invalid argument at -e line 1. " See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726600#122 This issue was fixed upstream in OTRS in the following commits, which is not yet part of OTRS 3.2.12 (which is also no longer supported) https://github.com/OTRS/otrs/commit/3200f38e4ece3b73c1d8f98642b0bf30f5e39043 https://github.com/OTRS/otrs/commit/eda2b2b9a19eeaf513be3d214ab5b680d87c49e3 Updating the OTRS ebuild should resolve this issue, the ebuild upgrade is discussed in: https://bugs.gentoo.org/show_bug.cgi?id=506052 Backporting the upstream fix for the 3.2.12 ebuild may be a quicker fix than updating OTRS to 3.3.x or newer.
Created attachment 391866 [details] Updated ebuild to apply the patch for this issue
Created attachment 391868 [details, diff] Patch from OTRS git repo fixing this issue I've updated the otrs-3.2.12 ebuild to apply the patch OTRS upstream commited in their rel_3.2 branch.
Removed in 934a47e2dfc9eb2ff6a38198622584ef458f028d, following last-rites in bug 664326, bug 692398.
