@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

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.

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?

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.

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.

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.

Wine installed on both containers.

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.

thanks for installing wine

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

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

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

Nope.

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

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.

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

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?

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.

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?

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

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.

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.

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

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

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.

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!

We again have No space left on device.

https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-4691/44/pipeline

We again have No space left on device.

I cleaned up some space on the affected agent.

a7 was again "No space left on device.", I cleaned up, should work again. 🚀

l1 again doesn't have enough space, I turned off the agent.

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.

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

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

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

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

@lukashartl l1 seems to be down again?

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.

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.

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

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

EDIT: done.

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.

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

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

</details>

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.

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

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

We ran out of disk space again

@lukashartl any ideas why this occurs again?

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?

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.

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.

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

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

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

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

Done.

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

CI