Have proper Debian package

szepeviktor commented 7 years ago

[x] Sort out sources: GitHub should mirror svn (not release tar-s)
[x] +TravisCI should build the Debian package
[ ] Semver versioning
[x] Dockerfile - builds directly from svn in Debian stretch
[ ] Debian formatted: NEWS (release-notes-* ?) README AUTHORS ChangeLog
[x] Consider merging COPYING, LICENSE, LICENSE.Sendmail
[ ] Full config with defaults, at least the formatted output of dkimsign --config
[x] Add longer extended-description in debian/control
[x] There are two spec files in svn
[ ] zlib autoconf as below

AX_CHECK_ZLIB
AC_SUBST([ZLIB_LIB])
AC_SUBST([ZLIB_CFLAGS])

szepeviktor commented 7 years ago

Here it is: https://github.com/szepeviktor/zdkimfilter/tree/debian/debian

Current results:

# lintian --display-info --display-experimental --pedantic --show-overrides zdkimfilter_1.6-1_amd64.deb
P: zdkimfilter: no-upstream-changelog
W: zdkimfilter: new-package-should-close-itp-bug
I: zdkimfilter: extended-description-is-probably-too-short
I: zdkimfilter: spelling-error-in-manpage usr/share/man/man5/zdkimfilter.conf.5.gz allows to allows one to
I: zdkimfilter: spelling-error-in-manpage usr/share/man/man5/zdkimfilter.conf.5.gz allows to allows one to
I: zdkimfilter: spelling-error-in-manpage usr/share/man/man8/zdkimfilter.8.gz allow to allow one to

szepeviktor commented 7 years ago

@alevesely Could you please check whether Debian build system figured out your build steps: This is all I've taught it: https://github.com/szepeviktor/zdkimfilter/blob/debian/debian/rules The build log: https://travis-ci.org/szepeviktor/zdkimfilter/builds/228053699#L2010 Thanks!

ps. we have a Dockerfile also https://github.com/szepeviktor/zdkimfilter/blob/debian/Dockerfile

szepeviktor commented 7 years ago

Lintian tells us:

W: zdkimfilter: new-package-should-close-itp-bug
I: zdkimfilter: extended-description-is-probably-too-short
I: zdkimfilter: spelling-error-in-manpage usr/share/man/man5/zdkimfilter.conf.5.gz allows to allows one to
I: zdkimfilter: spelling-error-in-manpage usr/share/man/man5/zdkimfilter.conf.5.gz allows to allows one to

extended-description-is-probably-too-short:

Description: "z" DKIM filter for Courier-MTA using the OpenDKIM Project's library

If you have time for it you could heal the last three.

alevesely commented 7 years ago

I tried to download and build and it looks fine, except I removed the version constraint of libopendkim-dev in debian/control. Is it needed? Most opendkim versions work equally well. Version 2.10 had an API change, but zdkimfilter should behave the same. Version 2.2 had a new feature, and some tests are disabled if it's older than 2010. Furthermore, the filter is not multithreaded so the dependence on pthread can be avoided. Opendkim can be compiled with --disable-filter to avoid building the milter. Having only a static library (--disable-shared) can be used to make sure to avoid un-coordinated changes, otherwise, the stock Debian version should be fine (it misses the .pc file, though).

Since I had the control file loaded, I also changed the long description as follows:

Description: DKIM filter for Courier-MTA.
 This filter uses the OpenDKIM Project's library to sign messages from
 authenticated users, or verify relayed messages and add an
 Authentication-Results: header field if configured to do so.  The source package
 contains example scripts for building a database to save message details to.
 Database details allow one to configure sending DMARC aggregate reports.
 SPF results are imported from Courier processing.  DMARC rejection (as well
 as historic ADSP) can be enabled or disabled on a per-domain basis.

However, while that fixes one of the issues above, it opens the question of how to define a database. It can be any ODBX-compatible backend (man zfilter_db) where users can add tables and fields as needed. This topic deserves its own issue, but let it bake for the time being.

One of the "allows to" (save_from_anyway) was a really misleading piece of documentation. Both fixed.

szepeviktor commented 7 years ago

I removed the version constraint of libopendkim-dev in debian/control. Is it needed?

Don't you remember me struggling for months with buggy header normalization? It is fixed only in 2.11.

szepeviktor commented 7 years ago

Opendkim can be compiled with --disable-filter to avoid building the milter. Having only a static library (--disable-shared) can be used to make sure to avoid un-coordinated changes, otherwise, the stock Debian version should be fine (it misses the .pc file, though).

I am always following the Debian way. 2.11 is only present in stretch.

szepeviktor commented 7 years ago

Thank you for the long description. https://github.com/szepeviktor/zdkimfilter/commit/5b827e61886335ef203de9157af96d2ce1553b93

szepeviktor commented 7 years ago

@alevesely Have you noticed there are two spec files in svn?

alevesely commented 7 years ago

On Wed 03/May/2017 20:46:10 +0200 Viktor Szépe wrote:

I removed the version constraint of libopendkim-dev in debian/control. Is it needed?

