Control: tags -1 - unreproducible
Control: tags -1 + patch
On Sat, 08 Dec 2018 at 15:31:12 +0100, Andreas Henriksson wrote:
> Tags: patch unreproducible
(That's not what the unreproducible tag means: it's about whether we can
reproduce the bug, not about whether the package builds reproducibly.
For builds being reproducible or not, the reproducible-builds team have
various usertags, which are already set on this particular bug.)
On Mon, 10 Dec 2018 at 18:02:09 +0000, Ian Jackson wrote:
> Emacs likes plugins to be byte-compiled because that's much faster.
> The bytecode is not compatible between various emacs versions and
> forks. So on Debian, Emacs plugins are byte-compiled on installation.
>
> Often this can be done quite simply but vm is an old and complicated
> package. The upstream Makefile is what knows how to byte compile it,
> and it expects to do interesting things.
>
> So the solution chosen in the Debian package is to ship the upstream
> Makefile into the package, and run it at install time (from the Debian
> emacsen-common hook machinery, which is what initiates byte
> compilation).
That's all reasonable, but this is not how an Autotools build system is
generally designed to be used: the generated Makefiles are not generally
intended to be portable between source/build tree locations on the same
machine, never mind portable between machines. vm is already carrying
patches to lisp/Makefile.in to make it portable between filesystem
locations by replacing @abs_builddir@ with `pwd`, for example.
The more a package diverges from how its upstream intended it to be built,
the more build-system patches it is going to have to carry, and I don't
think that's really an upstream bug.
> > On Sat, Dec 08, 2018 at 09:00:53PM +0000, Ian Jackson wrote:
> Andreas Henriksson writes ("Bug#915955: vm: may embed undesired paths when
> built in local environment"):
> > It is the documented autotools solution, so basically what you're
> > saying is that you don't like autotools. I'm not a big fan of it myself
> > so won't argue with you on that.
[...]
> It would be sufficient to observe that this behaviour is
> not useful *when autotools is invoked in a Debian package build* and
> that therefore there should be a way to avoid it.
>
> I'm sorry to say that I don't have any effort available for tackling
> this in autoconf.
Please see attached.
The first patch (0002-*) applies cleanly after the one I sent to #992783,
but could easily be adjusted to be independent. Alternatively, you could
use dh-autoreconf if you prefer a more thorough rebuild from the preferred
form for modification, but dh-autoreconf is sufficiently widespread and
well-known that I assume you're more likely to be deliberately avoiding
it in this particular package, so I've erred on the side of minimalism.
For the uses of AC_PATH_PROG, if you don't want an absolute path,
then AC_PATH_PROG is the wrong macro. Patch 0003-* changes these to
AC_CHECK_PROG. I would personally not send this upstream if I was the
maintainer, because the fact that absolute paths are undesirable here
is a result of Debian-specific changes to the way it is installed -
but if you think you can justify this change to upstream, you're welcome
to rewrite the commit message to an upstream-suitable justification and
move my name to a Co-authored-by tag.
As an alternative to 0002-* and 0003-*, passing RM=rm, etc. to
configure might also work - I don't think AC_PATH_PROG *enforces* that
a caller-supplied path is absolute.
For AC_PROG_INSTALL, as a result of some unfortunate Unix retrocomputing
around install(1) being non-standard and ./install-sh being safe-but-slow,
I don't really see an upstream-suitable solution: AC_PROG_INSTALL
always finds an absolute path, and INSTALL=install is interpreted as
meaning ${top_srcdir}/install. I think patching the Makefile.in in a
Debian-specific way (patch 0004-*), as you and Manoj did in the past to
deal with @abs_builddir@, is probably going to be the cleanest answer.
I've built the resulting packages and put them through piuparts, but not
otherwise tested them (I don't use Emacs or vm).
smcv
>From b7244f821e041bd1e22ff950b7ebadc539fa53ed Mon Sep 17 00:00:00 2001
From: Simon McVittie <[email protected]>
Date: Mon, 23 Aug 2021 12:07:11 +0100
Subject: [PATCH 2/4] d/control, d/rules: Re-run autoconf
Otherwise changes to configure.ac will not take effect.
Signed-off-by: Simon McVittie <[email protected]>
---
debian/control | 2 +-
debian/rules | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/debian/control b/debian/control
index 62b812a..d12fb36 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Priority: optional
Maintainer: Ian Jackson <[email protected]>
Standards-Version: 3.9.6
Build-Depends: debhelper (>= 9.0.0), autotools-dev
-Build-Depends-Indep: emacs-nox | emacs25-nox | emacs25 | emacs24,
+Build-Depends-Indep: autoconf, emacs-nox | emacs25-nox | emacs25 | emacs24,
texinfo, texlive-latex-base, texlive-fonts-recommended
Package: vm
diff --git a/debian/rules b/debian/rules
index b3a4db5..a814fcb 100755
--- a/debian/rules
+++ b/debian/rules
@@ -47,6 +47,7 @@ DOCDIR = $(TMPTOP)$(P_DOCDIR)
override_dh_auto_configure:
+ autoreconf
dh_auto_configure -- --verbose --sysconfdir=/etc \
--with-pixmapdir=$(P_PIXMAPDIR)
--
2.33.0
>From 6a3184b9183c52415c18b06ba9e531a3403c0e0d Mon Sep 17 00:00:00 2001
From: Simon McVittie <[email protected]>
Date: Mon, 23 Aug 2021 11:17:51 +0100
Subject: [PATCH 3/4] Don't hard-code (most) absolute paths in lisp/Makefile
AC_PATH_PROG discovers the absolute path of a tool, but this is not
desirable if vm's Debian package is built on a system where PATH will
find a non-standard implementation of these tools, such as
/usr/local/bin/rm or /home/me/.bin/ls. lisp/Makefile gets installed into
the Debian package, but even if the system doing the build has those
non-standard paths, that doesn't mean the system where the package is
installed will also have them.
These variables don't actually need to be set to absolute paths if we
can assume that a PATH search will find some suitable implementation,
both on the build system and on the installed system. If an absolute
path is not desired, then AC_PATH_PROG is the wrong macro, and
AC_CHECK_PROG is more appropriate.
Closes: #915955
Signed-off-by: Simon McVittie <[email protected]>
---
configure.ac | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac
index 11e4331..66b1d5b 100755
--- a/configure.ac
+++ b/configure.ac
@@ -260,10 +260,10 @@ AC_CONFIG_FILES([Makefile lisp/Makefile info/Makefile src/Makefile pixmaps/Makef
AC_PROG_MAKE_SET
AC_PROG_INSTALL
AC_PROG_LN_S
-AC_PATH_PROG(RM, rm, /bin/rm)
-AC_PATH_PROG(LS, ls, /bin/ls)
-AC_PATH_PROG(MKDIR, mkdir, /bin/mkdir)
-AC_PATH_PROG(GREP, grep, /bin/grep)
+AC_CHECK_PROG([RM], [rm], [rm], [/bin/rm])
+AC_CHECK_PROG([LS], [ls], [ls], [/bin/ls])
+AC_CHECK_PROG([MKDIR], [mkdir], [mkdir], [/bin/mkdir])
+AC_CHECK_PROG([GREP], [grep], [grep], [/bin/grep])
# External programs checking:
VM_PROG_XARGS
--
2.33.0
>From 02749493ff86ebe4d60ab2501806a7c4a9c8d016 Mon Sep 17 00:00:00 2001
From: Simon McVittie <[email protected]>
Date: Mon, 23 Aug 2021 11:54:01 +0100
Subject: [PATCH 4/4] Don't hard-code absolute path to install(1) in
lisp/Makefile
Using its absolute path is not desirable if vm's Debian package is
built on a system where PATH will find a non-standard implementation of
install(1), such as /usr/local/bin/install or /home/me/.bin/install.
lisp/Makefile gets installed into the Debian package, but even if the
system doing the build has one of those non-standard paths, that doesn't
mean the system where the package is installed will also have it.
For AC_PROG_INSTALL, there is no direct equivalent of AC_CHECK_PROG that
defers the PATH search, and passing INSTALL=install to ./configure
doesn't work either, because for historical reasons related to
install-sh, AC_PROG_INSTALL assumes that if ${INSTALL} is not an
absolute path then it should be taken to be relative to the top-level
source directory.
We know that Debian systems have GNU coreutils install(1), so we can
write a suitable implementation here directly.
Closes: #915955
Signed-off-by: Simon McVittie <[email protected]>
---
lisp/Makefile.in | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lisp/Makefile.in b/lisp/Makefile.in
index dd0d5d8..8d94532 100755
--- a/lisp/Makefile.in
+++ b/lisp/Makefile.in
@@ -85,10 +85,10 @@ AUTOLOAD_FILE = (setq generated-autoload-file \"./auto-autoloads.el\")
RM = @RM@
LS = @LS@
XARGS = @XARGS@
-INSTALL = @INSTALL@
-INSTALL_PROGRAM = @INSTALL_PROGRAM@
-INSTALL_SCRIPT = @INSTALL_SCRIPT@
-INSTALL_DATA = @INSTALL_DATA@
+INSTALL = install
+INSTALL_PROGRAM = install
+INSTALL_SCRIPT = install
+INSTALL_DATA = install -m644
prefix = @prefix@
top_srcdir = @top_srcdir@
--
2.33.0
