Wide character error starting in 4/28 build

[peter-mcclonski]

Seeing the following error on container start, preventing usage of RT:

[1] [Wed Apr 29 08:30:01 2026] [error]: Wide character in subroutine entry at /opt/rt/sbin/../lib/RT/Squish.pm line 85.
Stack:
  [/opt/rt/sbin/../lib/RT/Squish.pm:85]
  [/opt/rt/sbin/../lib/RT/Interface/Web.pm:116]
  [/opt/rt/share/html/Elements/HeaderJavascript:82]
  [/opt/rt/share/html/Elements/Header:91]
  [/opt/rt/share/html/Elements/Login:49]
  [/opt/rt/share/html/NoAuth/Login.html:56]
  [/opt/rt/sbin/../lib/RT/Interface/Web.pm:455]
  [/opt/rt/share/html/autohandler:53] (/opt/rt/sbin/../lib/RT/Interface/Web/Handler.pm:216)

Error re-prints every few seconds until the pod gets OOMKilled.

Error is present in amd64 builds for firefart/requesttracker:nightly-6.0.2-20260428, firefart/requesttracker:nightly-6.0.2-20260429, and firefart/requesttracker:6.0.2. Going back to firefart/requesttracker:nightly-6.0.2-20260427 does NOT show this error.

As an aside, it was surprising to see that the main version tag (6.0.2) gets rebuilt regularly and thus is not necessarily known to be stable. Is best practice then to peg to a specific nightly that is known to be stable?

[firefart]

I will have a look tomorrow but I guess this might be something the request tracker team has to fix.
The images are rebuilt daily as rt relies on a ton of dependencies that change almost daily, so the image is rebuilt each night. There is also no lock file for the dependencies so it’s always “install the latest stuff”, so depending when you install rt you get a completely different set of dependencies. You can pin a exact build using the nightly builds

[firefart]

Can replicate this issue, looking at the image diff here is what changed:

  ~ /usr/local/lib/perl5/site_perl/5.42.2/Alien/LibGumbo/ConfigData.pm
  ~ /usr/local/lib/perl5/site_perl/5.42.2/HTTP/Message/PSGI.pm
  ~ /usr/local/lib/perl5/site_perl/5.42.2/Net/CIDR/Set.pm
  ~ /usr/local/lib/perl5/site_perl/5.42.2/Net/CIDR/Set/IPv4.pm
  ~ /usr/local/lib/perl5/site_perl/5.42.2/Net/CIDR/Set/IPv6.pm
  ~ /usr/local/lib/perl5/site_perl/5.42.2/Plack.pm
  ~ /usr/local/lib/perl5/site_perl/5.42.2/Plack/App/Cascade.pm
  ~ /usr/local/lib/perl5/site_perl/5.42.2/Plack/App/File.pm
  ~ /usr/local/lib/perl5/site_perl/5.42.2/Plack/MIME.pm
  ~ /usr/local/lib/perl5/site_perl/5.42.2/Plack/Middleware/Auth/Basic.pm
  ~ /usr/local/lib/perl5/site_perl/5.42.2/Plack/Middleware/Lint.pm
  ~ /usr/local/lib/perl5/site_perl/5.42.2/Plack/Middleware/XSendfile.pm
  ~ /usr/local/lib/perl5/site_perl/5.42.2/Plack/Request.pm
  ~ /usr/local/lib/perl5/site_perl/5.42.2/Plack/Response.pm

So I suspect the new version of Plack causing some issues

[firefart]

I've openend a bug with Plack to see if that's the issue, lets see if they respond

[firefart]

@peter-mcclonski this is a bug in RTs code which triggered because of a change in Plack.

I will try to open a bug on rts side, but in the past they where not really responsive.

As a temp fix you can add

use Plack::MIME;
Plack::MIME->add_type('.js', 'application/javascript');

on top of your RT_SiteConfig.pm which resolves the startup issues

[firefart]

Ok looks like the config setting only prevents the startup error, but it results in the javascript not being generated correctly and RT is broken again. I now downgrade this dependency in the docker image

[peter-mcclonski]

Thank you for being so on top of this!