The approx-regex USE flag sets dev-libs/tre as a dependency but this library is only used in dkim-milter if the 'DIFFHEADERS' feature is enabled in site.config.m4. This feature is not enabled in the ebuild.
ok working on this. Alin - parallel make problems? I'll add you to the maintainer and remove some old version.
Yeah, I've spotted "job control not available" through compilation output. Please allow me to fix this. I'm already working on -r2 which will have: - a default /etc/mail/dkim-filter/dkim-filter.conf file (conf.d will no longer be used, -P and -x parameters being forced by init script) - keys will be created in pkg_config() Do you guys have a better name for approx-regex useflag?
(In reply to comment #2) > Yeah, I've spotted "job control not available" through compilation output. > > Please allow me to fix this. Fixed the original problem and a few others I found. Cleaned it up a bit. > I'm already working on -r2 which will have: > - a default /etc/mail/dkim-filter/dkim-filter.conf file (conf.d will no longer > be used, -P and -x parameters being forced by init script) > - keys will be created in pkg_config() > Sounds really good. > Do you guys have a better name for approx-regex useflag? > DIFFHEADERS ??/ committed as -r1 so you can incorporate your changes.
Created attachment 133059 [details] dkim-milter-2.3.0-r1.ebuild > committed as -r1 so you can incorporate your changes. ok - i lied - as attached.
patches added upstream too
dodoc ./dkim-filter/dkim-filter.conf.sample
Fixed in -r2 by applying a patch. My favorite way...;) As of now, all previous revisions have been removed from the tree. Daniel, if you have MAKEOPTS=-j2 and remove those -j1 from emake command line, you will see several warnings with "use -j1". The previous revision installed man pages full of funny escape sequences, so I figured I have to install the man pages myself. No need for MANROOT and stuff... I don't think they will ever going to change their Linux.m4. Is like this for as much as I can remember. Anyway, no biggie, we can use emake foo=bar for that, like is done in sendmail ebuild. The new version do not use a conf.d file anymore. Instead it has a healty (read patched) dkim-filter.conf. Cryptographic keys are now created pkg_config. This function also give you information on how you should configure your DNS and MTA. That's all folks! I don't have anything more to offer in this ebuild. Well mostly all... Support for DomainKeys verification would be a nice thing to have (did you knew yahoo still use DomainKeys?!?).
(In reply to comment #7) > Fixed in -r2 by applying a patch. My favorite way...;) cool. > As of now, all previous revisions have been removed from the tree. yeh it was getting a bit ugly. > Daniel, if you have MAKEOPTS=-j2 and remove those -j1 from emake command line, > you will see several warnings with "use -j1". yeh - i just assumed it was because of my other distcc machine being off. opps. > > The previous revision installed man pages full of funny escape sequences, so I > figured I have to install the man pages myself. No need for MANROOT and > stuff... ah - I though i saw a m4 option for that. could be wrong. > I don't think they will ever going to change their Linux.m4. Is like this for > as much as I can remember. Anyway, no biggie, we can use emake foo=bar for > that, like is done in sendmail ebuild. They said they'd pass it on. I was going to suggest autoconf but that would just be like asking them to change religion. > The new version do not use a conf.d file anymore. Instead it has a healty (read > patched) dkim-filter.conf. Yay. > Cryptographic keys are now created pkg_config. This function also give you > information on how you should configure your DNS and MTA. Looks pretty. > That's all folks! I don't have anything more to offer in this ebuild. Well > mostly all... Support for DomainKeys verification would be a nice thing to have > (did you knew yahoo still use DomainKeys?!?). > and gmail, and everyone who sends through gmail.
(In reply to comment #8) > > The previous revision installed man pages full of funny escape sequences, so I > > figured I have to install the man pages myself. No need for MANROOT and > > stuff... > > ah - I though i saw a m4 option for that. could be wrong. yes, there is a option to disable man reformat and I've already used it ;) just that you need to install man pages by hand after enabling NO_MAN_BUILD > They said they'd pass it on. I was going to suggest autoconf but that would > just be like asking them to change religion. prolly sendmail is older than autotools :D > > That's all folks! I don't have anything more to offer in this ebuild. Well > > mostly all... Support for DomainKeys verification would be a nice thing to have > > (did you knew yahoo still use DomainKeys?!?). > > > > and gmail, and everyone who sends through gmail. gmail supports DK and DKIM, so it isn't an issue to verify their email. yahoo on the other hand supports only DK. guess I will have to mess with dk-milter after all (dkim-milter needs libdk for verifying domains that only support DK).
> > gmail supports DK and DKIM, so it isn't an issue to verify their email. > yahoo on the other hand supports only DK. > guess I will have to mess with dk-milter after all (dkim-milter needs libdk for > verifying domains that only support DK). I got part of the way until i ran out of time and dk-milter was old didn't install the libs. in site.config.m4 below define(`bld_VERIFY_DOMAINKEYS', `true') APPENDDEF(`bld_dkim_filter_LIB', `-ldk ') dkim-filter/Makefile.m4 -bldPUSH_SMLIB(`dk') other thoughts pkg_postinst - einfo -> elog
I will add verify-dk useflag which will add dk-milter to DEPENDs. Since not many will want to clutter their etc with useless files, I will also add a libdk-only useflag to dk-milter. Thoughts?
An alternative way would be to add dk-milter tarball to SRC_URI and compile libdk within dkim-milter.
(In reply to comment #11) > I will add verify-dk useflag which will add dk-milter to DEPENDs. > Sounds good. > Since not many will want to clutter their etc with useless files, I will also > add a libdk-only useflag to dk-milter. Thoughts? probably a bit excessive. As its a static lib it will only show up as a DEPEND. A decent clean will remove it anyway. Its only a small library and a header file anyway. Come to think of it - maybe we should install the libdkim.a and headers for those that want to use it? (In reply to comment #12) > An alternative way would be to add dk-milter tarball to SRC_URI and compile > libdk within dkim-milter. This may simplify the make system that wants to look in ../libdk. Happy either way. PS - Graham - sorry for the bug spam. Noted that although gmail uses dkim signatures they don't define a Sender Signing Policy in _ssp.domainkey.gmail.com. Hmm interesting. Its all testing anyway. Not sure who uses it in non-testing mode.
I've looked over the dkim-milter sources and discovered I'm not insterested by this option. All it does is generate logs about DK signature status. Whoever want to filter mail that doesn't verify with DK policies declared by the sender's domain will have to install separate software for that (e.g. dk-milter). I've made a s/einfo/elog/ in pkg_postinst's body.
(In reply to comment #9) > (In reply to comment #8) > > > The previous revision installed man pages full of funny escape sequences, so I > > > figured I have to install the man pages myself. No need for MANROOT and > > > stuff... > > > > ah - I though i saw a m4 option for that. could be wrong. > > yes, there is a option to disable man reformat and I've already used it ;) > just that you need to install man pages by hand after enabling NO_MAN_BUILD > option to disable the build and keep the install. I'm just noting it here so I may remember it for next release. define(`confNO_MAN_BUILD',`') Next release will also include a umask config option to set permissions on the socket correctly.
