p5.16-spiffy configure error - sed: RE error: illegal byte sequence

[mf2k (Frank Schima)]

I'm suddenly seeing the following error when trying to build p5.16-spiffy with all the new perl updates.

--->  Configuring p5.16-spiffy
sed: RE error: illegal byte sequence

See also #43145.

[danielluke (Daniel J. Luke)]

Can you try the standard fix? (i.e.. add 'build.env LANG=C' to the Portfile and see if it fixes it)?

[mf2k (Frank Schima)]

I just tried it and the same error occurs.

[danielluke (Daniel J. Luke)]

Replying to mf2k@…:

I just tried it and the same error occurs.

oh, because this sed is being run in the configure phase, not the build phase.

Try 'configure.env-append LANG=C' instead.

[mf2k (Frank Schima)]

Good thought, but I tried that and the problem remains.

[danielluke (Daniel J. Luke)]

can you attach the main.log from the new failure?

[mf2k (Frank Schima)]

OK attached.

[danielluke (Daniel J. Luke)]

Looks like setting configure.env doesn't change the env in post-configure blocks (which is where the perl5 portgroup does a couple of reinplaces). This also a problem for p5-shell-parser (#37066).

We probably need to (at least temporarily) be setting LANG=C or LC_CTYPE=C in the perl5 portgroup.

[danielluke (Daniel J. Luke)]

has duplicate #44636

[ryandesign (Ryan Carsten Schmidt)]

One fix would be to change the perl5 portgroup's post-configure reinplace to use -locale C. When last I encountered this with a different module I instead patched its Makefile.PL. There is a real underlying bug somewhere that should be fixed—a Makefile.PL that starts out as UTF-8 should not result in a Makefile that is not UTF-8—I just couldn't find where in ExtUtils::MakeMaker the bug was, then realized it could be a bug in any of its dependencies, and also the bug affects the versions of these modules that ship with perl5.16 and perl5.18 (but not perl5.14 or earlier nor perl5.20).

[ryandesign (Ryan Carsten Schmidt)]

Replying to dluke@…:

This also a problem for p5-shell-parser (#37066).

#37066 has a different cause: that project's Makefile.PL isn't UTF-8 (it's ISO8859-1).

And I've now realized that while p5-spiffy's Makefile.PL is ASCII, it contains escape codes representing ISO8859-1 characters, which get turned into real ISO8859-1 characters in the generated Makefile.

[danielluke (Daniel J. Luke)]

Replying to ryandesign@…:

Replying to dluke@…:

This also a problem for p5-shell-parser (#37066).

#37066 has a different cause: that project's Makefile.PL isn't UTF-8 (it's ISO8859-1).

And I've now realized that while p5-spiffy's Makefile.PL is ASCII, it contains escape codes representing ISO8859-1 characters, which get turned into real ISO8859-1 characters in the generated Makefile.

yep. I think there may be some fixes for this sort of thing in ExtUtils::MakeMaker 7.00 (which isn't out yet).

Easiest way to work around this would be to make a change to the perl5 portgroup (for now).

[mojca (Mojca Miklavec)]

I attached a patch that can be applied to fix this problem. See #43145. I wrote to ingy at cpan, but never got any answer. This is a problem with all the modules from the same author.

[danielluke (Daniel J. Luke)]

For now, I've just patched the Makefile.PL - r123722 (like Ryan did for p5-xml-entities). This isn't ideal, since we're effectively mangling the author's name, but at least it lets things build.

[danielluke (Daniel J. Luke)]

The META.yml file that gets generated from Makefile.PL is supposed to allow utf8 characters, so ideally we wouldn't have to munge the author's name in order to get things to build. I haven't tested newer ExtUtils::MakeMaker, but they've made some utf8 handling changes that possibly fix this (and/or allow it to be fixed more appropriately).

[ryandesign (Ryan Carsten Schmidt)]

But we also don't have a dependency on p5-extutils-makemaker in these ports. I'm for using -locale C in the perl5 portgroup for now.

[mojca (Mojca Miklavec)]

Oh ... I always thought that döt Net was just an obfuscation method to confuse spammers and that it meant the .net part in his email address. I didn't notice until now that it's actually part of his official name.

[danielluke (Daniel J. Luke)]

Replying to ryandesign@…:

But we also don't have a dependency on p5-extutils-makemaker in these ports.

yeah, we could add one if/when a fixed ExtUtils::MakeMaker appears, though.

I'm for using -locale C in the perl5 portgroup for now.

Me too, I just verified it fixes the issue with p5-spiffy as well. I'm going to go ahead an commit the perl5 portgroup change and then remove the patch from p5-spiffy.

[mojca (Mojca Miklavec)]

If p5-extutils-makemaker is some semi-universal dependency – wouldn't it make sense to add it to the PortGroup?

[danielluke (Daniel J. Luke)]

Replying to dluke@…:

Me too, I just verified it fixes the issue with p5-spiffy as well. I'm going to go ahead an commit the perl5 portgroup change

r123724

and then remove the patch from p5-spiffy

r123725

[mf2k (Frank Schima)]

Thanks everyone for figuring out and fixing this so fast!

[ryandesign (Ryan Carsten Schmidt)]

Replying to mojca@…:

If p5-extutils-makemaker is some semi-universal dependency – wouldn't it make sense to add it to the PortGroup?

ExtUtils::MakeMaker is one perl module build system, which uses a file Makefile.PL and is the default in the MacPorts perl5 portgroup. The other perl module build system is Module::Build which uses a file Build.PL and is activated by setting perl5.use_module_build. If we were to add a universal dependency on p5-extutils-makemaker, it would have to exclude p5-extutils-makemaker itself and all of its dependencies and any ports using perl5.use_module_build. I guess the reason why we don't have the dependency currently is that each perl port ships with a copy of ExtUtils::MakeMaker and thus far that version was thought to be sufficient. I see there are 9 ports that do depend on p5-extutils-makemaker...