Bug 480727 (daemontools)

Summary: Review Request: daemontools: is a collection of tools for managing UNIX services.
Product: [Fedora] Fedora Reporter: pjp <pj.pandit>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: fedora-package-review, itamar, notting, rc040203, redhat
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
URL: http://cr.yp.to/daemontools/daemontools-0.76.tar.gz
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-02-06 03:57:44 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 480724    

Description pjp 2009-01-20 01:21:48 EST
daemontools is a collection of tools for managing UNIX services.

supervise monitors a service. It starts the service and restarts the service
if it dies. Setting up a new service is easy: all supervise needs is a
directory with a run script that runs the service.

multilog saves error messages to one or more logs. It optionally timestamps
each line and, for each log, includes or excludes lines matching specified
patterns. It automatically rotates logs to limit the amount of disk space used.
If the disk fills up, it pauses and tries again, without losing any data.  

SPEC: http://pjp.dgplug.org/tools/daemontools.spec
SORC: http://pjp.dgplug.org/tools/daemontools-0.76.tar.gz
SRPM: http://pjp.dgplug.org/tools/daemontools-0.76-1.fc10.src.rpm

Daemontools is required by another package called `djbdns', which is open for
review

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

I hereby request the reviewers to vet both the packages.

Thank you!
Comment 1 Itamar Reis Peixoto 2009-01-20 01:34:13 EST
this is your first package ?
Comment 2 Mamoru TASAKA 2009-01-20 01:43:52 EST
I am the sponsor of the submitter.
Comment 3 Ralf Corsepius 2009-01-20 02:16:16 EST
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 4 Ralf Corsepius 2009-01-20 02:26:57 EST
Sorry, comment #3 was addressing djbdns 
(https://bugzilla.redhat.com/show_bug.cgi?id=480724)

Re-adding comment there.
Comment 5 Ralf Corsepius 2009-01-20 03:02:03 EST
The same as with dbjdns, Debian's link:

http://packages.debian.org/changelogs/pool/main/d/daemontools/daemontools_0.76-3/daemontools.copyright

=> Put a similar document as Debian does into your rpm.
Comment 6 pjp 2009-01-20 04:15:03 EST
  Hello Ralf, that was real quick, thanks.

(In reply to comment #3)
> * %files
> /usr/local/etc/*
> /usr/local/bin/*
> => Distro packages must not contrain files below /usr/local

  But that's the prefix where files get installed. What do you suggest /usr?
 
> * Package doesn't seem to honor RPM_OPT_FLAGS.

   Flags like?

> * *.tar.gz doesn't match upstream (http://cr.yp.to/djbdns/djbdns-1.05.tar.gz)

  Yep, I had to do some changes to get a clean compile && install.
 
> * 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.

  I don't think there are any legal issues, for djb has declared it as a 
Public Domain work. But still please correct me if I'm wrong.

> Finally: Does this package still have an active upstream? 
> I thought, DJB discontinued all his works.

   That's right, it's development has seized since 2007, I guess.

please see: http://cr.yp.to/distributors.html

Thanks!
Comment 7 Itamar Reis Peixoto 2009-01-20 05:04:10 EST
>   Yep, I had to do some changes to get a clean compile && install.

include small patch'es

here are a example to generate a patch


diff -ruNp daemontools-0.76.old daemontools-0.76.new > fix_xyz.patch

or

diff -ruNp daemontools-0.76.old/file daemontools-0.76.new/file > fix_xyz_file.patch

I recommend you to work with daemontools first and after you get this package approved then start the work with djbdns.
Comment 8 pjp 2009-01-21 01:00:30 EST
> include small patch'es

  include small patches and send to whom? I'm not sure if djb(or anybody) is
actively maintaining it to apply those patches.


> I recommend you to work with daemontools first and after you get this package
> approved then start the work with djbdns.

  Right, I understand. I too was thinking about the same.

Thanks!
Comment 9 Ralf Corsepius 2009-01-21 01:30:46 EST
(In reply to comment #8)
> > include small patch'es
> 
>   include small patches and send to whom?
Nowhere.

You are supposed to use the original tarballs + patches inside of your rpm.
Comment 10 pjp 2009-01-21 04:05:02 EST
> Nowhere. You are supposed to use the original tarballs + patches inside of
> your rpm.

  Why? I don't think that's a good idea. I think it'll be easy for me to
maintain the patched sources, may be on my local svn.
Comment 11 Itamar Reis Peixoto 2009-01-21 04:58:39 EST
(In reply to comment #10)

>   Why? I don't think that's a good idea. I think it'll be easy for me to
> maintain the patched sources, may be on my local svn.

it's more easy to track what's changed if you "use the original tarballs + patches inside of your rpm.", and if you like your package reviewed please work in this way

include small patchs like daemontools-0.76-errno.patch and others
Comment 12 pjp 2009-01-21 06:19:40 EST
> it's more easy to track what's changed if you "use the original tarballs +
> patches inside of your rpm.", and if you like your package reviewed please
> work in this way

  Uff...alright; I've made the changes. Please have a loot at the following

SPEC: http://pjp.dgplug.org/tools/daemontools.spec
SRPM: http://pjp.dgplug.org/tools/daemontools-0.76-1.fc10.src.rpm

Thank you.
Comment 13 pjp 2009-01-21 06:56:15 EST
Please consider this new

SRPM: http://pjp.dgplug.org/tools/daemontools-0.76-2.fc10.src.rpm

Thank you.
Comment 14 Itamar Reis Peixoto 2009-01-21 08:48:05 EST
1 - instead changing conf-cc please use  daemontools-0.76-errno.patch as Patch0

2 - debug info package is not being created for some reason, we need to figure why

3 - should be good to have a svscanboot [UPS] running with upstart, Mamoru is the best person to answer about what directory, because /service should not be used, may be somthing like /var/run/daemontools  ?


UPS -> https://bugs.launchpad.net/ubuntu/+source/daemontools-installer/+bug/66615
Comment 15 Ralf Corsepius 2009-01-21 10:15:54 EST
(In reply to comment #14)

> 2 - debug info package is not being created for some reason, we need to figure
> why
The cause is this *.spec not acknowledging RPM_OPT_FLAGS.

In other words: You must somehow propagate $RPM_OPT_FLAGS from inside of the *.spec into the build-machinery.

One way is to edit compile-cc inside %prep (e.g. using sed).


4. You patch's file name is weird. The standard extensions for patches is *.diff or *.patch.
Comment 16 Itamar Reis Peixoto 2009-01-21 10:27:50 EST
> 
> > 2 - debug info package is not being created for some reason, we need to figure
> > why
> The cause is this *.spec not acknowledging RPM_OPT_FLAGS.
> 
> In other words: You must somehow propagate $RPM_OPT_FLAGS from inside of the
> *.spec into the build-machinery.
> 
> One way is to edit compile-cc inside %prep (e.g. using sed).
> 
> 
> 4. You patch's file name is weird. The standard extensions for patches is
> *.diff or *.patch.

if you like to contribute with a patch to speed up this review, I believe it will welcome
Comment 17 Ralf Corsepius 2009-01-21 10:42:57 EST
(In reply to comment #16)

> if you like to contribute with a patch to speed up this review, I believe it
> will welcome
Well, for didactical reasons, I prefer candidate maintainers to write such things themselves, because Fedora needs maintainers who have an understanding of what they are doing.
Comment 18 pjp 2009-01-22 01:28:51 EST
> 1 - instead changing conf-cc please use  daemontools-0.76-errno.patch as Patch0

  Pardon me..?

> 2 - debug info package is not being created for some reason, we need to figure
> why

  It did for me as daemontools-debuginfo-0.76-2.fc10.i386.rpm
Comment 19 pjp 2009-01-22 01:39:35 EST
(In reply to comment #15)
> The cause is this *.spec not acknowledging RPM_OPT_FLAGS.
> In other words: You must somehow propagate $RPM_OPT_FLAGS from inside of the
> *.spec into the build-machinery.

  I'm sorry, I still don't get what you are trying to convey. Could you please be more specific.

 
> 4. You patch's file name is weird. The standard extensions for patches is
> *.diff or *.patch.

  Huh...I'll do the change.
Comment 20 Itamar Reis Peixoto 2009-01-22 07:02:44 EST
>   Pardon me..?

only one time :-), don't worry you're welcome


>   It did for me as daemontools-debuginfo-0.76-2.fc10.i386.rpm

run rpmlint on it

rpmlint daemontools-debuginfo-0.76-2.fc10.i386.rpm
Comment 21 pjp 2009-01-23 01:56:20 EST
> only one time :-), don't worry you're welcome

  What, No! I mean, I didn't get what you were trying to say by this:

 "instead changing conf-cc please use  daemontools-0.76-errno.patch as Patch0"


> run rpmlint on it
> rpmlint daemontools-debuginfo-0.76-2.fc10.i386.rpm

  Alright found it, He(djb) was stripping the symbols while linking: `gcc -s`, and thus I *debeuginfo was empty. Anyway, I've made the changes, please see the files below

SPEC: http://pjp.dgplug.org/tools/daemontools.spec
SRPM: http://pjp.dgplug.org/tools/daemontools-0.76-2.fc10.src.rpm

Thank you.
Comment 22 Itamar Reis Peixoto 2009-01-23 06:51:31 EST
l@@k

http://qmail.kldp.org/src/patches/glibc-2.3.1/daemontools-0.76.errno.patch

about stripping in conf-ld, you can do this in .spec instead of creating a patch, something like this 

echo "gcc" > src/conf-ld

but if you want to use patch there are no problem, but create one patch for each change for example.

0 - daemontools-0.76.errno.patch
1 - daemontools-0.76.install.patch
2 - daemontools-0.76.remove_stripping_conf-ld.patch
Comment 23 Ralf Corsepius 2009-01-23 07:06:39 EST
(In reply to comment #22)

> echo "gcc" > src/conf-ld
Wrong.

sed -i -e \
"s!^gcc.*\$!%{__cc} ${RPM_OPT_FLAGS} -include /usr/include/errno.h!" src/conf-cc
sed -i -e \
"s!^gcc.*\$!%{__cc} ${RPM_OPT_FLAGS}!" src/conf-ld
Comment 24 pjp 2009-01-27 06:59:03 EST
(In reply to comment #22)
> http://qmail.kldp.org/src/patches/glibc-2.3.1/daemontools-0.76.errno.patch

  is it different than saying -include /usr/include/errno.h?

> but if you want to use patch there are no problem, but create one patch for
> each change for example.

  Are you kidding, one patch for each change? May I know what's the advantage of doing that??
Comment 25 pjp 2009-01-27 07:02:39 EST
> sed -i -e \
> "s!^gcc.*\$!%{__cc} ${RPM_OPT_FLAGS} -include /usr/include/errno.h!"
> src/conf-cc
> sed -i -e \
> "s!^gcc.*\$!%{__cc} ${RPM_OPT_FLAGS}!" src/conf-ld

  Yeah, may be that looks clean. But still I fail to see how it is helpful.
Comment 26 pjp 2009-01-27 07:32:19 EST
(In reply to comment #23)
> sed -i -e \
> "s!^gcc.*\$!%{__cc} ${RPM_OPT_FLAGS} -include /usr/include/errno.h!"
> src/conf-cc

  Wait, this changes the whole command in src/conf-cc, I don't think that's intended, do you?


> sed -i -e \
> "s!^gcc.*\$!%{__cc} ${RPM_OPT_FLAGS}!" src/conf-ld

  How/where do you set this RPM_OPT_FLAGS?
Comment 27 Ralf Corsepius 2009-01-27 10:20:20 EST
(In reply to comment #26)
> (In reply to comment #23)
> > sed -i -e \
> > "s!^gcc.*\$!%{__cc} ${RPM_OPT_FLAGS} -include /usr/include/errno.h!"
> > src/conf-cc
> 
>   Wait, this changes the whole command in src/conf-cc, I don't think that's
> intended, do you?
This is what is intended. It changes the compiler call to acknowledge the settings rpm-packaging expects it to acknowledge.

It has the same effect as
make CC=%{__cc} CFLAGS="${RPM_OPT_FLAGS} -include /usr/include/errno.h"
would have with ordinary Makefiles.

Unfortunately DJB's build-system is "special" and doesn't allow overriding settings from the environment, therefore one has to resort to hardcoding settings (which is what this sed call does).

> > sed -i -e \
> > "s!^gcc.*\$!%{__cc} ${RPM_OPT_FLAGS}!" src/conf-ld
> 
>   How/where do you set this RPM_OPT_FLAGS?
RPM_OPT_FLAGS is an rpm internal variable. It contains the CFLAGS all packages are supposed to compile with.
Comment 28 pjp 2009-01-28 02:30:37 EST
   Hi, I've made the changes. Please have a look at the following

SPEC: http://pjp.dgplug.org/tools/daemontools.spec
SRPM: http://pjp.dgplug.org/tools/daemontools-0.76-3.fc10.src.rpm

Thank you!
Comment 29 Itamar Reis Peixoto 2009-01-28 20:11:01 EST
> * 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.

you can remove FE-LEGAL

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


> Finally: Does this package still have an active upstream? 
> I thought, DJB discontinued all his works.

the package maintaner need's to fix the bugs :-)
Comment 30 Itamar Reis Peixoto 2009-01-28 20:14:13 EST
(In reply to comment #28)
>    Hi, I've made the changes. Please have a look at the following

seems better now, but I have a question ?

how you will start djbdns ?

using something like /service directory ? 

3 - should be good to have a svscanboot [UPS] running with upstart, Mamoru is
the best person to answer about what directory, because /service should not be
used, may be somthing like /var/run/daemontools  ?


UPS ->
https://bugs.launchpad.net/ubuntu/+source/daemontools-installer/+bug/66615
Comment 31 pjp 2009-01-29 00:07:10 EST
> the package maintaner need's to fix the bugs :-)

  Right I know, I could be an upstream for this and djbdns as well.
Comment 32 pjp 2009-01-29 00:29:54 EST
> seems better now, but I have a question?
> how you will start djbdns?

  Well, for now will have to run it manually. I'm working on making it usable with the existing /etc/init.d and /sbin/service framework, as that'll be more intuitive and seamless I guess.

> using something like /service directory ? 
> 
> 3 - should be good to have a svscanboot [UPS] running with upstart, Mamoru is
> the best person to answer about what directory, because /service should not be
> used, may be somthing like /var/run/daemontools?

  I haven't looked at it, but surely would explore about it as well.

So, can I consider daemontools to be approved? May be, I can work on packaging djbdns now.

Thanks.
Comment 33 Itamar Reis Peixoto 2009-01-29 14:23:53 EST
> So, can I consider daemontools to be approved? 
still not, for compatibility with other djb program's you should put /services directory in some place, for example  /var/run/daemontools 

you need to adjust svscanboot to look for services in this directory, 

can you write a init.d script or a upstart script to start svscanboot?


>May be, I can work on packaging djbdns now. ?

feel free, packaging djb programs is not easy and you can speed up working in both packages at the same time, please posts messages related to djbdns in their own BugZilla
Comment 34 Itamar Reis Peixoto 2009-02-04 17:55:24 EST
hello

any news about daemontools ?
Comment 35 pjp 2009-02-05 00:01:07 EST
  Hey hi,

(In reply to comment #34)
> any news about daemontools ?

  Sorry, got a little busy with other work, will start working on it real soon.

I had one more doubt about svscanboot, is it really required? I think we can very well do without it. It's just djbs way of starting services. And needless to say it's just not as user friendly to buy. I was also working of using /sbin/services.
Comment 36 Itamar Reis Peixoto 2009-02-05 06:23:15 EST
> I had one more doubt about svscanboot, is it really required? 

I think yes for compatibility with alot of howto's in the world. and if you don't do this now you're probably never do, there are alot of howtos about qmail,djbdns, vpopmail, and others saying to start the services creating a symlink, something like this.

  ln -s /etc/dnscache /service
  ln -s /etc/tinydns /service

but you should not use /service directory, you need something like /var/run/daemontools or /var/lib/daemontols or something else, ask Mamoru he is the best person to answer what's the best location.


I think we can
> very well do without it. It's just djbs way of starting services. And needless
> to say it's just not as user friendly to buy. I was also working of using
> /sbin/services.

feel free to do this, this is the recommended way
Comment 37 manuel wolfshant 2009-02-05 09:26:07 EST
just because DJB decided to ignore FHS and invent his own way of starting daemons and that those inventions were described in number of howtos is no reason to use the same non-sense in fedora.
Comment 38 Itamar Reis Peixoto 2009-02-05 12:40:40 EST
(In reply to comment #37)
> just because DJB decided to ignore FHS and invent his own way of starting
> daemons and that those inventions were described in number of howtos is no
> reason to use the same non-sense in fedora.

I agree with you in some point.

but I am asking only a sysv script to start svscanboot and a service directory in someplace, it's not much work, only 25-40 lines of code

djbdns will take alot more of work than this.
Comment 39 manuel wolfshant 2009-02-05 13:01:25 EST
We already have sysinit and upstart which are the only recommended and supported methods to start daemons. What you ask for is yet another service daemon and not only that but one which violates our guidelines.
Comment 40 Itamar Reis Peixoto 2009-02-05 13:14:24 EST
(In reply to comment #39)
> We already have sysinit and upstart which are the only recommended and
> supported methods to start daemons. What you ask for is yet another service
> daemon and not only that but one which violates our guidelines.

I agree with you in some point, but the intention is to make all packages work out of the box without much work.

in the future someone will report a bug and ask, where are the service directory ?

look

https://bugs.launchpad.net/ubuntu/+source/daemontools-installer/+bug/66615

feel free to take over,  the package seems to be good, but for me is missing this detail.
Comment 41 manuel wolfshant 2009-02-05 13:35:03 EST
yeah, https://bugs.launchpad.net/ubuntu/+source/daemontools-installer/+bug/66615/comments/11 is very informative. quote, for those who are not in the mood to visit that link: "The package has removed from Ubuntu Hardy and later versions. For this reason I am marking as Invalid."
Comment 42 pjp 2009-02-06 01:36:13 EST
  Hello folks,

Really pleased to see those comments and to know that I'm not the only one who thinks daemontools are redundant, cheers Manuel. :)

So here is the deal, I'll make djbdns *free* of daemontools and integrate it with /sbin/services, so it works just like any other service. I'll see to it that the necessary steps are documented at the right places.

Thank you.
Comment 43 Ralf Corsepius 2009-02-06 02:32:25 EST
Provided what you say, consider to close this review request.
Comment 44 pjp 2009-02-06 03:56:49 EST
> Provided what you say, consider to close this review request.

  Sure, will do that.
Comment 45 pjp 2009-03-05 02:15:06 EST
(In reply to comment #42)
> So here is the deal, I'll make djbdns *free* of daemontools and integrate it
> with /sbin/services, so it works just like any other service. I'll see to it
> that the necessary steps are documented at the right places.

https://bugzilla.redhat.com/show_bug.cgi?id=488681
Comment 46 Piotr Dobrogost 2016-10-26 04:24:54 EDT
I understand that some/most part of daemontools package is not needed on modern system but what about small utility programs like envdir included in this package?