I have written for myself a ebuild for OpenDKIM on the 18.08.2009 and since then have updated the ebuild each time a new release of OpenDKIM has been released. Lately I have seen that there is now a ebuild for OpenDKIM 1.1.0 in Portage. That ebuild builds OpenDKIM but installs it into /etc/opendkim while all other mail related stuff in Gentoo is normally installed in /etc/mail/ (dkim-milter, sid-milter, DSPAM, etc). So that's the reason I post now the ebuild for OpenDKIM 1.1.1 which fixes this issue and activates more options for OpenDKIM then the one currently available in Portage. Reproducible: Always
Created attachment 207758 [details] opendkim-1.1.1.ebuild
Created attachment 207760 [details] files/opendkim.init
Created attachment 207762 [details, diff] files/opendkim-1.1.1-tre.patch
Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manner. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Thanks, On behalf of the Gentoo Sunrise Team, Justin. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
(In reply to comment #4) > Hello, The Gentoo Team would like to firstly thank you for your ebuild > submission. We also apologize for not being able to accommodate you in a timely > manner. There are simply too many new packages. > > Allow me to use this opportunity to introduce you to Gentoo Sunrise. The > sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to > commit to and all users can have ebuilds reviewed by Gentoo devs for entry > into the overlay. So, the sunrise team is suggesting that you look into this > and submit your ebuild to the overlay where even *you* can commit to. =) > > Thanks, > On behalf of the Gentoo Sunrise Team, > Justin. > > [1]: http://www.gentoo.org/proj/en/sunrise/ > [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq > Hallo Justin I just quickly read the FAQ for the Sunrise overlay. Did that changed in the past? I knew about Sunrise but had in my mind that submitting ebuilds there is hard. But from what I read now in the FAQ shows me a very easy process for submission. I am going to submit the ebuild there tonight. Thanks for reminding me about Sunrise and making me read the FAQ again. Kind Regards from Switzerland Steve
Totally forgot to assign the bug. Steve, just join us in #gentoo-sunrise
(In reply to comment #0) > ... That ebuild builds OpenDKIM but installs it into /etc/opendkim while > all other mail related stuff in Gentoo is normally installed in /etc/mail/ > (dkim-milter, sid-milter, DSPAM, etc). I guess /etc/mail is the normal sendmail way of storing files. I changed this to opendkim to be consistent with other packages generally. I also wanted this to not conflict with dkim-milter. How important is the /etc/mail structure? > which fixes this issue for the moment I disagree that it is a fix. > and activates more options for OpenDKIM then the one currently available in Portage. now that I've looked at the code I'll probably change a lot more options in the next ebuild. I won't be adding 1.1.1 to portage however Murray was talking about a new release in what I assume may be the next few weeks. Once this comes out give me a chance to add an ebuild and we can look at improvements from there. I've started to get fairly heavily involved in the upstream development here so let me know what features/gripes you have with opendkim and we'll see what can be addressed. My little fork/development branch is here http://gitorious.org/opendkim so feel free to add some feature suggestions to the wiki or alternately on the sf feature requests site.
closing wontfix for now but i'll still receive mail on this but and I won't forget about next release.
(In reply to comment #7) > > How important is the /etc/mail structure? > To be honest: I don't know. I am not the one having the power to decide how the layout should be in Gentoo. But personally I think that there is a reason for /etc/mail and since dkim-milter used to be installed there and since OpenDKIM is a fork from dkim-milter, OpenDKIM should resist there as well. I find it irritating that there is such an inconsistency in the layout. Either we follow our own set rules or we don't. Out of my mind I remember the following Ebuilds to install under /etc/mail: anomy-sanitizer dk-milter dkim-milter dspam milter-regex mimedefang sid-milter spamassassin > for the moment I disagree that it is a fix. > You disagree with the move to /etc/mail and/or with all the other options as well? Why if I might ask? > now that I've looked at the code I'll probably change a lot more options in the > next ebuild. I won't be adding 1.1.1 to portage however Murray was talking > about a new release in what I assume may be the next few weeks. > > Once this comes > out give me a chance to add an ebuild and we can look at improvements from > there. > > I've started to get fairly heavily involved in the upstream development here so > let me know what features/gripes you have with opendkim and we'll see what can > be addressed. > Since DKIM can be sometime troublesome I would like for testing purposes to see the following additional features enabled in future Gentoo Ebuilds of OpenDKIM: diffheaders selectcanon ztags Since I use DKIM in production and have a gazillion of domains where I can not always control the selector and other aspects, I would like to see the following features enabled in future Gentoo Ebuilds of OpenDKIM: selectorheader replacerules identityheader sendermacro And finally I would like to see in future Gentoo Ebuilds of OpenDKIM the possibility to use libdk (dk-milter) to verify older DKIM signed mails. > My little fork/development branch is here http://gitorious.org/opendkim so feel > free to add some feature suggestions to the wiki or alternately on the sf > feature requests site. > Will do. Might I ask why is it such a problem to add 1.1.1 into Portage?
(In reply to comment #9) > You disagree with the move to /etc/mail and/or with all the other options as > well? Why if I might ask? I do not have an opinion on /etc/mail vs /etc/opendkim but I disagree with enabling a bunch of "generally unreleased or incomplete features" (author's words in FEATURES). If these options make it to the tree, at least give the user the option to opt-out via USE flags.
(In reply to comment #9) > (In reply to comment #7) > > How important is the /etc/mail structure? > To be honest: I don't know. > I am not the one having the power to decide how the layout should be in Gentoo. I'm am taking your reasons provided into consideration. /etc/mail was the easy way to comply with the upstream layout which I think followed sendmails pseudostandard. I'll float some discussion with the other package maintainers here. > > for the moment I disagree that it is a fix. > > > You disagree with the move to /etc/mail and/or with all the other options as > well? Why if I might ask? it just seems that normal packages install config under /etc/{pkgname} and it seemed logical to me to follow this. You do put a good argument for keeping /etc/mail/ though. > Since DKIM can be sometime troublesome I would like for testing purposes to see > the following additional features enabled in future Gentoo Ebuilds of OpenDKIM: > diffheaders will do - I just ran out of time because of packaging problems to include this. > selectcanon > ztags sure > Since I use DKIM in production and have a gazillion of domains where I can not > always control the selector and other aspects, I would like to see the > following features enabled in future Gentoo Ebuilds of OpenDKIM: > selectorheader > replacerules > identityheader > sendermacro ok > And finally I would like to see in future Gentoo Ebuilds of OpenDKIM the > possibility to use libdk (dk-milter) to verify older DKIM signed mails. > from memory it provided only a static library that couldn't link to a shared libopendkim library. > > My little fork/development branch is here http://gitorious.org/opendkim so feel > > free to add some feature suggestions to the wiki or alternately on the sf > > feature requests site. > > > Will do. also http://www.sonic.net/~dougotis/id/draft-otis-dkim-tpa-label-03.html has a proposal for dealing with email lists. feedback welcome there too. a trial implementation in opendkim is something i hope to acheive. > Might I ask why is it such a problem to add 1.1.1 into Portage? I don't want to go though and validate all the patches again. Most are getting fix into upstream so next release should be easier. Also gives time to carify path issues. (In reply to comment #10) > I disagree with > enabling a bunch of "generally unreleased or incomplete features" (author's > words in FEATURES). If these options make it to the tree, at least give the > user the option to opt-out via USE flags. From memory I selected these so they only take effect if the user enables config options for them potentially with the exception of libar. If I get around to the man pages of next release will show and indicate the FFR FEATURES. I'll make more of an effort to provide USE flags for those that effect runtime operations next ebuild.
(In reply to comment #10) > (In reply to comment #9) > > You disagree with the move to /etc/mail and/or with all the other options as > > well? Why if I might ask? > > I do not have an opinion on /etc/mail vs /etc/opendkim but I disagree with > enabling a bunch of "generally unreleased or incomplete features" (author's > words in FEATURES). If these options make it to the tree, at least give the > user the option to opt-out via USE flags. > I agree here. I would have introduced some USE flags but they would all have been local USE flags and I did not wanted to pollute the Ebuild with a bunch of local USE flags.
(In reply to comment #11) > > Might I ask why is it such a problem to add 1.1.1 into Portage? > > I don't want to go though and validate all the patches again. Most are getting > fix into upstream so next release should be easier. Also gives time to carify > path issues. > The only patch I introduced is the one for TRE but Murray has already fixed that in trunk. So probably that will anyway be fixed in the next release of OpenDKIM. > From memory I selected these so they only take effect if the user enables > config options for them potentially with the exception of libar. If I get > around to the man pages of next release will show and indicate the FFR > FEATURES. I'll make more of an effort to provide USE flags for those that > effect runtime operations next ebuild. > That would be great. As a normal Gentoo user I had not the courage to include new local USE flags (fearing that adding them would prevent the Ebuild to flow into Portage) but you as a Gentoo developer have sure more power regarding what USE flags to add and what not.
(In reply to comment #10) As suggested - features that effect functionality like arlib and multiplesignatures have been put in as use flags. > In reply to comment #9) > Since DKIM can be sometime troublesome I would like for testing purposes to see > the following additional features enabled in future Gentoo Ebuilds of OpenDKIM: > diffheaders > selectcanon > ztags ... > selectorheader > replacerules > identityheader > sendermacro done. > And finally I would like to see in future Gentoo Ebuilds of OpenDKIM the > possibility to use libdk (dk-milter) to verify older DKIM signed mails. still not possible as libdk doesn't create a shared library. (In reply to comment #11) > (In reply to comment #9) > I'm am taking your reasons provided into consideration. /etc/mail was the easy > way to comply with the upstream layout which I think followed sendmails > pseudostandard. I'll float some discussion with the other package maintainers > here. I'm sorry - didn't get around to starting this discussion. as such its currently unchanged. >If I get around to the man pages of next release will show and indicate the FFR > FEATURES. patch is in progress. Didn't make it to this release though. (In reply to comment #13) > The only patch I introduced is the one for TRE but Murray has already fixed > that in trunk. So probably that will anyway be fixed in the next release of > OpenDKIM. which incidentally I wrote. There were lots of other things as you'll see from the release notes that weren't in the 1.1.0 ebuild > That would be great. As a normal Gentoo user I had not the courage to include > new local USE flags (fearing that adding them would prevent the Ebuild to flow > into Portage) but you as a Gentoo developer have sure more power regarding what USE flags to add and what not. Try not to be too put off. While lots of USE flags is a pain to maintain just adding a bit of justification is a probably all thats necessary. Its your distro too. Anyhow 1.1.2 here to enjoy (1.5 hr after upstream release :-). Bug reports also welcome.
(In reply to comment #14) > (In reply to comment #10) > As suggested - features that effect functionality like arlib and > multiplesignatures have been put in as use flags. > > > In reply to comment #9) > > Since DKIM can be sometime troublesome I would like for testing purposes to see > > the following additional features enabled in future Gentoo Ebuilds of OpenDKIM: > > diffheaders > > selectcanon > > ztags > ... > > selectorheader > > replacerules > > identityheader > > sendermacro > done. > > > And finally I would like to see in future Gentoo Ebuilds of OpenDKIM the > > possibility to use libdk (dk-milter) to verify older DKIM signed mails. > > still not possible as libdk doesn't create a shared library. > > (In reply to comment #11) > > (In reply to comment #9) > > I'm am taking your reasons provided into consideration. /etc/mail was the easy > > way to comply with the upstream layout which I think followed sendmails > > pseudostandard. I'll float some discussion with the other package maintainers > > here. > > I'm sorry - didn't get around to starting this discussion. as such its > currently unchanged. > > >If I get around to the man pages of next release will show and indicate the FFR > > FEATURES. > > patch is in progress. Didn't make it to this release though. > > (In reply to comment #13) > > The only patch I introduced is the one for TRE but Murray has already fixed > > that in trunk. So probably that will anyway be fixed in the next release of > > OpenDKIM. > which incidentally I wrote. > > There were lots of other things as you'll see from the release notes that > weren't in the 1.1.0 ebuild > > > That would be great. As a normal Gentoo user I had not the courage to include > > new local USE flags (fearing that adding them would prevent the Ebuild to flow > > into Portage) but you as a Gentoo developer have sure more power regarding what USE flags to add and what not. > > Try not to be too put off. While lots of USE flags is a pain to maintain just > adding a bit of justification is a probably all thats necessary. Its your > distro too. > My distro? Yes it is. But I have given up in submitting to b.g.o. I do have my local repository and I maintain almost 300 packages there: nyx ~ # find /mnt/gentoo.overlay/ -mindepth 2 -maxdepth 2 -type d|wc -l 297 nyx ~ # I could submit them to b.g.o but why keep an additional maintenance dependency when most of the submission anyway stay in b.g.o for ages (I am exaggerating with the word "ages" but I think you know what I mean)? Don't tell me know to apply to be a dev. It's complicated and just to become a dev I would need to have another dev guiding me and I don't know who that would be? So I stay here and maintain my own overlay and I am happy with it. From time to time I see some one on a mailing list for a specific application trying to package an application and asking some things to the mailing list. Then I do often jump into the discussion and submit my Ebuild to the person. Just 5 minutes ago I have helped one Gentoo user to get the Ebuild for GROSS. He is claiming to submit it to sunrise. Fine. Let's see if it shows up there? > Anyhow 1.1.2 here to enjoy (1.5 hr after upstream release :-). Bug reports also > welcome. > I am still using my own Ebuild. Will wait till you move to /etc/mail/ and then I am going to switch to the stock Gentoo Ebuild for OpenDKIM.
