[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#505976: marked as done (FTBFS: PACKAGE_VERSION in configure is corrupted by excess make spew)

Your message dated Sun, 6 Jun 2010 09:56:42 +0200
with message-id <20100606075642.GS3043@radis.liafa.jussieu.fr>
and subject line Re: Bug#505976: FTBFS: PACKAGE_VERSION in configure is corrupted by excess make spew
has caused the Debian Bug report #505976,
regarding FTBFS: PACKAGE_VERSION in configure is corrupted by excess make spew
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
505976: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505976
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: mesa
Version: 7.2-1
Severity: normal

The invocation of make being used in configure.ac to generate
mesa_version (which later goes into PACKAGE_VERSION in configure) is
missing a --no-print-directory switch. The lack of --no-print-directory
is resulting in the following line in the generated configure:

PACKAGE_VERSION='make2: Entering directory `/root/mesa-7.2'7.2.0make2: Leaving directory `/root/mesa-7.2''

Subsequently, all kinds of badness happens when attempts are made to use
this malformed configure script.

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'

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.27-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

--- End Message ---
--- Begin Message --- 
On Sat, Jun  5, 2010 at 22:06:09 -0400, EspeonEefi wrote:

> 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.
> 
OK, I'll close the bug then.

> 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?
> 
I doubt it, we only changed the 'install' target...

> [...]

> 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.
> 
Indeed :/

We'll reopen if this appears again in the future, thanks for your report
and followup.

Cheers,
Julien

Attachment: signature.asc
Description: Digital signature


--- End Message ---
Reply to: