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

Few comments :
- -b 0 in %setup is useless
- %{_sysconfdir}/openvas/openvas-client_log.conf should be marked as %config(noreplace)
- manfiles should end with .* rather than .gz in case the compression format
ever changes.
- Missing BuildRequires: desktop-file-utils. See https://fedoraproject.org/wiki/Packaging/Guidelines#desktop
- You must not add a vendor tag to the desktop file.

Adding Huzaifa to the CC list.

New package:

Spec URL:
http://www.zemris.fer.hr/~sgros/stuff/fedora/openvas3/openvas-client.spec
SRPM URL:
http://www.zemris.fer.hr/~sgros/stuff/fedora/openvas3/openvas-client-3.0.0-3.fc12.src.rpm

* Missing BuildRequires: on zlib-devel, gnutls-devel, gtk2-devel, openssl-devel, libpcap-devel, gpgme-devel.

* rpmlint is not silent :
openvas-client.i686: E: executable-marked-as-config-file /etc/openvas/openvas-client_log.conf
openvas-client.i686: E: script-without-shebang /etc/openvas/openvas-client_log.conf
2 packages and 0 specfiles checked; 2 errors, 0 warnings.

However, this is bogus, the issue is rather the conf file has bad perms (0755 instead of 0644).

* %{_sysconfdir}/openvas is not owned.

I fixed configuration file problems. Here are new spec and srpm files:

Spec URL:
http://www.zemris.fer.hr/~sgros/stuff/fedora/openvas3/openvas-client.spec
SRPM URL:
http://www.zemris.fer.hr/~sgros/stuff/fedora/openvas3/openvas-client-3.0.0-4.fc12.src.rpm

Directory ownership of /etc/openvas I moved to the libraries as both, scanner and client, use this directory so if both are installed there would be a collision. For a reference, here is a new SPEC file for the libraries, the change is actually a minor one:

http://www.zemris.fer.hr/~sgros/stuff/fedora/openvas3/openvas-libraries.spec

Created attachment 397514 [details]
Changes in openvas-libraries related to the changes in client

Here is a small patch against spec file for openvas libraries in the CVS that makes libraries owner of /etc/openvas directory.

Not sure moving the ownership of the sysconfdir to the libraries is the preferred solution. There is nothing wrong with the sysconfdir being owned by both the openvas-client and openvas-scanner.

My reasoning was that the user will install libraries and also either scanner or client, or both. Because it's obvious that only libraries will be installed in a very few cases (if any) I thought that this is the better solution. Also, wouldn't it be confusing if I query to which package /etc/openvas belongs and I get two answers? I newer encountered such a case, which of course, doesn't mean it don't exists.

But, I can change it back, if you think it's better solution.

Hello guys,
If I can add opinion to the discussion - I would preffer the sysconfdir owned by 1 package and as the libraries is the common baseline, it seems logical it will be this package ovning the directory.
Best regards
Michal Ambroz

Hello,
I was testing the openvas-client so here are my 2 copper coins:

1) inconsistency in naming between the openvas packages
Most tools in openvas suite are named openvas-something except the client OpenVAS-Client .
The discrepancy is comming from the upstream package.
I would recommend to create symbolic link openvas-client just for comfort - big letters are sexy, but could be hard to remember when all the other tools from the suite are lowercase.

2) OpenVAS-Client is crushing with export to LaTeX of empty report
reported upstream 
http://wald.intevation.org/tracker/index.php?func=detail&aid=1343&group_id=29&atid=220

3) Export to pdf requires htmldoc
As report to pdf won't be probably the main exports used, 
however there is question whether there should be rpm dependency 
added to the spec file.

Best regards
Michal Ambroz

(In reply to comment #10)

> 1) inconsistency in naming between the openvas packages
> Most tools in openvas suite are named openvas-something except the client
> OpenVAS-Client .
> The discrepancy is comming from the upstream package.
> I would recommend to create symbolic link openvas-client just for comfort - big
> letters are sexy, but could be hard to remember when all the other tools from
> the suite are lowercase.
> 
Agreed, a lower-case symlink would be handy.

> 2) OpenVAS-Client is crushing with export to LaTeX of empty report
> reported upstream 
> http://wald.intevation.org/tracker/index.php?func=detail&aid=1343&group_id=29&atid=220
> 
This fixes it and could be included as a patch :
http://wald.intevation.org/plugins/scmsvn/viewcvs.php/trunk/openvas-client/openvas/latex_output.c?root=openvas&rev=7137&r1=5830&r2=7137&makepatch=1&diff_format=h

> 3) Export to pdf requires htmldoc
> As report to pdf won't be probably the main exports used, 
> however there is question whether there should be rpm dependency 
> added to the spec file.
> 
If it doesn't drag too much dependencies, it probably should. What happens if you try to use this feature and htmldoc is not available ?

The files are currently unavailable, but here a couple notes based on an older version :
- rename Source1: OpenVAS.desktop to openvas-client.desktop to match the package name.
- License is GPLV2 and GPLv2+, there are files under both GPLv2 and GPLv2 or later license, the resulting binary is likely GPLv2. I need to double check the licensing guidelines to make sure.
http://fedoraproject.org/wiki/Licensing
- Group: System Environment/Libraries is wrong, I'd use something like Applications/System.
- Following Michal comment above about the non-lowercase OpenVAS-Client binary name, the manpage should also have a symlink to the lowercase equivalent. Actually, I think it would be even better to ask upstream to switch to lowercase.

Ok, the new package will be available tomorrow on the following links (currently, the server is down because some work is done on the power supply in the building):

Spec URL:
http://www.zemris.fer.hr/~sgros/stuff/fedora/openvas3/openvas-client.spec
SRPM URL:
http://www.zemris.fer.hr/~sgros/stuff/fedora/openvas3/openvas-client-3.0.0-4.fc12.src.rpm

I renamed desktop file, changed group, added htmldoc require.

For symlinks, I looked in debian package and they also add symlinks. So, I created them. But I don't think there is a point in asking upstream to change the name of the binary. There is no point in changing it because some packager asks for it, there are plenty of other users that are probably used to it as it is.

Ops, wrong URLS:

Spec URL:
http://www.zemris.fer.hr/~sgros/stuff/fedora/openvas3/openvas-client.spec
SRPM URL:
http://www.zemris.fer.hr/~sgros/stuff/fedora/openvas3/openvas-client-3.0.0-5.fc12.src.rpm

I have added request to openvas-client bugzila to consider adding of the symlinks as it is done in fedora (and debian) package.

Building in koji fails.
https://koji.fedoraproject.org/koji/taskinfo?taskID=2139416

Missing dependencies:
BuildRequires:  zlib-devel
BuildRequires:  gtk2-devel
BuildRequires:  gpgme-devel
BuildRequires:  glib-devel
BuildRequires:  gnutls-devel

Pakage is still failing to build in koji FC13. file cflags in src directory is created too late so building of package is still failing:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2139686

Michal Ambroz

Hello colleagues, 
as Stjepan is probably busy I will post an update - please can someone review?

All build requirements were added to the SPEC file.
Makefiles were patched to reference cflags file necessary to
build of some objects.

SPEC URL: http://rebus.fedorapeople.org/12/SPECS/openvas-client.spec
SRPM URL: http://rebus.fedorapeople.org/12/SRPMS/openvas-client-3.0.0-6.fc12.src.rpm

Rpmlint is free of errors:
$ rpmlint openvas-client-3.0.0-6.fc12.src.rpm openvas-client-3.0.0-6.fc12.i686.rpm openvas-client-debuginfo-3.0.0-6.fc12.i686.rpm
3 packages and 0 specfiles checked; 0 errors, 0 warnings.

Koji build is successfull for FC12 and FC13:
Koji build for FC13: http://koji.fedoraproject.org/koji/taskinfo?taskID=2166099
Koji build for FC12: http://koji.fedoraproject.org/koji/taskinfo?taskID=2166123

Best regards
Michal Ambroz

(In reply to comment #9)
> Hello guys,
> If I can add opinion to the discussion - I would preffer the sysconfdir owned
> by 1 package and as the libraries is the common baseline, it seems logical it
> will be this package ovning the directory.
> Best regards
> Michal Ambroz    

What about creating a openvas-common subpackage that owns the common directories? There are quite a few -common subpackages with this purpose

I was testing the application. The users manual under help doesnt work, The popup menu says: PDF file //usr/share/doc/openvas-manual/users-manual.pdf not found.

Hello Sergio
(In reply to comment #19)
> I was testing the application. The users manual under help doesnt work, The
> popup menu says: PDF file //usr/share/doc/openvas-manual/users-manual.pdf not
> found.    

openvas-manual is replaced by openvas-compendium - it is not part of the client.
I believe this is not important at this stage - we do not have any openvas-compendium package sofar.

This is the review for Michal's 3.0.0-6.

+ : OK
- : not OK
= : non applicable
? : not tested


+    * MUST: rpmlint must be run on every package. The output should be posted in the review.
3 packages and 0 specfiles checked; 0 errors, 0 warnings.
+    * MUST: The package must be named according to the Package Naming Guidelines.
+    * MUST: The spec file name must match the base package %{name}, in the format %{name}.spec unless your package has an exemption.
+    * MUST: The package must meet the Packaging Guidelines.
+    * MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines .
-     * MUST: The License field in the package spec file must match the actual license.
licensecheck reports a mix of GPLv2 and GPLv2+. Also some files doesn't have a license header at all.
License tag should be GPLv2 and GPLv2+. Files without a license header should be fixed upstream, if you feel like asking them.
+    * MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc.
+    * MUST: The spec file must be written in American English.
+    * MUST: The spec file for the package MUST be legible.
-    * MUST: The sources used to build the package must match the upstream source, as provided in the spec URL.
Replace Source0: http://wald.intevation.org/frs/download.php/467/%{name}-%{version}.tar.gz
with Source0: http://wald.intevation.org/frs/download.php/685/%{name}-%{version}.tar.gz
I guess this stupid php downloader will probably cause more trouble in the future. It might worth not using the %{name}-%{version} macros in the Source to avoid errors.
+    * MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture.
=    * MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch.
+    * MUST: All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines.
=    * MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.
=    * MUST: Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun.
+    * MUST: Packages must NOT bundle copies of system libraries.
=    * MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package.
+    * MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory.
+    * MUST: A Fedora package must not list a file more than once in the spec file's %files listings.
+    * MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line.
+    * MUST: Each package must consistently use macros.
+    * MUST: The package must contain code, or permissable content.
=    * MUST: Large documentation files must go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity).
+    * MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present.
=    * MUST: Header files must be in a -devel package.
=    * MUST: Static libraries must be in a -static package.
=    * MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package.
=    * MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release}
+    * MUST: Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built.
+    * MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section.
+    * MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon.
+    * MUST: At the beginning of %install, each package MUST run rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
+    * MUST: All filenames in rpm packages must be valid UTF-8.

=    * SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it.
-    * SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available.
+    * SHOULD: The reviewer should test that the package builds in mock.
?    * SHOULD: The package should compile and build into binary rpms on all supported architectures.
+    * SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example.
+    * SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity.
=    * SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency.
=    * SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb.
=    * SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself.
+    * SHOULD: your package should contain man pages for binaries/scripts. If it doesn't, work with upstream to add them where they make sense.

Also, it would be nice the missing manual pdf file error could be handled in some way. Maybe package the compendium and patch openvas-client to use it instead (although it seems the latest compendium release is outdated anyway). Definitely not a blocker, though.

Please fix Source0: and License: tags and then the package is APPROVED.
Sorry for the very long delay...

I fixed Source0 and License tags. But rpmlint shows the following warnings:

