From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 Firefox/1.0.7 Description of problem: The current version of rkhunter is the 1.2.7 one. However, 1.1.9-2 is the one on extras repository. An update would be most welcome! Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.It occurss always 2.It occurss always 3.It occurss always Additional info:
Yikes! My apologies. I have a version of the 1.2.7 RPM that I've got about 6 months runtime on with various systems (RH9-FC3) that I appearantly FORGOT to get into the pipeline (shakes head in dismay). I will endeavor to correct this oversight this weekend... Expect to see an SRPM available for QA by Monday 5 Dec. GregH
There is no QA process for updates. You can import into Fedora Extras CVS directly and send it to the build system directly, too.
Again, sorry for the delay. I've committed the 1,2,7 SRPM to CVS (there is probably a better way to get it updated in all branches, but for now I just 'brute-forced' it...) The BOOTSCAN is being re-written to allow for background execution as a SysV Init procedure that won't hold up the boot process. It's not there yet, and as a result this release has the BOOTSCAN removed. It does however have auto-update integrated into the CRON scan and much better logging with Date-stamped output and rotated appended logfiles. A much simplified option file in /etc/sysconfig/rkhunter provides detailed diagnostic running at the 'flip' of a switch... Should show up in the download repository by weeks end. Feedback, as always, is welcome...
Only FC-3, FC-4 and Development are supported at Fedora Extras. The FC-2 and FC-1 directories have historical reasons only. You need to use Release: 1%{?dist} in your spec files if you want the same release version for all branches. The build system replaces the macro with .fc4, .fc3, and so on. Because else you cannot tag the package revision within CVS, and the build system will reject your attempt at sending something to it. http://fedoraproject.org/wiki/Extras
Ahh... are there corrections that need to be made to the repository BESIDES adding %{?dist} to the .spec file Release: Tag? I read Tom's guidelines but was under the impression that this was optional, and I do wish rkhunter to be consistent with Fedora Extras standards. There may be a future need to have seperate distribution revisions of the package, though I'm unaware of such needs currently (though I have not tested on FC4). What else do I/we need to do in order to fix what I've botched?
Yes, using the dist tag macro is optional. But still, you need to make sure that %{version}-%{release} for a package in a newer distribution is "higher than" (and hence seen as "newer than") version-release of a package for an older distribution. That means, what is rkhunter-1.2.7-1 for FC3 cannot be rkhunter-1.2.7-1 for FC4, too, but should be rkhunter-1.2.7-2 or above. Using %{?dist} is a way to work around that (which is not entirely bullet-proof for distribution upgrades, however, but that is another story). Furthermore, "make tag", as needed for "make build" to understand what you want the build server to build, creates a tag in CVS using the name/version/release values from your spec file. This CVS tag must be unique and cannot be shared by multiple branch directories in CVS. http://fedoraproject.org/wiki/Extras/BuildRequests > What else do I/we need to do in order to fix what I've botched? I haven't seen the diff for this package on fedora-extras-commits list yet. But I believe you haven't run "make tag" or "make build" yet. When you do, you will run into problems if you don't use %{?dist}.
Between automobile breakage, computer crashes and personal illness I've had pretty much nothing but bad luck lately. In the process of setting up a 'plague' client workstation, my only core 3 machine suffered a major malfunction leaving me with only a core 1 laptop (which I am unable to install the plague client on for various reasons). While I do still have CVS access, I will be unable to run the tag and build process until I get Core 4 installed on a repaired/upgraded machine. I'll see if I can get the time to make the spec file changes sometime this week...
This is starting to read like a damn blog! O.K... I have resurrected my linux development workstation on core 4, now fully updated and building and signing RPMs. Michael has released a new upstream of rkhunter = 1.2.8 which I am now checking for .spec/patch compatibility. I still have to get the plague client and CVS authentication set up (and I am well aware that the core 5 release is bearing down on us). This will take at least another week for me to get to... I'm working it...
The new package version (1.2.8) has been committed to CVS, tagged and submitted for build in FC-3 and FC-4 flavours. Again, this release has had the BOOTSCAN removed. It's being re-written for background execution during startup. It does however have auto-update integrated into the CRON scan and much better logging with Date-stamped output and rotated appended logfiles. I did not build a 'devel' version yet as the upstream signatures database currently only supports FC1-4 and I don't see a reason to give someone a package that I know is going to cause a lot of grief due to confusion. Sorry for taking so loooong... This will go much smoother next time.
Don't forget to build for "devel", too, as FC-5 is near.
Tagged and ready... The problem is that while support for FC5 is simply a matter of downloading new os.dat, defaulthashes.dat, etc. files, it may take some time before the signature database entries are added. During the interim, the scan will be reporting a 'warning' (Warning: this operating system is not fully supported!) that not all functions and checks can be performed, because the system is 'unknown' to the script. This can be confusing enough to the end user that it warrants a couple of entries in the FAQ. I have some concerns about this... and what can be done about it before the 20th. Ideally, as soon as FC-5 goes gold, a new set of database file changes would be generated and sent to Michael Boelen for use in updating his master set (I don't have access to another machine that I can install FC-5 on to do this). I should be doing this as the Fedora port maintainer, but I just don't have the resources... any ideas?
It's just that until the update will be available, Fedora Extras for FC-5 contains the old build from April 11th 2005, http://fedoraproject.org/extras/development/i386/rkhunter-1.1.9-2.noarch.rpm and people who upgrade from FC-4 will end up with the FC-4 rkhunter being newer.
Hmmm... Well, faced with the choice of the lesser of two 'evils', I've opted to go ahead with the devel build for rkhunter 1.2.8 (and hope that it doesn't cause too much confusion for end users before updated .dat files become available). I really don't want anyone to continue to use the 1.1.9 package. It just has too many shortcomings and is too 'long in the tooth'...