Re: About a mass bug report not based on Sid or Jessie.
+++ Charles Plessy [2014-04-15 08:15 +0900]:
> Le Mon, Apr 14, 2014 at 05:12:32PM +0200, Matthias Klose a écrit :
> >
> > it would be much more productive for Debian if you wouldn't claim wrong things
> > and start fixing the issue in at least this package. The mass-filing proposal
> > was sent in January to this very list. It's not my problem if you don't read
> > this list or ignore proposals for mass bug filings.
> >
> > The bug itself (#744664) is not fixed in 1.13.5-1.1, the issue that you merged
> > back (thanks for this) was a build failure on arm64. This is a build failure on
> > ppc64el. The reason for this are outdated libtool.m4 and/or aclocal.m4 files,
> > resulting in shared libraries not being built. Please note that exactly this is
> > mentioned in the bug report. You did close it apparently without reading. And
> > without fixing.
>
> Hi Matthias,
>
> Thanks for your post in January (https://lists.debian.org/52D81606.4030701@debian.org).
>
> Next time, please consider adding such an URL near the top of the bug report
> instead of expecting people to remember that the bug they see in April with a
> package version from November is related to a mass filing proposed in January…
>
> I indeed noted that the patch sent uses autoreconf instead of dh_autotools-dev,
> but your email states:
>
> “The package fails to build on ppc64el (powerpc64le-linux-gnu), because
> the config.{guess,sub} files are out of date”
>
> The only mention of libtool.m4 is, further down in the message:
>
> “After the build on any architecture, and before a clean, a grep for
> powerpc64le in the configure, aclocal.m4 and/or libtool.m4 file(s)
> should print some lines. It is not enough to just update the
> config.guess and config.sub files.”
The QA page mentionned there
https://wiki.debian.org/qa.debian.org/FTBFS is very useful, but I know
that I would like to see more explicit advice on how to determine
whether autotools-dev alone is sufficient (because there is no libtool
useage in the package), or when dh_autoreconf is needed.
I think your average package maintainer is pretty vague about this
stuff and thus defaults to leaving well alone.
And equally documented the rare cases where both are needed.
or perhaps we should collectively decide that dh-autoreconf should
just be used everywhere unles there is a damn good reason not to?
> Nevertheless, with these mass filings where we add en masse the same option to
> many packages, I wonder if we are doing something wrong. Don't we use
> debhelper and CDBS to have reasonable defaults ?
Neither debhelper nor CDBS does an autreconf by default. CDBS does do
config.{sub,guess} updating by default, but only is autotools-dev is
installed (and that a recommends, not a depends, so by default on
buildds it does not do this). I intend to file a bug about that
because this defaults to not working for porters (unless they
pre-install autotools-dev in their 'clean' chroots).
dh/debhelper does not do the config.{sub,guess} updating at all unless asked.
> Are there more packages that
> fail to build after autoreconf, than packages that fail to build without ?
For a new port that needs config.{sub,guess} updates, the answer is always no.
If we start autoreconf-ing by default then everything will work with
autoreconf anyway (because it always gets tested) so everything will
work with new ports too. We have nothing to lose SFAICS apart from
having to fix up some packages that currently only work with old
autofoo.
We currently have 3 new ports in progress (arm64, ppc64el and or1k)
which would all benefit from this.
As I have become fond of pointing out, we bootstrap new ports twice as
often as we release, so making that easier should be a stronger focus
than it has historically been. autoreconfing, or at least
config.{sub,guess} updating by default should be at least best
practice, if not policy.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: