- 07 May, 2021 3 commits
-
-
Jérome Perrin authored
-
Jérome Perrin authored
- make cloudooo services use same name as in haproxy, this was off by one (service cloudooo-0 was cloudooo_0 in haproxy) - test cluster functionality (to catch bug from nexedi/cloudooo!29 ) - update cloudooo with that fix - make sure we set an existant locale ( by using `C.UTF-8` ) and exercice a bit conversions involving characters encoding See merge request nexedi/slapos!975
-
Łukasz Nowak authored
The "30" was not removed by mistake, which lead to activity timeout being 30, instead of configured one.
-
- 06 May, 2021 1 commit
-
-
Thomas Gambier authored
See merge request !977
-
- 05 May, 2021 4 commits
-
-
Xavier Thompson authored
-
Xavier Thompson authored
-
Xavier Thompson authored
-
Xavier Thompson authored
-
- 04 May, 2021 1 commit
-
-
Xavier Thompson authored
-
- 03 May, 2021 1 commit
-
-
Julien Muchembled authored
-
- 30 Apr, 2021 4 commits
-
-
Jérome Perrin authored
see nexedi/cloudooo@0b5ff71a
-
Jérome Perrin authored
So that the service names match the backend names in haproxy
-
Jérome Perrin authored
-
Jérome Perrin authored
Libreoffice needs to run with an UTF-8 locale, otherwise it does not use proper encoding for text files. cloudooo sets a default locale as a fallback, but using en_US.UTF-8, which is not always present (it is not present on capri testnodes). Anyway, this kind of configuration is the job of slapos, so we prefer to have it done at slapos level.
-
- 28 Apr, 2021 1 commit
-
-
Léo-Paul Géneau authored
- pins component/fluentd gems version to fix : ERROR: Error installing fluentd: msgpack requires Ruby version >= 2.4. encountered while supplying software/fluentd in a SlapOS Webrunner. - removes outdated gem arguments '--no-ri --no-rdoc' by default `rubygemsrecipe` uses '--no-document' (see https://lab.nexedi.com/nexedi/rubygemsrecipe/blob/master/rubygems.py#L206) - splits `gem-options` arguments to fit the README example (see https://lab.nexedi.com/nexedi/rubygemsrecipe/blob/master/README.rst#L50) - adds minimal test to check fluentd SR instanciation
-
- 27 Apr, 2021 5 commits
-
-
Julien Muchembled authored
-
Julien Muchembled authored
https://mesonbuild.com/
-
Julien Muchembled authored
-
Thomas Gambier authored
The keyboard option is actually not recommended in the QEMU documentation (https://manpages.debian.org/buster/qemu-system-x86/qemu-system-x86_64.1.en.html). After some tests, it appears that noVNC is already sending raw keyCode to QEMU since 2016 (see https://github.com/novnc/noVNC/commit/f4f4e8993d6daeb43b957766cd6973993232ba13). More information can be found in https://github.com/novnc/noVNC/issues/21 and https://www.berrange.com/posts/2010/07/04/more-than-you-or-i-ever-wanted-to-know-about-virtual-keyboard-handling/
-
Thomas Gambier authored
-
- 26 Apr, 2021 3 commits
-
-
Julien Muchembled authored
-
Łukasz Nowak authored
rotate_size 0 or rotate_size -1 does not help to disable rotation, so workaround it by setting very big rotation limit.
-
Julien Muchembled authored
See merge request nexedi/slapos!968
-
- 21 Apr, 2021 7 commits
-
-
Cédric Le Ninivin authored
-
Cédric Le Ninivin authored
-
Thomas Gambier authored
-
Jérome Perrin authored
It was formatted with a '\t', which json-schemas test does not allow.
-
Jérome Perrin authored
We are not using this
-
Jérome Perrin authored
-
Jérome Perrin authored
This host header is not passed by default, because we are already using proxy_set_header, so we need to set it explicitly. It seems that since we updated some packages in in 279486fe (stack/slapos: version up some eggs with known vulnerabilties, 2021-01-28) slaprunner was producing URLs with "localhost" as hostname when using redirect(url_for(...))
-
- 20 Apr, 2021 4 commits
-
-
Thomas Gambier authored
-
Cédric Le Ninivin authored
-
Jérome Perrin authored
As discussed in https://github.com/nextcloud/news/issues/1306 a new release was uploaded.
-
Thomas Gambier authored
See merge request nexedi/slapos!939
-
- 19 Apr, 2021 1 commit
-
-
Łukasz Nowak authored
-
- 16 Apr, 2021 5 commits
-
-
Julien Muchembled authored
-
Julien Muchembled authored
Commit 2f4d8cf8 fixed the following error: Generating phar.php .../parts/apache-php__compile__/php-7.3.6/sapi/cli/php: error while loading shared libraries: libzstd.so.1: cannot open shared object file: No such file or directory Makefile:420: recipe for target 'ext/phar/phar.php' failed and only -rpath is needed. apache-php does not actually depend on zstd (hence the removal of the 'extends' line) but there's something not smart: $ ldd .../parts/apache-php__compile__/php-7.3.6/sapi/cli/php linux-vdso.so.1 (0x00007ffe29f86000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f625e64a000) libcrypto.so.1.1 => .../shared/openssl/.../lib/libcrypto.so.1.1 (0x00007f625e35e000) libssl.so.1.1 => .../shared/openssl/.../lib/libssl.so.1.1 (0x00007f625ea05000) libzip.so.5 => .../shared/libzip/.../lib/libzip.so.5 (0x00007f625e9ea000) libz.so.1 => .../shared/zlib/.../lib/libz.so.1 (0x00007f625e142000) libargon2.so.1 => /srv/slapgrid/slappart10/srv/runner/software/.../parts/argon2/lib/x86_64-linux-gnu/libargon2.so.1 (0x00007f625e9de000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f625df3a000) libldap-2.4.so.2 => .../shared/openldap/.../lib/libldap-2.4.so.2 (0x00007f625e991000) libsasl2.so.3 => .../shared/cyrus-sasl/.../lib/libsasl2.so.3 (0x00007f625e973000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f625dd36000) liblber-2.4.so.2 => .../shared/openldap/.../lib/liblber-2.4.so.2 (0x00007f625e963000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f625db1f000) libstdc++.so.6 => .../shared/gcc-8.4/.../lib/../lib64/libstdc++.so.6 (0x00007f625d994000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f625d690000) libintl.so.8 => .../shared/gettext/.../lib/libintl.so.8 (0x00007f625d485000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f625d0e6000) /lib64/ld-linux-x86-64.so.2 (0x00007f625e882000) libjpeg.so.9 => .../shared/libjpeg/.../lib/libjpeg.so.9 (0x00007f625e924000) libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f625cece000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f625ccb1000) libcurl.so.4 => .../shared/curl/.../lib/libcurl.so.4 (0x00007f625e8ac000) libnghttp2.so.14 => .../shared/nghttp2/.../lib/libnghttp2.so.14 (0x00007f625cc87000) libzstd.so.1 => not found libfreetype.so.6 => .../shared/freetype/.../lib/libfreetype.so.6 (0x00007f625cbe8000) libbz2.so.1.0 => .../shared/bzip2/.../lib/libbz2.so.1.0 (0x00007f625cbd5000) libpng16.so.16 => .../shared/libpng/.../lib/libpng16.so.16 (0x00007f625cba0000) libicui18n.so.58 => .../shared/icu/.../lib/libicui18n.so.58 (0x00007f625c914000) libicuuc.so.58 => .../shared/icu/.../lib/libicuuc.so.58 (0x00007f625c762000) libicudata.so.58 => .../shared/icu/.../lib/libicudata.so.58 (0x00007f625ae60000) libicuio.so.58 => .../shared/icu/.../lib/libicuio.so.58 (0x00007f625ae50000) libxml2.so.2 => .../shared/libxml2/.../lib/libxml2.so.2 (0x00007f625aaef000) libgcc_s.so.1 => .../shared/gcc-8.4/.../lib/../lib64/libgcc_s.so.1 (0x00007f625aad5000) libzstd.so.1 => .../shared/zstd/.../lib/libzstd.so.1 (0x00007f625a9fb000) (look at the 2 'libzstd.so.1 => ' lines above) $ grep zstd .../shared/curl/.../lib/pkgconfig/libcurl.pc supported_features="..." Libs.private: -lnghttp2 -lssl -lcrypto -lssl -lcrypto -lzstd -lzstd -lz -pthread $ ldd .../shared/curl/.../lib/libcurl.so.4 linux-vdso.so.1 (0x00007ffc42b15000) libnghttp2.so.14 => .../shared/nghttp2/.../lib/libnghttp2.so.14 (0x00007f54315d5000) libssl.so.1.1 => .../shared/openssl/.../lib/libssl.so.1.1 (0x00007f543153f000) libcrypto.so.1.1 => .../shared/openssl/.../lib/libcrypto.so.1.1 (0x00007f5431168000) libzstd.so.1 => .../shared/zstd/.../lib/libzstd.so.1 (0x00007f543108e000) libz.so.1 => .../shared/zlib/.../lib/libz.so.1 (0x00007f5430e72000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f5430c55000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f54308b6000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f54306b2000) /lib64/ld-linux-x86-64.so.2 (0x00007f5431454000)
-
Julien Muchembled authored
-
Julien Muchembled authored
-
Julien Muchembled authored
This fixes the following random failure: .../shared/nano/3a832cf2f5e8161a0cbd45936bbdac02/bin/rnano uses system library /lib/x86_64-linux-gnu/liblzma.so.5.2.2 for liblzma.so.5
-