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!
this is your first package ?
I am the sponsor of the submitter.
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.
Sorry, comment #3 was addressing djbdns (https://bugzilla.redhat.com/show_bug.cgi?id=480724) Re-adding comment there.
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.
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!
> 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.
> 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!
(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.
> 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.
(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
> 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.
Please consider this new SRPM: http://pjp.dgplug.org/tools/daemontools-0.76-2.fc10.src.rpm Thank you.
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
(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.
> > > 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
(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.
> 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
(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.
> 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
> 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.
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
(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
(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??
> 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.
(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?
(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.
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!
> * 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 :-)
(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
> the package maintaner need's to fix the bugs :-) Right I know, I could be an upstream for this and djbdns as well.
> 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.
> 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
hello any news about daemontools ?
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.
> 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
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.
(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.
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.
(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.
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."
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.
Provided what you say, consider to close this review request.
> Provided what you say, consider to close this review request. Sure, will do that.
(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
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?