@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 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.
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.
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?