Build Server stuff

[markus2330]

This issue gives up-to-date information about the health of our build system.

Report here any permanent problems (that cannot be fixed by rerunning the build job). Temporary problems should be reported in #2967.

Current open issues for our Jenkins build system:

• check if make uninstall leaves a clean system, see make uninstall does not uninstall everything #1244
• integrate link checker (grep for warning: invalid link, see .cirrus.yml)
• man pages not regenerated (ronn)
• shellcheck [FLOSS] shellcheck #4497
• check if any temporary files are left over after running test cases
• Check for file names find . | grep -v '^[-_/.a-zA-Z0-9]*$' see [FLOSS H1] build server check: only allow a-z, 0-9 and _ for file names #1615
• check if core builds with c99
• add white spaces in top-level directory (above source&build)
• add ninja build
• Integrate go-elektra binding to main repo #3458
• even more tasks at Continuous Releases (see Continuous Releases #3519)
• integrate clang-tidy

Fixed issues:

• add -Werror to build jobs without warnings: Add -Werror to all Build Jobs #1812
• complexity checker: oclint (4 level)
• remove redundant jobs
• more build scripts in source?
• readding the -xdg build job (because we lost debian-unstable-mm)
• RelWithDebInfo in https://build.libelektra.org/jenkins/job/elektra-multiconfig-gcc-stable/203/ skipped?
• Rename elektra-gcc-configure-debian-optimizations to elektra-gcc-configure-debian-no-optimizations
• use higher -j on the mm agents (done for libelektra build job)
• jobs to update global repo so that not every job needs to refetch whole source again.
• enable elektra-clang-asan again
• stretch build agent which builds Elektra debian packages needs webserver
• have docker variants with minimal dependences
• run bashism checker
• build and install CppCms (build job for cppcms)
• minimal debian repos
• fix walking error on some jobs (e.g. doc, todo)
• gnupg2 on debian-wheezy-mr and debian-strech-mr
• fast build in passwd broken?
• build+source directory should contain spaces, define the names globally -> elektra-gcc-configure-debian-intree

[manuelm]

@markus2330

Just pushed a few build system related fixes. But you need to fix some packages on your stable debian-stable machine as well:

• Please install qtdeclarative5-dev from wheezy-backports (you can remove /opt/Qt5.3.0 afterwards)
• Please install java8 as package:
  • Use this method: http://www.webupd8.org/2014/03/how-to-install-oracle-java-8-in-debian.html
  • Let cmake actually find jdk8: cd /usr/lib/jvm/ && ln -s java-8-oracle default-java
  • echo -e "/usr/lib/jvm/java-8-oracle/jre/lib/amd64\n/usr/lib/jvm/java-8-oracle/jre/lib/amd64/server" > /etc/ld.so.conf.d/java-8-oracle.conf && ldconfig
  • kill + restart the local jenkins java process. Otherwise all builds will fail
  • Optional: Remove jdk7

[markus2330]

Looks good, thanks for fixing those issues.

I also did those steps on debian-stable agent.

For other machines installing qtdeclarative5-dev was not possible, because it conflicts with qdbus which is needed by kde4. So I restored the previous script configure-debian-wheezy as configure-debian-wheezy-local.

I also added the installation steps you mentioned as notes in the README.md because they might be of interest by others.

[markus2330]

Thanks for upgrading the agents!

Stuff that is missing on stable

1.) latex (+ I think texlive-latex-recommended is needed, too)
see http://build.libelektra.org:8080/job/elektra-doc/495/console

-- Found Doxygen: /usr/bin/doxygen (found version "1.8.8") 
CMake Warning at doc/CMakeLists.txt:46 (message):
  Latex not found, PDF Manual can't be created.


-- Found Perl: /usr/bin/perl (found version "5.20.2") 
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    BUILD_EXAMPLES

2.) Can you install clang (for elektra-clang, clang of wheezy won't work)?
3.) Can you install mingw+wine for elektra-gcc-configure-mingw?

[manuelm]

apt install --no-install-recommends doxygen-latex + clang + mingw done

Why do you need wine?

Btw, you should change i586-mingw32msvc-X to i686-w64-mingw32-X in Toolchain-mingw32.cmake. Right now this won't work on unstable.

[markus2330]

Thank you for docu!

wine is needed to execute the cross-compiled windows binaries (e.g. exporterrors.exe)

