Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper
On Wed, Dec 07, 2016 at 06:22:50PM +0100, Hilmar Preuße wrote: > Am 06.10.2016 um 22:20 tastete Mattia Rizzolo: > >On Thu, Oct 06, 2016 at 06:55:22PM +0200, Hilmar Preuße wrote: > >9) now that you're like this you can reinstate hardening, that you > > removed but not replaced, so just put > > export DEB_BUILD_MAINT_OPTIONS = hardening=+all > > on top, it should just work after the changs above > > > I did not remove any hardening implementation. It is just there as before: > AFAICT the following code should bring them in: > ./configure $(shell dpkg-buildflags --export=configure) > I just removed the test, which checked the presence of the hardening flags. AFAIK $(shell dpkg-buildflags --export=configure) doesn't get you all hardening options (including non-default optional ones, like pie (everywhere, now it's default in some archs, but in October wasn't) and bindnow). > I'm working on your list to go to compat level 9 and dh_auto_configure. Be aware that if you want to see your package in stretch you need to hurry, as the freeze is approaching: it has to be in sid by Christmas, and hope you won't get new RC bugs after that. See https://release.debian.org/#release-dates -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper
Am 06.10.2016 um 22:20 tastete Mattia Rizzolo: On Thu, Oct 06, 2016 at 06:55:22PM +0200, Hilmar Preuße wrote: Hi, I'm not a DD (yet), I can't do upload. I know we have DD's on that list: could anybody finalize the changelog in git and then upload the current git state? I can sponsor the upload if you want, but before I'd like to see more changes done, meaning: 9) now that you're like this you can reinstate hardening, that you removed but not replaced, so just put export DEB_BUILD_MAINT_OPTIONS = hardening=+all on top, it should just work after the changs above > I did not remove any hardening implementation. It is just there as before: AFAICT the following code should bring them in: ./configure $(shell dpkg-buildflags --export=configure) I just removed the test, which checked the presence of the hardening flags. I'm working on your list to go to compat level 9 and dh_auto_configure. H. -- #206401 http://counter.li.org
Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper
Am 06.10.2016 um 22:20 schrieb Mattia Rizzolo: Hi, 13) the -l option of dh_shlibdeps is really unneeded nowadays dh_shlibdeps - calculate shared library dependencies -ldirectory[:directory ...] With recent versions of dpkg-shlibdeps, this option is generally not needed. It tells dpkg-shlibdeps (via its -l parameter), to look for private package libraries in the specified directory (or directories -- separate with colons). With recent versions of dpkg-shlibdeps, this is mostly only useful (...) or other situations where the library is installed into a directory not on the regular library search path. We install a lot of so-files into /usr/lib/proftpd (as plugins). Is /usr/lib/... considered to be a "regular library search path"? After removing that option these messages are still there: dpkg-shlibdeps: warning: debian/proftpd-mod-ldap/usr/lib/proftpd/mod_ldap.so contains an unresolvable reference to symbol pr_signals_handle: it's probably a plugin dpkg-shlibdeps: warning: 33 other similar warnings have been skipped (use -v to see them all) ...so this makes me thinks that the option is indeed useless. Please confirm. Many thanks! Hilmar -- #206401 http://counter.li.org
Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper
Am 06.10.2016 um 22:20 schrieb Mattia Rizzolo: Hi, 11) the rules' clean target doesn't call dh_auto_clean. I think that with it you can save a lot of manual `rm -rf` and also revert adf6a7e88b051ed2fa7e7638d41d9105aa3c603c Replaced clean target. That doesn't make the manual `rm -rf` surplus as the upstream Makefile is incomplete and some generated file are not removed. ;-( Hilmar -- http://www.hilmar-preusse.de.vu/ #206401 http://counter.li.org
Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper
On 27.10.16 Mattia Rizzolo (mat...@debian.org) wrote: > On Thu, Oct 27, 2016 at 02:07:17PM +0200, Hilmar Preuße wrote: Hi, > > Sorry to bother you again. The generated configure script seems to be broken > > or incomplete: > > arggg :( > #842293, I've set you as submitter. > IMHO, this should be handled upstream. > I've now looked for the first time at the upstream git repo, and I see > the "configure" file being there: it shouldn't. All the artifacts of > autotool are not supposed to be stored within a VCS, only generated at > release time. Though that one seems to be kept up to date with > configure.in; clearly they are not doing the same with the rest of > autotools-generated artifacts. > > Considering that there are so many issues and maybe you want to upload > soon rather than later, for me feel free to skip this point about > autoreconf, but please try to get this fixed. > Yes, I'll/we'll do so. > btw, I peaked at the debian's git repository, and I saw that you used > the git:// protocol in Vcs-Git; given that it's possible please avoid > doing so, also see > https://lintian.debian.org/tags/vcs-field-uses-insecure-uri.html > Fixed i git. Sorry for misunderstanding. Hilmar -- sigmentation fault signature.asc Description: PGP signature
Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper
On Thu, Oct 27, 2016 at 02:07:17PM +0200, Hilmar Preuße wrote: > Sorry to bother you again. The generated configure script seems to be broken > or incomplete: arggg :( > Should we open a new bug for all this? IMHO yes. > > > I suggest you bring that upstream, not being able to run > > autoreconf -f -i > > on a autotools project is IMHO a bug that ought to be fixed. > > > Well, yes. Something to do in the future, not sure when. IMHO, this should be handled upstream. I've now looked for the first time at the upstream git repo, and I see the "configure" file being there: it shouldn't. All the artifacts of autotool are not supposed to be stored within a VCS, only generated at release time. Though that one seems to be kept up to date with configure.in; clearly they are not doing the same with the rest of autotools-generated artifacts. Considering that there are so many issues and maybe you want to upload soon rather than later, for me feel free to skip this point about autoreconf, but please try to get this fixed. btw, I peaked at the debian's git repository, and I saw that you used the git:// protocol in Vcs-Git; given that it's possible please avoid doing so, also see https://lintian.debian.org/tags/vcs-field-uses-insecure-uri.html -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper
Am 27.10.2016 um 01:58 schrieb Mattia Rizzolo: On Wed, Oct 26, 2016 at 10:56:12PM +0200, Hilmar Preuße wrote: Hi, Tried to implement this according to [1]. I gave me an FTBFS (log attached). That's configure.in being buggy. I quickly asked to a friend of mine (jrtc27) whom speaks autotools (I don't really), and in about 5 minutes he came up with https://paste.debian.net/890189/ Apparently this is a requirement since 2001: http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=e3e7e0a0afcbb870bec9a34d22fe0750393c40a1;hp=aa8dfa178d82db0fae8f5b0692f74e33763a263d Unless I'm missing something, this also means upstream did not run autoheader in the last 15+ years?! Sorry to bother you again. The generated configure script seems to be broken or incomplete: checking for struct statfs.f_type... yes ./configure: line 22589: PR_CHECK_STRUCT_ADDRINFO: command not found ./configure: line 22590: PR_CHECK_STRUCT_SS: command not found ./configure: line 22591: PR_CHECK_SS_FAMILY: command not found ./configure: line 22592: PR_CHECK_SS_LEN: command not found checking sys/acl.h usability... yes checking sys/acl.h presence... yes checking whether linking with OpenSSL has complete ECC support... yes checking for Postgres's PQescapeStringConn... yes ./configure: line 24427: syntax error near unexpected token `Wfloat-equal' ./configure: line 24427: `PR_CHECK_CC_OPT(Wfloat-equal)' debian/rules:77: recipe for target 'configure-stamp' failed make: *** [configure-stamp] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 debuild: fatal error at line 1376: The code in question is if test x"$GCC" = xyes; then PR_CHECK_CC_OPT(Wfloat-equal) PR_CHECK_CC_OPT(Wformat) PR_CHECK_CC_OPT(Wformat-security) PR_CHECK_CC_OPT(Wimplicit-function-declaration) PR_CHECK_CC_OPT(Wmaybe-uninitialized) PR_CHECK_CC_OPT(Wpointer-to-int-cast) PR_CHECK_CC_OPT(Wstack-protector) PR_CHECK_CC_OPT(Wunreachable-code) PR_CHECK_CC_OPT(fstack-protector-all) fi PR_CHECK_CC_OPT is defined in m4/proftpd.m4. Not sure if it is read, b/c the functions above PR_CHECK_STRUCT_ADDRINFO... are defined there too. Should we open a new bug for all this? I suggest you bring that upstream, not being able to run autoreconf -f -i on a autotools project is IMHO a bug that ought to be fixed. Well, yes. Something to do in the future, not sure when. Hilmar -- http://www.hilmar-preusse.de.vu/ #206401 http://counter.li.org
Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper
On Wed, Oct 26, 2016 at 10:56:12PM +0200, Hilmar Preuße wrote: > Am 06.10.2016 um 22:20 schrieb Mattia Rizzolo: > > Hi, > > > I can sponsor the upload if you want, but before I'd like to see more > > changes done, meaning: > > > > 6) run dh_autoreconf > > > Tried to implement this according to [1]. I gave me an FTBFS (log attached). That's configure.in being buggy. I quickly asked to a friend of mine (jrtc27) whom speaks autotools (I don't really), and in about 5 minutes he came up with https://paste.debian.net/890189/ Apparently this is a requirement since 2001: http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=e3e7e0a0afcbb870bec9a34d22fe0750393c40a1;hp=aa8dfa178d82db0fae8f5b0692f74e33763a263d Unless I'm missing something, this also means upstream did not run autoheader in the last 15+ years?! I suggest you bring that upstream, not being able to run autoreconf -f -i on a autotools project is IMHO a bug that ought to be fixed. > Not sure if I did the steps in wrong order, but this should be rather > independent of dh compat level (step 5) and configure call. Nah, the order of the points doesn't really matter (I numbered them only for convenience) > The fact that we have a local copy of libltdl (#561748) doesn't make things > easier. Doesn't seem to matter in this case, though of course that's a bug. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper
Am 06.10.2016 um 22:20 schrieb Mattia Rizzolo: Hi, I can sponsor the upload if you want, but before I'd like to see more changes done, meaning: 6) run dh_autoreconf Tried to implement this according to [1]. I gave me an FTBFS (log attached). Not sure if I did the steps in wrong order, but this should be rather independent of dh compat level (step 5) and configure call. The fact that we have a local copy of libltdl (#561748) doesn't make things easier. Hilmar [1] https://wiki.debian.org/Autoreconf#debhelper_packages -- http://www.hilmar-preusse.de.vu/ #206401 http://counter.li.org # Use current autotools helpers dh_update_autotools_config dh_autoreconf aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in' configure.in:682: warning: LTDL_INIT was called before LTDL_CONVENIENCE /usr/share/aclocal/ltdl.m4:68: LTDL_CONVENIENCE is expanded from... ../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from... ../../lib/autoconf/general.m4:1473: AC_ARG_ENABLE is expanded from... configure.in:682: the top level configure.in:2825: warning: AC_CONFIG_SUBDIRS: you should use literals ../../lib/autoconf/status.m4:1097: AC_CONFIG_SUBDIRS is expanded from... configure.in:2825: the top level configure.in:2831: warning: AC_CONFIG_SUBDIRS: you should use literals ../../lib/autoconf/status.m4:1097: AC_CONFIG_SUBDIRS is expanded from... configure.in:2831: the top level acinclude.m4:6664: warning: the serial number must appear before any macro definition configure.ac:67: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2672: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2689: AC_LINK_IFELSE is expanded from... m4/libtool.m4:1022: _LT_SYS_MODULE_PATH_AIX is expanded from... m4/libtool.m4:4170: _LT_LINKER_SHLIBS is expanded from... m4/libtool.m4:5249: _LT_LANG_C_CONFIG is expanded from... m4/libtool.m4:138: _LT_SETUP is expanded from... m4/libtool.m4:67: LT_INIT is expanded from... configure.ac:67: the top level configure.ac:67: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2672: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2689: AC_LINK_IFELSE is expanded from... m4/libtool.m4:4170: _LT_LINKER_SHLIBS is expanded from... m4/libtool.m4:5249: _LT_LANG_C_CONFIG is expanded from... m4/libtool.m4:138: _LT_SETUP is expanded from... m4/libtool.m4:67: LT_INIT is expanded from... configure.ac:67: the top level configure.ac:67: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2672: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2689: AC_LINK_IFELSE is expanded from... m4/libtool.m4:1022: _LT_SYS_MODULE_PATH_AIX is expanded from... m4/libtool.m4:4170: _LT_LINKER_SHLIBS is expanded from... m4/libtool.m4:5249: _LT_LANG_C_CONFIG is expanded from... m4/libtool.m4:138: _LT_SETUP is expanded from... m4/libtool.m4:67: LT_INIT is expanded from... configure.ac:67: the top level configure.ac:67: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2672: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2689: AC_LINK_IFELSE is expanded from... m4/libtool.m4:4170: _LT_LINKER_SHLIBS is expanded from... m4/libtool.m4:5249: _LT_LANG_C_CONFIG is expanded from... m4/libtool.m4:138: _LT_SETUP is expanded from... m4/libtool.m4:67: LT_INIT is expanded from... configure.ac:67: the top level configure.ac:67: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2672: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2689: AC_LINK_IFELSE is expanded from... m4/libtool.m4:1022: _LT_SYS_MODULE_PATH_AIX is expanded from... m4/libtool.m4:4170: _LT_LINKER_SHLIBS is expanded from... m4/libtool.m4:5249: _LT_LANG_C_CONFIG is expanded from... m4/libtool.m4:138: _LT_SETUP is expanded from... m4/libtool.m4:67: LT_INIT is expanded from... configure.ac:67: the top level configure.ac:67: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2672: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2689: AC_LINK_IFELSE is expanded from... m4/libtool.m4:4170: _LT_LINKER_SHLIBS is expanded from... m4/libtool.m4:5249: _LT_LANG_C_CONFIG is expanded from... m4/libtool.m4:138: _LT_SETUP is expanded from... m4/libtool.m4:67: LT_INIT is expanded from... configure.ac:67: the top level libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'config'. libtoo
Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper
On Tue, Oct 25, 2016 at 11:35:42PM +0200, Hilmar Preuße wrote: > > 3) configure done by dh_auto_configure > > > I'd simply replace > > ./configure $(shell dpkg-buildflags --export=configure) $(CONF_ARGS) > --with-shared=$(DSOMODS1)$(DSOMODS2)$(DSOMODS3)$(DSOMODS4) > > by > > dh_auto_configure -- $(shell dpkg-buildflags --export=configure) > $(CONF_ARGS) --with-shared=$(DSOMODS1)$(DSOMODS2)$(DSOMODS3)$(DSOMODS4) > > Is that correct? This will give me a lot of duplicate parameters e.g. > --prefix=/usr will be specified twice in the configure call. This can be > cleaned up later on. That, and remove some options from CONF_ARGS that are already passed by dh_auto_configure. Also the change at point 4 should allow you to drop that $(shell dpkg-buildpackage ..), and if not that can be considered some bad habit from the the build system. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper
On 06.10.2016 22:20, Mattia Rizzolo wrote: Hi, > I can sponsor the upload if you want, but before I'd like to see more > changes done, meaning: > > > 3) configure done by dh_auto_configure > I'd simply replace ./configure $(shell dpkg-buildflags --export=configure) $(CONF_ARGS) --with-shared=$(DSOMODS1)$(DSOMODS2)$(DSOMODS3)$(DSOMODS4) by dh_auto_configure -- $(shell dpkg-buildflags --export=configure) $(CONF_ARGS) --with-shared=$(DSOMODS1)$(DSOMODS2)$(DSOMODS3)$(DSOMODS4) Is that correct? This will give me a lot of duplicate parameters e.g. --prefix=/usr will be specified twice in the configure call. This can be cleaned up later on. Hilmar -- http://www.hilmar-preusse.de.vu/ #206401 http://counter.li.org
Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper
On 06.10.2016 22:20, Mattia Rizzolo wrote: Hi Mattia, > I can sponsor the upload if you want, but before I'd like to see > more changes done, meaning: > Many thanks for the offer! I'm aware that the d/rules file is rather a mess and we do a lot of work which could by upstream or dh. However I'm new in the team and I didn't find the time yet to do large changes. Hence I concentrated on fixing bugs and get the package back into a more usable and more compliant state. Cleaning up d/rules wasn't on the top of the list until now. > Then, that's assuming you're interested in having me as a sponsor, and > nobody else steps up :) > (also, I'm not in the team, so I can't push commit/tags) > I'll have a look at that however I can't promise that your suggestions will be in our package soon. Hilmar -- http://www.hilmar-preusse.de.vu/ #206401 http://counter.li.org
Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper
On Thu, Oct 06, 2016 at 06:55:22PM +0200, Hilmar Preuße wrote: > On 01.10.2016 19:01, Mattia Rizzolo wrote: > > Can you also upload it? > I'm not a DD (yet), I can't do upload. > > I know we have DD's on that list: could anybody finalize the changelog > in git and then upload the current git state? I can sponsor the upload if you want, but before I'd like to see more changes done, meaning: 1) both Vcs-Git and Vcs-Browser canonicalized to (it works for both) https://anonscm.debian.org/git/pkg-proftpd/proftpd-dfsg.git 2) build done by dh_auto_build, instead of manual `make all` 3) configure done by dh_auto_configure 4) compat level bumped to at least 9, so that buildflags from dpkg-buidflags are exported by dh_* tools (read debhelper(7)) 5) config.{sub,guess} updated by dh_update_autotools_config (just call it instead of that `test -r / mv / cp` + cleanup; the cleanup is done by dh_clean) 6) run dh_autoreconf 7) there are so many trailing whitespaces in that d/rules... 8) install done with dh_auto_install. That nostrip facility is not needed, the strip is done by dh_strip anyway, also stripping the binaries at install time like that makes the -dbgsym binaries produced by dh_strip useless 9) now that you're like this you can reinstate hardening, that you removed but not replaced, so just put export DEB_BUILD_MAINT_OPTIONS = hardening=+all on top, it should just work after the changs above 10) moving to dh_* tools makes you posible to drop: + thing for supporting cross build (the `ifeq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))` ) + that `CC := gcc`, that it's also breaking cross compiling, I think (haven't tried) 11) the rules' clean target doesn't call dh_auto_clean. I think that with it you can save a lot of manual `rm -rf` and also revert adf6a7e88b051ed2fa7e7638d41d9105aa3c603c 12) I wouldn't mind seeing those `install ...` moved to the already existing d/*.install files 13) the -l option of dh_shlibdeps is really unneeded nowadays 14) you have a `CFLAGS := ..` on the top, but it's not exported, hence it's just about useless 15) after all of this you will see how most of d/rules turned into "just call calling dh_*", and eventually rewriting the whole thing to use the dh(1) sequencer with just a couple of overrides will be very easy 16) given that you're preparing the upload, your name should be in the trailing of d/changelog, imho, then you're not in the Uploaders field, so you either should be there, or stick a "Team upload" in the beginning. Then, that's assuming you're interested in having me as a sponsor, and nobody else steps up :) (also, I'm not in the team, so I can't push commit/tags) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper
On 01.10.2016 19:01, Mattia Rizzolo wrote: > On Mon, Sep 19, 2016 at 10:44:21PM +0200, Hilmar Preuße wrote: >> On 19.09.2016 19:29, Niels Thykier wrote: >>> On Sat, 17 Sep 2016 22:36:20 +0200 Hilmar Preusse wrote: Hi Mattia, Is it OK to simply remove that check? Is there an replacement for hardening-check? >>> Hi Hilmar :) >>> >>> I believe you can just remove that check. >>> >> Done in git, tag pending. > > Can you also upload it? > I'm not a DD (yet), I can't do upload. I know we have DD's on that list: could anybody finalize the changelog in git and then upload the current git state? Thanks!! Hilmar -- http://www.hilmar-preusse.de.vu/ #206401 http://counter.li.org
Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper
On Mon, Sep 19, 2016 at 10:44:21PM +0200, Hilmar Preuße wrote: > On 19.09.2016 19:29, Niels Thykier wrote: > > On Sat, 17 Sep 2016 22:36:20 +0200 Hilmar Preusse wrote: > > Hi, > > >> Is it OK to simply remove that check? Is there an replacement for > >> hardening-check? > >> > > Hi Hilmar :) > > > > I believe you can just remove that check. > > > Done in git, tag pending. Can you also upload it? We want to remove the whole hardening-wrapper package, and ~everything is already uploaded (either in the archive or as NMU in the DEFERRED queue). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper
Hilmar Preuße: > tags 836759 + pending > stop > > On 19.09.2016 19:29, Niels Thykier wrote: >> On Sat, 17 Sep 2016 22:36:20 +0200 Hilmar Preusse wrote: > > Hi, > >>> Is it OK to simply remove that check? Is there an replacement for >>> hardening-check? >>> >> Hi Hilmar :) >> >> I believe you can just remove that check. >> > Done in git, tag pending. > Thanks, >> As for a replacement, lintian will still implement the hardening-no-* >> tags, which were based on the code from hardening-check. >> > Hmm: lintian still depends on hardening-includes. Not my problem. ;-) > > Hilmar > Indeed, the dependency will be removed in the next upload. :) Thanks, ~Niels
Processed: Re: Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper
Processing commands for cont...@bugs.debian.org: > tags 836759 + pending Bug #836759 [proftpd-dfsg] proftpd-dfsg: please drop the build dependency on hardening-wrapper Added tag(s) pending. > stop Stopping processing here. Please contact me if you need assistance. -- 836759: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836759 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper
tags 836759 + pending stop On 19.09.2016 19:29, Niels Thykier wrote: > On Sat, 17 Sep 2016 22:36:20 +0200 Hilmar Preusse wrote: Hi, >> Is it OK to simply remove that check? Is there an replacement for >> hardening-check? >> > Hi Hilmar :) > > I believe you can just remove that check. > Done in git, tag pending. > As for a replacement, lintian will still implement the hardening-no-* > tags, which were based on the code from hardening-check. > Hmm: lintian still depends on hardening-includes. Not my problem. ;-) Hilmar -- http://www.hilmar-preusse.de.vu/ #206401 http://counter.li.org
Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper
On Sat, 17 Sep 2016 22:36:20 +0200 Hilmar Preusse wrote: > On 05.09.16 Matthias Klose (d...@debian.org) wrote: > > Hi Matthias, > > > [...] > Is it OK to simply remove that check? Is there an replacement for > hardening-check? > > Thanks, > Hilmar > > [1] > https://wiki.debian.org/HardeningWalkthrough#rules_files_based_on_standard_debhelper_or_hand-written_rules_files > -- > sigfault Hi Hilmar :) I believe you can just remove that check. As for a replacement, lintian will still implement the hardening-no-* tags, which were based on the code from hardening-check. Thanks, ~Niels
Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper
On 05.09.16 Matthias Klose (d...@debian.org) wrote: Hi Matthias, > This package builds using the hardening-includes package, which > is now replaced by dpkg-dev's DEB_BUILD_MAINT_OPTIONS settings. > > Please consider dropping the build dependency of hardening-includes > and use the DEB_BUILD_MAINT_OPTIONS settings. > Currently hardening is implemented like this: ./configure $(shell dpkg-buildflags --export=configure) (...) ..according to [1]. The only place where we use hardening-includes is that line: find $(CURDIR)/debian/tmp -type f \( -executable -o -name \*.so\* \) -exec hardening-check {} + || true Is it OK to simply remove that check? Is there an replacement for hardening-check? Thanks, Hilmar [1] https://wiki.debian.org/HardeningWalkthrough#rules_files_based_on_standard_debhelper_or_hand-written_rules_files -- sigfault signature.asc Description: Digital signature