Hide Forgot
`djbdns' is a Domain Name System written by the eminent author of qmail, D. J. Bernstein. djbdns is also suppose to be utmost secure like qmail. SPEC: http://pjp.dgplug.org/tools/djbdns.spec SORC: http://pjp.dgplug.org/tools/djbdns-1.05.tar.gz SRPM: http://pjp.dgplug.org/tools/djbdns-1.05-1.fc10.src.rpm `djbdns' depends on another package called daemontools, which is again written by D J Bernstein.
Daemontools package is open for review at: https://bugzilla.redhat.com/show_bug.cgi?id=480727
Some remarks: This package will need a lot of love to let it pass a review. * %files .. /usr/local/etc/* /usr/local/bin/* => Distro packages must not contrain files below /usr/local * Package doesn't seem to honor RPM_OPT_FLAGS. * *.tar.gz doesn't match upstream (http://cr.yp.to/djbdns/djbdns-1.05.tar.gz) * I can't spot any license (I am not sure, but haven't there been some legal issues with DJB's works?). Blocking FE-LEGAL. Finally: Does this package still have an active upstream? I thought, DJB discontinued all his works.
Debian's package database had the missing legal link: http://packages.debian.org/changelogs/pool/main/d/djbdns/djbdns_1.05-4/djbdns.copyright => Put a similar document as Debian does into your rpm.
(In reply to comment #3) > Debian's package database had the missing legal link: > http://packages.debian.org/changelogs/pool/main/d/djbdns/djbdns_1.05-4/djbdns.copyright > > => Put a similar document as Debian does into your rpm. Sure, I'll put that.
Ralf you can remove FE-LEGAL http://www.redhat.com/archives/fedora-legal-list/2007-November/msg00023.html
This code is in the Public Domain, should not be a legal issue as long as it is marked properly in the spec file (which it is). Lifting FE-Legal.
Here is a maintained fork of djbdns (and daemontools and ucspi-tcp): http://sourceforge.net/projects/zinq DISCLAIMER: I'm the maintainer / originator of said fork.
New review request: https://bugzilla.redhat.com/show_bug.cgi?id=488681
*** Bug 488681 has been marked as a duplicate of this bug. ***
you don't need a new review request for the same package.
(In reply to comment #10) > you don't need a new review request for the same package. Oh, okay. Here are the links to the new updated soruce and rpms for review. SPEC: http://pjp.dgplug.org/djbdns/djbdns.spec SORC: http://pjp.dgplug.org/djbdns/djbdns-1.05.1.tar.gz SRPM: http://pjp.dgplug.org/djbdns/djbdns-1.05.1-1.fc10.src.rpm
I know I'm probably butting in where I'm not wanted, but... At the moment, via this URL: http://pjp.dgplug.org/djbdns/djbdns.spec I see: License: GPLv2+ Is that a mistake or do you intend the changes you have made for this package under the GPL?
(In reply to comment #12) > I know I'm probably butting in where I'm not wanted, but... > > At the moment, via this URL: > > http://pjp.dgplug.org/djbdns/djbdns.spec > > I see: > > License: GPLv2+ > > Is that a mistake or do you intend the changes you have made for this package > under the GPL? Coherent grammer: Is that a mistake or do you intend the changes you have made for this package to be covered by the GPL? If the latter, should the license for the whole package really be listed as GPL when the original source is Public Domain?
Quoting README from: http://pjp.dgplug.org/djbdns/djbdns-1.05.1.tar.gz Hello all, I am pleased to release this *new* version of djbdns-1.05.1. Djbdns is a fully-fledged Domain Name System(DNS), originally written by the eminent author of qmail, Dr. D J Bernstein. This new release is a complete makeover to the original source(djbdns-1.05) and is meant to make life a lot more pleasant. The notable changes so far are in the set-up & configuration steps. Also, this new release is distributed under the GNU General Public Licence. See ChangeLog for more details. Whoah...is it legal to do that? Take public domain software, make some changes, and distribute the entire result under the GPL? Note also that DJB's original copyright notice has been removed and I see no mention of his release of djbdns into the public domain.
(In reply to comment #14) > Whoah...is it legal to do that? Take public domain software, make some > changes, and distribute the entire result under the GPL? Absolutely. Anyone can pick up public domain software and do _whatever_ they want to it. Relicense it, make it proprietary, turn it into a play, wear it as a hat, anything. > Note also that DJB's original copyright notice has been removed and I see no > mention of his release of djbdns into the public domain. While it might be good to mention that it is based on the Public Domain djbdns, there is no requirement that he do this. Also, there is no longer a copyright notice, because when DJB put it into the Public Domain, he officially abandoned copyright on the work.
(In reply to comment #15) > (In reply to comment #14) > > > Whoah...is it legal to do that? Take public domain software, make some > > changes, and distribute the entire result under the GPL? > > Absolutely. Anyone can pick up public domain software and do _whatever_ they > want to it. Relicense it, make it proprietary, turn it into a play, wear it as > a hat, anything. Yes, but the original public domain bits are still public domain, and not covered by the GPL: http://www.gnu.org/licenses/gpl-faq.html#CombinePublicDomainWithGPL Legal or not, my personal opinion is that commingling public domain and GPL code is just asking for trouble. > > Note also that DJB's original copyright notice has been removed and I see no > > mention of his release of djbdns into the public domain. > > While it might be good to mention that it is based on the Public Domain djbdns, > there is no requirement that he do this. Also, there is no longer a copyright > notice, because when DJB put it into the Public Domain, he officially abandoned > copyright on the work. Your own comments: "This code is in the Public Domain, should not be a legal issue as long as it is marked properly in the spec file (which it is). Lifting FE-Legal." Has there some further legal review since you made those remarks? Required or not, I'd think it appropriate to reference DJB's explicit abandonment of his copyright when removing his original copyright notice.
The original public domain work is Public Domain. A modified, or derived work, can be under any license that the new author of the work wants. Since Public Domain is not a license, but the absence of a license (or if it helps you wrap your brain around it, the granting of all possible rights), it doesn't matter. My comments reflected upon an entirely Public Domain work, because we need to track that in the spec file somehow. If someone came along and made changes to a public domain work under GPLv2+, it would be fine to say: License: GPLv2+ because that is in every way functionally identical to: License: GPLv2+ and Public Domain As to removing DJB's copyright notice, DJB did that. It would be nice to reference his message in which he took that action.
(In reply to comment #17) > The original public domain work is Public Domain. A modified, or derived work, > can be under any license that the new author of the work wants. Since Public > Domain is not a license, but the absence of a license (or if it helps you wrap > your brain around it, the granting of all possible rights), it doesn't matter. Say there exists a source code file within pjp's djbdns-1.05.1.tar.gz that is identical to version in DJB's djbdns-1.05.tar.gz available at http://cr.yp.to/djbdns/djbdns-1.05.tar.gz. Are you saying that if that file is obtained from pjp's djbdns-1.05.1.tar.gz, the terms of the GPL apply if that file, and only that file, are incorporated in a further derived work? > As to removing DJB's copyright notice, DJB did that. It would be nice to > reference his message in which he took that action. DJB did not make this tarball available: http://pjp.dgplug.org/djbdns/djbdns-1.05.1.tar.gz which is a modified version his original djbdns-1.05 with a new README file that does not have his original copyright statement (But does have a copy of the GPL v3 in COPYING). Since pjp did, I think it would be prudent to also reference this URL and / or the statement found there relevant to djbdns in future releases: http://cr.yp.to/distributors.html Otherwise, I think somebody could get the idea that DJB released djbdns under the GPL, which is not the case. Also, if the License is intended to be GPLv2+, should COPYING really include v3?
Hello guys, Boy...wow, I was kind of expecting all this fuss over public-domain & licensing to happen when I included the COPYING file in the source. It feels like a Deja-vu now. :) > I think it would be prudent to also reference this URL and / or the statement > found there relevant to djbdns in future releases: > > http://cr.yp.to/distributors.html Anyway, Mark, I think it's okay to take a public domain soruce, change it and release it as licensed version. If I'm not wrong, I guess openDNS is based on `dnscache'. But still if you want me to put that link in the README, I'll do that. > Otherwise, I think somebody could get the idea that DJB released djbdns under > the GPL, which is not the case. Well that seems less likely, for one, the source is distributed from my page, and second the README quotes me says "I'm pleased to release this *new* version..." along with my email address. > Also, if the License is intended to be GPLv2+, should COPYING really include > v3? Ah, that should be okay; that's why the `+' sign is there. Thank you! PS: I'm kind of more looking forward to some technical review, folks.
(In reply to comment #19) > But still if you want me to put that link in the README, I'll do that. Please consider these files with the given link mentioned in the README and the spec file. SPEC: http://pjp.dgplug.org/djbdns/djbdns.spec SORC: http://pjp.dgplug.org/djbdns/djbdns-1.05.1.tar.gz SRPM: http://pjp.dgplug.org/djbdns/djbdns-1.05.1-2.fc10.src.rpm Thank you.
(In reply to comment #18) > Say there exists a source code file within pjp's djbdns-1.05.1.tar.gz that is > identical to version in DJB's djbdns-1.05.tar.gz available at > http://cr.yp.to/djbdns/djbdns-1.05.tar.gz. Are you saying that if that file is > obtained from pjp's djbdns-1.05.1.tar.gz, the terms of the GPL apply if that > file, and only that file, are incorporated in a further derived work? This is generally how the GPL works. If you take file A, which is under Public Domain (all rights granted to everyone) and file B, which is under some version of the GPL, and you compile them together to generate binary C, binary C is under the terms of the GPL, because the GPL is by far the more restrictive license, and the terms of file A are all being met by it. The same is true if file A is under a permissive license, such as MIT or BSD, because the GPL's coverage meets those terms. This is precisely why the FSF (and Fedora) tracks GPL compatiblity on other licenses. With some license pairings, this can get even trickier, because it may be possible for file A and file B to have licenses which have differing grants and restrictions, which, while neither prevents the other from being honored, results in the need to honor the terms of both A and B simultaneously (technically, we're always doing this, but when one covers both, we simplify it to one). In those cases, we note it in the spec file with a: License: Foo and Bar style notation. We also use that notation in cases like this: File A is MIT. It is compiled by itself into a standalone binary. File B, C, D, E, and F are all GPL. They get compiled together into a standalone binary. Both binaries end up in the same package. In this case, the spec License tag would be "MIT and GPL". > > As to removing DJB's copyright notice, DJB did that. It would be nice to > > reference his message in which he took that action. > > DJB did not make this tarball available: No, but I'm pretty sure the latest release for all of his code drops took out the copyright statement. He has also issued blanket DJB clearly understands US Public Domain law, as can be seen here: http://cr.yp.to/publicdomain.html He writes: "The normal way to abandon a copyright is to make a clear written dedication of the work to the public domain." He then does exactly this, here: http://cr.yp.to/distributors.html "What are the distribution terms for djbdns? 2007.12.28: I hereby place the djbdns package (in particular, djbdns-1.05.tar.gz, with MD5 checksum 3147c5cd56832aa3b41955c7a51cbeb2) into the public domain. The package is no longer copyrighted." Thus, there is no need to retain his copyright statement, as it clearly no longer applies. To re-add it would be incorrect and misleading. > Otherwise, I think somebody could get the idea that DJB released djbdns under > the GPL, which is not the case. Given that he has abandoned copyright entirely, he no longer has any say in what anyone does with it. > Also, if the License is intended to be GPLv2+, > should COPYING really include v3? No, but upstream should correct that mistake.
That sentence that trails off should be "blanket statements to this effect."
(In reply to comment #19) > Anyway, Mark, I think it's okay to take a public domain soruce, change it and > release it as licensed version. If I'm not wrong, I guess openDNS is based on > `dnscache'. But still if you want me to put that link in the README, I'll do > that. I don't think that "those other guys did it so it must be okay" is much of a justification. In any event, I'm just giving you advice. I've got zip for authority here. Consider it, ignore it, your call. > PS: I'm kind of more looking forward to some technical review, folks. Unfortunately, I'm afraid to examine your code closely for fear of being accused of being a GPL violator later on down the road. I will say that over the years, the djbdns community has identified and fixed a few issues. Such as the ones that hit the front page of Slashdot the other day. You might wish to take a look at those. While you may have no legal obligation to credit the originators of any of those fixes, personally, I'd consider it very rude not to do so. There is more to djbdns that dnscache. Somebody who wishes to use dnscache might not be interested in tinydns/axfrdns and vice versa (not to mention pickdns and walldns). I think Debian does package it all up in one bundle, but I don't know if it's all turned on by default when the package is installed. In the past, some RPM distributors have made separate packages for each djbdns component.
(In reply to comment #21) > This is generally how the GPL works. > > If you take file A, which is under Public Domain (all rights granted to > everyone) and file B, which is under some version of the GPL, and you compile > them together to generate binary C, binary C is under the terms of the GPL, > because the GPL is by far the more restrictive license, and the terms of file > A are all being met by it. I didn't ask about a hypothetical binary C. To use your terminology for this thought experiment, do the terms of the GPL apply to file A, if file A and only file A, is obtained from pjp's djbdns-1.05.1.tar.gz, which includes a copy of v3 of the GPL? > No, but I'm pretty sure the latest release for all of his code drops took out > the copyright statement. He has also issued blanket To my knowledge, the last release of djbdns was 8 years ago and he did not issue a new release when he abandoned his copyright. The tarball at: http://cr.yp.to/djbdns/djbdns-1.05.tar.gz still contains this in the README: djbdns 1.05 20010211 Copyright 2001 D. J. Bernstein > Thus, there is no need to retain his copyright statement, as it clearly no > longer applies. To re-add it would be incorrect and misleading. I did not say his copyright statement should be retained. I'm just trying to say that when it is removed (as it already has been), his declaration at http://cr.yp.to/distributors.html should be referenced explicitly. > Given that he has abandoned copyright entirely, he no longer has any say in > what anyone does with it. No, but it's no excuse to get sloppy and give people the wrong idea, either. I've got my own public domain fork of djbdns and I would very much appreciate it if pjp was very clear that the original material he based his fork on was public domain. In any event, we're seriously cluttering this bug/ticket up. Suggest we take any further discussions elsewhere or just table them.
Hey Mark, hi > I did not say his copyright statement should be retained. I'm just trying to > say that when it is removed (as it already has been), his declaration at > > http://cr.yp.to/distributors.html > > should be referenced explicitly. It's done, please see the latest files. > No, but it's no excuse to get sloppy and give people the wrong idea, either. > I've got my own public domain fork of djbdns and I would very much appreciate > it if pjp was very clear that the original material he based his fork on was > public domain. Sure, may be I'll put up a web-page to this effect in couple of days, guess that should be okay. Thanks.
(In reply to comment #24) > I didn't ask about a hypothetical binary C. To use your terminology for this > thought experiment, do the terms of the GPL apply to file A, if file A and only > file A, is obtained from pjp's djbdns-1.05.1.tar.gz, which includes a copy of > v3 of the GPL? Not solely by inclusion of COPYING, no, but upon first change, yes. Even if that change is the inclusion of the GPL license notice in the code's header. > To my knowledge, the last release of djbdns was 8 years ago and he did not > issue a new release when he abandoned his copyright. I stand corrected (on this point). > I did not say his copyright statement should be retained. I'm just trying to > say that when it is removed (as it already has been), his declaration at > > http://cr.yp.to/distributors.html > > should be referenced explicitly. Indeed, but this is a "should", rather than a "must". It would be polite to do so. To bring this back on topic, please make sure you've got this patch applied: http://marc.info/?l=djbdns&m=123613000920446&w=2
My thanks to Prasad for working on this. 1. Did I miss a trick during software build, or does Prasad's tarball Makefile so far build/install only dnscache, and not the six other binaries? (I've not looked closely; I just did ./configure; make; make install.) 2. From a very quick glance, I think Prasad has not yet applied quite a number of patches often recommended to fix djbdns and bring it up to current standards -- some of those fixing significant security issues. I have a list at http://linuxmafia.com/faq/Network_Other/dns-servers.html#djbdns-patches , and link to Jonathan de Boyne Pollard's and tinydns.org's separate pages. 3. It would be good if you could work with Mark Johnson (zinq-djbdns) and Gerrit Pape (Debian djbdns/dbndns). Although Dan is finally talking about an 1.06 version solely to fix the recent AXFR security problem, it seems highly likely that he'll ignore most other fixes, notably those he is known to dislike (e.g., FHS, GNU make-tools, system headers, manpages, IPv6, default dependency on ucspi-tcp and daemontools). So, a robust upstream elsewhere is crucial. 4. I applaud the measures Prasad is taking and says he'll take to make sure Dan's role remains properly credited and that people can find the non-copylefted upstream source if they want it. I second Mark Johnson in strongly suggesting care to credit other prior contributors, irrespective of obligation. 5. While wishing to avoid licence discussion here, I'll point out that "public domain" dedications have known legal problems albeit Dan's is probably good enough in context. My analysis: http://linuxmafia.com/faq/Licensing_and_Law/public-domain.html Perhaps Red Hat Legal should be consulted, though. (Whether his purporting to do that actually has the intended legal effect is subject to some doubt. Tom, yes, Dan does "understand" the portion of the law that he wants to acknowledge, but he's selective in what he acknowledges, and argues rather illogically with genuine experts like Larry Rosen when they say things he finds convenient.)
I really do not want this bugzilla ticket to be a forum for folks to draw up sides on legal issues. Rick, I have a huge amount of respect for you and Larry, but I disagree with your assessment, as does Red Hat Legal. If you'd like to discuss this off-bugzilla, I'd be happy to do so.
Thanks for that, Tom. Good idea. And yes, I'd be delighted to hear, by e-mail, your and Red Hat Legal's take on either PD dedications generally, or just on Dan's. (As a practical matter, I do think it very likely, in any event, that judges would implement Dan's approximate intention in some manner, if not the way he intended. And I think it vanishingly likely to ever be litigated, anyway.)
(I meant "unlikely", just as I meant "inconvenient" in the earlier post. Sorry; not enough coffee.)
Just thought I'd add my feeling that if significant enough changes are being made to warrant a new version number beyond what's officially released as "djbdns" AND you want to apply a license to it you might seriously consider changing the name of your incarnation to something else. Especially since a new release of djbdns from the real djbdns author is forthcoming. I know it's public domain and pretty much anything goes but I think it would be a nice courtesy. Plus, people who use the "real" djbdns would appreciate the lack of confusion.
Hello there, (In reply to comment #25) > Sure, may be I'll put up a web-page to this effect in couple of days, guess > that should be okay. Please see: http://pjp.dgplug.org/djbdns Thank you.
Hello Rick, First of all thanks a million for your comments, I deeply appreciate it. (In reply to comment #27) > 1. Did I miss a trick during software build, or does Prasad's tarball > Makefile so far build/install only dnscache, and not the six other > binaries? (I've not looked closely; I just did ./configure; make; make > install.) Well no, you didn't miss any steps. It's just that, so far I've only been able to change dnscacahe. Though the work is in good progress for others, and soon I'll include them as well. > 2. From a very quick glance, I think Prasad has not yet applied quite a > number of patches often recommended to fix djbdns and bring it up to > current standards -- some of those fixing significant security issues. I have > a list at > http://linuxmafia.com/faq/Network_Other/dns-servers.html#djbdns-patches , > and link to Jonathan de Boyne Pollard's and tinydns.org's separate pages. Thanks Rick! That's the kind of inputs I'm looking for. I'll see to it that all those patches are applied, with due credits to the original authors. Thanks so much.
(In reply to comment #31) > Just thought I'd add my feeling that if significant enough changes are being > made to warrant a new version number beyond what's officially released as > "djbdns" AND you want to apply a license to it you might seriously consider > changing the name of your incarnation to something else. Especially since a new > release of djbdns from the real djbdns author is forthcoming. Well, yeah I understand the point. But so far I've not changed so much as to warrant a name change. Thanks.
Hello all, It's a pleasure to announce the second release of `djbdns' I've been working on. Please have a look at: http://pjp.dgplug.org/djbdns And for package review SPEC: http://pjp.dgplug.org/djbdns/djbdns.spec SORC: http://pjp.dgplug.org/djbdns/djbdns-1.05.2.tar.gz SRPM: http://pjp.dgplug.org/djbdns/djbdns-1.05.2-1.fc10.src.rpm Thank you.
Hi, I'm *happy* to announce the new release of djbdns-1.05.3. Please take a look at: http://pjp.dgplug.org/djbdns And for package review SPEC: http://pjp.dgplug.org/djbdns/djbdns.spec SORC: http://pjp.dgplug.org/djbdns/djbdns-1.05.3.tar.gz SRPM: http://pjp.dgplug.org/djbdns/djbdns-1.05.3-1.fc10.src.rpm Thank you.
Please change the name. :(
Unofficial review: [?] The spec file from spec link does not match spec file provided in srpm ?? [?] Naming guideline: fine, but as you have branched an existing project and changed it lot, it needs to be renamed. [x] Builds successfully http://koji.fedoraproject.org/koji/taskinfo?taskID=1611918 [x] License: Checked [x] rpmlint bash-4.0$ rpmlint djbdns-1.05.3-1.fc11.i586.rpm djbdns.i586: W: conffile-without-noreplace-flag /etc/djbdns/tinydns.conf djbdns.i586: W: conffile-without-noreplace-flag /etc/djbdns/servers/@ djbdns.i586: W: conffile-without-noreplace-flag /etc/djbdns/dnscache.conf Two conf files need to have noreplace flag in %files section like %config(noreplace) /etc/your_config_file_here djbdns.i586: E: zero-length /etc/djbdns/ip/127.0.0.1 [?] Looks like this place will be populated by more empty files for some functionality, but placing all of them in /etc/ does not make sense. djbdns.i586: W: non-conffile-in-etc /etc/djbdns/ip/127.0.0.1 djbdns.i586: W: dangerous-command-in-%post ln djbdns.i586: W: dangerous-command-in-%preun rm 1 packages and 0 specfiles checked; 1 errors, 6 warnings. bash-4.0$ du -sh djbdns-debuginfo-1.05.3-1.fc11.i586.rpm 436K djbdns-debuginfo-1.05.3-1.fc11.i586.rpm file djbdns-1.05.3-1.fc11.i586/etc/djbdns/servers/@ lists root dns but name '@' should be changed to something meaningful. The package has too many servers and client side tools. It would make more sense to package them as subpackages so that anyone who say wants to run tinydns does not have to download whole djbdns tools in a single package. [?] Use %preun if [ $1 -eq 0 ] ; then /sbin/chkconfig --del %{name} fi in preun section and no need to create sym link. Simply install djbdns in /etc/init.d/ in %install section e.g mkdir -p $RPM_BUILD_ROOT/etc/init.d/ mv $RPM_BUILD_ROOT/%{_bindir}/djbns / $RPM_BUILD_ROOT/etc/init.d/ and include file in %files section [?] The package does not own all directories e.g /etc/djbdns, /etc/djbdns/ip, /etc/djbdns/servers/ bash-4.0$ rpmls djbdns-1.05.3-1.fc11.i586.rpm -rw-r--r-- /etc/djbdns/dnscache.conf -rw-r--r-- /etc/djbdns/ip/127.0.0.1 -rw-r--r-- /etc/djbdns/servers/@ -rw-r--r-- /etc/djbdns/tinydns.conf -------------------------------------------------- needs some fix in %files section List: [?] rpmlint done check above [x] Package Naming Guidelines: OKay -But it is better to rename it. [x] Basepackage name matches spec name [?] License: Fine Suggestion: Add license block at top in all source files. It seems after re-licensing you have just updated license blocks in files which you have modified. Other files should also get this block. [x] License file in spec matches actual licenses mentioned in wiki [?] Does not look like you are using RPM_OPT_FLAGS flags for compilation. [x] spec file written in American English [x] Legible [x] Builds on ppc, ppc64, i586, x86_64 [?] Does not own all directories [x] Extra Suggestions (unless you want this package to be imported into EPEL): 1. You can remove rm -rf $RPM_BUILD_ROOT from %install section - Not required any more 2. You can also remove BuildRoot ?: Needs attention x: OKay
I can help with this one: > The package has too many servers and client side tools. It would make more > sense to package them as subpackages so that anyone who say wants to run > tinydns does not have to download whole djbdns tools in a single package. I've made ma own rpm long time ago which is divided to several subpackages. You can inspire from it. It is made for centos but it's useful for fedora too. this is list: djbdns-axfrdns-1.05-5.el5.i386.rpm djbdns-debuginfo-1.05-5.el5.i386.rpm djbdns-devel-1.05-5.el5.i386.rpm djbdns-dnscache-1.05-5.el5.i386.rpm djbdns-docs-1.05-5.el5.i386.rpm djbdns-man-1.05-5.el5.noarch.rpm djbdns-pickdns-1.05-5.el5.i386.rpm djbdns-rbldns-1.05-5.el5.i386.rpm djbdns-tinydns-1.05-5.el5.i386.rpm djbdns-tools-1.05-5.el5.i386.rpm djbdns-walldns-1.05-5.el5.i386.rpm Spec file is here: http://ftp-hk.tmapy.cz/tmapy-twist/centos/5/os/SRPMS/djbdns-1.05-5.el5.src.rpm There are other support packages too (daemontools, ucspi*).
(In reply to comment #39) > I've made ma own rpm long time ago which is divided to several subpackages. You > can inspire from it. It is made for centos but it's useful for fedora too. > > http://ftp-hk.tmapy.cz/tmapy-twist/centos/5/os/SRPMS/djbdns-1.05-5.el5.src.rpm Thank you so much Pavel; I'll take a look at the srpm and do the necessary. Thank you.
Hi, I've made most of the changes indicated in the *brilliant* review above, except for the sub package and name change part. I tried doing that as well, but I think it'll become more complex with so many rpm/subpackages and in turn be less intuitive for users. So it'll be better to install all tools/servers/docs from one rpm. Simple and straight forward. Please take a look at the latest files: SPEC: http://pjp.dgplug.org/djbdns/djbdns.spec SORC: http://pjp.dgplug.org/djbdns/djbdns-1.05.3.tar.gz SRPM: http://pjp.dgplug.org/djbdns/djbdns-1.05.3-2.fc10.src.rpm Thanks so much.
And why not the name change?
Hi pjp. you're shipping cbd [1] inside djbdns, I have ported cdb to gnu-autotools and make it as shared library, what you think about linking in it and removing cbd code inside of djbdns ? 1 - http://cr.yp.to/cdb/install.html
Hey, hello Itamar, (In reply to comment #43) > you're shipping cbd [1] inside djbdns, I have ported cdb to gnu-autotools and > make it as shared library, what you think about linking in it and removing cbd > code inside of djbdns? Sure, that sounds reasonable. Nonetheless as I see, it won't be fast or easy change to do. Plus linking with external library means having a dependency on that package. So if you don't mind, I would like to be sure about few things, - does your shared library works on all operating systems, both 32/64 bit Linux/*BSD/Solaris etc. and all innumerable dirstributions of each? If not, I suggest *please* aim for that. - Is it packaged for any distribution? And does it have enough *useful* documentation for each API you provide. - Are you up for maintaining and supporting the library as long as it is in use? For it should not happen that I remove the code from djbdns source, start using the library and then one day you stop maintaining the library and then I'll be stuck somewhere nowhere. Besides that I'll need your help to do the actual transition. Thanks so much. PS: can I have a look at the library source?
I have inspected the proposed packaging of djbdns and am delighted that somebody has decided to get it into Fedora. To help make the package better, I have a few suggestions. First, as the package does not use DJB's daemontools to manage the services it provides, it requires initscripts for that purpose. Only one initscript is included in the package, however, and it is named "djbdns", making unclear which of the services it controls (it's dnscache). The initscript for tinydns, for example, is missing. Recommendation: include one initscript per service and make the names of the initscripts match the services they control. Second, the package is missing some important parts of djbdns -- axfdns, walldns, and rbldns, for example. While these parts are probably used less often than dnscache or tinydns, they are well established within DJB's bundle, and most people will expect them to be included in any package calling itself "djbdns". Recommendation: include the missing pieces. Third, I must agree with Satya Komaragiri about the need for subpackages. It's very common to need only one part of djbdns for any particular install, either dnscache (for a site needing a local, recursive DNS cache), tinydns (for a site needing a content DNS server to publish its public records), or the tools (for administration and debugging). To place all of these in one package will contribute clutter to the typical install. (This problem wasn't so bad in DJB's bundle because it didn't use initscripts, but we do, and installing 5 initscripts when the typical sysadmin will need only 1 seems excessive.) Recommendation: split the package into logical subpackages, following Pavel Lisý's scheme, which makes a lot of sense from an administrator's point of view (and ought to be immediately understandable to anyone familiar with how to deploy from DJB's bundle). Fourth, DJB's bundle relied upon the multilog program from daemontools to handle logging, whereas our proposed package writes to log files directly. But multilog did more than just write to files; it also inserted timestamps, which our logs lack. Timestamps are essential in system logs, so we must put them back in somehow. Maybe we could use syslog or bring back multilog. Recommendation: Restore the timestamps in logs. This package is looking great. I think it's just a few tweaks away from being both a good Fedora package and a faithful representation of everything that made DJB's bundle great. Keep up the good work! Cheers, Tom
Hello Tom, First of all thank you so much for your suggestions, I really appreciate it. (In reply to comment #45) > Recommendation: include one initscript per service and make the names of > the initscripts match the services they control. Okay, I'll do the changes. > Second, the package is missing some important parts of djbdns -- axfdns, > walldns, and rbldns, for example. While these parts are probably used less > often than dnscache or tinydns, they are well established within DJB's bundle, > and most people will expect them to be included in any package calling itself > "djbdns". Recommendation: include the missing pieces. Yes, they are in the queue and will be released in due course. > Recommendation: split the package into logical subpackages, > following Pavel Lisý's scheme, which makes a lot of sense from an > administrator's point of view (and ought to be immediately understandable > to anyone familiar with how to deploy from DJB's bundle). I understand the point, but when I look at so many rpms/subpackages, it just appears to be confusing to me. Anyway, I'll look at the sub-packaging again and try to do it. I was confused about, the few client tools like dnsip/dnsq/dnsname etc. and with which server(dnscache/tinydns) should I package them or to make a separate sub package for them. > Fourth, DJB's bundle relied upon the multilog program from daemontools to > handle logging, whereas our proposed package writes to log files directly. > But multilog did more than just write to files; it also inserted timestamps, > which our logs lack. Timestamps are essential in system logs, so we must > put them back in somehow. Maybe we could use syslog or bring back multilog. > Recommendation: Restore the timestamps in logs. Yeah, I'm working on the logging part as well, will do the necessary changes. > This package is looking great. I think it's just a few tweaks away from being > both a good Fedora package and a faithful representation of everything that > made DJB's bundle great. Keep up the good work! Thanks a lot Tom, I sincerely appreciate it. Thank you.
Note that axfrdns is really desired if you are using tinydns, as it handles fallback to tcp. Multilog also handles rotating the logfiles. It also handles a full disk in a way that DJB thought reasonable, though not everyone may want it to work that way.
This ticket is waiting for development from upstream and it would make sense to defer it for time till all changes are done. This has become an upstream devel mailing list.
No comments for long. Waiting for upstream work to complete. Will close it for now.
Hi, After long-long time I could again get back to this one. Please have a look at the latest files for review. SPEC: http://pjp.dgplug.org/djbdns/djbdns.spec SORC: http://pjp.dgplug.org/djbdns/djbdns-1.05.4.tar.gz SRPM: http://pjp.dgplug.org/djbdns/djbdns-1.05.4-2.fc14.src.rpm Thank you.
Hi, I've changed the project name to ndjbdns: New djbdns. Also, fixed few packaging errors. Please have a look at SPEC: http://pjp.dgplug.org/djbdns/ndjbdns.spec SRPM: http://pjp.dgplug.org/djbdns/ndjbdns-1.05.4-3.fc14.src.rpm Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=3232097 Thank you.
Hi, Please have a look at these new files which install the systemd(1) service unit files. SPEC: http://pjp.dgplug.org/djbdns/ndjbdns.spec SRPM: http://pjp.dgplug.org/djbdns/ndjbdns-1.05.4-4.fc16.src.rpm Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=3815910 Thank you.
No need to specify BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX) anymore. Any reason you are not using %configure macro Since all current releases of Fedora are using systemd by default, you can drop the sysvinit scripts entirely. Also you need to do BuildRequires: systemd-units
Hi, I've made the changes, please see: SPEC: http://pjp.dgplug.org/djbdns/ndjbdns.spec SRPM: http://pjp.dgplug.org/djbdns/ndjbdns-1.05.4-5.fc16.src.rpm Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=3827635 Thanks you!
Is this necessary? -- export CFLAGS="$CFLAGS $RPM_OPT_FLAGS" The following is redundant: rm -rf $RPM_BUILD_ROOT %clean rm -rf $RPM_BUILD_ROOT %defattr(-,root,root,-) Although not a blocker, I strongly urge you to consider renaming filepaths with the project name. /etc/ndjbdns instead of /etc/djbdns for instance to avoid confusion with the original project.
(In reply to comment #55) > Although not a blocker, I strongly urge you to consider renaming filepaths with > the project name. /etc/ndjbdns instead of /etc/djbdns for instance to avoid > confusion with the original project. Yep done. Please see SPEC: http://pjp.dgplug.org/djbdns/ndjbdns.spec SRPM: http://pjp.dgplug.org/djbdns/ndjbdns-1.05.4-6.fc16.src.rpm Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=3844111 Thanks so much!
Sorry for the delay. Here is a more detailed review; You should change the license header to specify the version info that matches the license tag in the spec file * I've modified this file for good and am releasing this new version under * GNU General Public License. * Copyright (C) 2009 - 2011 Prasad J Pandit This has to say GNU General Public License version 2 or later. It does say that below so this is a bit redundant. I won't insist on it but I recommend that. mkdir -p $RPM_BUILD_ROOT/%{_unitdir} mv dnscache.service $RPM_BUILD_ROOT/%{_unitdir}/ mv tinydns.service $RPM_BUILD_ROOT/%{_unitdir}/ You should probably do the above in the makefile itself since you are upstream and add a dependency list in the upstream source, say in the README file that specifies that the source depends on systemd. You should remove the reference to service framework in the spec file description If cdb is nominally considered to be a separate library, static linking requires a exception from the Fedora packaging committee. Otherwise, you need to split that up and package it separately. ndjbdns.x86_64: W: no-manual-page-for-binary dnsipq ndjbdns.x86_64: W: no-manual-page-for-binary tinydnsd ndjbdns.x86_64: W: no-manual-page-for-binary dnstxt ndjbdns.x86_64: W: no-manual-page-for-binary dnscached ndjbdns.x86_64: W: no-manual-page-for-binary tcprules ndjbdns.x86_64: W: no-manual-page-for-binary axfrdns-conf ndjbdns.x86_64: W: no-manual-page-for-binary dnstracesort ndjbdns.x86_64: W: no-manual-page-for-binary dnstrace ndjbdns.x86_64: W: no-manual-page-for-binary randomip ndjbdns.x86_64: W: no-manual-page-for-binary axfrdns ndjbdns.x86_64: W: no-manual-page-for-binary dnsmx ndjbdns.x86_64: W: no-manual-page-for-binary dnsname ndjbdns.x86_64: W: no-manual-page-for-binary axfr-get ndjbdns.x86_64: W: no-manual-page-for-binary dnsqr Ideally all binaries need to include man pages. The purpose of these binaries are currently undocumented in the source. Address these concerns and I will approve you. Thanks.
(In reply to comment #57) > * I've modified this file for good and am releasing this new version under > * GNU General Public License. > * Copyright (C) 2009 - 2011 Prasad J Pandit Yep, removed. > mkdir -p $RPM_BUILD_ROOT/%{_unitdir} > mv dnscache.service $RPM_BUILD_ROOT/%{_unitdir}/ > mv tinydns.service $RPM_BUILD_ROOT/%{_unitdir}/ > You should probably do the above in the makefile itself In the Makefile it may not fit, for not all systems have systemd(1) support. > If cdb is nominally considered to be a separate library, static linking > requires a exception from the Fedora packaging committee. cdb is not installed separately. It'll be some work + time to separate it from the main source. I'll urge you to approve the package while I continue work towards linking cdb dynamically. > ndjbdns.x86_64: W: no-manual-page-for-binary dnsipq > ndjbdns.x86_64: W: no-manual-page-for-binary tinydnsd > ndjbdns.x86_64: W: no-manual-page-for-binary dnstxt > ndjbdns.x86_64: W: no-manual-page-for-binary dnscached > ndjbdns.x86_64: W: no-manual-page-for-binary tcprules > ndjbdns.x86_64: W: no-manual-page-for-binary axfrdns-conf > ndjbdns.x86_64: W: no-manual-page-for-binary dnstracesort > ndjbdns.x86_64: W: no-manual-page-for-binary dnstrace > ndjbdns.x86_64: W: no-manual-page-for-binary randomip > ndjbdns.x86_64: W: no-manual-page-for-binary axfrdns > ndjbdns.x86_64: W: no-manual-page-for-binary dnsmx > ndjbdns.x86_64: W: no-manual-page-for-binary dnsname > ndjbdns.x86_64: W: no-manual-page-for-binary axfr-get > ndjbdns.x86_64: W: no-manual-page-for-binary dnsqr I've added all the manuals except for dnstracesort(1). It is a small shell script to sort the output of dnstrace(1) command. I've documented it in the manual of dnstrace(1) command. Please see: SPEC: http://pjp.dgplug.org/djbdns/ndjbdns.spec SRPM: http://pjp.dgplug.org/djbdns/ndjbdns-1.05.4-7.fc16.src.rpm Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=3878658
APPROVED There are several other code improvements suggested in this review that you should look at but they aren't blockers to getting this in the repository. So I am approving this and recommend that you go through the history of this review and apply patches and changes from branches/forks of djbdns as applicable.
OMG...such a *bliss* to see this approved! Thank you so much! :)
(In reply to comment #59) > There are several other code improvements suggested in this review that you > should look at but they aren't blockers to getting this in the repository. So > I am approving this and recommend that you go through the history of this > review and apply patches and changes from branches/forks of djbdns as > applicable. Yes, I'll do that. Once again, thanks a lot! :)
New Package SCM Request ======================= Package Name: ndjbdns Short Description: New djbdns. Owners: pjp Branches: f15 f16 el6 InitialCC:
You are welcome. Couple of quick notes before you import: * List the binaries individually rather than use a wildcard * If you are creating log files in /var/log by default, you should run logrotate on them. See other spec files for examples. say httpd.spec * You might want to change the upstream url to ndjbdns as well to avoid any confusion with the original source.
(In reply to comment #63) > You are welcome. Couple of quick notes before you import: > > * List the binaries individually rather than use a wildcard > > * If you are creating log files in /var/log by default, you should run > logrotate on them. See other spec files for examples. say httpd.spec > > * You might want to change the upstream url to ndjbdns as well to avoid any > confusion with the original source. Yes, I'll do these before the upcoming release. Thank you.
Git done (by process-git-requests). Added f17.
ndjbdns-1.05.4-9.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/ndjbdns-1.05.4-9.fc16
ndjbdns-1.05.4-9.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/ndjbdns-1.05.4-9.fc17
ndjbdns-1.05.4-9.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/ndjbdns-1.05.4-9.fc15
ndjbdns-1.05.4-9.fc17 has been pushed to the Fedora 17 testing repository.
ndjbdns-1.05.4-9.fc15 has been pushed to the Fedora 15 stable repository.
ndjbdns-1.05.4-9.fc16 has been pushed to the Fedora 16 stable repository.
Please see: -> http://pjp.dgplug.org/ndjbdns -> https://pjps.wordpress.com/2012/03/28/new-djbdns Mission accomplished...YAY!!! :)
ndjbdns-1.05.4-9.fc17 has been pushed to the Fedora 17 stable repository.
Package Change Request ====================== Package Name: ndjbdns New Branches: el5 el6 Owners: pjp slaanesh
Git done (by process-git-requests).