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

Attachment: signature.asc
Description: Digital signature

Reply via email to