Bug#505976: FTBFS: PACKAGE_VERSION in configure is corrupted by excess make spew
On 06/05/2010 10:53 AM, Julien Cristau wrote:
> On Mon, Nov 17, 2008 at 06:24:27 -0500, EspeonEefi wrote:
[...snip...]
>> The following patch I've found fixes this problem:
>>
>> diff -Naur mesa-7.2.orig/configure.ac mesa-7.2/configure.ac
>> --- mesa-7.2.orig/configure.ac 2008-09-13 20:25:44.000000000 +0000
>> +++ mesa-7.2/configure.ac 2008-11-17 08:21:36.445563599 +0000
>> @@ -4,7 +4,7 @@
>>
>> dnl Versioning - scrape the version from configs/default
>> m4_define([mesa_version],
>> - [m4_esyscmd([${MAKE-make} -s -f bin/version.mk version | tr -d '\n'])])
>> + [m4_esyscmd([${MAKE-make} -s --no-print-directory -f bin/version.mk version | tr -d '\n'])])
>> m4_ifval(mesa_version,[],[
>> m4_errprint([Error: Failed to get the Mesa version from the output of
>> running `make -f bin/version.mk version'
>>
> info make suggests that the -s option turns off --print-directory.
> What's the story here? (Obviously we haven't seen mesa ftbfs because of
> this so far...)
Strangely enough, this seems magically fixed in the most recent version
of mesa in unstable. After trawling through snapshot.debian.org, I was
able to determine that I can reproduce the original FTBFS bug with mesa
7.5.1-1 but not with mesa 7.6-1.
It seems that the main difference between these two package versions was
the removal of parallel building from debian/rules. It seems that
perhaps that removal did something to the environment to cause the above
failure to happen anymore?
Tangentially, another Debian bug that seems to be showing similar
symptoms is bug #584462 [1].
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584462
By the way, if you want to reproduce the problem I was having, the build
procedure I used was
1. Make a new sid chroot with the command
debootstrap --variant=buildd --include=locales mesa evince
http://debian.lcs.mit.edu/debian/
(Unfortunately, because of Debian bug #581420 [2], currently, the first
time you run it, this will fail, but it if you then re-run it without
touching the partially-set-up chroot, it will succeed the second time.)
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581420
2. chroot mesa
3. "dpkg-reconfigure locales" to generate the en_US.UTF-8 locale and set
it to be default to shut up perl errors.
4. Modify /etc/apt/sources.list to add a deb-src entry.
5. apt-get update
6. apt-get --no-install-recommends build-dep mesa
7. Download mesa 7.5.1-1 from [3] into the chroot somewhere and change
to that directory in the chroot.
[3] http://snapshot.debian.org/package/mesa/7.5.1-1/
8. tar xzvf mesa_7.5.1.orig.tar.gz
9. cd mesa-7.5.1
10. gunzip ../mesa_7.5.1-1.diff.gz | patch -p1
11. debian/rules binary
In the output, just after the quilt patch application, you should see
something along the lines of
"""
Now at patch 06_kfreebsd-ftbfs.diff
touch debian/stamp/patch
autoreconf -vfi
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force
configure.ac:15: warning: AC_INIT: not a literal: mesa_version
autoreconf: configure.ac: tracing
configure.ac:15: warning: AC_INIT: not a literal: mesa_version
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf --force
configure.ac:15: warning: AC_INIT: not a literal: mesa_version
autoreconf: configure.ac: not using Autoheader
autoreconf: configure.ac: not using Automake
autoreconf: Leaving directory `.'
dh_testdir
mkdir -p /tmp/mesa-7.5.1/obj-x86_64-linux-gnu/swx11+glu
"""
and then a whole lot of errors.
Anyway, as noted at the beginning of this email, I can no longer
reproduce this bug with the newest mesa version in unstable (and in
fact, 7.6-1 also seems to work just fine as well), so feel free to close
this bug. It is a bit frustrating not to understand the underlying
reasons why the change in build procedure between 7.5.1-1 and 7.6-1 made
this problem go away, though.
-- eefi
Reply to: