Your message dated Thu, 29 May 2014 05:44:42 +0930
with message-id <[email protected]>
and subject line Re: opus-tools: run dh-autoreconf to update config.{sub,guess}
and {libtool,aclocal}.m4
has caused the Debian Bug report #727481,
regarding opus-tools: run dh-autoreconf to update config.{sub,guess} and
{libtool,aclocal}.m4
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 [email protected]
immediately.)
--
727481: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727481
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: src:opus-tools
Version: 0.1.2-1
Severity: normal
User: [email protected]
Usertags: arm64
The package fails to build on arm64 (aarch64-linux-gnu), because the
config.{guess,sub} files are out of date, and are not updated during
the build. If possible, please do not update these files directly,
but build-depend on autotools-dev instead, and use the tools provided
by autotools-dev to update these files.
- For dh, call dh --with autotools_dev (yes, underscore).
- For other rules files, call dh_autotools-dev_updateconfig before
calling configure (in the build or configure target), and call
dh_autotools-dev_restoreconfig before calling dh_clean in the clean
target.
After the build on any architecture, and before a clean, a grep for
aarch64 in the config.sub file(s) should print some lines.
The full build log can be found at:
http://people.debian.org/~doko/logs/arm64-20131023/logs/buildlog_ubuntu-trusty-arm64.opus-tools_0.1.2-1_FAILEDTOBUILD.txt
The last lines of the build log are at the end of this report.
Please note that these build were done in an Ubuntu development,
environment there may be a few false positives in these bug reports.
[...]
Setting up intltool-debian (0.35.0+20060710.1) ...
Setting up po-debconf (1.0.16+nmu2ubuntu1) ...
Setting up libogg-dev:arm64 (1.3.1-1) ...
Setting up libopus-dev (1.0.3-0ubuntu1) ...
Setting up pkg-config (0.26-1ubuntu4) ...
Setting up python3 (3.3.2-14ubuntu1) ...
running python rtupdate hooks for python3.3...
running python post-rtupdate hooks for python3.3...
Setting up dh-python (1.20131003-1) ...
Setting up apparmor-easyprof (2.8.0-0ubuntu31) ...
Setting up dh-apparmor (2.8.0-0ubuntu31) ...
Setting up debhelper (9.20130921ubuntu1) ...
Processing triggers for libc-bin ...
Checking correctness of source dependencies...
Toolchain package versions: libc6-dev_2.17-93ubuntu4 make_3.81-8.2ubuntu3
dpkg-dev_1.16.12ubuntu1 gcc-4.8_4.8.2-1ubuntu2 g++-4.8_4.8.2-1ubuntu2
binutils_2.23.90.20131017-1ubuntu1 libstdc++-4.8-dev_4.8.2-1ubuntu2
libstdc++6_4.8.2-1ubuntu2
------------------------------------------------------------------------------
gpgv: Signature made Wed Jun 13 00:58:20 2012 UTC using DSA key ID 68021CE4
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./opus-tools_0.1.2-1.dsc
dpkg-source: info: extracting opus-tools in opus-tools-0.1.2
dpkg-source: info: unpacking opus-tools_0.1.2.orig.tar.gz
dpkg-source: info: applying opus-tools_0.1.2-1.diff.gz
dpkg-buildpackage: source package opus-tools
dpkg-buildpackage: source version 0.1.2-1
dpkg-source --before-build opus-tools-0.1.2
dpkg-buildpackage: host architecture arm64
/usr/bin/fakeroot debian/rules clean
dh_testdir
dh_testroot
rm -f *-stamp
rm -f -r objs
dh_clean
debian/rules build-arch
dh_testdir
mkdir -p objs
cd objs && ../configure --host=aarch64-linux-gnu \
--build=aarch64-linux-gnu \
--prefix=/usr
checking git revision... no
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking build system type... Invalid configuration `aarch64-linux-gnu':
machine `aarch64' not recognized
configure: error: /bin/bash ../config.sub aarch64-linux-gnu failed
make: *** [objs/config.status] Error 1
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
--- End Message ---
--- Begin Message ---
So, uhm ...
On Sat, May 24, 2014 at 05:34:42PM +0100, Manuel A. Fernandez Montecelo wrote:
> I plan to upload a NMU to fix this bug. It's pretty straightforward
> and it's affecting some ports being prepared for Debian right now
> (e.g. OpenRISC/or1k, ppc64el)
... this would appear to be a completely false assertion that you don't
appear to have confirmed at all.
> I plan to upload NMUs as well for other opus tools and other packages
> that you maintain, as libogg that I told you a few days ago. These
> packages are preventing hundreds or reverse build-dependencies to
> build cleanly in new arches, and
Uh No. Not only did you apparently completely confuse this package
with libopus, it seems that you didn't actually bother to look at
*either* of them before sending me long dogmatic lectures on how to
solve a problem that doesn't actually exist for them at all right now ...
> thus causing us to do a lot of dull manual work.
... which indeed would appear to be the result of you not even doing
the minimum of diligence checking here :(
> For example, there are 18 reverse build-deps of libopus-dev in main,
> including libav, which in turn has 86 reverse build-depends on main
> for libavcodec-dev alone; etc etc.
Which is all very nice statistics, except for the fact that if libopus
is in fact blocking your port somehow, that would seem to have nothing
to do with the autotools boilerplate being out of date. Since support
for or1k was added to it nearly a year ago now ...
and several of the other new arches for even longer than that.
So if it's really causing you trouble, you're going to have to present
some more actually applicable facts about why that is if you want us
to help you fix them. Please open a new bug, against the correct
package, if that is actually the case here.
> Worse is the case of libogg-dev, which has 77 direct reverse
> build-depends in main.
No, worse is the time we just wasted on a wild goose chase because
you didn't do your homework. Not even to the extent of reading this
particular bug report before proposing a panic-NMU.
AFAICS, the only package of mine that had an outstanding issue with
the new ports you mentioned was libogg. And you could have trivially
fixed that yourself to keep your port moving until a new version was
uploaded by running autoreconf on it and creating a local version for
your port's buildd. For the grand investment of just two minutes of
your time you could have known the actual answer to all of the things
that you've wrongly claimed here. And saved both of us valuable time.
So I'm closing this bug (again) now, so that nobody else substitutes
looking at a usertag for actually reading and testing things and ends
up wasting more of both their valuable time and mine.
The libogg 1.3.2 release is making its way though the buildds now,
though if I understood Breno's message to -release correctly, that
one was also already ok for ppc64el and building out of the box
there already?
If there's anything else your ports are stuck on, then do please
file appropriate bug reports about those and I'll look into them,
but _please_ at least do some minimal triage to confirm the problem
actually is something related to the package itself. We'll all get
the work that we care about done faster that way.
Thanks!
Ron
--- End Message ---
