Bug#978767: apr: ftbfs with autoconf 2.70
Package: src:apr Version: 1.7.0-3 Severity: normal Tags: sid bookworm User: d...@debian.org Usertags: ftbfs-ac270 [This bug report is not targeted to the upcoming bullseye release] The package fails to build in a test rebuild on at least amd64 with autoconf 2.70, but succeeds to build with autoconf 2.69. The severity of this report will be raised before the bookworm release, so nothing has to be done for the bullseye release. The full build log can be found at: http://qa-logs.debian.net/2020/09/26.ac270/apr_1.7.0-3_unstable_ac270.log The last lines of the build log are at the end of this report. To build with autoconf 2.70, please install the autoconf package from experimental: apt-get -t=experimental install autoconf [...] checking for pwd.h... yes checking for semaphore.h... yes checking for signal.h... yes checking for stdarg.h... yes checking for stddef.h... yes checking for stdio.h... yes checking for stdlib.h... yes checking for string.h... yes checking for strings.h... (cached) yes checking for sysapi.h... no checking for sysgtime.h... no checking for termios.h... yes checking for time.h... yes checking for tpfeq.h... no checking for tpfio.h... no checking for unistd.h... (cached) yes checking for unix.h... no checking for windows.h... (cached) no checking for winsock2.h... no checking for arpa/inet.h... yes checking for kernel/OS.h... (cached) no checking for net/errno.h... no checking for netinet/in.h... yes checking for netinet/sctp.h... yes checking for netinet/sctp_uio.h... no checking for sys/file.h... (cached) yes checking for sys/ioctl.h... yes checking for sys/mman.h... (cached) yes checking for sys/param.h... yes checking for sys/poll.h... yes checking for sys/resource.h... yes checking for sys/select.h... yes checking for sys/sem.h... yes checking for sys/sendfile.h... yes checking for sys/signal.h... yes checking for sys/socket.h... (cached) yes checking for sys/sockio.h... no checking for sys/stat.h... (cached) yes checking for sys/sysctl.h... yes checking for sys/syslimits.h... no checking for sys/time.h... yes checking for sys/types.h... (cached) yes checking for sys/uio.h... yes checking for sys/un.h... yes checking for sys/wait.h... yes checking for netinet/tcp.h... yes checking for h_errno in netdb.h... yes checking for off_t... yes checking for pid_t... yes checking for size_t... (cached) yes checking for uid_t in sys/types.h... yes checking for ssize_t... yes checking for inline... inline checking for an ANSI C-conforming const... yes checking whether setpgrp takes no argument... yes checking for socklen_t... yes checking size of void*... 8 checking size of char... 1 checking size of short... 2 checking size of int... 4 checking size of long... 8 checking size of long long... 8 checking whether int64_t and int use fmt %d... no checking whether int64_t and long use fmt %ld... no checking whether int64_t and long long use fmt %lld... no configure: error: could not determine the string function for int64_t make[1]: *** [debian/rules:84: override_dh_auto_configure] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:20: build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
Bug#936128: apr: Python2 removal in sid/bullseye
Package: src:apr Version: 1.6.5-1 Severity: normal Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: py2removal Python2 becomes end-of-live upstream, and Debian aims to remove Python2 from the distribution, as discussed in https://lists.debian.org/debian-python/2019/07/msg00080.html Your package either build-depends, depends on Python2, or uses Python2 in the autopkg tests. Please stop using Python2, and fix this issue by one of the following actions. - Convert your Package to Python3. This is the preferred option. In case you are providing a Python module foo, please consider dropping the python-foo package, and only build a python3-foo package. Please don't drop Python2 modules, which still have reverse dependencies, just document them. This is the preferred option. - If the package is dead upstream, cannot be converted or maintained in Debian, it should be removed from the distribution. If the package still has reverse dependencies, raise the severity to "serious" and document the reverse dependencies with the BTS affects command. If the package has no reverse dependencies, confirm that the package can be removed, reassign this issue to ftp.debian.org, make sure that the bug priority is set to normal and retitle the issue to "RM: PKG -- removal triggered by the Python2 removal". - If the package has still many users (popcon >= 300), or is needed to build another package which cannot be removed, document that by adding the "py2keep" user tag (not replacing the py2remove tag), using the debian-pyt...@lists.debian.org user. Also any dependencies on an unversioned python package (python, python-dev) must not be used, same with the python shebang. These have to be replaced by python2/python2.7 dependencies and shebang. This is the least preferred option. If the conversion or removal needs action on another package first, please document the blocking by using the BTS affects command, like affects + src:apr If there is no py2removal bug for that reverse-dependency, please file a bug on this package (similar to this bug report). If there are questions, please refer to the wiki page for the removal: https://wiki.debian.org/Python/2Removal, or ask for help on IRC #debian-python, or the debian-pyt...@lists.debian.org mailing list.
Bug#936129: apr-util: Python2 removal in sid/bullseye
Package: src:apr-util Version: 1.6.1-4 Severity: normal Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: py2removal Python2 becomes end-of-live upstream, and Debian aims to remove Python2 from the distribution, as discussed in https://lists.debian.org/debian-python/2019/07/msg00080.html Your package either build-depends, depends on Python2, or uses Python2 in the autopkg tests. Please stop using Python2, and fix this issue by one of the following actions. - Convert your Package to Python3. This is the preferred option. In case you are providing a Python module foo, please consider dropping the python-foo package, and only build a python3-foo package. Please don't drop Python2 modules, which still have reverse dependencies, just document them. This is the preferred option. - If the package is dead upstream, cannot be converted or maintained in Debian, it should be removed from the distribution. If the package still has reverse dependencies, raise the severity to "serious" and document the reverse dependencies with the BTS affects command. If the package has no reverse dependencies, confirm that the package can be removed, reassign this issue to ftp.debian.org, make sure that the bug priority is set to normal and retitle the issue to "RM: PKG -- removal triggered by the Python2 removal". - If the package has still many users (popcon >= 300), or is needed to build another package which cannot be removed, document that by adding the "py2keep" user tag (not replacing the py2remove tag), using the debian-pyt...@lists.debian.org user. Also any dependencies on an unversioned python package (python, python-dev) must not be used, same with the python shebang. These have to be replaced by python2/python2.7 dependencies and shebang. This is the least preferred option. If the conversion or removal needs action on another package first, please document the blocking by using the BTS affects command, like affects + src:apr-util If there is no py2removal bug for that reverse-dependency, please file a bug on this package (similar to this bug report). If there are questions, please refer to the wiki page for the removal: https://wiki.debian.org/Python/2Removal, or ask for help on IRC #debian-python, or the debian-pyt...@lists.debian.org mailing list.
Bug#909077: apr-util has not needed b-d on libpcre3-dev
Package: apr-util Version: 1.6.1-2 As pointed out in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757140 the dependencies on libpcre3-dev are not needed anymore, but still present in the build dependencies. Please remove.
Bug#897705: apr: ftbfs with GCC-8
Package: src:apr Version: 1.6.3-2 Severity: normal Tags: sid buster User: debian-...@lists.debian.org Usertags: ftbfs-gcc-8 Please keep this issue open in the bug tracker for the package it was filed for. If a fix in another package is required, please file a bug for the other package (or clone), and add a block in this package. Please keep the issue open until the package can be built in a follow-up test rebuild. The package fails to build in a test rebuild on at least amd64 with gcc-8/g++-8, but succeeds to build with gcc-7/g++-7. The severity of this report will be raised before the buster release. The full build log can be found at: http://aws-logs.debian.net/2018/05/01/gcc8/apr_1.6.3-2_unstable_gcc8.log.gz The last lines of the build log are at the end of this report. To build with GCC 8, either set CC=gcc-8 CXX=g++-8 explicitly, or install the gcc, g++, gfortran, ... packages from experimental. apt-get -t=experimental install g++ Common build failures are new warnings resulting in build failures with -Werror turned on, or new/dropped symbols in Debian symbols files. For other C/C++ related build failures see the porting guide at http://gcc.gnu.org/gcc-8/porting_to.html [...] testpools : SUCCESS testproc: SUCCESS testprocmutex : SUCCESS testrand: SUCCESS testsleep : SUCCESS testshm : SUCCESS testsockopt : SUCCESS teststr : E: Build killed with signal TERM after 150 minutes of inactivity Build finished at 2018-05-02T12:34:43Z Finished +--+ | Cleanup | +--+ Purging /<> Not cleaning session: cloned chroot in use E: Build failure (dpkg-buildpackage died) +--+ | Summary | +--+ Build Architecture: amd64 Build Type: any Build-Space: 36324 Build-Time: 9100 Distribution: unstable Fail-Stage: build Host Architecture: amd64 Install-Time: 13 Job: apr_1.6.3-2 Machine Architecture: amd64 Package: apr Package-Time: 9142 Source-Version: 1.6.3-2 Space: 36324 Status: attempted Version: 1.6.3-2 Finished at 2018-05-02T12:34:43Z Build needed 02:32:22, 36324k disk space E: Build failure (dpkg-buildpackage died) DC-Status: Failed 9142.619472132s DC-Time-Estimation: 9142.619472132 versus expected 128 (r/m: 70.42671462603126 ; m: 128.0)
Bug#820243: please build using lua5.2 instead of lua5.1
Package: src:apache2 Version: 2.4.18-2 looking at the sources, apache2 can be built using lua5.2 instead of lua5.1. Please use the more recent version.
Bug#761732: apr: libtool split: package needs a b-d on libtool-bin (or avoid using the libtool binary)
Package: src:apr Version: 1.5.1-2 Severity: wishlist User: debian-cr...@lists.debian.org Usertags: libtool-split As part of the effort to cross-build the archive, the libtool package needs a split into an architecture independent part and an architecture dpendent part (the latter only consisting of the libtool binary). The split is already done for jessie/sid, but to enable the cross buildability, the dependency in libtool on libtool-bin needs to be removed, and libtool-bin needs to depend on libtool instead. The vast majority of packages using libtool via automake don't need the libtool binary, and thus no changes in the build dependencies, however about 60 source packages are using libtool directly, and need changes. - some packages just check for the libtool binary, and then don't use it for the build (but are using libtoolize instead). Such usages are seen in a script called buildcheck.sh, and sometimes in autogen.sh scripts. The solution for these cases is to patch these scripts to check for libtoolize instead of libtool, and not to introduce the new build dependency. - other packages just need the additional build dependency on libtool-bin. To test your packages with the libtool-bin package removed, please use the binaries found at deb https://people.debian.org/~doko/tmp/20140820 ./ It is not clear, if all of these changes can be done in time for the jessie release, but it would be nice to have to be able to cross-build more packages in jessie. For questions and help please email the debian-cross ML. For additional pointers please see https://lists.debian.org/debian-devel-announce/2014/08/msg00013.html and some discussion in the orignal issue filed for libtool (#682045). The full build log can be found at: http://people.debian.org/~doko/logs/20140912/failed-libtool/apr_1.5.1-2_unstable_jdk-libtool.log The last lines of the build log are at the end of this report. [...] dpkg-buildpackage: source package apr dpkg-buildpackage: source version 1.5.1-2 dpkg-buildpackage: source distribution unstable dpkg-buildpackage: source changed by Stefan Fritsch s...@debian.org dpkg-source --before-build apr-1.5.1 dpkg-buildpackage: host architecture amd64 fakeroot debian/rules clean dh clean -Bdebian/build --parallel --with autotools_dev dh_testdir -O-Bdebian/build -O--parallel debian/rules override_dh_auto_clean make[1]: Entering directory '/«PKGBUILDDIR»' dh_auto_clean rm -rf debian/build for f in configure build/libtool.m4 build/ltmain.sh ; do [ ! -e $f.dr-orig ] || mv $f.dr-orig $f ; done make[1]: Leaving directory '/«PKGBUILDDIR»' dh_autotools-dev_restoreconfig -O-Bdebian/build -O--parallel dh_clean -O-Bdebian/build -O--parallel dpkg-source -b apr-1.5.1 dpkg-source: info: using source format `3.0 (quilt)' dpkg-source: info: building apr using existing ./apr_1.5.1.orig.tar.bz2 dpkg-source: info: building apr in apr_1.5.1-2.debian.tar.xz dpkg-source: info: building apr in apr_1.5.1-2.dsc debian/rules build make: Nothing to be done for 'build'. fakeroot debian/rules binary dh binary -Bdebian/build --parallel --with autotools_dev debian/rules build make[1]: Entering directory '/«PKGBUILDDIR»' make[1]: Nothing to be done for 'build'. make[1]: Leaving directory '/«PKGBUILDDIR»' dh_testdir -O-Bdebian/build -O--parallel dh_autotools-dev_updateconfig -O-Bdebian/build -O--parallel debian/rules override_dh_auto_configure make[1]: Entering directory '/«PKGBUILDDIR»' mkdir -p debian/build/docs for f in configure build/libtool.m4 build/ltmain.sh ; do [ -e $f.dr-orig ] || cp -p $f $f.dr-orig ; done ./buildconf buildconf: checking installation... buildconf: python version 2.7.8 (ok) buildconf: autoconf version 2.69 (ok) buildconf: libtool not found. You need libtool version 1.4 or newer installed to build APR from SVN. make[1]: *** [override_dh_auto_configure] Error 1 debian/rules:76: recipe for target 'override_dh_auto_configure' failed make[1]: Leaving directory '/«PKGBUILDDIR»' make: *** [binary] Error 2 debian/rules:18: recipe for target 'binary' failed dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xtftx-00017e...@paradis.debian.org
Bug#717327: unnecessary loop in configure searching for berkley-db
Package: apr-util Version: 1.5.2-1 Looking at the build log, there is a loop searching for berkley-db, searching a lot of unnecessary directories. Even when configuring with --with-berkeley-db=/usr/include:/usr/lib/multiarch-tuple the loop is taken, and not the given configuration. -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e92b2b.2070...@debian.org
Bug#717231: apr hard-codes -fstack-protector even on unsupported platforms
Package: apr Version: 1.4.8-1 apr hard-codes -fstack-protector even on unsupported platforms, leading to not that useful warnings during the build. -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e7b0b9.70...@debian.org
Bug#335438: libsvncpp-dev and libapr0-dev cannot be installed together
Package: libsvncpp-dev,libapr0-dev Severity: serious that means, that pysvn's build-deps cannot be installed anymore. Please coordinate, if these these packages should depend on libdb4.2-dev or libdb4.3-dev. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#262582: Fix apache-modconf script
tags 262582 + patch
thanks
--- /usr/sbin/apache-modconf~ 2004-06-24 22:40:22.0 +0200
+++ /usr/sbin/apache-modconf2004-08-01 09:12:57.0 +0200
@@ -65,7 +65,7 @@
fi
done
- cd -
+ cd - /dev/null
if [ $err = 1 ]; then
echo The above errors might cause $FLA to not work properly or
start
@@ -120,7 +120,7 @@
cd /usr/lib/apache/1.3/ \
LC_COLLATE=C \
ls *.info | sed -e 's/\.info$/,/g' -e 's/^...//g' \
- cd -`
+ cd - /dev/null`
available=`blacklist_modules $available`
@@ -158,7 +158,7 @@
for i in $enabled; do
mapped=`$GREP -l $i.so$ *.info | sed -e 's/\.info$/,/g' -e
's/^...//g'` $mapped
done
- cd -
+ cd - /dev/null
# this enable or disable a module
# note that the enable now checks if the module is already there
@@ -293,7 +293,7 @@
mv -f /etc/$FLA/modules.conf.perlfix.dpkg-inst.queue
/etc/$FLA/modules.conf.dpkg-inst.queue
fi
- cd -
+ cd - /dev/null
}
set_defaults() {
Re: Bug#228421: gcc 3.0.4 generates bad code on Debian 3.0/PARISC
tags 228421 + woody
tags 228421 + fixed-upstream
thanks
Well, maybe a recompilation and binary NMU for apache would suffice?
Should the report be reassignd to apache?
Willy Tarreau writes:
Package: gcc
Version: 2:3.0.4-5
Kernel: Linux hp 2.4.24-pa0 #1 Sun Jan 11 18:48:21 CET 2004 parisc unknown
glibc: Version: 2.2.5-11.5
GCC 3.0.4 included in Debian 3.0 generates bad code on PARISC platform. The
original apache 1.3.26 distributed in this port returns lines full of zeroes
in the size field of the files between 1 and 100 MB :
linux-2.4.20-wt17.tar.bz2 08-Jun-2003 11:05
0.M
patch-2.4.20-to-2.4.20-wt17.bz2 08-Jun-2003 11:04
-0.0M
CONTENTS-2.4.20-wt1708-Jun-2003 10:5218k
... and so on.
So I have recompiled 1.3.29 from sources with gcc-3.0.4, and the problem was
exactly the same. Digging through the code, I discovered that for exactly
these files, apache uses a floating point representation for the size, and it
calls ap_rprintf() which is sort of an sprintf(), with (size/1048576.0) as an
argument, and %4.1fM as the format string.
Replacing the format with %4eM gave me something interesting :
linux-2.4.20-wt17.tar.bz2 08-Jun-2003 11:05 8.417643e-53M
patch-2.4.20-to-2.4.20-wt17.bz2 08-Jun-2003 11:04 1.284430e-57M
CONTENTS-2.4.20-wt1708-Jun-2003 10:5218k
I've read the complete implementation of ap_rprintf(), and it seems correct
to me. But some double arguments are passed as va_args at several places. So
I thought that it could be possible that gcc does not handle this very well.
Then I recompiled only util_script.c and ap_snprintf.c with gcc-3.3.2, not
changing anything else, and apache now reports correct sizes :
linux-2.4.20-wt17.tar.bz2 08-Jun-2003 11:05 30.1M
patch-2.4.20-to-2.4.20-wt17.bz2 08-Jun-2003 11:04 7.2M
CONTENTS-2.4.20-wt1708-Jun-2003 10:5218k
Now I've found that it's very easy to reproduce. Consider this trivial
program :
#include stdio.h
#include stdlib.h
main() {
printf(%4.1f\n, 1.23456);
}
Now, test it :
# gcc -O2 -o fp-test fp-test.c
# ./fp-test
0.0
# gcc -O1 -o fp-test fp-test.c
# ./fp-test
1.2
# gcc-3.3.2-parisc -O2 -o fp-test fp-test.c
# ./fp-test
1.2
# gcc -v
Reading specs from /usr/lib/gcc-lib/hppa-linux/3.0.4/specs
Configured with: ../src/configure -v --enable-languages=c,c++,f77,proto,objc
--prefix=/usr --infodir=/share/info --mandir=/share/man --enable-shared
--with-gnu-as --with-gnu-ld --with-system-zlib --enable-long-long
--enable-nls --without-included-gettext --disable-checking
--enable-threads=posix --with-cpp-install-dir=bin hppa-linux
Thread model: posix
gcc version 3.0.4
# gcc-3.3.2-parisc -v
Reading specs from /usr/lib/gcc-lib/hppa1.1-hp-linux-gnu/3.3.2/specs
Configured with: ../gcc-3.3.2/configure --prefix=/usr --with-gnu-ld
--with-gnu-as --host=hppa1.1-hp-linux-gnu --target=hppa1.1-hp-linux-gnu
--with-cpu=7100LC --enable-languages=c,c++ --disable-nls --disable-locale
--enable-shared --enable-target-optspace
--enable-version-specific-runtime-libs --program-suffix=-3.3.2-parisc
--enable-threads
Thread model: posix
gcc version 3.3.2
So it seems that the work-around simply is to switch back to -O1.
Unfortunately, I tried about 20 -fno-XXX with -O2 to find the culprit,
but I couldn't. And I don't remember how I can dump the -O1 and -O2
equivalents.
I hope I didn't forget anything. At the moment, I don't know if there are
packages other than apache which have been affected by this bug.
Regards,
Willy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
