Would you mind requesting an EL-5 branch and maintaining it? I'm thinking the 1.6 tree (FC-6) would be more suitable for that, but it's up to you. TIA!
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Package Change Request ====================== Package Name: syslog-ng New Branches: EL-4 EL-5 Owners: silfreed
Douglas, Just a couple of issues you will have to address/lookup into: * you'll have to static link the tcpwrappers' library in EL4 and in EL5 (syslog daemons can't depend on anything under /usr) rpm -ql tcp_wrappers (in EL5) ----------------------------- /usr/include/tcpd.h /usr/lib/libwrap.a /usr/lib/libwrap.so /usr/lib/libwrap.so.0 /usr/lib/libwrap.so.0.7.6 .... * EL4 only: you may also have to check if the glib2 library is already located in /lib * with the introduction of rsyslog in EL5.2 the logrotate file was modified $ cat /etc/logrotate.d/syslog /var/log/messages /var/log/secure /var/log/maillog /var/log/spooler \ /var/log/boot.log /var/log/cron { sharedscripts postrotate /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true /bin/kill -HUP `cat /var/run/rsyslogd.pid 2> /dev/null` 2> /dev/null || true endscript } Notice the two pid files: one for sysklogd and one for rsyslog (question: why doesn't rsyslog use the same filename as the pid file?)
(In reply to comment #5) > * you'll have to static link the tcpwrappers' library in EL4 and in EL5 > (syslog daemons can't depend on anything under /usr) > > rpm -ql tcp_wrappers (in EL5) > ----------------------------- > /usr/include/tcpd.h > /usr/lib/libwrap.a > /usr/lib/libwrap.so > /usr/lib/libwrap.so.0 > /usr/lib/libwrap.so.0.7.6 > > * EL4 only: you may also have to check if the glib2 library is already > located in /lib > Thanks, I'll have to look into this. > * with the introduction of rsyslog in EL5.2 the logrotate file was modified > > $ cat /etc/logrotate.d/syslog > /var/log/messages /var/log/secure /var/log/maillog /var/log/spooler \ > /var/log/boot.log /var/log/cron { > sharedscripts > postrotate > /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || > true > /bin/kill -HUP `cat /var/run/rsyslogd.pid 2> /dev/null` 2> /dev/null || > true > endscript > } > > Notice the two pid files: one for sysklogd and one for rsyslog > I actually have EL4/EL5 packages at my website that I've maintained for many years (http://www.silfreed.net/download/repo/packages/syslog-ng , https://rpm.silfreed.net:8002/file/tip/syslog-ng/) that allows parallel installation of sysklogd, rsyslog, and syslog-ng. > (question: why doesn't rsyslog use the same filename as the pid file?) No clue, it's quite the pain. And getting the other syslog-facility maintainers to coordinate on making this pain-point go away has had very slow progress.
cvs done.
Have started some initial work on getting this to compile for EL5 with one .spec file. Patch to configure.in is attached. http://rayvd.fedorapeople.org/syslog-ng/syslog-ng.spec http://rayvd.fedorapeople.org/syslog-ng/syslog-ng-2.0.10-2.el5.src.rpm Some notes: * EL4 issues still need addressed (glib2 needs to be statically linked) * Assuming this is a branch agnostic patch, it should probably be modified to only patch configure.in if we're on EL4 or EL5. * There is an rpmlint complaint about the Provides: syslog-ng.src:44: W: unversioned-explicit-provides syslog rsyslog provides syslog in exactly the same way though. Comments? I'm not sure if this is the cleanest way to do a static patch short of getting upstream to make some changes to the autoconf files before packaging up their tarball.
Created attachment 335459 [details] Patch against configure.in to statically link against libwrap
http://rayvd.fedorapeople.org/syslog-ng/syslog-ng.spec http://rayvd.fedorapeople.org/syslog-ng/syslog-ng-2.0.10-3.el5.src.rpm The above should build on EL4, EL5 as well as the Fedora's. The complaint about the syslog version is still there. I don't know if this is a big deal to anyone. I also added the new log rotation script as well. Doug, could you take a look when you get a chance?
Created attachment 335478 [details] Patch to be applied on EL4
Created attachment 335479 [details] Patch to be applied on EL5
Hmm, for some reason, under mock, it seems like configure gets run twice (gets called by make?). The second time through it doesn't pass --enable-dynamic-linking and as a result we don't get the static linking we want. Grr.
From looking at the mock build logs, there were errors trying to call automake as a result of the configure.in file being patched. Added a BuildRequires of automake17 and now mock seems to produce a correctly statically linked binary. http://rayvd.fedorapeople.org/syslog-ng/syslog-ng.spec http://rayvd.fedorapeople.org/syslog-ng/syslog-ng-2.0.10-4.el5.src.rpm
rayvd, if you apply for co-maintainer on any branches in pkgdb I'll approve you as co-maintainer.
Updating eventlog package to include the -static package needed for RHEL builds since I was stupid and removed this in the previous version.
FYI, at least on my CentOS 5 box, libevtlog.so and friends are in /lib so I think it's ok to dynamically link against them.
Yep, but that's not what the --mixed-linking option does and I don't feel like patching it at this time.
Built; should be going into EPEL shortly.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.