Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper

2016-12-10 Thread Mattia Rizzolo 
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

2016-12-07 Thread Hilmar Preuße 

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

2016-11-28 Thread Hilmar Preuße 

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

2016-10-28 Thread Hilmar Preuße 

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

2016-10-27 Thread Hilmar Preusse 
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

2016-10-27 Thread Mattia Rizzolo 
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

2016-10-27 Thread Hilmar Preuße 

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

2016-10-26 Thread Mattia Rizzolo 
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

2016-10-26 Thread Hilmar Preuße 

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'.

Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper

2016-10-25 Thread Mattia Rizzolo 
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

2016-10-25 Thread Hilmar Preuße 
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

2016-10-06 Thread Hilmar Preuße 
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

2016-10-06 Thread Mattia Rizzolo 
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

2016-10-06 Thread Hilmar Preuße 
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

2016-10-01 Thread Mattia Rizzolo 
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

2016-09-19 Thread Niels Thykier 
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

Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper

2016-09-19 Thread 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.

> 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

2016-09-19 Thread Niels Thykier 
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

2016-09-17 Thread Hilmar Preusse 
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