$ rpmlint openvas-client-3.0.0-7.fc13.x86_64.rpm
openvas-client.x86_64: W: unstripped-binary-or-object /usr/bin/OpenVAS-Client
openvas-client.x86_64: W: unstripped-binary-or-object /usr/bin/omp-cli
openvas-client.x86_64: W: manual-page-warning /usr/share/man/man1/OpenVAS-Client.1.gz 243: warning: `UR' not defined
openvas-client.x86_64: W: manual-page-warning /usr/share/man/man1/openvasclient-mkcert.1.gz 31: warning: `UR' not defined
openvas-client.x86_64: W: manual-page-warning /usr/share/man/man1/openvasclient-mkcert.1.gz 33: warning: `UE' not defined
openvas-client.x86_64: W: no-manual-page-for-binary omp-cli
1 packages and 0 specfiles checked; 0 errors, 6 warnings.

I think that warnings about manual pages could be ignored, but what about unstripped binary?

I don't get these rpmlint warnings, neither with a local mock build nor with a koji scratch build (http://koji.fedoraproject.org/koji/taskinfo?taskID=2228313).

Ok, here are the new SPEC and SRPM files:

Spec URL:
http://www.zemris.fer.hr/~sgros/stuff/fedora/openvas3/openvas-client.spec
SRPM URL:
http://www.zemris.fer.hr/~sgros/stuff/fedora/openvas3/openvas-client-3.0.0-7.fc13.src.rpm

rpmling on F13 gives me the following output:


$ rpmlint openvas-client-3.0.0-7.fc13.x86_64.rpm 
openvas-client.x86_64: W: unstripped-binary-or-object /usr/bin/OpenVAS-Client
openvas-client.x86_64: W: unstripped-binary-or-object /usr/bin/omp-cli
openvas-client.x86_64: W: manual-page-warning /usr/share/man/man1/OpenVAS-Client.1.gz 243: warning: `UR' not defined
openvas-client.x86_64: W: manual-page-warning /usr/share/man/man1/openvasclient-mkcert.1.gz 31: warning: `UR' not defined
openvas-client.x86_64: W: manual-page-warning /usr/share/man/man1/openvasclient-mkcert.1.gz 33: warning: `UE' not defined
openvas-client.x86_64: W: no-manual-page-for-binary omp-cli
1 packages and 0 specfiles checked; 0 errors, 6 warnings.

ok, I updated rpmlint to 0.97 and I'm now getting the man page warnings, but not the unstripped binaries warning, which are the only warnings I would worry about. Maybe something in your .rpmmacros disable the stripping ? I'd say go ahead, import and build the package, we'll see if this happens again, but my feeling is this is an issue in your setup, not in the spec.
For the others remaining warnings, the missing manual page for omp-cli is not a packaging bug and cannot be fixed easily, and anyway there's no packaging rule enforcing a manpage should be present for every binary. I'm a bit puzzled at the 'UR' and 'UE' not defined warning, but this looks harmless.

Hello I can confirm Xavier's findings. 

My OpenVAS-client is definitely stripped (strip comes from binutils-2.20.51.0.2-15.fc13.i686 package).

I have checked yesterday for 3.0.0-6, now I have compiled the 3.0.0-7 to confirm

$rpmlint openvas-client-3.0.0-7.fc13.i686.rpm openvas-client-debuginfo-3.0.0-7.fc13.i686.rpm
openvas-client.i686: W: manual-page-warning /usr/share/man/man1/OpenVAS-Client.1.gz 243: warning: `UR' not defined
openvas-client.i686: W: manual-page-warning /usr/share/man/man1/openvasclient-mkcert.1.gz 31: warning: `UR' not defined
openvas-client.i686: W: manual-page-warning /usr/share/man/man1/openvasclient-mkcert.1.gz 33: warning: `UE' not defined
openvas-client.i686: W: no-manual-page-for-binary omp-cli
2 packages and 0 specfiles checked; 0 errors, 4 warnings.

$ file /usr/bin/OpenVAS-Client 
/usr/bin/OpenVAS-Client: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped

It is really stripped.

Koji build of 3.0.0-7 is successfull:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2236964

Files from koji build for x84_64 are stripped as well
$ file OpenVAS-Client omp-cli 
OpenVAS-Client: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
omp-cli:        ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped

Best regards
Michal Ambroz

Hello guys,
seems Stjepan is busy (1 week no response), the package is reviewed and main concern (non-stripped binaries) is not reproducible. As we agreed earlier on the principles of co-maintenance I am submitting the CVS request on Stjepan's behalf.


New Package CVS Request
=======================
Package Name: openvas-client
Short Description: Client component of Open Vulnerability Assessment (OpenVAS) Scanner
Owners: sgros huzaifas xavierb rebus
Branches: F-12 F-13 EL-5 EL-6 devel
InitialCC: 

Thank you
Michal Ambroz

CVS done (by process-cvs-requests.py).

openvas-client-3.0.0-7.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/openvas-client-3.0.0-7.fc12

openvas-client-3.0.0-7.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/openvas-client-3.0.0-7.fc13

Hello,
I have rebuild for F-12 F-13 F-14. Builds for F-12 and F-13 were sumbittend for signing for the updates. Build for EL-5 and EL-6 failed, because openvas-libraries are not in those branches yet.

Please help with testing if you have some spare time.

Best regards
Michal Ambroz

openvas-client-3.0.0-7.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

openvas-client-3.0.0-7.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.