Bug 480724 - Review Request: ndjbdns - New djbdns, usable djbdns.
Summary: Review Request: ndjbdns - New djbdns, usable djbdns.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Rahul Sundaram
QA Contact: Fedora Extras Quality Assurance
URL: http://pjp.dgplug.org/djbdns/ndjbdns-...
Whiteboard:
: 488681 (view as bug list)
Depends On: daemontools
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-01-20 06:09 UTC by pjp
Modified: 2013-01-03 22:07 UTC (History)
15 users (show)

Fixed In Version: ndjbdns-1.05.4-9.fc17
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-26 03:58:00 UTC
Type: ---
Embargoed:
metherid: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)

Description pjp 2009-01-20 06:09:42 UTC
`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.

Comment 1 pjp 2009-01-20 06:26:57 UTC
Daemontools  package is open for review

at: https://bugzilla.redhat.com/show_bug.cgi?id=480727

Comment 2 Ralf Corsepius 2009-01-20 07:27:09 UTC
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.

Comment 3 Ralf Corsepius 2009-01-20 08:01:21 UTC
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.

Comment 4 pjp 2009-01-20 09:26:06 UTC
(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.

Comment 5 Itamar Reis Peixoto 2009-02-06 11:30:55 UTC
Ralf 

you can remove FE-LEGAL

http://www.redhat.com/archives/fedora-legal-list/2007-November/msg00023.html

Comment 6 Tom "spot" Callaway 2009-02-12 18:38:59 UTC
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.

Comment 7 Mark Johnson 2009-03-02 22:09:30 UTC
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.

Comment 8 pjp 2009-03-05 07:14:05 UTC
New review request: https://bugzilla.redhat.com/show_bug.cgi?id=488681

Comment 9 Itamar Reis Peixoto 2009-03-05 11:52:16 UTC
*** Bug 488681 has been marked as a duplicate of this bug. ***

Comment 10 Itamar Reis Peixoto 2009-03-05 11:54:54 UTC
you don't need a new review request for the same package.

Comment 11 pjp 2009-03-05 12:37:00 UTC
(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

Comment 12 Mark Johnson 2009-03-05 17:01:40 UTC
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?

Comment 13 Mark Johnson 2009-03-05 17:04:30 UTC
(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?

Comment 14 Mark Johnson 2009-03-05 18:36:40 UTC
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.

Comment 15 Tom "spot" Callaway 2009-03-05 18:43:35 UTC
(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.

Comment 16 Mark Johnson 2009-03-05 19:34:42 UTC
(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.

Comment 17 Tom "spot" Callaway 2009-03-05 20:34:45 UTC
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.

Comment 18 Mark Johnson 2009-03-05 21:34:17 UTC
(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?

Comment 19 pjp 2009-03-06 04:52:40 UTC
   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.

Comment 20 pjp 2009-03-06 05:54:58 UTC
(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.

Comment 21 Tom "spot" Callaway 2009-03-06 13:42:47 UTC
(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.

Comment 22 Tom "spot" Callaway 2009-03-06 13:44:24 UTC
That sentence that trails off should be "blanket statements to this effect."

Comment 23 Mark Johnson 2009-03-06 16:17:46 UTC
(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.

Comment 24 Mark Johnson 2009-03-06 17:11:55 UTC
(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.

Comment 25 pjp 2009-03-06 17:27:47 UTC
  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.

Comment 26 Tom "spot" Callaway 2009-03-06 18:49:58 UTC
(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

Comment 27 Rick Moen 2009-03-06 22:22:15 UTC
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.)

Comment 28 Tom "spot" Callaway 2009-03-06 22:34:40 UTC
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.

Comment 29 Rick Moen 2009-03-06 22:45:13 UTC
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.)

Comment 30 Rick Moen 2009-03-06 22:46:31 UTC
(I meant "unlikely", just as I meant "inconvenient" in the earlier post. Sorry; not enough coffee.)

Comment 31 Dan Peterson 2009-03-07 03:58:47 UTC
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.

Comment 32 pjp 2009-03-09 05:48:55 UTC
  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.

Comment 33 pjp 2009-03-09 06:07:16 UTC
  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.

Comment 34 pjp 2009-03-09 06:14:25 UTC
(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.

Comment 35 pjp 2009-03-23 09:03:24 UTC
   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.

Comment 36 pjp 2009-08-17 10:14:55 UTC
  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.

Comment 37 Dan Peterson 2009-08-17 11:31:09 UTC
Please change the name. :(

Comment 38 Satya Komaragiri 2009-08-18 14:04:03 UTC
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

Comment 39 Pavel Lisý 2009-08-18 15:37:39 UTC
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*).

Comment 40 pjp 2009-08-19 04:54:47 UTC
(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.

Comment 41 pjp 2009-08-19 12:59:48 UTC
  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.

Comment 42 Dan Peterson 2009-08-19 13:41:49 UTC
And why not the name change?

Comment 43 Itamar Reis Peixoto 2009-08-21 01:02:37 UTC
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

Comment 44 pjp 2009-08-21 06:02:52 UTC
  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?

Comment 45 Tom Moertel 2009-08-22 18:41:29 UTC
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

Comment 46 pjp 2009-08-25 09:32:44 UTC
  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.

Comment 47 Bruno Wolff III 2009-08-25 14:45:28 UTC
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.

Comment 48 Rakesh Pandit 2009-09-14 05:31:15 UTC
 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.

Comment 49 Rakesh Pandit 2009-12-09 10:51:09 UTC
No comments for long. Waiting for upstream work to complete. Will close it for now.

Comment 50 pjp 2011-04-11 04:54:33 UTC
  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.

Comment 51 pjp 2011-07-26 18:21:10 UTC
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.

Comment 52 pjp 2012-02-24 16:27:06 UTC
  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.

Comment 53 Rahul Sundaram 2012-02-28 03:08:38 UTC
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

Comment 55 Rahul Sundaram 2012-03-01 15:59:27 UTC
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.

Comment 56 pjp 2012-03-01 20:50:25 UTC
(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!

Comment 57 Rahul Sundaram 2012-03-09 18:37:42 UTC
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.

Comment 58 pjp 2012-03-10 20:51:35 UTC
(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

Comment 59 Rahul Sundaram 2012-03-11 07:53:16 UTC
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.

Comment 60 pjp 2012-03-11 16:07:03 UTC
OMG...such a *bliss* to see this approved!

Thank you so much! :)

Comment 61 pjp 2012-03-11 16:26:07 UTC
(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! :)

Comment 62 pjp 2012-03-11 17:43:28 UTC
New Package SCM Request
=======================
Package Name: ndjbdns
Short Description: New djbdns.
Owners: pjp
Branches: f15 f16 el6
InitialCC:

Comment 63 Rahul Sundaram 2012-03-11 17:47:28 UTC
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.

Comment 64 pjp 2012-03-12 10:18:32 UTC
(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.

Comment 65 Gwyn Ciesla 2012-03-12 11:59:07 UTC
Git done (by process-git-requests).

Added f17.

Comment 66 Fedora Update System 2012-03-15 11:45:07 UTC
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

Comment 67 Fedora Update System 2012-03-15 11:45:24 UTC
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

Comment 68 Fedora Update System 2012-03-15 11:45:56 UTC
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

Comment 69 Fedora Update System 2012-03-16 02:45:23 UTC
ndjbdns-1.05.4-9.fc17 has been pushed to the Fedora 17 testing repository.

Comment 70 Fedora Update System 2012-03-26 03:58:00 UTC
ndjbdns-1.05.4-9.fc15 has been pushed to the Fedora 15 stable repository.

Comment 71 Fedora Update System 2012-03-26 17:53:02 UTC
ndjbdns-1.05.4-9.fc15 has been pushed to the Fedora 15 stable repository.

Comment 72 Fedora Update System 2012-03-26 17:57:33 UTC
ndjbdns-1.05.4-9.fc16 has been pushed to the Fedora 16 stable repository.

Comment 73 pjp 2012-03-27 19:41:49 UTC
Please see:

 -> http://pjp.dgplug.org/ndjbdns
 -> https://pjps.wordpress.com/2012/03/28/new-djbdns

Mission accomplished...YAY!!! :)

Comment 74 Fedora Update System 2012-04-12 03:11:13 UTC
ndjbdns-1.05.4-9.fc17 has been pushed to the Fedora 17 stable repository.

Comment 75 pjp 2012-12-23 18:51:20 UTC
Package Change Request
======================
Package Name: ndjbdns
New Branches: el5 el6
Owners: pjp slaanesh

Comment 76 Gwyn Ciesla 2012-12-24 13:41:50 UTC
Git done (by process-git-requests).


Note You need to log in before you can comment on or make changes to this bug.