Knot 1.6.0 is out at Oct 23, as per URL Please bump it in tree, thanks
Created attachment 402546 [details] Proposed ebuild for 1.6.3.
Created attachment 402548 [details, diff] Patch to adapt upstream Makefile to Gentoo QA standards
1.6.3 is out. I adapted the in-tree ebuild for 1.5.3. It's been a while since I last wrote an ebuild, and I'm uncomfortable with some of the hacks (patching Makefile.in instead of patching Makefile.am and rerunning Automake is the big one). The dependencies on libcap-ng, lmdb and libsystemd are documented ( https://www.knot-dns.cz/docs/1.6/html/installation.html ) to be automagic, but I hope I got them right. I haven't tested with systemd, and there is no unit file. Upstream requires recent enough versions of dev-libs/userspace-rcu and sys-libs/libcap-ng, which I included. But the oldest version in Portage is newer than the oldest version they support, so maybe the version dependency is unnecessary. Changes: * Change Git repo to git://git.nic.cz/knot-dns.git (see https://www.knot-dns.cz/pages/development.html ). Not tested. * Use .xz tarballs instead of .gz, since they have GnuPG signatures * Depend on specific versions of dev-libs/openssl, dev-libs/userspace-rcu, and sys-libs/libcap-ng (see https://www.knot-dns.cz/docs/1.6/html/installation.html ) * Depend on systemd if USE=systemd. Not tested. * Depend on sys-devel/bison instead of virtual/yacc, since the build system explicitly checks what kind of yacc it has and only accepts bison. * Depend on dev-python/sphinx (HTML), dev-tex/texlive-core (PDF), and sys-apps/texinfo (Info) for documentation. * Upstream ships a Makefile that explicitly creates /var/run/knot, which gives a QA warning. Patch the Makefile to remove that bit. Also remove explicit creation of /var/lib/knot (moved to a "keepdir" call) and /etc/knot (we get that anyway with the sample configuration). * Remove configure flags --disable-lto and --enable-recvmmsg, since they just reduntantly specify default values. * Enable lmdb and systemd if USE flags are set. * If USE=doc, build and install documentation in HTML, HTML-single, PDF, and TeXInfo formats.
Created attachment 402568 [details] Proposed ebuild for 1.6.3. New version of the ebuild, now with more correct dependencies.
Could maintainer add endorsement or otherwise to the submitted patch and ebuild. Timeout 2 weeks
lgtm with one comment - if you have src_check() phase, please add it as well (and run make check in it)
Created attachment 402932 [details] Proposed ebuild for 1.6.3. The default src_test() function doesn't work, because the upstream makefile gives an error when Portage runs "make -n check" to see if there is a "check" target. Added a custom src_check() which just runs "emake -j1 check" unconditionally.
Created attachment 402934 [details] metadata.xml with descriptions for the new USE flags. The point of the "fastparser" USE flag has changed (no longer requires external programs to build, but does require a lot of memory and CPU time). The "lmdb" USE flag has been added. Document both of these in metadata.xml.
I still can't test the systemd functionality, and there still isn't any unit file. Can systemd use the OpenRC init file?
Is there any point to having the live VCS code (-9999) in the same ebuild file as the released version? It was there in 1.5.3, so I just kept it for 1.6.3, but since upstream is about to release a new major version (latest is 2.0.0-beta), I wouldn't expect the build system to stay perfectly compatible.
(In reply to Karl-Johan Karlsson from comment #10) > Is there any point to having the live VCS code (-9999) in the same ebuild > file as the released version? It was there in 1.5.3, so I just kept it for > 1.6.3, but since upstream is about to release a new major version (latest is > 2.0.0-beta), I wouldn't expect the build system to stay perfectly compatible. Agreed, it doesn't make any sense now, because the 2.0 release has switched from OpenSSL to GnuTLS+Nettle for crypto, so this will need a rehaul. BTW (with upstream hat on): Thank you very much for taking care of the ebuilds.
(In reply to Karl-Johan Karlsson from comment #9) > I still can't test the systemd functionality, and there still isn't any unit > file. Can systemd use the OpenRC init file? With my Debian maintainer hat on, I use: --cut here-- [Unit] Description=Knot DNS server Wants=network-online.target After=network-online.target [Service] Environment=CONFFILE=/etc/knot/knot.conf ExecStartPre=/usr/lib/knot/prepare-environment $CONFFILE ExecReload=/usr/sbin/knotc reload ExecStart=/usr/sbin/knotd -c $CONFFILE Restart=on-abort [Install] WantedBy=multi-user.target --cut here-- You probably want to strip the prepare-environment which is just a shared script between sysv-rc and systemd scripts to create and chown Knot DNS rundir (/run/knot) I will add this to our TODO list to add this the repository.
(In reply to Karl-Johan Karlsson from comment #7) > Created attachment 402932 [details] > Proposed ebuild for 1.6.3. > > The default src_test() function doesn't work, because the upstream makefile > gives an error when Portage runs "make -n check" to see if there is a > "check" target. Added a custom src_check() which just runs "emake -j1 check" > unconditionally. With my upstream hat again - could you please send us (echo knot-dnsZZZZ@ZZZZlabs.nic.cz | sed -e s/ZZZZZ//g) the failing output? (Or just to me.) This would be appreciated (and hopefully fixed).
Created attachment 402956 [details] Proposed ebuild for 1.6.3. Removed the live VCS support from the ebuild, since upstream has changed things. Revisit after the 2.0.0 release.
(In reply to Ondřej Surý from comment #11) > (In reply to Karl-Johan Karlsson from comment #10) > > Is there any point to having the live VCS code (-9999) in the same ebuild > > file as the released version? It was there in 1.5.3, so I just kept it for > > 1.6.3, but since upstream is about to release a new major version (latest is > > 2.0.0-beta), I wouldn't expect the build system to stay perfectly compatible. > > Agreed, it doesn't make any sense now, because the 2.0 release has switched > from OpenSSL to GnuTLS+Nettle for crypto, so this will need a rehaul. OK. I removed the support code from the -1.6.3 ebuild, and someone with write access should remove the -9999 ebuild from the tree. > BTW (with upstream hat on): Thank you very much for taking care of the > ebuilds. Hooray for enlightened self-interest: I wanted a DNS server that makes DNSSEC easy, and it seemed that getting the latest release of Knot into Portage was the easiest way. Speaking of which, I'd like to report that I have been running these ebuilds for the last week as a primary NS (with NSD as slave) for a small DNSSEC-enabled domain, and they work for me. (In reply to Ondřej Surý from comment #12) > (In reply to Karl-Johan Karlsson from comment #9) > > I still can't test the systemd functionality, and there still isn't any unit > > file. Can systemd use the OpenRC init file? > > With my Debian maintainer hat on, I use: > [...] OK. As I said, I can't test for systemd, so I'm not going to blindly add that. I'll leave the USE flag in to make the automagic dependency on libsystemd explicit, but any more support than that I'll gladly leave to someone who actually runs systemd. (In reply to Ondřej Surý from comment #13) > (In reply to Karl-Johan Karlsson from comment #7) > > The default src_test() function doesn't work, because the upstream makefile > > gives an error when Portage runs "make -n check" to see if there is a > > "check" target. Added a custom src_check() which just runs "emake -j1 check" > > unconditionally. > > With my upstream hat again - could you please send us (echo > knot-dnsZZZZ@ZZZZlabs.nic.cz | sed -e s/ZZZZZ//g) the failing output? (Or > just to me.) This would be appreciated (and hopefully fixed). Done.
As for 'make check -n' - our automakegic looks correct, libtap.a should be built only for tests, hence it's placed in check_LIBRARIES, but as an result it's not built during 'make all' phase and thus 'make check -n' fails. Even the fail looks correct with this perspective. You can either do what you already do (e.g. skip automatics and run make check manually), or this little patch should do the trick: diff --git a/libtap/Makefile.am b/libtap/Makefile.am index 3246e14..9a88264 100644 --- a/libtap/Makefile.am +++ b/libtap/Makefile.am @@ -3,7 +3,7 @@ libtap_a_SOURCES = \ tap/float.c tap/float.h \ tap/macros.h -check_LIBRARIES = libtap.a +noinst_LIBRARIES = libtap.a check_PROGRAMS = \ runtests The only downside is that libtap.a is built during make all. I would suggest to stay with overriding automatics in gentoo builds.
(In reply to Ondřej Surý from comment #16) > The only downside is that libtap.a is built during make all. I would > suggest to stay with overriding automatics in gentoo builds. Sound reasonable. So, that would mean we're done here? Ondřej, since you're the maintainer on record, could you please bump it to the proxy maintainers? Proxy maintainers, could you please check that I haven't done anything stupid? Areas with high potential for stupidity include: * Patching Makefile.in instead of Makefile.am to avoid having to re-run automake. * Building with untested libsystemd support and not shipping a unit file. If it's OK, these attached files are submitted for inclusion in the Portage tree: net-dns/knot/knot-1.6.3.ebuild net-dns/knot/metadata.xml net-dns/knot/files/1.6.3-dont-create-extra-directories.patch and this file should be removed from the tree: net-dns/knot/knot-9999.ebuild (needs a rewrite to adapt to upstream changes)
Created attachment 402972 [details] Proposed ebuild for 1.6.3. Depend on dev-db/lmdb if USE=lmdb. Comment why we override src_test(). Update copyright year.
Since I had the Knot build system fresh in memory, I created bug 549104 for a bump to 2.0.0-beta.
(In reply to Karl-Johan Karlsson from comment #17) > Ondřej, since you're the maintainer on record, could you please bump it to > the proxy maintainers? Eh, bump? :) Well, if you can help me with how to do that, I will do that. I sort-of-maintain the package by talking to scarabeus :). Me being "maintainer on record" is sort-of a last resort since I don't use Gentoo, so if you want to step up and become maintainer of Knot DNS in Gentoo, I would really appreciated, since it's already much better to have an active user of the software in the distribution to maintain it.
(In reply to Ondřej Surý from comment #20) > (In reply to Karl-Johan Karlsson from comment #17) > > Ondřej, since you're the maintainer on record, could you please bump it to > > the proxy maintainers? > > Eh, bump? :) > > Well, if you can help me with how to do that, I will do that. I > sort-of-maintain the package by talking to scarabeus :). Ah, the joys of a Swede and a Czech talking past each other in English :) What I meant was: if you think what I wrote in comment #17 is a good idea, please use whatever small official powers you have to ask scarabeus to do what it says in comment #17. > Me being "maintainer on record" is sort-of a last resort since I don't use > Gentoo, so if you want to step up and become maintainer of Knot DNS in > Gentoo, I would really appreciated, since it's already much better to have > an active user of the software in the distribution to maintain it. An interesting suggestion, but perhaps a bit premature since I've only just switched to Knot from NSD a week ago. Ask me again after 2.0.0 is released.
(In reply to Karl-Johan Karlsson from comment #21) > (In reply to Ondřej Surý from comment #20) > > (In reply to Karl-Johan Karlsson from comment #17) > > > Ondřej, since you're the maintainer on record, could you please bump it to > > > the proxy maintainers? > > > > Eh, bump? :) > > > > Well, if you can help me with how to do that, I will do that. I > > sort-of-maintain the package by talking to scarabeus :). > > Ah, the joys of a Swede and a Czech talking past each other in English :) And the Czech is in Amsterdam right now :) > What I meant was: if you think what I wrote in comment #17 is a good idea, > please use whatever small official powers you have to ask scarabeus to > do what it says in comment #17. Ok, I am asking scarabeus to do what is says in comment #17, since it seems good to me. > > Me being "maintainer on record" is sort-of a last resort since I don't use > > Gentoo, so if you want to step up and become maintainer of Knot DNS in > > Gentoo, I would really appreciated, since it's already much better to have > > an active user of the software in the distribution to maintain it. > > An interesting suggestion, but perhaps a bit premature since I've only just > switched to Knot from NSD a week ago. Ask me again after 2.0.0 is released. OK, will do. Thank you.
hi Karl-Johan Karlsson, you didn't introduce USE=dnstap for 1.6.3, while do for 2.0.0_beta, is it intentional? and i'm sure the live version (-9999) is out-dated, do you have problem if I drop it？ (we usually don't help to maintain live ebuild) since @scarabeus is away, we @proxy-maint team will help to commit this ebuild (plus 2.0.0_beta bug 549106)， I'll prmote Karl-Johan Karlsson as primary maintainer, which mean further bugs will be assigned to him, and CCed to Ondrej Sury. many thanks
(In reply to Yixun Lan from comment #23) > hi Karl-Johan Karlsson, you didn't introduce USE=dnstap for 1.6.3, while do > for 2.0.0_beta, is it intentional? Somewhat :) I didn't want to make too large a change for the releasd version, so I saved that for the beta. But then it turned out the dnstap support was just two lines, so I should have included it in 1.6.3 as well. I'll upload a new ebuild. > and i'm sure the live version (-9999) is out-dated, do you have problem if I > drop it？ (we usually don't help to maintain live ebuild) As I said in comment #17, and Ondřej accepted in comment #22, we want it to be removed since it doesn't work. If someone asks for it, a new one could be created based on the 2.0.0_beta ebuild. > since @scarabeus is away, we @proxy-maint team will help to commit this > ebuild (plus 2.0.0_beta bug 549106)， Thanks. > I'll prmote Karl-Johan Karlsson as > primary maintainer, which mean further bugs will be assigned to him, and > CCed to Ondrej Sury. As I said in comment #21, please wait a while, until I'm comfortable running the software and know I will continue doing so. We can revisit the question after 2.0.0 is released.
Created attachment 403312 [details] Proposed ebuild for 1.6.3. Include dnstap support (backported from 2.0.0_beta). Correct list of debug subsystems.
Created attachment 403316 [details] metadata.xml with descriptions for the new USE flags. Describe USE=dnstab.
+*knot-2.0.0_beta (15 May 2015) +*knot-1.6.3 (15 May 2015) + + 15 May 2015; Yixun Lan <dlan@gentoo.org> +knot-1.6.3.ebuild, + +knot-2.0.0_beta.ebuild, -knot-9999.ebuild, + +files/1.6.3-dont-create-extra-directories.patch, + +files/2.0.0_beta-dont-create-extra-directories.patch, + +files/2.0.0_beta-spell-enable-vars-correctly.patch, metadata.xml: + version bump, bug 531448, 549104, thanks Karl-Johan Karlsson and Ondřej + Surý thanks all
