Bugzilla 5.0* on sourceware.org / gcc.gnu.org has been disabled, apparently by an update to this package. perl-Email-MIME-ContentType-1.024-1.epel8.playground.noarch The following error message is generated when outgoing mail is being originated. Invalid Content-Type 'subtype' parameter at Bugzilla/BugMail.pm line 471. Reverting perl-Email-MIME and perl-Email-MIME-ContentType to the previous (late-2019) versions fixes bugzilla.
This is the change that caused the issue: https://github.com/rjbs/Email-MIME-ContentType/commit/ed2a0311dbaa268dc575a0eb55ddaace8038571e Essentially, one of the subtypes is not matching this regex: my $re_token = qr/[\x21\x23-\x27\x2A\x2B\x2D\x2E\x30-\x39\x41-\x5A\x5E-\x7E]+/; # US-ASCII except SPACE, CTLs and tspecials ()<>@,;:\\"/[]?= If you can change this line (178) from: croak 'Invalid Content-Type \'subtype\' parameter' if $ct->{subtype} !~ /^(?:$re_token)*$/; to croak "Invalid Content-Type 'subtype' parameter: '$ct->{subtype}'" if $ct->{subtype} !~ /^(?:$re_token)*$/; I think that will shed light on what subtype in Bugzilla is not passing the regex, and whether that is a bug in Bugzilla or in the regex.
Looks like Bug #1855962, which would be a bugzilla bug rather than one in perl-Email-MIME-ContentType.
(In reply to Paul Howarth from comment #2) > Looks like Bug #1855962, which would be a bugzilla bug rather than one in > perl-Email-MIME-ContentType. Arguably, infrastructure code should not add new assertions ("croak") that result in program crashes for API usage that was formerly acceptable. Perhaps consider turning that into a warning, if the Email-MIME code can tolerate the previous usage?