Hi, am I correct, that in this case one normally schedules an binNMU to solve the issue? In our specific case this is not sufficient, b/c the test suite is broken; fix is on salsa: rev -3.
I can't do anything before Saturday b/c the local WLAN does not allow SSH connections to anywhere. H. 30.10.2024 11:57:07 Francesco P. Lovergine <fran...@debian.org>: > On Tue, Oct 29, 2024 at 06:57:07PM +0100, Santiago Vila wrote: >> Package: proftpd-dev >> Version: 1.3.8.b+dfsg-2 >> Severity: grave >> >> Dear maintainer: >> >> Package proftpd-mod-clamav and many others currently FTBFS in this way: >> >> ck-protector-strong -fstack-clash-protection -Wformat >> -Werror=format-security -fcf-protection -Wall -fno-omit-frame-po >> inter -fno-strict-aliasing -Werror=implicit-function-declaration >> -DPR_SHARED_MODULE -I. -I/usr/include/proftpd -c mod_ >> clamav.c -fPIC -DPIC -o .libs/mod_clamav.o >> In file included from /usr/include/proftpd/conf.h:105, >> from mod_clamav.c:30: >> /usr/include/proftpd/fsio.h:41:13: fatal error: attr/xattr.h: No such file >> or directory >> 41 | # include <attr/xattr.h> >> | ^~~~~~~~~~~~~~ >> compilation terminated. >> prxs: error executing command (1) >> make[1]: *** [debian/rules:13: override_dh_auto_build] Error 1 >> make[1]: Leaving directory '/<<PKGBUILDDIR>>' >> make: *** [debian/rules:10: binary] Error 2 >> dpkg-buildpackage: error: debian/rules binary subprocess returned exit >> status 2 >> >> > > I just had a look into this issue. TJ code already dynamically checks for > sys/xattr.h and attr/xattr.h with specific vars in the autoconf > configure.in. > # On Linux/MacOSX, it's sys/xattr.h > AC_CHECK_HEADER(sys/xattr.h, > [AC_DEFINE(HAVE_SYS_XATTR_H, 1, [Define if sys/xattr.h is present.]) > AC_DEFINE(PR_USE_XATTR, 1, [Define if using xattr support.]) > AC_CHECK_HEADERS(attr/xattr.h) > ... > Now, proftpd depends on libacl1-dev which depends on libattr1-dev > and so indirecly find the obsolete attr/xattr.h in the system at build > time. That of course coherently introduces a tentative include in proftpd > dev headers. > SO, I guess the next upload of proftpd will simply force this issue > disappearing and a coherent rebuild of all -mod after that > will adjust things. > > -- > ⢀⣴⠾⠻⢶⣦⠀ Francesco Paolo Lovergine > ⣾⠁⢠⠒⠀⣿⡁ Debian Developer > ⢿⡄⠘⠷⠚⠋⠀ 0579 A97A 2238 EBF9 BE61 > ⠈⠳⣄⠀⠀⠀⠀ ED02 0F02 A5E1 1636 86A4 > > _______________________________________________ > Pkg-proftpd-maintainers mailing list > pkg-proftpd-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-proftpd-maintainers
