reassign 740476 chromium-browser retitle 740476 chromium-browser: FTBFS since file fixed a bug in file >= 5.04, file < 5.17 tags 740476 patch thanks
Michael Gilbert wrote... > The latest update to file leads to a chromium build failure: > https://buildd.debian.org/status/fetch.php?pkg=chromium-browser&arch=i386&ver=32.0.1700.123-2&stamp=1392729354 > > Downgrading to 5.14 solves the problem. That took a while, mostly downloading and unpacking the huge chromium sources. What actually went wrong: The build system calls ../build/linux/python_arch.sh /usr/lib/libpython2.6.so.1.0 and that one calls file(1) which fails (and did so before) for ENOFILE: + file --dereference /usr/lib/libpython2.6.so.1.0 + file_out=/usr/lib/libpython2.6.so.1.0: ERROR: cannot open `/usr/lib/libpython2.6.so.1.0' (No such file or directory) The odd part is this file does not exist in the file system anyhow, since * Debian unstable moved to 2.7 (2.6 is hard coded in src/build/common.gypi), and * additionally libpython2.7.so.1.0 has been moved to /usr/lib/<triple>/. So this check doesn't make sense, figuring out why it's done at all and whether it should be adjusted to the current file system layout is left as exercise to the reader. *However* python_arch.sh assumes file(1) exits non-zero upon ENOFILE. This was true for file from 5.04 on and before 5.17, but was a bug since it was in violation of | If the file named by the file operand does not exist, cannot be | read, or the type of the file named by the file operand cannot be | determined, this shall not be considered an error that affects the | exit status. [ http://pubs.opengroup.org/onlinepubs/007904975/utilities/file.html ] See the file(1) ticket at <http://bugs.gw.com/view.php?id=316> for a longer discussion. How to fix: Upstream added a new option that restores the non-zero exit behaviour of file(1), the patch below applies this to python_arch.sh. I didn't do a complete build for full verification, but can confirm the build got beyond that critical point now. This patch however might be a work-around. In your (chromium-browser maintainer) position I'd do a check whether build/gyp_chromium should rather provide the right libpython2.X.* path. Christoph commit d4926c4f9e8171b4edd931033759d57a7ded5116 Author: Christoph Biedl <debian.a...@manchmal.in-ulm.de> Date: Sun Mar 2 12:19:36 2014 +0100 Fix FTBFS with file >= 5.17. Closes: #740476 diff --git a/debian/control b/debian/control index 285b01e..f9bb162 100644 --- a/debian/control +++ b/debian/control @@ -80,6 +80,7 @@ Build-Depends: libjs-excanvas, libjs-jquery-tablesorter, libjs-jquery-flot | libjs-flot, + file (>= 1:5.17), Built-Using: libjs-jquery, libjs-excanvas, diff --git a/debian/patches/exit-nonzero-on-file-error.patch b/debian/patches/exit-nonzero-on-file-error.patch new file mode 100644 index 0000000..0275e5c --- /dev/null +++ b/debian/patches/exit-nonzero-on-file-error.patch @@ -0,0 +1,11 @@ +--- a/src/build/linux/python_arch.sh ++++ b/src/build/linux/python_arch.sh +@@ -10,7 +10,7 @@ + # python_arch.sh /path/to/sysroot/usr/lib/libpython2.4.so.1.0 + # + +-file_out=$(file --dereference "$1") ++file_out=$(file -E --dereference "$1") + if [ $? -ne 0 ]; then + echo unknown + exit 0 diff --git a/debian/patches/series b/debian/patches/series index 6162e40..bd0d921 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -20,3 +20,4 @@ ps-print.patch window-placement.patch no-promo.patch chromedriver-revision.patch +exit-nonzero-on-file-error.patch
signature.asc
Description: Digital signature