I just noticed the release of GVM 22.4.0 , When I wanted to rebuild my container I bumped into the error:
-- Looking for radcli library...
-- No suitable radius library found - radius support disabled
-- Looking for libldap...
-- No ldap library found - ldap support disabled
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- WARNING: Doxygen is required to build the HTML docs.
-- Configuring done
-- Generating done
-- Build files have been written to: /root/sources/gvm-libs-22.4.0/build
Scanning dependencies of target gvm_util_shared
[ 1%] Building C object util/CMakeFiles/gvm_util_shared.dir/passwordbasedauthentication.c.o
[ 2%] Building C object util/CMakeFiles/gvm_util_shared.dir/compressutils.c.o
[ 3%] Building C object util/CMakeFiles/gvm_util_shared.dir/fileutils.c.o
[ 4%] Building C object util/CMakeFiles/gvm_util_shared.dir/gpgmeutils.c.o
[ 5%] Building C object util/CMakeFiles/gvm_util_shared.dir/kb.c.o
[ 7%] Building C object util/CMakeFiles/gvm_util_shared.dir/ldaputils.c.o
[ 8%] Building C object util/CMakeFiles/gvm_util_shared.dir/nvticache.c.o
[ 9%] Building C object util/CMakeFiles/gvm_util_shared.dir/mqtt.c.o
In file included from /root/sources/gvm-libs-22.4.0/util/mqtt.c:41:
/root/sources/gvm-libs-22.4.0/util/mqtt.h:28:10: fatal error: MQTTClient.h: No such file or directory
28 | #include <MQTTClient.h>
make: *** [util/CMakeFiles/gvm_util_shared.dir/build.make:173: util/CMakeFiles/gvm_util_shared.dir/mqtt.c.o] Error 1
make: *** [CMakeFiles/Makefile2:711: util/CMakeFiles/gvm_util_shared.dir/all] Error 2
make: *** [CMakeFiles/Makefile2:281: CMakeFiles/tests.dir/rule] Error 2
make: *** [Makefile:216: tests] Error 2
error building at STEP "RUN mkdir --verbose --parents /root/sources/gvm-libs-"$gvm_libs_version"/build /root/downloads && curl --location https://github.com/greenbone/gvm-libs/archive/v"$gvm_libs_version".tar.gz --output /root/downloads/gvm-libs.tar.gz && curl --location https://github.com/greenbone/gvm-libs/releases/download/v"$gvm_libs_version"/gvm-libs-"$gvm_libs_version".tar.gz.asc --output /root/downloads/gvm-libs.tar.gz.asc && if ! gpg --verify /root/downloads/gvm-libs.tar.gz.asc ; then echo "GPG signature check failed"; exit 1; fi && tar --verbose --extract --file /root/downloads/gvm-libs.tar.gz --directory /root/sources/ && cd /root/sources/gvm-libs-"$gvm_libs_version"/build && cmake -DBUILD_TESTS=ON -DCMAKE_INSTALL_PREFIX="$install_prefix" -DCMAKE_BUILD_TYPE=Release -DSYSCONFDIR=/etc -DLOCALSTATEDIR=/var .. && make tests && make install && cmake -DBUILD_TESTS=ON .. && make tests && rm --verbose --recursive --force /root/sources /root/downloads": error while running runtime: exit status 2
So I though, let’s check the docs, but the latest still points to 21.4.0. My experience is that the GitHub README.md and INSTALL.md files have mistakes and are not up to date. The documentation link I just mentioned does usually work. When can we expect the latest documentation be ready?
Probably I need to install
libpaho-mqtt-dev, but if the docs are not in sync, I’d rather wait before I start troubleshooting and fixing things myself.
@AquaL1te well. where you can find this 22.4 documentation?
@AquaL1te and @Eero you should probably jsut wait until the docs are up to date (so will I - as I’ve came across a few issues I haven’t resolved yet), but you need to build paho.mqtt.c (paho client) e.g:
# Install Paho C client (temp solution)
curl -f -L https://github.com/eclipse/paho.mqtt.c/archive/refs/tags/v1.3.10.tar.gz -o $SOURCE_DIR/paho-client-1.3.10.tar.gz
tar -C $SOURCE_DIR -xvzf $SOURCE_DIR/paho-client-1.3.10.tar.gz && \
mkdir -p $BUILD_DIR/paho-client && cd $BUILD_DIR/paho-client
cmake $SOURCE_DIR/paho.mqtt.c-1.3.10 \
if ! [ $? -eq 0 ]; then
echo "Error: cmake failed."
cmake --build $BUILD_DIR/paho-client --target install
if ! [ $? -eq 0 ]; then
echo "Error: cmake install failed."
I did add a test file you can follow and see if it works. Any feedback is more than welcome before I update my documentation. I did not have time yet to test it all myself if it works 100% but might be useful for you to figure out the new build. You’ll find the file at: https://github.com/libellux/Libellux-Up-and-Running/blob/master/docs/openvas/config/ubuntu_22.4.0.sh
I can’t promise I’ll have time this week to check this out. Thanks for the example.
gvmd 22.4 moved the postgresql functions into a proper standalone postgresql extension “pg-gvm” (https://github.com/greenbone/pg-gvm) which is currently still missing a release/tag. strangly the CMake build system of gvmd 22.4 additionally still checks for postgresql as well https://github.com/greenbone/gvmd/blob/stable/src/CMakeLists.txt#L38 to my understanding that shouldn’t be needed anymore now that we have the postgresql extension(?).
I was running into this same issue
I referenced libellux’s provided build script and was able to get my pipeline to go through. All I needed to do was add lines 70-75 to my installation script (With some minor modifications); that appears to have done the trick.
I’ve updated and fixed gvm-libs in https://github.com/greenbone/gvm-libs/pull/695 for the 22.04 release. This release is not announced yet therefore it isn’t ready. The docs (https://greenbone.github.io/docs/) will always stay with the current recommended release(s). If they don’t mention a specific release then this release in not recommended from our side (yet or anymore).
I don’t want to sound like “that guy”, but if you create a release on GitHub most people would consider it ready for use
From my experiences with other software projects on GitHub (this is not specific to Greenbone) a release tagged on GitHub doesn’t mean that the release is “officially” published / ready, especially if multiple components are involved.
Exactly. We just had to re-create some tags/releases on GitHub. Until there is no announcement in this forum I wouldn’t consider it as ready for consumption.
Why is our process different to just do a release on GitHub? We need to coordinate releases with several repos that even have some inter dependencies. That means we need to create a GitHub release for being able to test other repo releases.
My experience is different, also release monitoring by Linux distros is done based on release tags. Automatic builds and issue creating/tracking are also triggered by it. For example Anitya for Fedora. Ubuntu, Debian and others have theirs. Creating a tag is fine, publishing it as a release, is a ready to use release. But maybe we life in different timelines
Not absolutely sure but i have seen this automatic building so far only for minor releases (which should be IMHO fine) but not for major releases. But i must admin that i have only see a minor part of the whole packaging world.
Maybe in the future this problem could be solved by tagging such a release as a “pre-release”:
These automatic builds are scratch builds, so they are not automatically published, not even to rawhide/sid. It happens regardless of minor or major releases. I suppose pre-release makes it more obvious.