Even EPEL 5 ships Cmake 2.6. I think, you don't need the version constraint.

Please inform upstream about the incorrect FSF postal address.

Please see http://fedoraproject.org/wiki/Packaging:Guidelines#Handling_Locale_Files

You try to own the directory /etc/openvas, which is already owned by another package.

Don't include INSTALL.

Hello Volker,

(In reply to comment #1)
> Even EPEL 5 ships Cmake 2.6. I think, you don't need the version constraint.
CMakeLists.txt:cmake_minimum_required (VERSION 2.6)
That's the reason I included the version constraint

> Please inform upstream about the incorrect FSF postal address.
I will do. 

> Please see
> http://fedoraproject.org/wiki/Packaging:Guidelines#Handling_Locale_Files
I have seen it when packaging the gsd - that guideline is for gettext localisations. Translations in GSD are not done using gettext, but it uses the QT functionalities for that. As there are no special guideline for that I have checked how it is in other projects using the QT (scribus, smplayer, scidavis) and left it as it is in the translations directory.

> You try to own the directory /etc/openvas, which is already owned by another
> package.
Historical reasons for that - openvas-libraries originally didn't own the directory so it is owned by each of the openvas packages storing there the configuration. I will remove it.


> Don't include INSTALL.
OK I will remove it.

Quite about every possible build target (besides EPEL4 maybe) ships CMake 2.6 or newer. You don't have an older version anywhere around, so the version restriction is pointless. It is fulfilled whatever may be.

You can drop the defattr line, if you don't plan to package to EPEL4. If you don't plan to package for EPEL at all, you can drop Buildroot, the clean section and rm -rf %{buildroot} in the install section. Please see for reference: http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Distribution_specific_guidelines

The configuration file points to a log directory, that doesn't exist. Create it or require a package that provides it.

Ad translations: Forget the gettext part, but the rest applies.

Please use -p when you install the icon to keep the timestamp. Why do you set 755 for an icon?

You should probably be more explicit in your files section, given the fact, you only install a few files. For instance:

- %{upname}* --> %{upname}.8.*
- %{_datadir}/applications/* --> %{_datadir}/applications/%{upname}.desktop

While it is not necessary from a technical point of view, it avoids to install things inadvertently.

Concerning the CMake flags: It is probably easier to set CMAKE_INSTALL_PREFIX empty, but I haven't tried.

I'm pretty certain, "Requires: htmldoc" is not needed to run the program. It also pulls in other packages. I beg your pardon, if I'm wrong.

If you BR Doxygen, you should also use it: See INSTALL -- there is a build target for the documentation. I don't know though, whether the output is valuable.

Hi,
once again thanks for comments. 
Sorry for delay - I am fighting the deprecated gnutls code in openvas-libraries to be able to update whole suite to recent versions.

>You can drop the defattr line, if you don't plan to package to EPEL4.
I do plan for EPEL as the other packages of openvas do.

>Why do you set 755 for an icon?
This is just wrong should be 644.

Michal Ambroz

Any news here?

Any news, Michal?

Unfortunately the core packages (libraries, server, manager) are still not working properly to me.

Here is the update openvas-gsd package
Spec URL: http://rebus.fedorapeople.org/SPECS/openvas-gsd.spec
SRPM URL: http://rebus.fedorapeople.org/SRPMS/openvas-gsd-1.2.1-1.fc16.src.rpm

Best regards
Michal Ambroz

Updated openvas-gsd package:
Here is the update openvas-gsd package
Spec URL: http://rebus.fedorapeople.org/SPECS/openvas-gsd.spec
SRPM URL: http://rebus.fedorapeople.org/SRPMS/openvas-gsd-1.2.2-2.fc17.src.rpm

There is still issue with gnutls x openvas.
According to upstream - gnutls in fedora is old and not compiled with the recommended ASN1 library.
Openvas claims working fine.
Gnutls claims working fine.
Truth is probably somewhere in between.

According the network dumps the difference is that on working systems connection is established in one TCP packet and data is read on other. With gnutls the TLS connection and data is in 1 TCP packet and openvas-library keeps waiting forever.
I will describe more on openvas-cli.

Once openvas-library is fixed this will start working as well so please do the review.
For working please test against the LiveCD from Openvas Project.

Michal Ambroz

OpenVas5 seems to work with current version of gnutls in Fedora 17.

Spec URL: http://rebus.fedorapeople.org/SPECS/openvas-gsd.spec
SRPM URL: http://rebus.fedorapeople.org/SRPMS/openvas-gsd-1.2.2-2.fc17.src.rpm


You need to use srpms from rawhide in order to try on Fedroa 17:
openvas-libraries https://koji.fedoraproject.org/koji/buildinfo?buildID=366563
openvas-scanner https://koji.fedoraproject.org/koji/buildinfo?buildID=366564
openvas-manager https://koji.fedoraproject.org/koji/buildinfo?buildID=366590

openvas-administrator https://bugzilla.redhat.com/show_bug.cgi?id=693126

Best regards
Michal Ambroz

Please make the build verbose! Also, read through the locale guidelines once more, as they apply.

Hi Volker,

>Please make the build verbose!
I am not sure what you mean. 
Build is made verbose by makro %cmake by default.
I have added explicit -DCMAKE_VERBOSE_MAKEFILE:BOOL=TRUE, but I believe it is redundant.
Please can you confirm this is what you have meant?

>Also, read through the locale guidelines once more, as they apply.
Added %find_lang.

Spec URL: http://rebus.fedorapeople.org/SPECS/openvas-gsd.spec
SRPM URL: http://rebus.fedorapeople.org/SRPMS/openvas-gsd-1.2.2-3.fc18.src.rpm

http://koji.fedoraproject.org/koji/taskinfo?taskID=4940635

Fails to build in Rawhide now:

http://koji.fedoraproject.org/koji/taskinfo?taskID=5308077

Can we close this request?

Yes we can close this one ... not supported in the 7.x branch anyway.