Created attachment 504986 [details] getdns-1.2.0.ebuild https://getdnsapi.net/ this library is a dependency for stubby (Stubby is an application that acts as a local DNS Privacy stub resolver).
Comment on attachment 504986 [details] getdns-1.2.0.ebuild net-dns/getdns-1.2.0.ebuild You know, the whole cate-gory/pkg-version.ebuild is used precisely nowhere in portage.
Comment on attachment 504986 [details] getdns-1.2.0.ebuild ># Copyright 1999-2017 Gentoo Foundation ># Distributed under the terms of the GNU General Public License v2 > >EAPI=6 > >inherit autotools You don't seem to use this.
Created attachment 505802 [details] getdns-1.2.0.ebuild removed the inherit line and the dependency on yaml. Thanks for helping to improve the ebuilds.
Created attachment 512090 [details] getdns-1.3.0.ebuild updated version for upstream release use versionator for source url
Created attachment 526498 [details] getdns-1.4.1.ebuild Hi, I'm attaching a newer version of the ebuild, feedback is welcome. Once this looks good, I'll proceed with #638168.
getdns is now in portage tree
(In reply to Quentin R. from comment #6) > getdns is now in portage tree Could you include the systemd unit and tmpfile config files, conditional on the stubby use flag? They are not in the getdns archive, only in the terribly named (v0.2.2.tar.gz) stubby archive. I think that was my reason for making two ebuilds. I also started with a single one and a use flag initially. Without these files stubby is pretty much useless on a systemd system.
I agree with Kristian, stubby is not developed separately: https://github.com/getdnsapi/stubby There should definitely be two distinct ebuilds. Also, you need to depend on libbsd and it'd be nice to have the static-libs use flag, see my proposed ebuild.
(In reply to Kristian from comment #7) > Could you include the systemd unit and tmpfile config files, conditional on > the stubby use flag? They are not in the getdns archive, only in the > terribly named (v0.2.2.tar.gz) stubby archive. I'm not able to test these, could you confirm they work smoothly? (In reply to Alessandro Di Federico from comment #8) > Also, you need to depend on libbsd and it'd be nice to have the static-libs > use flag, see my proposed ebuild. I'll add them. I have to admit that I did not notice libbsd dependency because it is a dependency of some @system packages actually. (In reply to Kristian from comment #7) > I think that was my reason > for making two ebuilds. I also started with a single one and a use flag > initially. > Without these files stubby is pretty much useless on a systemd system. (In reply to Alessandro Di Federico from comment #8) > I agree with Kristian, stubby is not developed separately: > > https://github.com/getdnsapi/stubby > > There should definitely be two distinct ebuilds. I see that getdnsapi team left a notice on their website that stubby has now its own repository. The fact that I do not understand is why they still include stubby sources in their getdns tarball.
(In reply to Quentin R. from comment #9) > (In reply to Kristian from comment #7) > > Could you include the systemd unit and tmpfile config files, conditional on > > the stubby use flag? They are not in the getdns archive, only in the > > terribly named (v0.2.2.tar.gz) stubby archive. > > I'm not able to test these, could you confirm they work smoothly? Sure. (probably on monday.)
(In reply to Kristian from comment #10) > (In reply to Quentin R. from comment #9) > > (In reply to Kristian from comment #7) > > > Could you include the systemd unit and tmpfile config files, conditional on > > > the stubby use flag? They are not in the getdns archive, only in the > > > terribly named (v0.2.2.tar.gz) stubby archive. > > > > I'm not able to test these, could you confirm they work smoothly? > > Sure. (probably on monday.) meaning they are included in my stubby ebuild (bug #638168) and are working. Have been using them for months now. Doe the service will not start after install as "systemd-tmpfiles --create" must be run first (will be run automatically at boot). Might be worth to either try to run it from the ebuild or print a message for the user to run on first install. I'd have time to test a new ebuild on monday.
did you had time to test it? no rights problem for pid file?
(In reply to Quentin R. from comment #12) > did you had time to test it? > no rights problem for pid file? Could you clarify the question for me? The stubby supplied files work on my systems, as I have been using my separate stubby ebuild on them. I added the lines to the in-tree getdns ebuild: systemd_dounit "${FILESDIR}"/stubby.service systemd_dotmpfilesd "${FILESDIR}"/stubby.conf after adding these files to $FILESDIR. (and inherit systemd) This creates a working setup on my system. There is however no pid file created. Neither under {/var}/run/stubby nor any other sensible place. I have no idea why. But that seems not to bother stubby nor systemd as for simple processes systemd works reliably without pid files.
(In reply to Kristian from comment #13) > Could you clarify the question for me? The stubby supplied files work on my > systems, as I have been using my separate stubby ebuild on them. > > I added the lines to the in-tree getdns ebuild: > > systemd_dounit "${FILESDIR}"/stubby.service > systemd_dotmpfilesd "${FILESDIR}"/stubby.conf > > after adding these files to $FILESDIR. (and inherit systemd) > > This creates a working setup on my system. There is however no pid file > created. Neither under {/var}/run/stubby nor any other sensible place. I > have no idea why. But that seems not to bother stubby nor systemd as for > simple processes systemd works reliably without pid files. Ok, so systemd is not using pid files. I'll add systemd unit files to getdns ebuild.
https://github.com/gentoo/gentoo/pull/8141
Now, I think the packages is complete. What about that split for stubby as a separate package? Do you think I should still separate it?
(In reply to Quentin R. from comment #16) > What about that split for stubby as a separate package? > Do you think I should still separate it? One argument for separation: As long as upstream is maintaining the systemd related files in the stubby-only source code (archive), you would not have to mainain them yourself (watch for changes in another development repository or wait for user bug reports). Apart from that, the current in-tree ebuild (1.4.1-r1) works satisfactory on my systemd-based system. I will check my openrc system later. Thanks for getting it in the tree.
(In reply to Quentin R. from comment #16) > Now, I think the packages is complete. > What about that split for stubby as a separate package? > Do you think I should still separate it? Is it maintained independantly from getdns? Is it consumed by other packages?
(In reply to Anthony Basile from comment #18) > Is it maintained independantly from getdns? Is it consumed by other > packages? They separated stubby in its own repository since August 2017 but they still keep including new stubby versions in getdns tarball since. It does not seem to be consumed by other packages actually.
First release candidate for 1.4.2 https://github.com/getdnsapi/getdns/tree/v1.4.2-rc1
(In reply to Kristian from comment #7) > (In reply to Quentin R. from comment #6) > > getdns is now in portage tree > > Could you include the systemd unit and tmpfile config files, conditional on > the stubby use flag? They are not in the getdns archive, only in the > terribly named (v0.2.2.tar.gz) stubby archive. I think that was my reason > for making two ebuilds. I also started with a single one and a use flag > initially. > Without these files stubby is pretty much useless on a systemd system. They included systemd files in this rc1, I hope they will keep them on release.
i pasted a wrong url, here is the changelog: https://github.com/getdnsapi/getdns/releases/tag/v1.4.2-rc1
okay this is now in the tree. please open another bug if there are any issues with getdns.
I think https://bugs.gentoo.org/638168 should be closed too then.
