GVM 22.4.0 documentation not ready?

@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 \
  -DPAHO_WITH_SSL=ON

if ! [ $? -eq 0 ]; then 
  echo "Error: cmake failed."
  exit 1
fi

cmake --build $BUILD_DIR/paho-client --target install

if ! [ $? -eq 0 ]; then 
  echo "Error: cmake install failed."
  exit 1
fi
1 Like

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

1 Like

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(?).

1 Like

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).

1 Like

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 :slight_smile:

1 Like

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.

2 Likes

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.

1 Like

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 :nerd_face:

https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring/#_anitya

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. :slight_smile:

Maybe in the future this problem could be solved by tagging such a release as a “pre-release”:

https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository

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. :slight_smile:

2 Likes

This error seems to persist, and I guess 22.4 is now a release:

#13 19.51 [ 29%] Building C object base/CMakeFiles/gvm_base_shared.dir/hosts.c.o
#13 19.53 [ 29%] Built target gvm_gmp_shared
#13 19.72 [ 31%] Building C object base/CMakeFiles/gvm_base_shared.dir/logging.c.o
#13 20.24 [ 34%] Building C object base/CMakeFiles/gvm_base_shared.dir/networking.c.o
#13 20.68 [ 36%] Building C object util/CMakeFiles/gvm_util_shared.dir/kb.c.o
#13 20.81 [ 38%] Building C object util/CMakeFiles/gvm_util_shared.dir/ldaputils.c.o
#13 23.03 [ 40%] Building C object base/CMakeFiles/gvm_base_shared.dir/nvti.c.o
#13 23.14 [ 43%] Building C object util/CMakeFiles/gvm_util_shared.dir/nvticache.c.o
#13 24.71 [ 45%] Building C object base/CMakeFiles/gvm_base_shared.dir/prefs.c.o
#13 24.74 [ 47%] Building C object base/CMakeFiles/gvm_base_shared.dir/pidfile.c.o
#13 25.27 [ 50%] Building C object util/CMakeFiles/gvm_util_shared.dir/mqtt.c.o
#13 25.80 In file included from /source/gvm-libs-22.4.0/util/mqtt.c:41:
#13 25.80 /source/gvm-libs-22.4.0/util/mqtt.h:28:10: fatal error: MQTTClient.h: No such file or directory
#13 25.80 28 | #include <MQTTClient.h>
#13 25.80 | ^~~~~~~~~~~~~~
#13 25.80 compilation terminated.

Any ideas how I can resolve this or is there a PR missing?

@thomasho by reading the documentation.

hint: install libpaho-mqtt-dev

Eero

1 Like

@Eero libpaho-mqtt-dev is installed on the build image, it was added with apt-get install before…

@thomasho your system is missing ” MQTTClient.h” or the search path is incorrect.

First make sure that it really exits in filesystem:

find / -type f -iname ”MQTTClient.h” -print

Eero

1 Like

Hi @thomasho

what OS are you running on? Do you have the correct version of MQTT? Did you follow our guide: Building 22.4 from Source - Greenbone Community Documentation ?

2 Likes

@Eero @y0urself Thanks, I got it to compile!

Happy to hear this. Do you want to share your solution for others? Thanks!

3 Likes

3 posts were split to a new topic: Libellux Documentation “E1187: Failed to source defaults.vim” and does not continue