Bug#746450: dpkg-dev: New make breaks dpkg-buildpackage test for existence of targets

2014-04-30 Thread Manoj Srivastava
Package: dpkg-dev
Version: 1.17.8
Severity: normal
Control: block 746443

Hi,

A new version of Make has been released, and is currently in
 experimental. An archive rebuild was done to check for breakage with
 this new major version.  73 packages failed to build  (in comparison
 with a similar run with the current version of make). The results are
 here: http://aws-logs.debian.net/ftbfs-logs/results-make4/

Of the 73 packages that failed, 10 were due to a known
 incompatibility, which has been fixed. About 20 or so were due to
 various issues i the package, unrelated to this report. However, 40
 packages failed to build due to the new make is not doing the expected
 thing when called as:  make -f debian/rules -qn build-arch

(And by expected is return 2 when not found, any other return
 code otherwise). Since dpkg-buildpackage cannot ascertain that
 'build-arch' and 'build-indep' targets exist, it calls build, and does
 not load B-D-I first. 40 packages fail to build due to this phenomena
 (list appended).

The options, as I see it are:
 1) Do nothing. retain make-3.81 in Debian forever more. Needless to
say, this is not very attractive. Pro: There is no action to
take. Con: Almost every other distro is shipping a more recent
make. We will continue to diverge from everyone else, and already
the featires have diverged enough that people are having to add
special cases in the vuild system for the Debian family of
distributions.
 2) Hack dpkg-buildpackage to always load B-D-I, and go back to just
calling ./debian/rules build. This is what we used to do. Pro: it
is pretty easy to do (umm, I would think, but I don't know the dpkg
code base so well anymore). This has the con of the inefficiency we
have tried to eliminate, in that all the build dependencies are
loaded for every build, even when not strictly needed.
  3) We state that packages must provide build-arch and build-indep for
 Jessie. This should trivially be true for every package using cdbs
 or debhelper (or, heaven forbid, my old home brew build system),
 and have dpkg-buildpackage call them without testing to see if they
 exist.  We would need to do another archive rebuild with the
 modified dpkg-buildpackage to see how many packages do not
 actually not implement these targets.

1) and 2) look to be unacceptable. 3) is where we want to be. I
 have blocked migration of make_4.0 with a serious bug report, and will
 make this bug block it,

Ideally, we should just bite the bullet and demand that all
 packages implement the build-arch and build-indep targets, and call
 them without testing for them as needed. An experimental build of
 dpkg-dev could be used to do a full archive rebuild to see how that
 shakes out.

apt_1.0.1
aspectc++_1.2-1
cernlib_20061220+dfsg3-4
csound_6.02~dfsg-2
dhcpcd_3.2.3-11
geant321_3.21.14.dfsg-11
gecode_4.2.1-1
gimp-dimage-color_1.1.0-3.2
git_1.9.2-1
gwhere_0.2.3.dfsg.1-4
gzip_1.6-3
haskell-tasty-golden_2.2.0.2-1
haskell-terminal-progress-bar_0.0.1.3-1
krb5_1.12.1+dfsg-1
libgksu_2.0.13~pre1-6
libreoffice_4.1.5-2
libusb-1.0_1.0.18-2
libusbx_1.0.17-1
lletters_0.1.95+gtk2-3.2
lpe_1.2.6.13-0.1
mclibs_20061220+dfsg3-3
mingw-w64_3.1.0-1
openjade1.3_1.3.2-12
openjade_1.4devel1-21
opusfile_0.5-1
paw_2.14.04.dfsg.2-9
plucker_1.8-34
portaudio_18.1-7.1
postgis_2.1.2+dfsg-2
pulseaudio_5.0-2
r-cran-base64enc_0.1-1-2
r-cran-maldiquant_1.10-1
readahead-fedora_1.5.6-5
sdcc_3.3.0+dfsg-1
slmon_0.5.13-2.2
socks4-server_4.3.beta2-18
speex_1.2~rc1.1-1
spellutils_0.7-5
xnee_3.18-1
xz-utils_5.1.1alpha+20120614-2

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

Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dpkg-dev depends on:
ii  base-files7.2
ii  binutils  2.24.51.20140425-1
ii  bzip2 1.0.6-5
ii  libdpkg-perl  1.17.8
ii  make  4.0-2
ii  patch 2.7.1-5
ii  xz-utils  5.1.1alpha+20120614-2

Versions of packages dpkg-dev recommends:
ii  bcc [c-compiler] 0.16.17-3.1
ii  build-essential  11.6
ii  fakeroot 1.20-3
ii  gcc [c-compiler] 4:4.8.2-3
ii  gcc-4.4 [c-compiler] 4.4.7-8
ii  gcc-4.5 [c-compiler] 4.5.4-1
ii  gcc-4.6 [c-compiler] 4.6.4-7
ii  gcc-4.7 [c-compiler] 4.7.3-13
ii  gcc-4.8 [c-compiler] 4.8.2-21
ii  gcc-4.9 [c-compiler] 4.9.0-1
ii  gnupg1.4.16-1.1
ii  gnupg2   2.0.22-3
ii  gpgv 1.4.16-1.1
ii  libalgorithm-merge-perl  0.08-2

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2014.04.25

-- no debconf information

-- 
character density, n.: The number of very weird people in the office.
Manoj Srivastava 

Bug#746450: dpkg-dev: New make breaks dpkg-buildpackage test for existence of targets

2014-04-30 Thread Raphael Hertzog
Hi,

On Wed, 30 Apr 2014, Manoj Srivastava wrote:
 Of the 73 packages that failed, 10 were due to a known
  incompatibility, which has been fixed. About 20 or so were due to
  various issues i the package, unrelated to this report. However, 40
  packages failed to build due to the new make is not doing the expected
  thing when called as:  make -f debian/rules -qn build-arch

Why is this broken by the new make?

Doesn't debhelper have a similar problem when trying to detect whether
override_dh_foo targets are present? If not maybe the right thing to do is
to fix our detection to work like the one used in debhelper...

 The options, as I see it are:

4) Fix the code detecting target availability to work with the new make.

 Ideally, we should just bite the bullet and demand that all
  packages implement the build-arch and build-indep targets, and call
  them without testing for them as needed. An experimental build of
  dpkg-dev could be used to do a full archive rebuild to see how that
  shakes out.

Indeed but I fear the list will be much bigger than the few that you found
out with the current situation.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#746450: dpkg-dev: New make breaks dpkg-buildpackage test for existence of targets

2014-04-30 Thread Manoj Srivastava
On Wed, Apr 30 2014, Raphael Hertzog wrote:

 On Wed, 30 Apr 2014, Manoj Srivastava wrote:
 Of the 73 packages that failed, 10 were due to a known
  incompatibility, which has been fixed. About 20 or so were due to
  various issues i the package, unrelated to this report. However, 40
  packages failed to build due to the new make is not doing the expected
  thing when called as:  make -f debian/rules -qn build-arch

 Why is this broken by the new make?

I have not yet found a pattern that I can identify.

 Doesn't debhelper have a similar problem when trying to detect whether
 override_dh_foo targets are present? If not maybe the right thing to do is
 to fix our detection to work like the one used in debhelper...

Indeed, I have not seen any evidence, either in the failed
 archive build logs, or on my development machine, that dh is having any
 issues discovering whether the an override target exists or not. I
 understand it processes the output from make.

 4) Fix the code detecting target availability to work with the new make.

From IRC, i think dh looks at make -n output like so:
 return defined $output  length $output 
$output !~ /\*\*\* No rule to make target (`|')\Q$target\E'/;

Presumably after setting the locale to C or something.

manoj
-- 
Which is worse: ignorance or apathy?  Who knows?  Who cares?
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/  
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


signature.asc
Description: PGP signature