*** Bug 198561 has been marked as a duplicate of this bug. ***

Missing the usual chkconfig and /sbin/service Requires. fedora-qa script says:

* Missing dependancy on service for %preun (package initscripts)
* Missing dependancy on chkconfig for %post (package chkconfig)
* Missing dependancy on chkconfig for %preun (package chkconfig)

for both zabbix and zabbix-agent.

Strange, rpmlint says objdump failed. x86_64 devel.

W: zabbix-agent objdump-failed objdump:
/tmp/zabbix-agent-1.1-1.fc6.x86_64.rpm.23260/usr/bin/zabbix_get: File format not
recognized
W: zabbix-agent objdump-failed objdump:
/tmp/zabbix-agent-1.1-1.fc6.x86_64.rpm.23260/usr/bin/zabbix_sender: File format
not recognized
W: zabbix-agent objdump-failed objdump:
/tmp/zabbix-agent-1.1-1.fc6.x86_64.rpm.23260/usr/bin/zabbix_agent: File format
not recognized
W: zabbix-agent objdump-failed objdump:
/tmp/zabbix-agent-1.1-1.fc6.x86_64.rpm.23260/usr/bin/zabbix_agentd: File format
not recognized

Deps on chkconfig and service added, misc other little spec clean-ups.

http://wilsonet.com/packages/zabbix/zabbix.spec
http://wilsonet.com/packages/zabbix/zabbix-1.1-2.fc6.src.rpm

As for those rpmlint objdump failures, you aren't by chance running on an FC5
box, building in an FC6 mock chroot, are you? I just ran into this today myself.
FC5 builds analyzed on FC5 work fine, but not the FC6 ones. If I scp the
mock-built FC6 packages over to an up-to-date rawhide box, rpmlint does its
thing without a problem. I believe this is due to recent glibc hash function
changes that rpmlint/objdump on FC5 doesn't understand.

Correct, I was building FC6 on FC5.

I notice MySQL is enabled, but configure also looked for Postgre. Would this be
something you would want to --enable but not Require?

You'll also want zabbix-web to Require php-mysql

Please substitute the references to /var with %{_localstatedir} in your sed scripts.

Zabbix 1.1.1 has been released:

http://www.zabbix.com/rn1.1.1.php

