GNOME Bugzilla – Bug 464474
intltool-update -m broke in 0.36.0
Last modified: 2007-08-08 13:57:18 UTC
Hi, Michael Biebl reported in Debian bug http://bugs.debian.org/436447: """ After upgrading to 0.36.0 from 0.35.4, I can't successfully run "intltool-update -m" anymore for one of my projects. The error message is: ======================================================================= srcdir=../../po ../intltool-update -m Use of uninitialized value in concatenation (.) or string at ../intltool-update line 308, <FILE> line 65. Use of uninitialized value in concatenation (.) or string at ../intltool-update line 308, <FILE> line 65. Use of uninitialized value in concatenation (.) or string at ../intltool-update line 308, <FILE> line 135. Use of uninitialized value in concatenation (.) or string at ../intltool-update line 308, <FILE> line 135. Use of uninitialized value in concatenation (.) or string at ../intltool-update line 308, <FILE> line 68. ... Use of uninitialized value in concatenation (.) or string at ../intltool-update line 308, <FILE> line 3. The following files contain translations and are currently not in use. Please consider adding these to the POTFILES.in file, located in the po/ directory. _build/src/tracker-preferences/tracker-preferences.desktop.in _build/src/tracker-search-tool/tracker-search-tool.desktop.in _build/trackerd.desktop.in If some of these files are left out on purpose then please add them to POTFILES.skip instead of POTFILES.in. A file 'missing' containing this list of left out files has been written in the current directory. ======================================================================= The three files, mentioned above are listed in po/POTFILES.skip Downgrading to intltool 0.35.4 makes intltool-update -m work again. """ Line 308 of intltool-update is the last return of: sub isNotValidMissing { my ($file) = @_; return if $file =~ /^\{arch\}\/.*$/; return if $file =~ /^$varhash{"PACKAGE"}-$varhash{"VERSION"}\/.*$/; } Bye,
This happens with "make distcheck" in the tracker module.
Created attachment 93246 [details] [review] Also check for configure.ac and not only configure.in in one code path Fixes the warnings, but not the bug; seemed to happen with configure.ac + srcdir != builddir, but didn't check the exact conditions.
Fixed in SVN.
Unfortunately it's not fixed; you only fixed the warnings like I did. I diagnosed the bug a bit further, and the bug is present since the addition of this find: + find sub { + push @buf_i18n_plain, "$File::Find::name" if /\.($buildin_gettext_support)$/; + push @buf_i18n_xml, "$File::Find::name" if /\.($xml_support)$/; + push @buf_i18n_ini, "$File::Find::name" if /\.($ini_support)$/; + push @buf_i18n_xml_unmarked, "$File::Find::name" if /\.(schemas(\.in)+)$/; + }, "$SRCDIR/.."; in FindLeftoutFiles(). The problem here is that the build dir during make distcheck is: /home/lool/svn/gnome/tracker/tracker-0.6.0/_build and the srcdir passed to intltool is /home/lool/svn/gnome/tracker/po So the find runs on /home/lool/svn/gnome/tracker ($SRCDIR/..) and finds files below /home/lool/svn/gnome/tracker/tracker-0.6.0/_build which have not been processed (which is normal).
I've added a special case for the _build directory in intltool-update.in.in. During distcheck the srcdir passed to intltool is /home/lool/svn/gnome/tracker/tracker-0.6.0/po and not /home/lool/svn/gnome/tracker/po. But with the special casing, it will strip the "_build/" from the path name, and allows distcheck to pass here. "Fixed" I think it would be better if tracker did the substitution for @VERSION@ in the .desktop files during build time, rather than configure time though. I was having trouble making it work with distcheck when I tried it really quickly though. For some reason it claims there's no rule to build the target, but this might just be an issue with how the build order occurs during distcheck, which would be an automake issue.
Fixes the problem here, but I suppose only for the case where builddir = _build.
This is the only case where it breaks distcheck. And given the request in bug #389561 we have to be able to find files in $builddir. I think special casing _build is a sufficient solution, until we can get all of these requests fixed properly.