[Xymon] Spec file for 4.3.4?

[Tom Diehl]

On Tue, 23 Aug 2011, Buchan Milne wrote:

> On Monday, 22 August 2011 21:34:34 Tom Diehl wrote:
>> On Mon, 22 Aug 2011, Jason Kincl wrote:
>>> Daniel,
>>>
>>> This issue has been discussed in another thread of the mailing list, see
>>> link here: http://lists.xymon.com/archive/2011-April/031407.html
>>>
>>> If you follow the thread, I replied with a fix for the xymonmenu.css file
>>> not found. As for the critical.cfg.bak file, I have just commented that
>>> line out of the spec file with no problems.
>>>
>>> On Aug 22, 2011, at 11:51 AM, Daniel McDonald wrote:
>>>> I tried to build 4.3.4 using the included spec file, and came up with a
>>>> few errors:
>>>>
>>>> RPM build errors:
>>>>     File not found: /tmp/xymon-root/var/lib/xymon/www/menu/xymonmenu.css
>>>>     File not found: /tmp/xymon-root/etc/xymon/critical.cfg.bak
>>>>     File listed twice: /usr/lib/xymon/client/bin/clientupdate
>>>>     File listed twice: /usr/lib/xymon/client/bin/logfetch
>>>>     File listed twice: /usr/lib/xymon/client/ext
>>>>
>>>> Does anyone have a working specfile?  I’d like to build this on
>>>> Mandriva Enterprise Server 5.2
>>
>> I do not know anything about Mandriva Enterprise Server 5.2 but I have an
>> srpm at:
>> http://yumrepo.tntechs.com/yum-repository/local/centos/tntechs-testing/6/SR
>> PMS/xymon-4.3.4-1.el6.tnt.2.src.rpm that I am using for my CentOS 5 and 6
>> servers.
>>
>> It is modified from the original spec file included with xymon
>
> Which has multiple issues regarding most package quality compliance
> guidelines. IMHO, it is a bad place to start ...

Agreed but it was the quickest way for me to get a template to hack on.
I have fixed a lot of the problems rpmlint shows when run against the 
srpm. When rpmlint is run against the rpm there are many errors. Most 
are things like the following:
xymon.i386: W: manpage-not-compressed gz /var/lib/xymon/www/help/manpages/man8/xymonproxy.8.html
xymon.i386: W: name-repeated-in-summary C Xymon
xymon.i386: W: non-standard-uid /var/lib/xymon/www/gifs/blue-ack.gif xymon

xymon.i386: E: non-standard-executable-perm /usr/lib/xymon/server/bin/xymon-mailack 0775L

In the xymon context, I do not think the above warnings are valid.

For the error, I need to understand what it is telling me. The permissions
on the referenced files are 0775 I do not understand what 0775L is and more
importantly how to fix it. The spec file says the permissions are 775.

As I said above this is a work in progress.

>
>> and includes
>> some selinux policy files that may or may not be correct. They were
>> generated by audit2allow after running xymon with selinux in permissive
>> mode.
>
> How about submitting a patch so these can be included in the source release?

I am hesitant to do that because I am not sure that they are correct. If someone
who understands selinux could review them then I do not have a problem.

>> It is a work in progress and guaranteed to contain as yet unknown bugs. :-)
>> Use it at your own risk or ignore it. Whatever you prefer.
>>
>> If someone finds errors/bugs, I would appreciate knowing about them.
>> Especially if you know how to fix them as they relate to CentOS/RHEL.
>
> Well, I have discussed this many times, but there are a number of spec files
> floating around, and most of them don't take upgrading (e.g. 4.2.3 to 4.3.x)
> into account, and many fix different issues, but almost no-one seems to be
> willing to discuss what must be fixed, and contribute to fixing the spec file
> in svn.

I would love to discuss what needs to be fixed to get a good set of rpms for
RHEL/centos/fedora. The problem is that many people want rpms for other rpm
based distros that I have no experience with. I have seen many attempts in the
past to maintain distro agnostic rpms with very limited success.

As to the upgrade issue, I have no real way of testing upgrades and there are
a lot of variables that I am sure I would miss. The only thing I did in my
srpm wrt upgrades was check to see if the old hobbit* config files existed
and rename them to the xymon equivalents.

>
> Until such a time, there will continue to be multiple incompatible packages.

Indeed.

Regards,

-- 
Tom Diehl       tdiehl at rogueind.com      Spamtrap address mtd123 at rogueind.com