I think you installed the mingw that builds for w64. In the mingw32 package, there is still a /usr/bin/i586-mingw32msvc-c++.

A new toolchain file for w64 is nevertheless appreciated.

[manuelm]

I installed gcc-mingw-w64-i686 which is the x64 build of mingw with i686 as target.
The package mingw32-binutils is deprecated and not available on unstable any more.

[manuelm]

Wine installed on both containers.

[markus2330]

Actually, the mingw build is bound to stable, so that should not be an issue.

MinGW-w64 is a fork on mingw and is quite a different target. Nobody tested it up to now.

[markus2330]

thanks for installing wine

[manuelm]

Mingw-w64 looks superior. Maybe it's time to move on :-)

[markus2330]

Contributions welcome ;) I do not have any machine to test it.

[markus2330]

I am afraid you got the wrong wine, it should be apt-get install wine32

see also http://build.libelektra.org:8080/job/elektra-gcc-configure-mingw/218/console

[manuelm]

Nope.

root@debian-stable:~# apt-get install wine32
....
E: Package 'wine32' has no installation candidate

[manuelm]

ok, dpkg --add-architecture i386 will solve this. But can't you just pin the mingw/wine job to your build machine? The mingw setup is rather special.

Edit: I'll see if I can get elektra build with mingw-w64 so I don't need to install tons of i686 libs.

[markus2330]

The problem is I do not have a spare jessie machine and wheezy's mingw does not know C++11.

[manuelm]

I managed to get mingw-w64 working. However std::mutex is not available because there's no glibc on windows and std::mutex depends on pthreads. Any ideas?

[markus2330]

Wow, thanks! Does it lead to a compilation error? The std::mutex is not used for internal functionality, but only in a header file to be included by a user. It is used in test cases though. One solution for compiliation problems is to provide a std::mutex in the mingw case throwing system errors on every attempt to lock/unlock. Actually, I would expect the mingw people to at least provide something like that (e.g. when some macro is set, similar to -D_GLIBCXX_USE_NANOSLEEP) https://github.com/meganz/mingw-std-threads might be another way. But that is most likely only useful if all test cases except the ones involving std::mutex already run. Basically, this is only one instance of C++11 not properly available.

[manuelm]

mingw status right now:

• added dlfcn-win32 as external project to libloader. this way cmake checks out + compiles the library as an additional build step. I'm linking the archive to avoid additional dll deps.
• added winsock2.h/ws2_32.dll dependency to cpp11_benchmark_thread. required by gethostname()-call

Right now I'm building with -static-libgcc + -static-libstdc++. Otherwise wine is unable to find the dlls. Additional mutex doesn't compile either. I tried mingw-std-threads. just got more compile errors :-)

If I switch from x86_64-w64-mingw32-X to x86_64-w64-mingw32-X-posix std::mutex compiles fine, because pthread stuff is defined. However I get an additional dependency to libwinpthread-1.dll, which wine is unable to find.

I think our best bet is using x86_64-w64-mingw32-X-posix though.

[markus2330]

Again, I am surprised that you even have this problem. Up to now we were happy when we got a libelektra.dll.

I cannot say anything about this x86_64-w64-mingw32-X-posix decision, because I do not use it and do not know the implications. I am wondering that such a posix-lib even exists, I thought that the posix-layer approach is cygwin and not mingw.