(In reply to comment #4)
> I notice MySQL is enabled, but configure also looked for Postgre. Would this be
> something you would want to --enable but not Require?

We could do that. However, based on the 1.1.1 release notes, it looks like
postgres support is currently broken, fix slated for 1.1.2.

Speaking of which, new build is updated to v1.1.1 (thank you, Jeff).

> You'll also want zabbix-web to Require php-mysql

Okay, I simply changed Requires: php to php-mysql, since php-mysql requires php.

> Please substitute the references to /var with %{_localstatedir} in your sed
scripts.

Done.

Latest build:
http://wilsonet.com/packages/zabbix/zabbix.spec
http://wilsonet.com/packages/zabbix/zabbix-1.1.1-1.fc6.src.rpm

(In reply to comment #4)
> 
> I notice MySQL is enabled, [...]. Would this be
> something you would want to --enable but not Require?

I would concur with this statement.  I would think that on larger installations
a person would want to run the Zabbix server and the MySQL server on separate
systems, and wouldn't want to have mysql-server installed needlessly.  Sure
having as a Require will make things easier for newbie administrators, but I
don't think that that is as important right now.  Plus hopefully the Zabbix devs
will have PostgreSQL support fixed soon and I'm sure that PostgreSQL users
wouldn't want the MySQL server installed on their systems and vice-versa.

(In reply to comment #7)
> (In reply to comment #4)
> > 
> > I notice MySQL is enabled, [...]. Would this be
> > something you would want to --enable but not Require?
> 
> I would concur with this statement.

Heh, I think John was only talking about Postgres there, but see my note on this
very issue in the initial description. I'm definitely open to not including
mysql-server as a Requires (I'll make that change to my local copy now).

Probably want to Require: fping so that the icmpping and icmppingsec checks work.

The web interface also needs to Require: php-gd for graphs to work.

Requires: on mysql-server removed, Requires: for fping (main package) and php-gd (-web package) 
added. Updated files:

http://wilsonet.com/packages/zabbix/zabbix.spec
http://wilsonet.com/packages/zabbix/zabbix-1.1.1-2.fc6.src.rpm

Zabbix 1.1.2 is out for some time and it adds support for PostgreSQL as the
backend database. Is it possible to parametrize the database support in the spec
file? To have something like the following:

%if !%db
%define db mysql
%endif

BuildRequires: %{db}-devel
Requires: php-%{db}

and when running the configure there will be "--with-%{db}" instead of
--with-mysql/--with-pgsql

Eep, now Zabbix 1.1.3 is out, and I've been slacking on this package... Its not
entirely pretty to do this conditionally, as only one or the other can be
enabled, but I've set up the default build to use mysql, and if '--with
postgresql' is passed in, it'll build with postgresql instead. Didn't bother
with a '--with mysql' flag, don't want to hassle with what to do if both were
passed in. Both mysql and postgresql versions are building fine for me on
FC6/x86_64.

Updated SRPM:
http://wilsonet.com/packages/zabbix/zabbix-1.1.3-1.fc6.src.rpm

Updated spec:
http://wilsonet.com/packages/zabbix/zabbix.spec

The proper Requires for PostgreSQL support in PHP is "php-pgsql" not
"php-postgresql".

D'oh. That's what I get for only build-testing... Fixed, thank you.

http://wilsonet.com/packages/zabbix/zabbix-1.1.3-2.fc6.src.rpm
http://wilsonet.com/packages/zabbix/zabbix.spec

Nice spec Jarod, thanks.

There's a few more build/runtime dependencies you probably need to add though.

Build: gnutls-devel

Runtime: net-snmp-libs

The build scripts sometimes can't determine where libgnutls is by default,
gnutls-devel includes libgnutls-config which fixes this. 

Without net-snmp-libs the zabbix_server binary can't load. Usually get's
resolved automatically, but given ucd-snmp is now net-snmp and that's what
Fedora is packaging, it should be OK to explicitly require net-snmp-libs ?

Added BR: gnutls-devel and R: net-snmp-libs (yeah, both are the correct thing to
do).

http://wilsonet.com/packages/zabbix/zabbix-1.1.3-3.fc6.src.rpm
http://wilsonet.com/packages/zabbix/zabbix.spec

Spec works well on RHEL4/CentOS4 too, and I've tested it with Zabbix 1.1.4 - no
compile issues, but the same problem I'm seeing below occurred.

Seems to center around 'make install'. Along with the .a libs you've excluded,
it's gone and dumped a bunch of object files in /usr/lib in my build
environment, so I'm getting unpackaged file errors on build.

Checking for unpackaged file(s): /usr/lib/rpm/check-files
/home/cstubbs/rpm/tmp/zabbix-1.1.3-3-root-cstubbs
error: Installed (but unpackaged) file(s) found:
   /usr/lib/stD0Ikh0
   /usr/lib/stIMYNMd/active.o
   /usr/lib/stIMYNMd/autoregister.o
   /usr/lib/stIMYNMd/trapper.o
   /usr/lib/stLeJGOP
   /usr/lib/stRDGpXX/action.o
....
etc

One work around is a few more exlude lines,

%exclude %{_libdir}/st*
%exclude %{_libdir}/st*/*.o

(In reply to comment #18)
> Spec works well on RHEL4/CentOS4 too, and I've tested it with Zabbix 1.1.4 - no
> compile issues, but the same problem I'm seeing below occurred.
> 
> Seems to center around 'make install'. Along with the .a libs you've excluded,
> it's gone and dumped a bunch of object files in /usr/lib in my build
> environment, so I'm getting unpackaged file errors on build.
> One work around is a few more exlude lines,
> 
> %exclude %{_libdir}/st*
> %exclude %{_libdir}/st*/*.o

I see the same problems, my workaround was to delete the *.a files manualy
during the %install and not use the %exclude directive at all. When you only
comment out the %exclude line, then the strange files st*/*.o are not created.

Odd, I remember seeing those files at one point in time, but I don't with the
1.1.3 spec that only %exclude'd .a files... If killing static libs in %install
works around it for cases where its still happening, I have no problem switching
to that instead of %exclude. I've done that in a 1.1.4 package:

http://wilsonet.com/packages/zabbix/zabbix-1.1.4-1.fc6.src.rpm
http://wilsonet.com/packages/zabbix/zabbix.spec

John, I hope you don't mind if I reassign this review to myself...

* source files match upstream
8e733e41506dd34759daba01deeeefd9  zabbix-1.1.4.tar.gz
8e733e41506dd34759daba01deeeefd9  zabbix-1.1.4.tar.gz.1
* package meets naming and packaging guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* dist tag is present.
* build root is correct.
* license field matches the actual license.
* license is open source-compatible.  License text included in package.
* latest version is being packaged.
* BuildRequires are proper.
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (fc6 i386).
* package installs properly. 
* rpmlint says:

E: zabbix non-standard-uid /var/run/zabbix zabbix
E: zabbix non-standard-gid /var/run/zabbix zabbix
E: zabbix non-standard-uid /var/log/zabbix zabbix
E: zabbix non-standard-gid /var/log/zabbix zabbix
E: zabbix-agent non-standard-uid /var/log/zabbix zabbix
E: zabbix-agent non-standard-gid /var/log/zabbix zabbix
E: zabbix-agent non-standard-uid /var/run/zabbix zabbix
E: zabbix-agent non-standard-gid /var/run/zabbix zabbix

Can be ignored.

E: zabbix-web script-without-shebang /usr/share/zabbix/include/locales/pt_br.inc.php

! fix in %prep with %{__chmod} a-x frontends/php/include/locales/pt_br.inc.php

E: zabbix-web wrong-script-end-of-line-encoding
/usr/share/zabbix/include/locales/pt_br.inc.php

! fix in %prep with %{__sed} -i 's/\r//' frontends/php/include/locales/pt_br.inc.php

* %check is not present; There is no test code in the districution.
* no shared libraries are present
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* scriptlets are OK
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers
* no unversioned .so file
* no pkconfig file
* no libtool .la droppings.

There should be:

Requires(pre): /usr/sbin/useradd

for both the main package and the agent package.

(In reply to comment #22)
[...]
> E: zabbix-web script-without-shebang
/usr/share/zabbix/include/locales/pt_br.inc.php
> 
> ! fix in %prep with %{__chmod} a-x frontends/php/include/locales/pt_br.inc.php
> 
> E: zabbix-web wrong-script-end-of-line-encoding
> /usr/share/zabbix/include/locales/pt_br.inc.php
> 
> ! fix in %prep with %{__sed} -i 's/\r//'
frontends/php/include/locales/pt_br.inc.php

Ugh. Musta been added to one of the recent builds, rpmlint used to be silent...
That's what I get for not linting new builds... :)

> There should be:
> 
> Requires(pre): /usr/sbin/useradd
> 
> for both the main package and the agent package.

Damn, missed that one...


Okay, new build should fix all of the above.

http://wilsonet.com/packages/zabbix/zabbix-1.1.4-2.fc6.src.rpm

APPROVED

Excellent, thanks much, importing shortly...

(In reply to comment #21)
> John, I hope you don't mind if I reassign this review to myself...
> 

Not at all, I was getting behind on the builds. I agree with the review.

Imported and built for devel, FC6 and FC5.

Package Change Request
======================
Package Name: zabbix
Updated Fedora Owners: jwilson,sharkcz
Updated EPEL Owners: jwilson,sharkcz

This request appears to have already been done via the web interface. 
Feel free to reset the flag if further cvsadmin attention is needed. 

Package Change Request
======================
Package Name: zabbix
Updated Fedora Owners: sharkcz,jcollie
Updated EPEL Owners: sharkcz,jcollie

again, this looks to have been completed via the pkgdb web interface. 
Let me know if you need anything further here.