Skip to content
This repository has been archived by the owner on Oct 15, 2024. It is now read-only.

Build Server stuff #160

Closed
20 of 31 tasks
markus2330 opened this issue Dec 13, 2014 · 671 comments
Closed
20 of 31 tasks

Build Server stuff #160

markus2330 opened this issue Dec 13, 2014 · 671 comments

Comments

@markus2330
Copy link
Contributor

markus2330 commented Dec 13, 2014

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:

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
Copy link
Contributor

manuelm commented Dec 16, 2014

@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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor

manuelm commented Sep 7, 2015

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
Copy link
Contributor Author

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
Copy link
Contributor

manuelm commented Sep 7, 2015

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
Copy link
Contributor

manuelm commented Sep 7, 2015

Wine installed on both containers.

@markus2330
Copy link
Contributor Author

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
Copy link
Contributor Author

thanks for installing wine

@manuelm
Copy link
Contributor

manuelm commented Sep 7, 2015

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

@markus2330
Copy link
Contributor Author

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

@markus2330
Copy link
Contributor Author

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
Copy link
Contributor

manuelm commented Sep 8, 2015

Nope.

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

@manuelm
Copy link
Contributor

manuelm commented Sep 8, 2015

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
Copy link
Contributor Author

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

@manuelm
Copy link
Contributor

manuelm commented Sep 10, 2015

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
Copy link
Contributor Author

markus2330 commented Sep 11, 2015 via email

@manuelm
Copy link
Contributor

manuelm commented Sep 11, 2015

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
Copy link
Contributor Author

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
Copy link
Contributor

manuelm commented Sep 11, 2015

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

@markus2330
Copy link
Contributor Author

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
Copy link
Contributor

manuelm commented Sep 11, 2015

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
Copy link
Contributor

manuelm commented Sep 11, 2015

@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
Copy link
Contributor

manuelm commented Sep 11, 2015

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

@manuelm
Copy link
Contributor

manuelm commented Sep 11, 2015

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
Copy link
Contributor Author

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
Copy link
Contributor Author

markus2330 commented Dec 11, 2022

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
Copy link
Collaborator

flo91 commented Dec 13, 2022

@kodebach
Copy link
Member

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
Copy link
Member

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

@markus2330
Copy link
Contributor Author

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

@lukashartl l1 seems to be down again?

@markus2330
Copy link
Contributor Author

markus2330 commented Dec 30, 2022

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
Copy link
Contributor

lukashartl commented Dec 30, 2022

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
Copy link
Member

mpranj commented Jan 18, 2023

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

@mpranj
Copy link
Member

mpranj commented Feb 3, 2023

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

EDIT: done.

@mpranj
Copy link
Member

mpranj commented Feb 28, 2023

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
Copy link
Member

mpranj commented Mar 12, 2023

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

@atmaxinger
Copy link
Contributor

atmaxinger commented Apr 28, 2023

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

See for example

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
Copy link
Contributor

tmakar commented May 1, 2023

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
Copy link
Contributor

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

@tmakar
Copy link
Contributor

tmakar commented May 10, 2023

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
Copy link
Contributor

We ran out of disk space again

@markus2330
Copy link
Contributor Author

@lukashartl any ideas why this occurs again?

@hannes99
Copy link
Contributor

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
Copy link
Contributor

tmakar commented May 16, 2023

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
Copy link
Contributor Author

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
Copy link
Contributor

lukashartl commented May 22, 2023

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
Copy link
Contributor

lukashartl commented May 22, 2023

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
Copy link
Contributor Author

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

@lukashartl
Copy link
Contributor

lukashartl commented May 25, 2023

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

Done.

@hannes99
Copy link
Contributor

hannes99 commented Jun 8, 2023

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

CI

Copy link

github-actions bot commented Jun 8, 2024

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 github-actions bot added the stale label Jun 8, 2024
Copy link

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 💖

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 23, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests