#357066 read DEBUILD_LINTIAN_OPTS from devscripts confs

#357066#5
Date:
2006-03-15 15:27:38 UTC
From:
To:
The file /etc/devscripts.conf provides a few variables which might be
useful for e.g. pdebuild too. In the section 'debuild', there are these
four variables which I consider very useful for me:

DEBUILD_LINTIAN=yes
DEBUILD_LINDA=yes
DEBUILD_LINTIAN_OPTS="..."
DEBUILD_LINDA_OPTS=".."

Is ther a way to add native support for these variables (without using
hooks), so users can specify globally (via pbuilderrc) to run lintian
and/or linda after package build process?

Regards, Daniel


- -- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (850, 'unstable'), (700, 'testing'), (550, 'stable'), (110, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15.02060113
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)

Versions of packages pbuilder depends on:
ii  cdebootstrap                  0.3.11     Bootstrap a Debian system
ii  coreutils                     5.94-1     The GNU core utilities
ii  debianutils                   2.15.3     Miscellaneous utilities specific t
ii  debootstrap                   0.3.3      Bootstrap a basic Debian system
ii  gcc                           4:4.0.2-2  The GNU C compiler
ii  wget                          1.10.2-1   retrieves files from the web

Versions of packages pbuilder recommends:
ii  devscripts                    2.9.15     Scripts to make the life of a Debi
ii  fakeroot                      1.5.7      Gives a fake root environment
ii  sudo                          1.6.8p12-1 Provide limited super user privile

- -- no debconf information
iD8DBQFEGDJqdg0kG0+YFBERAiuKAJwI8czm0GXal2GtC+flPo4VplR73wCfTLsW
Bm233jbBK1iMBRZyHq7v6uU=
=QMi5
-----END PGP SIGNATURE-----

#357066#10
Date:
2006-03-16 12:20:13 UTC
From:
To:
Hi,

I was thinking along the lines of making default hooks.  The hooks
potentially can process the config vars (there is a problem that those
config vars are outside of chroot, but the general idea is this).

regards,
	junichi

#357066#17
Date:
2008-09-27 17:46:47 UTC
From:
To:
tags 357066 + patch
thanks

Hi there!
hook.

I've used the following patch for at least one year:
--8<---------------cut here---------------start------------->8---
--- pdebuild.~1~	2008-09-27 19:22:14.000000000 +0200
+++ pdebuild	2008-09-27 19:22:40.000000000 +0200
@@ -63,6 +63,16 @@
     ${PBUILDERROOTCMD} ${PDEBUILD_PBUILDER} --build ${EXTRA_CONFIGFILE[@]/#/--configfile } --buildresult "${BUILDRESULT}"  --debbuildopts "${DEBBUILDOPTS}" "$@"  ../"${PKG_SOURCENAME}_${PKG_VERSION}".dsc
 fi

+# lintian
+if [ "${AUTO_LINTIAN}" = "yes" ]; then
+    unset LINTIAN_PARAM || true
+    if [ -n "${LINTIAN_OPTS}" ]; then
+	LINTIAN_PARAM[1]="${LINTIAN_OPTS}"
+    fi
+    LINTIAN_PARAM[2]="${BUILDRESULT}/${PKG_SOURCENAME}_${PKG_VERSION}_${ARCHITECTURE}.changes"
+    lintian "${LINTIAN_PARAM[@]}"
+fi
+
--8<---------------cut here---------------end--------------->8---

If there's a possibility to add this support upstream, I can rework the
patch to support devscripts options, as the oritinal submitter asked.
I, for myself, fully agree with Daniel on this point: we should not
duplicate variables, but instead use the existing ones, providing a
better integration between different tools.

Thx, bye,
Gismo / Luca

#357066#24
Date:
2008-09-28 09:35:48 UTC
From:
To:
 First, quick note: linda shouldn't be targetted anymore.

 I personally am not happy with that approach promoted by default
 because it runs lintian on the host.  I agree it's easy and useful to
 do this, but I prefer the approach of running lintian in the build env.
   This is particularly useful when:
 - uploading for another release (preparing an upload for etch from sid,
   or for lenny from sid, or for sid from lenny)
 - uploading for another distro (preparing binaries for Ubuntu from
   Debian)

 I'm using a hook for this (attached).

 I'm happy if we implement both approaches, but I wouldn't like pbuilder
 to push people in relying on tools from the host to build packages
 which might be targetted at something else.