intltool fails on reportedly bad regexp

[Alex Launi]

When I run intltool-update -m on my project, it crashes with this error message:
Invalid [] range "F-8" in regex; marked by <-- HERE in m/[encoding: UTF-8 <-- HERE ]
at /usr/bin/intltool-update line 321, <FILE> line 1.

It works fine on other files which have an identical hexdump up until the point where files start getting listed.

[Alex Launi (alexlauni)]

The POTFILES.in in question

[Félix Velasco (felix-velasco)]

intltool-update uses "encoding: UTF-8", or anything else in $file as a regexp without properly escaping special characters. Using quotemeta for escaping it works (see attached patch)

[Данило Шеган (danilo)]

I am unable to reproduce this with perl 5.10.0 on Ubuntu GNU/Linux. Can you let me know how this fails for you (i.e. what system, Perl version; I am assuming latest intltool version) so we know exactly who is affected. The proposed fix looks benign (well, more than that, it looks good), so I'd be happy to apply it as soon as I get more information about why it happens.

[Félix Velasco (felix-velasco)]

I'm reproducing it in Karmic, with perl 5.10.0 and intltool 0.41.0-0ubuntu1. The easiest way is to try to build gnome-do from the repos:

$ apt-get source gnome-do
$ cd gnome-do-0.8.2+dfsg/
$ dpkg-buildpackage -b

For me, that launches a failed build, that ends with:

INTLTOOL_EXTRACT=/usr/bin/intltool-extract srcdir=. /usr/bin/intltool-update --gettext-package gnome-do --pot
rm -f missing notexist
srcdir=. /usr/bin/intltool-update -m
Invalid [] range "F-8" in regex; marked by <-- HERE in m/[encoding: UTF-8 <-- HERE ]
/ at /usr/bin/intltool-update line 321, <FILE> line 1.
make[2]: *** [check] Error 2
...
dpkg-buildpackage: error: debian/rules build entregó error de estado de salida 2

[Y.Z. (y-zinch)]

I can confirm same issue. Karmic, perl 5.10, intltool 0.41. Getting same problem when trying to build Gnome-Do

[Félix Velasco (felix-velasco)]

Danilo, are you still unable to reproduce it?

[dobey (dobey)]

Can you attach a test case that fails without your patch, and that works
with your patch, so that we can have a regression test? This will show
what exactly is failing, and let us determine if your fix is the right
one or if we should be doing something else instead. Thanks.

On Mon, 2010-03-08 at 14:48 +0000, Félix Velasco wrote:
> Danilo, are you still unable to reproduce it?

[Félix Velasco (felix-velasco)]

You mean, besides the steps of comment #4?

[dobey (dobey)]

"I have a problem building Gnome Do" isn't a test case. It's a statement
of personal difficulty. It doesn't specify or reproduce what is failing.

On Mon, 2010-03-08 at 16:34 +0000, Félix Velasco wrote:
> You mean, besides the steps of comment #4?

[Félix Velasco (felix-velasco)]

I think you're confusing comments #4 and #5, but anyway, I'm attaching a rather minimal test case.
Uncompress the attached file, and, from within the created po directory, run "intltool-update -m". Fails without the patch, works with it.

[Данило Шеган (danilo)]

It doesn't fail for me. Are you perhaps using some special perl parameters to make it not escape these by default?

[Данило Шеган (danilo)]

Btw, a minimal test case would have been POTFILES.in with just the [encoding] line.

Also, what happens on your systems with lines like [gettext/xml]something.xml.in (when something.xml.in exists or doesn't exist, both with your patch and without)?

[Данило Шеган (danilo)]

Ok, I've figured out what the problem is: it's not POTFILES.in at all, but POTFILES.skip: I sometimes can reproduce it, but not at all times. It probably relates to actual files existing or not.

intltool has never supported []-tags in POTFILES.skip, so that's a problem in the package (and why should it? encoding is relevant only if you are going to actually parse the file, not skip or ignore it). FWIW, the correct patch to change this would have been the attached one, but I am not considering this a bug.