Don't you remember me struggling for months https://github.com/szepeviktor/zdkimfilter/issues/3#issuecomment-264700294 with buggy header normalization? It is fixed only in 2.11.

No, earlier versions, e.g. 2.9.2, did not have that bug.

At any rate, after you build the binary, you have no control on which libopendkim version you link with, unless you link static (that is, link to libopendkim.a, not .so)

alevesely commented 7 years ago

Have you noticed there are /two/ spec files in svn?

Oops. I added zdkimfilter.spec unwittingly; .spec.in was already versioned.

Thanks

alevesely commented 6 years ago

I try and include debian in the tarball, so that users can either run ./configure or dpkg-buildpackage -b -uc -us, according on their taste/style. To make it work I hack debian/rules to build conditionally based on the presence of m4_redist.zip, like so:

# https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#customrules
%:
    if test -f m4_redist.zip; then \
        dh $@ --with autoreconf; \
    else \
        dh $@; \
    fi

override_dh_autoreconf:
    if test -f m4_redist.zip; then \
        unzip m4_redist.zip; \
    fi
    touch NEWS README AUTHORS ChangeLog
    dh_autoreconf

Is that acceptable? I have no idea what is the "correct" way to handle m4 snippets and with/without autoreconf...

szepeviktor commented 6 years ago

I have no idea what is the "correct" way to handle m4 snippets and with/without autoreconf...

a Debian source package should be self-contained and complete

I think we should always go with dh $@ --with autoreconf which is automatic :) so dh $@

alevesely commented 6 years ago

Autoreconf needs the complete source, including redistributable m4 snippets. It makes no sense to include m4 in the tarball, which is meant to provide portable builds, possibly without autotools.

szepeviktor commented 6 years ago

provide portable builds

Ok-Ok

Debian is all about this! It runs on 10+ architectures.

All is up to you!

szepeviktor commented 6 years ago

@alevesely Could you implement one of the unchecked todos above?

alevesely commented 6 years ago

I checked the two spec. There are two spec in the tarball, zdkimfilter.spec and zdkimfilter.spec.in, but only the latter is still in the repository. It doesn't install a database, though.

For the other items, I'm a bit at a loss. Here's some thoughts:

Semver seems to require APIs. For general behavior, each release changes a little bit, so it obviously breaks anything which used to rely on that detail. Version 0 was conceptually different, with statistics that would be exported to opendkim, so a major version bump was due there. DMARC addition was rather an ADSP improvement than a conceptual change, IMHO, so we're still at v.1.
For the license files, IANAL. I modified LICENSE when I grabbed some sources from OpenDKIM (e.g. dkim-mailparse.c, in 2012). I also added a permission under GNU GPLv3 section 7 in order to comply with BSD licenses, and I don't recall where I read instructions to do so. OpenDKIM includes parts originally developed at Sendmail, Inc. LICENSE.Sendmail, clause (2) states that [r]edistributions of the Software Source Code must retain [...] these license terms and conditions, so I also keep that file. COPYING contains the GPLv3 terms, as added by autotools.
There used to be a busy config file. After I shortened it, it looked much easier. However, debian/postinst adds a bunch of DB statements, which is probably a pain for people who want a different DB or no DB at all. Anyway, setting each option at its default value, with comments about the other possibilities is just a different way to document options. Since we have zdkimfilter.conf(5) man page, we can refer to it.

szepeviktor commented 6 years ago

Ok I check now "LICENSE".

You could use 1 LICENSE file to contain all licenses.

szepeviktor commented 6 years ago

@alevesely As for semver it could be solved by changing 1.6 to 1.6.0 :)

mckaygerhard commented 2 years ago

hi @alevesely and @szepeviktor it seems the status of the debian package are loss in time.. i checked and it seems SEMVER are done now.. and "Full config with defaults, at least the formatted output of dkimsign --config" are nto so xplicit what means..

i configured by configure && make install but i do not use the debian pcakge cos it seems does still require manual setup..

so this work will not continue?

szepeviktor commented 2 years ago

Yes, if you open a PR.

alevesely commented 2 years ago

I don't make so many releases as to require a patch number. I use just major.minor; currently 3.9.

Although I'm slowly learning to use git, zdkimfilter development is done using subversion. See zdkimfilter.

The Debian package includes a postinst script which builds:

a config file in /usr/share/zdkimfilter,
a script to trim database entries,
a script to send DMARC reports,
a DKIM signing key for the domain, and
a cron snippet to call dmarc_send.

If you do configure, make, make install, you may want to take a look at that script.

Using a database is still somewhat exploratory. It's needed to send DMARC aggregate reports. Besides, it could be used for a number of tasks, possibly supplying web forms to modify values; for example per-user send limits, or shoot-on-sight. Quite likely, should save more data in order to be useful, but dunno what.

mckaygerhard commented 2 years ago

so in resume the only issue is the DB one.. but of course i must guess noted that all of those script assume current local hostname..

i will try fisrt to make a how to selft xploratory for me inside my job and then try to put feed back here.. of course i will take some weeks due the current task i have.. thanks for the info..

szepeviktor / zdkimfilter

Have proper Debian package #6