Does this decision even has an effect on libelektra.dll? If its only for the test cases, no one will care (as long as the build server is able to run it). If the test cases run, it will be a huge benefit. (See #270 where the unit tests unveiled some strange bugs on Mac OS X)

It seems like that libwinpthread-1.dll can be downloaded, I do not know if they work with wine though? Can you also add it as external project like done with dlfcn-win32 (so that all dlls are handled in the same way)? Otherwise, if you need to download 1 or 3 dlls for the tests might not really matter (again, I am no user, and do not understand the deployment concept, if there is any, of windows dlls).

@beku What do you think? Do you have time to test our latest 0.8.13 mingw-w64 build on Windows together with oyranos?

[manuelm]

Are tests usually enabled for the mingw build job? Yesterday all of them were disabled.

[markus2330]

Yes, they were disabled. But afaik examples/benchmarks like cpp11_benchmark_thread were disabled, too. So I thought you changed it and compile more than it was done previously.

[manuelm]

I compiled the whole repo with C++11 enabled. Nothing more.

But executables like bin/basename.exe built with -posix run fine as long as you copy the required dlls to the bin directory (thank you windows for not having RPATH). I haven't found a way to a) let cmake find the dll directory + b) point wine to the dll directory.
I thought static linking would work but then the build fails with duplicate symbols during linking the elektra dll. Because the dll already has the symbols included.

[manuelm]

@markus2330 I managed to get elektra to compile with mingw + running with wine without copying any dlls. The trick is to always enable static linking for both executable AND shared objects (CMAKE_SHARED_LINKER_FLAGS/CMAKE_EXE_LINKER_FLAGS => "-static").

To work around duplicated symbols I've added version-scripts for libelektra and libelektratools. This way only our symbols get exported.

This works really fine. e.g.

$ wine64 ./bin/kdb-static.exe
Usage: Z:\home\manuel\build\bin\kdb-static.exe <command> [args]

Z:\home\manuel\build\bin\kdb-static.exe is a program to manage elektra's key database.
Run a command with -H or --help as args to show a help text for
a specific command.

Known commands are:
check   Do some basic checks on a plugin.
convert Convert configuration.
cp      Copy keys within the key database.
export  Export configuration from the key database.
file    Prints the file where a key is located.
fstab   Create a new fstab entry.
get     Get the value of an individual key.
[...]

$ wine64 bin/cpp_example_iter.exe
user/key3/1
user/key3/2
user/key3/3

Even bin/cpp11_benchmark_thread.exe works.

Other things just crash:

$ wine64 ./bin/kdb-static.exe get
wine: Unhandled page fault on read access to 0x00000000 at address 0x7fd0e8b62c8a (thread 0009), starting debugger...
Application tried to create a window, but no driver could be loaded.
Make sure that your X server is running and that $DISPLAY is set correctly.
Unhandled exception: page fault on read access to 0x00000000 in 64-bit code (0x00007fd0e8b62c8a).
Register dump:
 rip:00007fd0e8b62c8a rsp:000000000033f428 rbp:0000000000000000 eflags:00010293 (  R- --  I S -A- -C)
 rax:0000000000000000 rbx:000000000033f700 rcx:0000000000000000 rdx:000000000033f5b0
 rsi:0000000000000000 rdi:0000000000000000  r8:0000000000000000  r9:0000000000000072 r10:0000000000000000
 r11:000000000003f615 r12:000000000033f5b0 r13:00000000000373b0 r14:0000000000000000 r15:000000000033f930
Stack dump:
0x000000000033f428:  00007fd0e748ea93 0000000000000000
0x000000000033f438:  0000000000000000 0000000000000000
0x000000000033f448:  0000000000000028 0000000000010020
0x000000000033f458:  8d98315017c96400 6f46746547485300
0x000000000033f468:  687461507265646c 0000000000000000
0x000000000033f478:  0000000000000000 0000000000000000
0x000000000033f488:  000000000003fab0 0000000000030000
0x000000000033f498:  8d98315017c96400 6f46746547485300
0x000000000033f4a8:  687461507265646c 0000000000000000
0x000000000033f4b8:  0000000000000000 0000000000000000
0x000000000033f4c8:  0000000000000000 0000000000000000
0x000000000033f4d8:  0000000000000000 0000000000000000
Backtrace:
=>0 0x00007fd0e8b62c8a strlen+0x2a() in libc.so.6 (0x0000000000000000)
  1 0x00007fd0e748ea93 MSVCRT_stat64+0x92() in msvcrt (0x0000000000000000)
  2 0x00000000004744af in kdb-static (+0x744ae) (0x000000000003f9d0)
  3 0x000000000043bda5 in kdb-static (+0x3bda4) (0x000000000003f9d0)
  4 0x0000000000431d76 in kdb-static (+0x31d75) (0x00000000000360a0)
[...]

Right now I've simply added the version-script stuff without thinking about other compilers. Shall I continue my work or not interested?

[manuelm]

crashes in src/plugins/wresolver/wresolver.c because pk->filename is NULL

[manuelm]

pk is of type resolverHandles.user

I tried to take a look at the plugin but I fail to understand the for-loop in elektraWresolverOpen. The loop calls elektraWresolveFileName --> elektraResolve{Spec,Dir,User,System} which all malloc resolverHandle->filename and therefor leak memory.

[markus2330]

Thanks for pointing that out! The code is obviously broken since the introduction in c87ae8e
During looping only and always the system handle was initialized. This lead to crashes when another namespace was used.

I fixed it in
edb4d50

About continuing work: On the one hand, it would be nice if the compiled stuff also runs. On the other hand, the release should happen this weekend, so a pull request would be important soon (there should be at least a chance of a short feedback circle, e.g. what the version-scripts actually does)

But imho its enough if only one variant (the static compilation) works. Great to see the kdb-tool running!

[markus2330]

Now it was i7, I cleaned and restarted. Everything should work again, otherwise please report here.

EDIT: Also happened on v2. I restarted the two master builds that failed.

[flo91]

And once again, no space left on device.
See https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-4750/6/pipeline/57

[kodebach]

Are there really this many PRs that require rebuilding Docker images recently? It almost seems as if there is actually a different problem here...

[kodebach]

@markus2330 @lukashartl see #4779 for my proposal to avoid the build-up of Docker images

[markus2330]

Please no discussions here as many people are subscribed. Only status reports of CI infrastructure.

@lukashartl l1 seems to be down again?

[markus2330]

a7 has no space left on device, cleaning up. Maybe related to #4795.

Failed build was retrigger on master: https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/master/940/pipeline

EDIT 16:10: /ssd is now cleaned up (15%), I retrigger master.

[lukashartl]

a7, i7, l1 and v2 will be restarted to apply important updates (kernel, etc.) and to test pb_apply_updates.yaml. (shouldn't take more than 10 minutes)

UPDATE: done.

[mpranj]

I just applied the patch for sudo, CVE-2023-22809.

[mpranj]

All systems will be down shortly (<10min) to apply updates.

EDIT: done.

[mpranj]

The community server (and Jenkins) are extremely slow. I will reboot at 21:00 CET if there are no objections.

EDIT: reboot didn't help at all.

[mpranj]

Jenkins has been upgraded due to important security fixes. Everything is up and running again.

[atmaxinger]

For the past two weeks, Jenkins continually fails at docker pull

See for example

• Session Recording #4892 - https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-4892/112/pipeline
• [#1164] Set validation #4907 - https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-4907/14/pipeline
• [#3742] Cascading writes #4908 - https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-4908/18/pipeline
• Webd and elektrad bulk kdb meta-set #4910 - https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-4910/9/pipeline

Command Output

``` + docker pull hub.libelektra.org/build-elektra-debian-bullseye:202304-5401e635bf4ecef13011d26d223ae7ffd7ec6810d370cd9ed620b4c8d701648e

202304-5401e635bf4ecef13011d26d223ae7ffd7ec6810d370cd9ed620b4c8d701648e: Pulling from build-elektra-debian-bullseye

b0248cf3e63c: Pulling fs layer

31be8d2127f7: Pulling fs layer

6bdfde3f76a9: Pulling fs layer

d3a02b34ef39: Pulling fs layer

bb31511815c5: Pulling fs layer

857252a3cce5: Pulling fs layer

44374bef8a4c: Pulling fs layer

7a7d0ea7565f: Pulling fs layer

7dd6ac2f41a1: Pulling fs layer

e9c9746c0c1f: Pulling fs layer

df04be6a58c4: Pulling fs layer

fc2f83bee459: Pulling fs layer

5f8bfc51628f: Pulling fs layer

b7ad29071e14: Pulling fs layer

857252a3cce5: Waiting

44374bef8a4c: Waiting

df04be6a58c4: Waiting

7a7d0ea7565f: Waiting

fc2f83bee459: Waiting

5f8bfc51628f: Waiting

7dd6ac2f41a1: Waiting

b7ad29071e14: Waiting

e9c9746c0c1f: Waiting

bb31511815c5: Waiting

d3a02b34ef39: Waiting

b0248cf3e63c: Retrying in 5 seconds

6bdfde3f76a9: Verifying Checksum

6bdfde3f76a9: Download complete

d3a02b34ef39: Verifying Checksum

d3a02b34ef39: Download complete

bb31511815c5: Verifying Checksum

bb31511815c5: Download complete

b0248cf3e63c: Retrying in 4 seconds

857252a3cce5: Verifying Checksum

857252a3cce5: Download complete

44374bef8a4c: Verifying Checksum

44374bef8a4c: Download complete

7a7d0ea7565f: Download complete

b0248cf3e63c: Retrying in 3 seconds

b0248cf3e63c: Retrying in 2 seconds

b0248cf3e63c: Retrying in 1 second

b0248cf3e63c: Retrying in 10 seconds

b0248cf3e63c: Retrying in 9 seconds

b0248cf3e63c: Retrying in 8 seconds

b0248cf3e63c: Retrying in 7 seconds

b0248cf3e63c: Retrying in 6 seconds

b0248cf3e63c: Retrying in 5 seconds

b0248cf3e63c: Retrying in 4 seconds

b0248cf3e63c: Retrying in 3 seconds

b0248cf3e63c: Retrying in 2 seconds

b0248cf3e63c: Retrying in 1 second

b0248cf3e63c: Retrying in 15 seconds

b0248cf3e63c: Retrying in 14 seconds

b0248cf3e63c: Retrying in 13 seconds

b0248cf3e63c: Retrying in 12 seconds

b0248cf3e63c: Retrying in 11 seconds

b0248cf3e63c: Retrying in 10 seconds

b0248cf3e63c: Retrying in 9 seconds

b0248cf3e63c: Retrying in 8 seconds

b0248cf3e63c: Retrying in 7 seconds

b0248cf3e63c: Retrying in 6 seconds

b0248cf3e63c: Retrying in 5 seconds

b0248cf3e63c: Retrying in 4 seconds

b0248cf3e63c: Retrying in 3 seconds

b0248cf3e63c: Retrying in 2 seconds

7dd6ac2f41a1: Verifying Checksum

7dd6ac2f41a1: Download complete

e9c9746c0c1f: Download complete

df04be6a58c4: Verifying Checksum

df04be6a58c4: Download complete

fc2f83bee459: Verifying Checksum

fc2f83bee459: Download complete

b0248cf3e63c: Retrying in 1 second

b0248cf3e63c: Retrying in 20 seconds

b0248cf3e63c: Retrying in 19 seconds

b0248cf3e63c: Retrying in 18 seconds

5f8bfc51628f: Verifying Checksum

5f8bfc51628f: Download complete

b0248cf3e63c: Retrying in 17 seconds

b0248cf3e63c: Retrying in 16 seconds

b0248cf3e63c: Retrying in 15 seconds

b0248cf3e63c: Retrying in 14 seconds

b0248cf3e63c: Retrying in 13 seconds

b0248cf3e63c: Retrying in 12 seconds

b0248cf3e63c: Retrying in 11 seconds

b0248cf3e63c: Retrying in 10 seconds

b0248cf3e63c: Retrying in 9 seconds

b0248cf3e63c: Retrying in 8 seconds

b0248cf3e63c: Retrying in 7 seconds

b0248cf3e63c: Retrying in 6 seconds

b0248cf3e63c: Retrying in 5 seconds

b0248cf3e63c: Retrying in 4 seconds

b0248cf3e63c: Retrying in 3 seconds

b0248cf3e63c: Retrying in 2 seconds

b0248cf3e63c: Retrying in 1 second

b0248cf3e63c: Retrying in 25 seconds

b0248cf3e63c: Retrying in 24 seconds

b0248cf3e63c: Retrying in 23 seconds

b0248cf3e63c: Retrying in 22 seconds

b0248cf3e63c: Retrying in 21 seconds

b0248cf3e63c: Retrying in 20 seconds

b0248cf3e63c: Retrying in 19 seconds

b0248cf3e63c: Retrying in 18 seconds

b0248cf3e63c: Retrying in 17 seconds

b0248cf3e63c: Retrying in 16 seconds

b0248cf3e63c: Retrying in 15 seconds

b0248cf3e63c: Retrying in 14 seconds

b0248cf3e63c: Retrying in 13 seconds

b0248cf3e63c: Retrying in 12 seconds

b0248cf3e63c: Retrying in 11 seconds

b0248cf3e63c: Retrying in 10 seconds

b0248cf3e63c: Retrying in 9 seconds

b0248cf3e63c: Retrying in 8 seconds

b0248cf3e63c: Retrying in 7 seconds

b0248cf3e63c: Retrying in 6 seconds

b0248cf3e63c: Retrying in 5 seconds

b0248cf3e63c: Retrying in 4 seconds

b0248cf3e63c: Retrying in 3 seconds

b0248cf3e63c: Retrying in 2 seconds

b0248cf3e63c: Retrying in 1 second

b7ad29071e14: Verifying Checksum

b7ad29071e14: Download complete

31be8d2127f7: Verifying Checksum

31be8d2127f7: Download complete

unexpected EOF

script returned exit code 1

</details>

[tmakar]

I am not sure if this is on purpose but I have noticed that if jenkins pipeline is rerun with no changes and all phases in the pipeline finish successfully, shows that the pipeline failed. If I click on details, I am redirected to the Jenkins overview page of this build and I see that all phases are green. At the top of the page it displays in yellow that there are no new changes introduced with this rerun - which is obvious.

[atmaxinger]

Seems like we ran out of disk space on Jenkins ...

[tmakar]

Seems like we ran out of disk space on Jenkins ...

It was working today for a short time but it ran out of disk again

[atmaxinger]

We ran out of disk space again

[markus2330]

@lukashartl any ideas why this occurs again?

[hannes99]

From CI debian-unstable-clang-asan

==117504==ERROR: LeakSanitizer: detected memory leaks



Direct leak of 181544 byte(s) in 2878 object(s) allocated from:

    #0 0x556d1c87e8b8 in __interceptor_calloc (/home/jenkins/workspace/libelektra_PR-4922@2/build/bin/kdb+0x1bb8b8) (BuildId: c4a33e5ec0abff3a48fd9f2489d71f533e1b7f48)

    #1 0x7f5ae5c1184d  (/lib/x86_64-linux-gnu/libruby-3.1.so.3.1+0xd884d) (BuildId: fcd998f35452f5c383eaf6ab80c42f4d61e32f30)

this looks like there's something wrong with libruby, was it updated recently? Any idea what else could cause this?

and CI debian-buster-mingw

fatal error: regex.h: No such file or directory

   16 | #include <regex.h>

      |          ^~~~~~~~~

compilation terminated.

AFAIK regex is part of the GNU C Library, so it should be available, no?

[tmakar]

From CI debian-unstable-clang-asan

==117504==ERROR: LeakSanitizer: detected memory leaks



Direct leak of 181544 byte(s) in 2878 object(s) allocated from:

    #0 0x556d1c87e8b8 in __interceptor_calloc (/home/jenkins/workspace/libelektra_PR-4922@2/build/bin/kdb+0x1bb8b8) (BuildId: c4a33e5ec0abff3a48fd9f2489d71f533e1b7f48)

    #1 0x7f5ae5c1184d  (/lib/x86_64-linux-gnu/libruby-3.1.so.3.1+0xd884d) (BuildId: fcd998f35452f5c383eaf6ab80c42f4d61e32f30)

this looks like there's something wrong with libruby, was it updated recently? Any idea what else could cause this?

and CI debian-buster-mingw

fatal error: regex.h: No such file or directory

   16 | #include <regex.h>

      |          ^~~~~~~~~

compilation terminated.

AFAIK regex is part of the GNU C Library, so it should be available, no?

AFAIK there were no changes for libruby. Maybe you try rerunning Jenkins build if you haven’t already.

[markus2330]

No, on mingw you don't have full POSIX. This is off-topic here, please discuss in a separate issue, it is definitely not a build server problem.

[lukashartl]

Due to important system updates, most parts of the infrastructure will be down for multiple, short periods of time starting today (2023-05-22) at 20:00 CEST (UTC+2).

Update 23:00: Updates have been installed (kernel, jenkins, jenkins plugins, etc.).

[lukashartl]

As there is currently a release build running, I'll postpone the maintenance until the release pipeline(s) are finished.

Update 23:00: Updates have been installed (kernel, jenkins, jenkins plugins, etc.).

[markus2330]

Thx, if you see it failing, you can do the maintenance tasks. Please retrigger the release afterwards (see #4928).

[lukashartl]

Due to important os updates on the virtualization host, there will be a short downtime of all services.

Done.

[hannes99]

Something seems to be wrong with Cirrus, the three "Check" checks fail consistently. It looks like the docker build fails.

CI

[github-actions]

I mark this stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping by writing a message here or create a new issue with the remainder of this issue.
Thank you for your contributions 💖

[github-actions]

I closed this now because it has been inactive for more than one year. If I closed it by mistake, please do not hesitate to reopen it or create a new issue with the remainder of this issue.
Thank you for your contributions 💖