The OpenDKIM package provides a service for signing and verifying
DomainKeys Identified Mail (DKIM) signatures. OpenDKIM consists of
a library that implements the DKIM service and a milter-based
filter application that can plug in to any milter-aware MTA, such
as Postfix or Sendmail, to provide that service to sufficiently
recent sendmail MTAs and other MTAs that support the milter
protocol.
This submission provides three new packages:
- libopendkim, a library for signing and verifying DKIM signatures,
- opendkim, the server application and the genkey script,
- opendkim-tools, a set of tools for configuring and testing OpenDKIM.
While at it, add PKG_BUILD_DEPENDS statement to sendmail's Makefile.
Travis CI buildbot sometimes fails to compile libopenssl before
starting to build sendmail. Since sendmail depends on libopenssl, the
whole Travis CI build process fails. Setting PKG_BUILD_DEPENDS
to "openssl", the directory name of libopenssl's Makefile, fixes the
problem.
Signed-off-by: Val Kulkov <val.kulkov@gmail.com>
This guarantees for the package feeds that
the mk files will always be available for all packages.
Will need to see about external-feed Python packages
a bit later.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
The only difference just a parameter for Python3
[ -b to compile bytecodes in legacy mode ].
No need to keep 2 almost identical files now
that they're exported.
I'm a bit scared of that param, since it may get
removed at some point.
But let's see until then.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Since `lang/python` is it's own folder of Python packages
(for both Python 2 & 3), and these build rules are needed
in a lot of packages [especially Python packages],
putting them here makes sense architecturally,
to be shared.
This also helps get rid of the `include_mk` construct
which relies on OpenWrt core to provide, and seems
like a broken design idea that has persisted for a while.
Reason is: it requires that Python 2/3 be built to provide
these mk files for other Python packages,
which seems like a bad idea.
Long-term, there could be an issue where some other feeds
would require these mk files [e.g. telephony] for
some Python packages.
We'll see how we handle this a bit later.
For now we limit this to this feed.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
The .mk snippets are not really usable at the moment, as they cannot be
considered for metadata collection (package DUMP) when included through
include_mk. Python packages do not use include_mk anymore for this reason,
so the install commands can be removed as well.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
openvswitch fails to build on my Arch Linux system, as it tries to use my build
host's sphinx-build with OpenWrt's python. Add an override to ensure this can't
happen.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Build depends refer to source package names, not binary package names.
In many cases, PKG_BUILD_DEPENDS simply duplicated runtime dependencies of
a source package's binary packages; as the corresponding source packages
are implicitly added as bulid dependencies, PKG_BUILD_DEPENDS can simply be
dropped in these cases. In the other cases, *_BUILD_DEPENDS is fixed to
refer to the correct source package name.
Dependency of mysql-server is adjusted from libncursesw to libncurses
(as libncursesw is a virtual package provided by libncurses), so the build
dependency on ncurses is emitted unconditionally.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
