[PATCH 00/12] Wave goodbye to RHEL 7 vintage distros

[PATCH 00/12] Wave goodbye to RHEL 7 vintage distros

[Daniel P. Berrangé]

The main motivation for this series is to eliminate some backcompat
logic in the crypto code only needed for RHEL-7. I take the opportunity
to also bump the min required versions of glib, gcc and clang since we
have dropped many distros since they were last bumped.

There are possibly some more cleanups that can be done as a side effect
of these new min versions, but I leave that for other interested people
to look at.

One that might be intesting is switching from std=gnu99 to gnu11 since
we're no longer constrainted by the 4.8.x vintage GCC which marked gnu11
as experimental (see 7be41675f7cb16be7c8d2554add7a63fa43781a8)

Daniel P. Berrangé (12):
  gitlab: move linux user build job from CentOS 7 to CentOS 8
  patchew: move quick build job from CentOS 7 to CentOS 8 container
  crypto: bump min nettle to 3.3, dropping RHEL-7 support
  crypto: drop back compatibility typedefs for nettle
  crypto: bump min gcrypt to 1.7.6, dropping RHEL-7 support
  crypto: bump min gnutls to 3.5.8, dropping RHEL-7 support
  crypto: drop used conditional check
  tests/vm: convert centos VM recipe to CentOS 8
  tests/docker: drop CentOS 7 container
  bump min required glib version to 2.50
  configure: bump min required GCC to 6.3.0
  configure: bump min required CLang to 7.0.0 / XCode 10.2

 .gitlab-ci.d/containers.yml             |   5 -
 .gitlab-ci.yml                          |  41 +----
 .patchew.yml                            |   6 +-
 configure                               |  40 ++---
 crypto/cipher-nettle.c.inc              |  91 +++--------
 crypto/hash-nettle.c                    |  10 +-
 crypto/hmac-nettle.c                    |  12 +-
 crypto/meson.build                      |   6 +-
 crypto/tlscredsx509.c                   |   2 -
 include/glib-compat.h                   |   9 --
 tests/docker/dockerfiles/centos7.docker |  43 -----
 tests/docker/dockerfiles/centos8.docker |   1 +
 tests/vm/centos                         |   6 +-
 util/oslib-win32.c                      | 204 ------------------------
 14 files changed, 52 insertions(+), 424 deletions(-)
 delete mode 100644 tests/docker/dockerfiles/centos7.docker

-- 
2.31.1

[PATCH 01/12] gitlab: move linux user build job from CentOS 7 to CentOS 8

[Daniel P. Berrangé]

It has been over two years since RHEL-8 was released, and thus per the
platform build policy, we no longer need to support RHEL-7 as a build
target.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 .gitlab-ci.yml                          | 6 +++---
 tests/docker/dockerfiles/centos8.docker | 1 +
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index dcb6317aac..23917d6d73 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -441,12 +441,12 @@ build-user-plugins:
     MAKE_CHECK_ARGS: check-tcg
   timeout: 1h 30m
 
-build-user-centos7:
+build-user-centos8:
   <<: *native_build_job_definition
   needs:
-    job: amd64-centos7-container
+    job: amd64-centos8-container
   variables:
-    IMAGE: centos7
+    IMAGE: centos8
     CONFIGURE_ARGS: --disable-system --disable-tools --disable-docs
     MAKE_CHECK_ARGS: check-tcg
 
diff --git a/tests/docker/dockerfiles/centos8.docker b/tests/docker/dockerfiles/centos8.docker
index a8c6c528b0..b00809e9fc 100644
--- a/tests/docker/dockerfiles/centos8.docker
+++ b/tests/docker/dockerfiles/centos8.docker
@@ -13,6 +13,7 @@ ENV PACKAGES \
     gettext \
     git \
     glib2-devel \
+    glibc-static \
     libaio-devel \
     libepoxy-devel \
     libfdt-devel \
-- 
2.31.1

[PATCH 02/12] patchew: move quick build job from CentOS 7 to CentOS 8 container

[Daniel P. Berrangé]

It has been over two years since RHEL-8 was released, and thus per the
platform build policy, we no longer need to support RHEL-7 as a build
target.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 .patchew.yml | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/.patchew.yml b/.patchew.yml
index 988c29261f..2638b7f564 100644
--- a/.patchew.yml
+++ b/.patchew.yml
@@ -88,7 +88,7 @@ email:
         more information:
 
         {{ logtext }}
-        {% elif test == "docker-mingw@fedora" or test == "docker-quick@centos7" or test == "asan" %}
+        {% elif test == "docker-mingw@fedora" or test == "docker-quick@centos8" or test == "asan" %}
         Hi,
 
         This series failed the {{ test }} build test. Please find the testing commands and
@@ -124,13 +124,13 @@ testing:
       script: |
         #!/bin/bash
         time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1
-    docker-quick@centos7:
+    docker-quick@centos8:
       enabled: false
       requirements: docker,x86_64
       timeout: 3600
       script: |
         #!/bin/bash
-        time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
+        time make docker-test-quick@centos8 SHOW_ENV=1 J=14 NETWORK=1
     checkpatch:
       enabled: true
       requirements: ''
-- 
2.31.1

[PATCH 03/12] crypto: bump min nettle to 3.3, dropping RHEL-7 support

[Daniel P. Berrangé]

It has been over two years since RHEL-8 was released, and thus per the
platform build policy, we no longer need to support RHEL-7 as a build
target. This lets us increment the minimum required nettle version and
drop a lot of backwards compatibility code for 2.x series of nettle.

Per repology, current shipping versions are:

             RHEL-8: 3.4.1
     Debian Stretch: 3.3
      Debian Buster: 3.4.1
 openSUSE Leap 15.2: 3.4.1
   Ubuntu LTS 18.04: 3.4
   Ubuntu LTS 20.04: 3.5.1
            FreeBSD: 3.7.2
          Fedora 33: 3.5.1
          Fedora 34: 3.7.2
            OpenBSD: 3.7.2
     macOS HomeBrew: 3.7.2

Debian Stretch has the oldest version and so 3.3 is the new minimum.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 .gitlab-ci.yml             | 10 ----------
 configure                  |  4 +---
 crypto/cipher-nettle.c.inc | 31 -------------------------------
 crypto/hash-nettle.c       |  4 ----
 crypto/hmac-nettle.c       |  4 ----
 5 files changed, 1 insertion(+), 52 deletions(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 23917d6d73..aef16515d3 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -716,16 +716,6 @@ build-coroutine-sigaltstack:
 #
 # These jobs test old gcrypt and nettle from RHEL7
 # which had some API differences.
-crypto-old-nettle:
-  <<: *native_build_job_definition
-  needs:
-    job: amd64-centos7-container
-  variables:
-    IMAGE: centos7
-    TARGETS: x86_64-softmmu x86_64-linux-user
-    CONFIGURE_ARGS: --disable-gcrypt --enable-nettle
-    MAKE_CHECK_ARGS: check
-
 crypto-old-gcrypt:
   <<: *native_build_job_definition
   needs:
diff --git a/configure b/configure
index 54f8475444..53902d9c02 100755
--- a/configure
+++ b/configure
@@ -2860,10 +2860,9 @@ has_libgcrypt() {
 
 if test "$nettle" != "no"; then
     pass="no"
-    if $pkg_config --exists "nettle >= 2.7.1"; then
+    if $pkg_config --exists "nettle >= 3.3"; then
         nettle_cflags=$($pkg_config --cflags nettle)
         nettle_libs=$($pkg_config --libs nettle)
-        nettle_version=$($pkg_config --modversion nettle)
         # Link test to make sure the given libraries work (e.g for static).
         write_c_skeleton
         if compile_prog "" "$nettle_libs" ; then
@@ -5722,7 +5721,6 @@ if test "$gcrypt" = "yes" ; then
 fi
 if test "$nettle" = "yes" ; then
   echo "CONFIG_NETTLE=y" >> $config_host_mak
-  echo "CONFIG_NETTLE_VERSION_MAJOR=${nettle_version%%.*}" >> $config_host_mak
   echo "NETTLE_CFLAGS=$nettle_cflags" >> $config_host_mak
   echo "NETTLE_LIBS=$nettle_libs" >> $config_host_mak
 fi
diff --git a/crypto/cipher-nettle.c.inc b/crypto/cipher-nettle.c.inc
index cac771e4ff..490472656c 100644
--- a/crypto/cipher-nettle.c.inc
+++ b/crypto/cipher-nettle.c.inc
@@ -39,41 +39,10 @@ typedef void (*QCryptoCipherNettleFuncWrapper)(const void *ctx,
                                                uint8_t *dst,
                                                const uint8_t *src);
 
-#if CONFIG_NETTLE_VERSION_MAJOR < 3
-typedef nettle_crypt_func * QCryptoCipherNettleFuncNative;
-typedef void *       cipher_ctx_t;
-typedef unsigned     cipher_length_t;
-#define CONST_CTX
-
-#define cast5_set_key cast128_set_key
-
-#define aes128_ctx aes_ctx
-#define aes192_ctx aes_ctx
-#define aes256_ctx aes_ctx
-#define aes128_set_encrypt_key(c, k) \
-    aes_set_encrypt_key(c, 16, k)
-#define aes192_set_encrypt_key(c, k) \
-    aes_set_encrypt_key(c, 24, k)
-#define aes256_set_encrypt_key(c, k) \
-    aes_set_encrypt_key(c, 32, k)
-#define aes128_set_decrypt_key(c, k) \
-    aes_set_decrypt_key(c, 16, k)
-#define aes192_set_decrypt_key(c, k) \
-    aes_set_decrypt_key(c, 24, k)
-#define aes256_set_decrypt_key(c, k) \
-    aes_set_decrypt_key(c, 32, k)
-#define aes128_encrypt aes_encrypt
-#define aes192_encrypt aes_encrypt
-#define aes256_encrypt aes_encrypt
-#define aes128_decrypt aes_decrypt
-#define aes192_decrypt aes_decrypt
-#define aes256_decrypt aes_decrypt
-#else
 typedef nettle_cipher_func * QCryptoCipherNettleFuncNative;
 typedef const void * cipher_ctx_t;
 typedef size_t       cipher_length_t;
 #define CONST_CTX    const
-#endif
 
 static inline bool qcrypto_length_check(size_t len, size_t blocksize,
                                         Error **errp)
diff --git a/crypto/hash-nettle.c b/crypto/hash-nettle.c
index 2a6ee7c7d5..5c8977fb80 100644
--- a/crypto/hash-nettle.c
+++ b/crypto/hash-nettle.c
@@ -26,11 +26,7 @@
 #include <nettle/sha.h>
 #include <nettle/ripemd160.h>
 
-#if CONFIG_NETTLE_VERSION_MAJOR < 3
-typedef unsigned int     hash_length_t;
-#else
 typedef size_t       hash_length_t;
-#endif
 
 typedef void (*qcrypto_nettle_init)(void *ctx);
 typedef void (*qcrypto_nettle_write)(void *ctx,
diff --git a/crypto/hmac-nettle.c b/crypto/hmac-nettle.c
index 1152b741fd..da6b6fa014 100644
--- a/crypto/hmac-nettle.c
+++ b/crypto/hmac-nettle.c
@@ -18,11 +18,7 @@
 #include "hmacpriv.h"
 #include <nettle/hmac.h>
 
-#if CONFIG_NETTLE_VERSION_MAJOR < 3
-typedef unsigned int hmac_length_t;
-#else
 typedef size_t hmac_length_t;
-#endif
 
 typedef void (*qcrypto_nettle_hmac_setkey)(void *ctx,
                                            hmac_length_t key_length,
-- 
2.31.1

[PATCH 04/12] crypto: drop back compatibility typedefs for nettle

[Daniel P. Berrangé]

Now that we only support modern nettle, we don't need to have local
typedefs to mask the real nettle types.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 crypto/cipher-nettle.c.inc | 60 ++++++++++++++++----------------------
 crypto/hash-nettle.c       |  6 ++--
 crypto/hmac-nettle.c       |  8 ++---
 3 files changed, 30 insertions(+), 44 deletions(-)

diff --git a/crypto/cipher-nettle.c.inc b/crypto/cipher-nettle.c.inc
index 490472656c..fc6f40c026 100644
--- a/crypto/cipher-nettle.c.inc
+++ b/crypto/cipher-nettle.c.inc
@@ -34,16 +34,6 @@
 #include <nettle/xts.h>
 #endif
 
-typedef void (*QCryptoCipherNettleFuncWrapper)(const void *ctx,
-                                               size_t length,
-                                               uint8_t *dst,
-                                               const uint8_t *src);
-
-typedef nettle_cipher_func * QCryptoCipherNettleFuncNative;
-typedef const void * cipher_ctx_t;
-typedef size_t       cipher_length_t;
-#define CONST_CTX    const
-
 static inline bool qcrypto_length_check(size_t len, size_t blocksize,
                                         Error **errp)
 {
@@ -166,12 +156,12 @@ static const struct QCryptoCipherDriver NAME##_driver_ctr = {           \
 static void NAME##_xts_wrape(const void *ctx, size_t length,            \
                              uint8_t *dst, const uint8_t *src)          \
 {                                                                       \
-    ENCRYPT((cipher_ctx_t)ctx, length, dst, src);                       \
+    ENCRYPT((const void *)ctx, length, dst, src);                       \
 }                                                                       \
 static void NAME##_xts_wrapd(const void *ctx, size_t length,            \
                              uint8_t *dst, const uint8_t *src)          \
 {                                                                       \
-    DECRYPT((cipher_ctx_t)ctx, length, dst, src);                       \
+    DECRYPT((const void *)ctx, length, dst, src);                       \
 }                                                                       \
 static int NAME##_encrypt_xts(QCryptoCipher *cipher, const void *in,    \
                               void *out, size_t len, Error **errp)      \
@@ -251,13 +241,13 @@ typedef struct QCryptoNettleDESRFB {
     uint8_t iv[DES_BLOCK_SIZE];
 } QCryptoNettleDESRFB;
 
-static void des_encrypt_native(cipher_ctx_t ctx, cipher_length_t length,
+static void des_encrypt_native(const void *ctx, size_t length,
                                uint8_t *dst, const uint8_t *src)
 {
     des_encrypt(ctx, length, dst, src);
 }
 
-static void des_decrypt_native(cipher_ctx_t ctx, cipher_length_t length,
+static void des_decrypt_native(const void *ctx, size_t length,
                                uint8_t *dst, const uint8_t *src)
 {
     des_decrypt(ctx, length, dst, src);
@@ -273,13 +263,13 @@ typedef struct QCryptoNettleDES3 {
     uint8_t iv[DES3_BLOCK_SIZE];
 } QCryptoNettleDES3;
 
-static void des3_encrypt_native(cipher_ctx_t ctx, cipher_length_t length,
+static void des3_encrypt_native(const void *ctx, size_t length,
                                 uint8_t *dst, const uint8_t *src)
 {
     des3_encrypt(ctx, length, dst, src);
 }
 
-static void des3_decrypt_native(cipher_ctx_t ctx, cipher_length_t length,
+static void des3_decrypt_native(const void *ctx, size_t length,
                                 uint8_t *dst, const uint8_t *src)
 {
     des3_decrypt(ctx, length, dst, src);
@@ -296,17 +286,17 @@ typedef struct QCryptoNettleAES128 {
     struct aes128_ctx key[2], key_xts[2];
 } QCryptoNettleAES128;
 
-static void aes128_encrypt_native(cipher_ctx_t ctx, cipher_length_t length,
+static void aes128_encrypt_native(const void *ctx, size_t length,
                                   uint8_t *dst, const uint8_t *src)
 {
-    CONST_CTX struct aes128_ctx *keys = ctx;
+    const struct aes128_ctx *keys = ctx;
     aes128_encrypt(&keys[0], length, dst, src);
 }
 
-static void aes128_decrypt_native(cipher_ctx_t ctx, cipher_length_t length,
+static void aes128_decrypt_native(const void *ctx, size_t length,
                                   uint8_t *dst, const uint8_t *src)
 {
-    CONST_CTX struct aes128_ctx *keys = ctx;
+    const struct aes128_ctx *keys = ctx;
     aes128_decrypt(&keys[1], length, dst, src);
 }
 
@@ -322,17 +312,17 @@ typedef struct QCryptoNettleAES192 {
     struct aes192_ctx key[2], key_xts[2];
 } QCryptoNettleAES192;
 
-static void aes192_encrypt_native(cipher_ctx_t ctx, cipher_length_t length,
+static void aes192_encrypt_native(const void *ctx, size_t length,
                                   uint8_t *dst, const uint8_t *src)
 {
-    CONST_CTX struct aes192_ctx *keys = ctx;
+    const struct aes192_ctx *keys = ctx;
     aes192_encrypt(&keys[0], length, dst, src);
 }
 
-static void aes192_decrypt_native(cipher_ctx_t ctx, cipher_length_t length,
+static void aes192_decrypt_native(const void *ctx, size_t length,
                                   uint8_t *dst, const uint8_t *src)
 {
-    CONST_CTX struct aes192_ctx *keys = ctx;
+    const struct aes192_ctx *keys = ctx;
     aes192_decrypt(&keys[1], length, dst, src);
 }
 
@@ -348,17 +338,17 @@ typedef struct QCryptoNettleAES256 {
     struct aes256_ctx key[2], key_xts[2];
 } QCryptoNettleAES256;
 
-static void aes256_encrypt_native(cipher_ctx_t ctx, cipher_length_t length,
+static void aes256_encrypt_native(const void *ctx, size_t length,
                                   uint8_t *dst, const uint8_t *src)
 {
-    CONST_CTX struct aes256_ctx *keys = ctx;
+    const struct aes256_ctx *keys = ctx;
     aes256_encrypt(&keys[0], length, dst, src);
 }
 
-static void aes256_decrypt_native(cipher_ctx_t ctx, cipher_length_t length,
-                               uint8_t *dst, const uint8_t *src)
+static void aes256_decrypt_native(const void *ctx, size_t length,
+                                  uint8_t *dst, const uint8_t *src)
 {
-    CONST_CTX struct aes256_ctx *keys = ctx;
+    const struct aes256_ctx *keys = ctx;
     aes256_decrypt(&keys[1], length, dst, src);
 }
 
@@ -373,13 +363,13 @@ typedef struct QCryptoNettleCAST128 {
     struct cast128_ctx key, key_xts;
 } QCryptoNettleCAST128;
 
-static void cast128_encrypt_native(cipher_ctx_t ctx, cipher_length_t length,
+static void cast128_encrypt_native(const void *ctx, size_t length,
                                    uint8_t *dst, const uint8_t *src)
 {
     cast128_encrypt(ctx, length, dst, src);
 }
 
-static void cast128_decrypt_native(cipher_ctx_t ctx, cipher_length_t length,
+static void cast128_decrypt_native(const void *ctx, size_t length,
                                    uint8_t *dst, const uint8_t *src)
 {
     cast128_decrypt(ctx, length, dst, src);
@@ -397,13 +387,13 @@ typedef struct QCryptoNettleSerpent {
 } QCryptoNettleSerpent;
 
 
-static void serpent_encrypt_native(cipher_ctx_t ctx, cipher_length_t length,
+static void serpent_encrypt_native(const void *ctx, size_t length,
                                    uint8_t *dst, const uint8_t *src)
 {
     serpent_encrypt(ctx, length, dst, src);
 }
 
-static void serpent_decrypt_native(cipher_ctx_t ctx, cipher_length_t length,
+static void serpent_decrypt_native(const void *ctx, size_t length,
                                    uint8_t *dst, const uint8_t *src)
 {
     serpent_decrypt(ctx, length, dst, src);
@@ -420,13 +410,13 @@ typedef struct QCryptoNettleTwofish {
     struct twofish_ctx key, key_xts;
 } QCryptoNettleTwofish;
 
-static void twofish_encrypt_native(cipher_ctx_t ctx, cipher_length_t length,
+static void twofish_encrypt_native(const void *ctx, size_t length,
                                    uint8_t *dst, const uint8_t *src)
 {
     twofish_encrypt(ctx, length, dst, src);
 }
 
-static void twofish_decrypt_native(cipher_ctx_t ctx, cipher_length_t length,
+static void twofish_decrypt_native(const void *ctx, size_t length,
                                    uint8_t *dst, const uint8_t *src)
 {
     twofish_decrypt(ctx, length, dst, src);
diff --git a/crypto/hash-nettle.c b/crypto/hash-nettle.c
index 5c8977fb80..1ca1a41062 100644
--- a/crypto/hash-nettle.c
+++ b/crypto/hash-nettle.c
@@ -26,14 +26,12 @@
 #include <nettle/sha.h>
 #include <nettle/ripemd160.h>
 
-typedef size_t       hash_length_t;
-
 typedef void (*qcrypto_nettle_init)(void *ctx);
 typedef void (*qcrypto_nettle_write)(void *ctx,
-                                     hash_length_t len,
+                                     size_t len,
                                      const uint8_t *buf);
 typedef void (*qcrypto_nettle_result)(void *ctx,
-                                      hash_length_t len,
+                                      size_t len,
                                       uint8_t *buf);
 
 union qcrypto_hash_ctx {
diff --git a/crypto/hmac-nettle.c b/crypto/hmac-nettle.c
index da6b6fa014..1ad6c4f253 100644
--- a/crypto/hmac-nettle.c
+++ b/crypto/hmac-nettle.c
@@ -18,18 +18,16 @@
 #include "hmacpriv.h"
 #include <nettle/hmac.h>
 
-typedef size_t hmac_length_t;
-
 typedef void (*qcrypto_nettle_hmac_setkey)(void *ctx,
-                                           hmac_length_t key_length,
+                                           size_t key_length,
                                            const uint8_t *key);
 
 typedef void (*qcrypto_nettle_hmac_update)(void *ctx,
-                                           hmac_length_t length,
+                                           size_t length,
                                            const uint8_t *data);
 
 typedef void (*qcrypto_nettle_hmac_digest)(void *ctx,
-                                           hmac_length_t length,
+                                           size_t length,
                                            uint8_t *digest);
 
 typedef struct QCryptoHmacNettle QCryptoHmacNettle;
-- 
2.31.1

[PATCH 05/12] crypto: bump min gcrypt to 1.7.6, dropping RHEL-7 support

[Daniel P. Berrangé]

It has been over two years since RHEL-8 was released, and thus per the
platform build policy, we no longer need to support RHEL-7 as a build
target. This lets us increment the minimum required gcrypt version and
assume that HMAC is always supported

Per repology, current shipping versions are:

             RHEL-8: 1.8.5
     Debian Stretch: 1.7.6
      Debian Buster: 1.8.4
 openSUSE Leap 15.2: 1.8.2
   Ubuntu LTS 18.04: 1.8.1
   Ubuntu LTS 20.04: 1.8.5
            FreeBSD: 1.9.2
          Fedora 33: 1.8.6
          Fedora 34: 1.9.3
            OpenBSD: 1.9.3
     macOS HomeBrew: 1.9.3

Debian Stretch has the oldest version and so 1.7.6 is the new minimum.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 .gitlab-ci.yml     | 10 ----------
 configure          | 18 +-----------------
 crypto/meson.build |  6 +-----
 3 files changed, 2 insertions(+), 32 deletions(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index aef16515d3..0fefda2674 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -716,16 +716,6 @@ build-coroutine-sigaltstack:
 #
 # These jobs test old gcrypt and nettle from RHEL7
 # which had some API differences.
-crypto-old-gcrypt:
-  <<: *native_build_job_definition
-  needs:
-    job: amd64-centos7-container
-  variables:
-    IMAGE: centos7
-    TARGETS: x86_64-softmmu x86_64-linux-user
-    CONFIGURE_ARGS: --disable-nettle --enable-gcrypt
-    MAKE_CHECK_ARGS: check
-
 crypto-only-gnutls:
   <<: *native_build_job_definition
   needs:
diff --git a/configure b/configure
index 53902d9c02..d5569f9252 100755
--- a/configure
+++ b/configure
@@ -426,7 +426,6 @@ gnutls="$default_feature"
 nettle="$default_feature"
 nettle_xts="no"
 gcrypt="$default_feature"
-gcrypt_hmac="no"
 gcrypt_xts="no"
 qemu_private_xts="yes"
 auth_pam="$default_feature"
@@ -2849,7 +2848,7 @@ has_libgcrypt() {
     maj=`libgcrypt-config --version | awk -F . '{print $1}'`
     min=`libgcrypt-config --version | awk -F . '{print $2}'`
 
-    if test $maj != 1 || test $min -lt 5
+    if test $maj != 1 || test $min -lt 7
     then
        return 1
     fi
@@ -2915,18 +2914,6 @@ if test "$gcrypt" != "no"; then
         gcrypt="yes"
         cat > $TMPC << EOF
 #include <gcrypt.h>
-int main(void) {
-  gcry_mac_hd_t handle;
-  gcry_mac_open(&handle, GCRY_MAC_HMAC_MD5,
-                GCRY_MAC_FLAG_SECURE, NULL);
-  return 0;
-}
-EOF
-        if compile_prog "$gcrypt_cflags" "$gcrypt_libs" ; then
-            gcrypt_hmac=yes
-        fi
-        cat > $TMPC << EOF
-#include <gcrypt.h>
 int main(void) {
   gcry_cipher_hd_t handle;
   gcry_cipher_open(&handle, GCRY_CIPHER_AES, GCRY_CIPHER_MODE_XTS, 0);
@@ -5713,9 +5700,6 @@ if test "$gnutls" = "yes" ; then
 fi
 if test "$gcrypt" = "yes" ; then
   echo "CONFIG_GCRYPT=y" >> $config_host_mak
-  if test "$gcrypt_hmac" = "yes" ; then
-    echo "CONFIG_GCRYPT_HMAC=y" >> $config_host_mak
-  fi
   echo "GCRYPT_CFLAGS=$gcrypt_cflags" >> $config_host_mak
   echo "GCRYPT_LIBS=$gcrypt_libs" >> $config_host_mak
 fi
diff --git a/crypto/meson.build b/crypto/meson.build
index 7f37b5d335..af7e80c6f6 100644
--- a/crypto/meson.build
+++ b/crypto/meson.build
@@ -26,11 +26,7 @@ if 'CONFIG_NETTLE' in config_host
   crypto_ss.add(files('hash-nettle.c', 'hmac-nettle.c', 'pbkdf-nettle.c'))
 elif 'CONFIG_GCRYPT' in config_host
   crypto_ss.add(files('hash-gcrypt.c', 'pbkdf-gcrypt.c'))
-  if 'CONFIG_GCRYPT_HMAC' in config_host
-    crypto_ss.add(files('hmac-gcrypt.c'))
-  else
-    crypto_ss.add(files('hmac-glib.c'))
-  endif
+  crypto_ss.add(files('hmac-gcrypt.c'))
 else
   crypto_ss.add(files('hash-glib.c', 'hmac-glib.c', 'pbkdf-stub.c'))
 endif
-- 
2.31.1

[PATCH 06/12] crypto: bump min gnutls to 3.5.8, dropping RHEL-7 support

[Daniel P. Berrangé]

It has been over two years since RHEL-8 was released, and thus per the
platform build policy, we no longer need to support RHEL-7 as a build
target. This lets us increment the minimum required gnutls version

Per repology, current shipping versions are:

             RHEL-8: 3.6.14
     Debian Stretch: 3.5.8
      Debian Buster: 3.6.7
 openSUSE Leap 15.2: 3.6.7
   Ubuntu LTS 18.04: 3.5.18
   Ubuntu LTS 20.04: 3.6.13
            FreeBSD: 3.6.15
          Fedora 33: 3.6.16
          Fedora 34: 3.7.1
            OpenBSD: 3.6.15
     macOS HomeBrew: 3.6.15

Debian Stretch has the oldest version and so 1.7.6 is the new minimum.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 .gitlab-ci.yml | 15 ---------------
 configure      |  2 +-
 2 files changed, 1 insertion(+), 16 deletions(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 0fefda2674..c5b8ea0d94 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -712,21 +712,6 @@ build-coroutine-sigaltstack:
                     --enable-trace-backends=ftrace
     MAKE_CHECK_ARGS: check-unit
 
-# Most jobs test latest gcrypt or nettle builds
-#
-# These jobs test old gcrypt and nettle from RHEL7
-# which had some API differences.
-crypto-only-gnutls:
-  <<: *native_build_job_definition
-  needs:
-    job: amd64-centos7-container
-  variables:
-    IMAGE: centos7
-    TARGETS: x86_64-softmmu x86_64-linux-user
-    CONFIGURE_ARGS: --disable-nettle --disable-gcrypt --enable-gnutls
-    MAKE_CHECK_ARGS: check
-
-
 # Check our reduced build configurations
 build-without-default-devices:
   <<: *native_build_job_definition
diff --git a/configure b/configure
index d5569f9252..69631fad3b 100755
--- a/configure
+++ b/configure
@@ -2790,7 +2790,7 @@ fi
 
 if test "$gnutls" != "no"; then
     pass="no"
-    if $pkg_config --exists "gnutls >= 3.1.18"; then
+    if $pkg_config --exists "gnutls >= 3.5.8"; then
         gnutls_cflags=$($pkg_config --cflags gnutls)
         gnutls_libs=$($pkg_config --libs gnutls)
         # Packaging for the static libraries is not always correct.
-- 
2.31.1

[PATCH 07/12] crypto: drop used conditional check

[Daniel P. Berrangé]

The condition being tested has never been set since the day the code was
first introduced.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 crypto/tlscredsx509.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/crypto/tlscredsx509.c b/crypto/tlscredsx509.c
index bc503bab55..d9d6f4421e 100644
--- a/crypto/tlscredsx509.c
+++ b/crypto/tlscredsx509.c
@@ -354,11 +354,9 @@ qcrypto_tls_creds_check_cert_pair(gnutls_x509_crt_t cert,
             reason = "The certificate has been revoked";
         }
 
-#ifndef GNUTLS_1_0_COMPAT
         if (status & GNUTLS_CERT_INSECURE_ALGORITHM) {
             reason = "The certificate uses an insecure algorithm";
         }
-#endif
 
         error_setg(errp,
                    "Our own certificate %s failed validation against %s: %s",
-- 
2.31.1

[PATCH 08/12] tests/vm: convert centos VM recipe to CentOS 8

[Daniel P. Berrangé]

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 tests/vm/centos | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/vm/centos b/tests/vm/centos
index efe3dbbb36..215da14c23 100755
--- a/tests/vm/centos
+++ b/tests/vm/centos
@@ -26,13 +26,13 @@ class CentosVM(basevm.BaseVM):
         export SRC_ARCHIVE=/dev/vdb;
         sudo chmod a+r $SRC_ARCHIVE;
         tar -xf $SRC_ARCHIVE;
-        make docker-test-block@centos7 {verbose} J={jobs} NETWORK=1;
-        make docker-test-quick@centos7 {verbose} J={jobs} NETWORK=1;
+        make docker-test-block@centos8 {verbose} J={jobs} NETWORK=1;
+        make docker-test-quick@centos8 {verbose} J={jobs} NETWORK=1;
         make docker-test-mingw@fedora  {verbose} J={jobs} NETWORK=1;
     """
 
     def build_image(self, img):
-        cimg = self._download_with_cache("https://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud-1802.qcow2.xz")
+        cimg = self._download_with_cache("https://cloud.centos.org/centos/8/x86_64/images/CentOS-8-GenericCloud-8.1.1911-20200113.3.x86_64.qcow2")
         img_tmp = img + ".tmp"
         sys.stderr.write("Extracting the image...\n")
         subprocess.check_call(["ln", "-f", cimg, img_tmp + ".xz"])
-- 
2.31.1

[PATCH 09/12] tests/docker: drop CentOS 7 container

[Daniel P. Berrangé]

It has been over two years since RHEL-8 was released, and thus per the
platform build policy, we no longer need to support RHEL-7 as a build
target.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 .gitlab-ci.d/containers.yml             |  5 ---
 tests/docker/dockerfiles/centos7.docker | 43 -------------------------
 2 files changed, 48 deletions(-)
 delete mode 100644 tests/docker/dockerfiles/centos7.docker

diff --git a/.gitlab-ci.d/containers.yml b/.gitlab-ci.d/containers.yml
index 33e4046e23..0fd792dbe7 100644
--- a/.gitlab-ci.d/containers.yml
+++ b/.gitlab-ci.d/containers.yml
@@ -26,11 +26,6 @@ amd64-alpine-container:
   variables:
     NAME: alpine
 
-amd64-centos7-container:
-  <<: *container_job_definition
-  variables:
-    NAME: centos7
-
 amd64-centos8-container:
   <<: *container_job_definition
   variables:
diff --git a/tests/docker/dockerfiles/centos7.docker b/tests/docker/dockerfiles/centos7.docker
deleted file mode 100644
index 75fdb53c7c..0000000000
--- a/tests/docker/dockerfiles/centos7.docker
+++ /dev/null
@@ -1,43 +0,0 @@
-FROM centos:7
-RUN yum install -y epel-release centos-release-xen-48
-
-RUN yum -y update
-
-# Please keep this list sorted alphabetically
-ENV PACKAGES \
-    bzip2 \
-    bzip2-devel \
-    ccache \
-    csnappy-devel \
-    dbus-daemon \
-    gcc-c++ \
-    gcc \
-    gettext \
-    git \
-    glib2-devel \
-    glibc-static \
-    gnutls-devel \
-    libaio-devel \
-    libepoxy-devel \
-    libfdt-devel \
-    libgcrypt-devel \
-    librdmacm-devel \
-    libzstd-devel \
-    lzo-devel \
-    make \
-    mesa-libEGL-devel \
-    mesa-libgbm-devel \
-    nettle-devel \
-    ninja-build \
-    perl-Test-Harness \
-    pixman-devel \
-    python3 \
-    SDL2-devel \
-    spice-glib-devel \
-    spice-server-devel \
-    tar \
-    vte-devel \
-    xen-devel \
-    zlib-devel
-RUN yum install -y $PACKAGES
-RUN rpm -q $PACKAGES | sort > /packages.txt
-- 
2.31.1

[PATCH 10/12] bump min required glib version to 2.50

[Daniel P. Berrangé]

The glib version was not previously constrained by RHEL-7 since it
rebases fairly often. Instead SLES 12 and Ubuntu 16.04 were the
constraints in 00f2cfbbec63fb6f5a7789797a62ccedd22466ea. Both of
these are old enough that they are outside our platform support
matrix now.

Per repology, current shipping versions are:

             RHEL-8: 2.56.4
     Debian Stretch: 2.50.3
      Debian Buster: 2.58.3
 openSUSE Leap 15.2: 2.62.6
   Ubuntu LTS 18.04: 2.56.4
   Ubuntu LTS 20.04: 2.64.6
            FreeBSD: 2.66.7
          Fedora 33: 2.66.8
          Fedora 34: 2.68.1
            OpenBSD: 2.68.1
     macOS HomeBrew: 2.68.1

Thus Debian Stretch is the constraint for GLib version now.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 configure             |   2 +-
 include/glib-compat.h |   9 --
 util/oslib-win32.c    | 204 ------------------------------------------
 3 files changed, 1 insertion(+), 214 deletions(-)

diff --git a/configure b/configure
index 69631fad3b..a1a40577c9 100755
--- a/configure
+++ b/configure
@@ -3296,7 +3296,7 @@ done
 ##########################################
 # glib support probe
 
-glib_req_ver=2.48
+glib_req_ver=2.50
 glib_modules=gthread-2.0
 if test "$modules" = yes; then
     glib_modules="$glib_modules gmodule-export-2.0"
diff --git a/include/glib-compat.h b/include/glib-compat.h
index 4542e920d5..f3b2eb04da 100644
--- a/include/glib-compat.h
+++ b/include/glib-compat.h
@@ -68,15 +68,6 @@
  * without generating warnings.
  */
 
-#if defined(_WIN32) && !GLIB_CHECK_VERSION(2, 50, 0)
-/*
- * g_poll has a problem on Windows when using
- * timeouts < 10ms, so use wrapper.
- */
-#define g_poll(fds, nfds, timeout) g_poll_fixed(fds, nfds, timeout)
-gint g_poll_fixed(GPollFD *fds, guint nfds, gint timeout);
-#endif
-
 #if defined(G_OS_UNIX)
 /*
  * Note: The fallback implementation is not MT-safe, and it returns a copy of
diff --git a/util/oslib-win32.c b/util/oslib-win32.c
index 05e4ee5033..ca99356fdf 100644
--- a/util/oslib-win32.c
+++ b/util/oslib-win32.c
@@ -347,210 +347,6 @@ const char *qemu_get_exec_dir(void)
     return exec_dir;
 }
 
-#if !GLIB_CHECK_VERSION(2, 50, 0)
-/*
- * The original implementation of g_poll from glib has a problem on Windows
- * when using timeouts < 10 ms.
- *
- * Whenever g_poll is called with timeout < 10 ms, it does a quick poll instead
- * of wait. This causes significant performance degradation of QEMU.
- *
- * The following code is a copy of the original code from glib/gpoll.c
- * (glib commit 20f4d1820b8d4d0fc4447188e33efffd6d4a88d8 from 2014-02-19).
- * Some debug code was removed and the code was reformatted.
- * All other code modifications are marked with 'QEMU'.
- */
-
-/*
- * gpoll.c: poll(2) abstraction
- * Copyright 1998 Owen Taylor
- * Copyright 2008 Red Hat, Inc.
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2.1 of the License, or (at your option) any later version.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, see <http://www.gnu.org/licenses/>.
- */
-
-static int poll_rest(gboolean poll_msgs, HANDLE *handles, gint nhandles,
-                     GPollFD *fds, guint nfds, gint timeout)
-{
-    DWORD ready;
-    GPollFD *f;
-    int recursed_result;
-
-    if (poll_msgs) {
-        /* Wait for either messages or handles
-         * -> Use MsgWaitForMultipleObjectsEx
-         */
-        ready = MsgWaitForMultipleObjectsEx(nhandles, handles, timeout,
-                                            QS_ALLINPUT, MWMO_ALERTABLE);
-
-        if (ready == WAIT_FAILED) {
-            gchar *emsg = g_win32_error_message(GetLastError());
-            g_warning("MsgWaitForMultipleObjectsEx failed: %s", emsg);
-            g_free(emsg);
-        }
-    } else if (nhandles == 0) {
-        /* No handles to wait for, just the timeout */
-        if (timeout == INFINITE) {
-            ready = WAIT_FAILED;
-        } else {
-            SleepEx(timeout, TRUE);
-            ready = WAIT_TIMEOUT;
-        }
-    } else {
-        /* Wait for just handles
-         * -> Use WaitForMultipleObjectsEx
-         */
-        ready =
-            WaitForMultipleObjectsEx(nhandles, handles, FALSE, timeout, TRUE);
-        if (ready == WAIT_FAILED) {
-            gchar *emsg = g_win32_error_message(GetLastError());
-            g_warning("WaitForMultipleObjectsEx failed: %s", emsg);
-            g_free(emsg);
-        }
-    }
-
-    if (ready == WAIT_FAILED) {
-        return -1;
-    } else if (ready == WAIT_TIMEOUT || ready == WAIT_IO_COMPLETION) {
-        return 0;
-    } else if (poll_msgs && ready == WAIT_OBJECT_0 + nhandles) {
-        for (f = fds; f < &fds[nfds]; ++f) {
-            if (f->fd == G_WIN32_MSG_HANDLE && f->events & G_IO_IN) {
-                f->revents |= G_IO_IN;
-            }
-        }
-
-        /* If we have a timeout, or no handles to poll, be satisfied
-         * with just noticing we have messages waiting.
-         */
-        if (timeout != 0 || nhandles == 0) {
-            return 1;
-        }
-
-        /* If no timeout and handles to poll, recurse to poll them,
-         * too.
-         */
-        recursed_result = poll_rest(FALSE, handles, nhandles, fds, nfds, 0);
-        return (recursed_result == -1) ? -1 : 1 + recursed_result;
-    } else if (/* QEMU: removed the following unneeded statement which causes
-                * a compiler warning: ready >= WAIT_OBJECT_0 && */
-               ready < WAIT_OBJECT_0 + nhandles) {
-        for (f = fds; f < &fds[nfds]; ++f) {
-            if ((HANDLE) f->fd == handles[ready - WAIT_OBJECT_0]) {
-                f->revents = f->events;
-            }
-        }
-
-        /* If no timeout and polling several handles, recurse to poll
-         * the rest of them.
-         */
-        if (timeout == 0 && nhandles > 1) {
-            /* Remove the handle that fired */
-            int i;
-            for (i = ready - WAIT_OBJECT_0 + 1; i < nhandles; i++) {
-                handles[i-1] = handles[i];
-            }
-            nhandles--;
-            recursed_result = poll_rest(FALSE, handles, nhandles, fds, nfds, 0);
-            return (recursed_result == -1) ? -1 : 1 + recursed_result;
-        }
-        return 1;
-    }
-
-    return 0;
-}
-
-gint g_poll_fixed(GPollFD *fds, guint nfds, gint timeout)
-{
-    HANDLE handles[MAXIMUM_WAIT_OBJECTS];
-    gboolean poll_msgs = FALSE;
-    GPollFD *f;
-    gint nhandles = 0;
-    int retval;
-
-    for (f = fds; f < &fds[nfds]; ++f) {
-        if (f->fd == G_WIN32_MSG_HANDLE && (f->events & G_IO_IN)) {
-            poll_msgs = TRUE;
-        } else if (f->fd > 0) {
-            /* Don't add the same handle several times into the array, as
-             * docs say that is not allowed, even if it actually does seem
-             * to work.
-             */
-            gint i;
-
-            for (i = 0; i < nhandles; i++) {
-                if (handles[i] == (HANDLE) f->fd) {
-                    break;
-                }
-            }
-
-            if (i == nhandles) {
-                if (nhandles == MAXIMUM_WAIT_OBJECTS) {
-                    g_warning("Too many handles to wait for!\n");
-                    break;
-                } else {
-                    handles[nhandles++] = (HANDLE) f->fd;
-                }
-            }
-        }
-    }
-
-    for (f = fds; f < &fds[nfds]; ++f) {
-        f->revents = 0;
-    }
-
-    if (timeout == -1) {
-        timeout = INFINITE;
-    }
-
-    /* Polling for several things? */
-    if (nhandles > 1 || (nhandles > 0 && poll_msgs)) {
-        /* First check if one or several of them are immediately
-         * available
-         */
-        retval = poll_rest(poll_msgs, handles, nhandles, fds, nfds, 0);
-
-        /* If not, and we have a significant timeout, poll again with
-         * timeout then. Note that this will return indication for only
-         * one event, or only for messages. We ignore timeouts less than
-         * ten milliseconds as they are mostly pointless on Windows, the
-         * MsgWaitForMultipleObjectsEx() call will timeout right away
-         * anyway.
-         *
-         * Modification for QEMU: replaced timeout >= 10 by timeout > 0.
-         */
-        if (retval == 0 && (timeout == INFINITE || timeout > 0)) {
-            retval = poll_rest(poll_msgs, handles, nhandles,
-                               fds, nfds, timeout);
-        }
-    } else {
-        /* Just polling for one thing, so no need to check first if
-         * available immediately
-         */
-        retval = poll_rest(poll_msgs, handles, nhandles, fds, nfds, timeout);
-    }
-
-    if (retval == -1) {
-        for (f = fds; f < &fds[nfds]; ++f) {
-            f->revents = 0;
-        }
-    }
-
-    return retval;
-}
-#endif
-
 int getpagesize(void)
 {
     SYSTEM_INFO system_info;
-- 
2.31.1

[PATCH 11/12] configure: bump min required GCC to 6.3.0

[Daniel P. Berrangé]

Several distros have been dropped since the last time we bumped the
minimum required GCC version.

Per repology, currently shipping versions are:

             RHEL-8: 8.3.1
     Debian Stretch: 6.3.0
      Debian Buster: 8.3.0
 openSUSE Leap 15.2: 7.5.0
   Ubuntu LTS 18.04: 7.5.0
   Ubuntu LTS 20.04: 9.3.0
            FreeBSD: 10.3.0
          Fedora 33: 9.2.0
          Fedora 34: 11.0.1
            OpenBSD: 8.4.0
     macOS HomeBrew: 11.1.0

With this list Debian Stretch is the constraint at 6.3.0

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 configure | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index a1a40577c9..43d2470bb6 100755
--- a/configure
+++ b/configure
@@ -2059,8 +2059,8 @@ cat > $TMPC << EOF
 #  endif
 # endif
 #elif defined(__GNUC__) && defined(__GNUC_MINOR__)
-# if __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 8)
-#  error You need at least GCC v4.8 to compile QEMU
+# if __GNUC__ < 6 || (__GNUC__ == 6 && __GNUC_MINOR__ < 3)
+#  error You need at least GCC v6.3.0 to compile QEMU
 # endif
 #else
 # error You either need GCC or Clang to compiler QEMU
@@ -2068,7 +2068,7 @@ cat > $TMPC << EOF
 int main (void) { return 0; }
 EOF
 if ! compile_prog "" "" ; then
-    error_exit "You need at least GCC v4.8 or Clang v3.4 (or XCode Clang v5.1)"
+    error_exit "You need at least GCC v6.3 or Clang v3.4 (or XCode Clang v5.1)"
 fi
 
 # Accumulate -Wfoo and -Wno-bar separately.
-- 
2.31.1

[PATCH 12/12] configure: bump min required CLang to 7.0.0 / XCode 10.2

[Daniel P. Berrangé]

Several distros have been dropped since the last time we bumped the
minimum required CLang version.

Per repology, currently shipping versions are:

             RHEL-8: 10.0.1
     Debian Stretch: 7.0.1
      Debian Buster: 7.0.1
 openSUSE Leap 15.2: 9.0.1
   Ubuntu LTS 18.04: 10.0.0
   Ubuntu LTS 20.04: 11.0.0
         FreeBSD 12: 8.0.1
          Fedora 33: 11.0.0
          Fedora 34: 11.1.0

With this list Debian Stretch is the constraint at 7.0.1

An LLVM version of 7.0.1 corresponds to macOS XCode version of 10.2
which dates from March 2019.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 configure | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index 43d2470bb6..c41a3e5eef 100755
--- a/configure
+++ b/configure
@@ -2050,12 +2050,12 @@ fi
 cat > $TMPC << EOF
 #if defined(__clang_major__) && defined(__clang_minor__)
 # ifdef __apple_build_version__
-#  if __clang_major__ < 5 || (__clang_major__ == 5 && __clang_minor__ < 1)
-#   error You need at least XCode Clang v5.1 to compile QEMU
+#  if __clang_major__ < 10 || (__clang_major__ == 10 && __clang_minor__ < 2)
+#   error You need at least XCode Clang v10.2 to compile QEMU
 #  endif
 # else
-#  if __clang_major__ < 3 || (__clang_major__ == 3 && __clang_minor__ < 4)
-#   error You need at least Clang v3.4 to compile QEMU
+#  if __clang_major__ < 7 || (__clang_major__ == 7 && __clang_minor__ < 0)
+#   error You need at least Clang v7.0 to compile QEMU
 #  endif
 # endif
 #elif defined(__GNUC__) && defined(__GNUC_MINOR__)
@@ -2068,7 +2068,7 @@ cat > $TMPC << EOF
 int main (void) { return 0; }
 EOF
 if ! compile_prog "" "" ; then
-    error_exit "You need at least GCC v6.3 or Clang v3.4 (or XCode Clang v5.1)"
+    error_exit "You need at least GCC v6.3 or Clang v7.0 (or XCode Clang v10.2)"
 fi
 
 # Accumulate -Wfoo and -Wno-bar separately.
-- 
2.31.1

Re: [PATCH 01/12] gitlab: move linux user build job from CentOS 7 to CentOS 8

[Thomas Huth]

On 11/05/2021 15.26, Daniel P. Berrangé wrote:
> It has been over two years since RHEL-8 was released, and thus per the
> platform build policy, we no longer need to support RHEL-7 as a build
> target.
> 
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>   .gitlab-ci.yml                          | 6 +++---
>   tests/docker/dockerfiles/centos8.docker | 1 +
>   2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index dcb6317aac..23917d6d73 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -441,12 +441,12 @@ build-user-plugins:
>       MAKE_CHECK_ARGS: check-tcg
>     timeout: 1h 30m
>   
> -build-user-centos7:
> +build-user-centos8:
>     <<: *native_build_job_definition
>     needs:
> -    job: amd64-centos7-container
> +    job: amd64-centos8-container
>     variables:
> -    IMAGE: centos7
> +    IMAGE: centos8

We urgently should decrease our huge amount of jobs ... What about removing 
this job completely? We already have the "build-user" job that tests the 
compilation on Debian, which is likely at a similar library level as 
centos8, so I doubt that we get much additional test coverage from this job 
here when it's running on Centos 8.

  Thomas

Re: [PATCH 02/12] patchew: move quick build job from CentOS 7 to CentOS 8 container

[Thomas Huth]

On 11/05/2021 15.26, Daniel P. Berrangé wrote:
> It has been over two years since RHEL-8 was released, and thus per the
> platform build policy, we no longer need to support RHEL-7 as a build
> target.
> 
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>   .patchew.yml | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/.patchew.yml b/.patchew.yml
> index 988c29261f..2638b7f564 100644
> --- a/.patchew.yml
> +++ b/.patchew.yml
> @@ -88,7 +88,7 @@ email:
>           more information:
>   
>           {{ logtext }}
> -        {% elif test == "docker-mingw@fedora" or test == "docker-quick@centos7" or test == "asan" %}
> +        {% elif test == "docker-mingw@fedora" or test == "docker-quick@centos8" or test == "asan" %}
>           Hi,
>   
>           This series failed the {{ test }} build test. Please find the testing commands and
> @@ -124,13 +124,13 @@ testing:
>         script: |
>           #!/bin/bash
>           time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1
> -    docker-quick@centos7:
> +    docker-quick@centos8:
>         enabled: false
>         requirements: docker,x86_64
>         timeout: 3600
>         script: |
>           #!/bin/bash
> -        time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
> +        time make docker-test-quick@centos8 SHOW_ENV=1 J=14 NETWORK=1

I think this should preferably go through Paolo's tree (now on CC:) ... and 
by the way, we should maybe add an entry to MAINTAINERS for this file, too...

  Thomas

Re: [PATCH 03/12] crypto: bump min nettle to 3.3, dropping RHEL-7 support

[Thomas Huth]

On 11/05/2021 15.26, Daniel P. Berrangé wrote:
> It has been over two years since RHEL-8 was released, and thus per the
> platform build policy, we no longer need to support RHEL-7 as a build
> target. This lets us increment the minimum required nettle version and
> drop a lot of backwards compatibility code for 2.x series of nettle.
> 
> Per repology, current shipping versions are:
> 
>               RHEL-8: 3.4.1
>       Debian Stretch: 3.3
>        Debian Buster: 3.4.1
>   openSUSE Leap 15.2: 3.4.1
>     Ubuntu LTS 18.04: 3.4
>     Ubuntu LTS 20.04: 3.5.1
>              FreeBSD: 3.7.2
>            Fedora 33: 3.5.1
>            Fedora 34: 3.7.2
>              OpenBSD: 3.7.2
>       macOS HomeBrew: 3.7.2
> 
> Debian Stretch has the oldest version and so 3.3 is the new minimum.
> 
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Reviewed-by: Thomas Huth <thuth@redhat.com>

Re: [PATCH 04/12] crypto: drop back compatibility typedefs for nettle

[Thomas Huth]

On 11/05/2021 15.26, Daniel P. Berrangé wrote:
> Now that we only support modern nettle, we don't need to have local
> typedefs to mask the real nettle types.
> 
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>   crypto/cipher-nettle.c.inc | 60 ++++++++++++++++----------------------
>   crypto/hash-nettle.c       |  6 ++--
>   crypto/hmac-nettle.c       |  8 ++---
>   3 files changed, 30 insertions(+), 44 deletions(-)

Reviewed-by: Thomas Huth <thuth@redhat.com>

Re: [PATCH 01/12] gitlab: move linux user build job from CentOS 7 to CentOS 8

[Daniel P. Berrangé]

On Tue, May 11, 2021 at 03:54:26PM +0200, Thomas Huth wrote:
> On 11/05/2021 15.26, Daniel P. Berrangé wrote:
> > It has been over two years since RHEL-8 was released, and thus per the
> > platform build policy, we no longer need to support RHEL-7 as a build
> > target.
> > 
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > ---
> >   .gitlab-ci.yml                          | 6 +++---
> >   tests/docker/dockerfiles/centos8.docker | 1 +
> >   2 files changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > index dcb6317aac..23917d6d73 100644
> > --- a/.gitlab-ci.yml
> > +++ b/.gitlab-ci.yml
> > @@ -441,12 +441,12 @@ build-user-plugins:
> >       MAKE_CHECK_ARGS: check-tcg
> >     timeout: 1h 30m
> > -build-user-centos7:
> > +build-user-centos8:
> >     <<: *native_build_job_definition
> >     needs:
> > -    job: amd64-centos7-container
> > +    job: amd64-centos8-container
> >     variables:
> > -    IMAGE: centos7
> > +    IMAGE: centos8
> 
> We urgently should decrease our huge amount of jobs ... What about removing
> this job completely? We already have the "build-user" job that tests the
> compilation on Debian, which is likely at a similar library level as
> centos8, so I doubt that we get much additional test coverage from this job
> here when it's running on Centos 8.

This job was added by Philippe just a couple of months ago


commit 4e41d4a34e4d9f11a99a03c2279f84e98df21984
Author: Philippe Mathieu-Daudé <f4bug@amsat.org>
Date:   Thu Jan 21 18:28:29 2021 +0100

    gitlab-ci: Test building linux-user targets on CentOS 7
    
    Add a configuration tested by Peter Maydell (see [1] and [2])
    but not covered in our CI [3]:
    
      [705/2910] Compiling C object libqemu-arm-linux-user.fa.p/linux-user_strace.c.o
      FAILED: libqemu-arm-linux-user.fa.p/linux-user_strace.c.o
      ../linux-user/strace.c: In function 'do_print_sockopt':
      ../linux-user/strace.c:2831:14: error: 'IPV6_ADDR_PREFERENCES' undeclared (first use in this function)
               case IPV6_ADDR_PREFERENCES:
                    ^
    
    This job currently takes 31 minutes 32 seconds ([4]).
    
    [1] https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg05086.html
    [2] https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg05379.html
    [3] https://gitlab.com/philmd/qemu/-/jobs/977408284
    [4] https://gitlab.com/philmd/qemu/-/jobs/978223286
    
    Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
    Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
    Reviewed-by: Thomas Huth <thuth@redhat.com>
    Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
    Message-Id: <20210121172829.1643620-3-f4bug@amsat.org>
    Signed-off-by: Thomas Huth <thuth@redhat.com>


I looked at the quoted thread, but I can't tell what the actual missing
scenario was that motivated this. The threads don't appear to specifically
mention CentOS 7, but if the issue was indeed specific to CentOS 7 we can
certainly drop the job. If it was some other scenario, I defer the
answer to someone who knows....

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH 05/12] crypto: bump min gcrypt to 1.7.6, dropping RHEL-7 support

[Thomas Huth]

On 11/05/2021 15.26, Daniel P. Berrangé wrote:
> It has been over two years since RHEL-8 was released, and thus per the
> platform build policy, we no longer need to support RHEL-7 as a build
> target. This lets us increment the minimum required gcrypt version and
> assume that HMAC is always supported
> 
> Per repology, current shipping versions are:
> 
>               RHEL-8: 1.8.5
>       Debian Stretch: 1.7.6
>        Debian Buster: 1.8.4
>   openSUSE Leap 15.2: 1.8.2
>     Ubuntu LTS 18.04: 1.8.1
>     Ubuntu LTS 20.04: 1.8.5
>              FreeBSD: 1.9.2
>            Fedora 33: 1.8.6
>            Fedora 34: 1.9.3
>              OpenBSD: 1.9.3
>       macOS HomeBrew: 1.9.3
> 
> Debian Stretch has the oldest version and so 1.7.6 is the new minimum.
> 
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Reviewed-by: Thomas Huth <thuth@redhat.com>

Re: [PATCH 06/12] crypto: bump min gnutls to 3.5.8, dropping RHEL-7 support

[Thomas Huth]

On 11/05/2021 15.26, Daniel P. Berrangé wrote:
> It has been over two years since RHEL-8 was released, and thus per the
> platform build policy, we no longer need to support RHEL-7 as a build
> target. This lets us increment the minimum required gnutls version
> 
> Per repology, current shipping versions are:
> 
>               RHEL-8: 3.6.14
>       Debian Stretch: 3.5.8
>        Debian Buster: 3.6.7
>   openSUSE Leap 15.2: 3.6.7
>     Ubuntu LTS 18.04: 3.5.18
>     Ubuntu LTS 20.04: 3.6.13
>              FreeBSD: 3.6.15
>            Fedora 33: 3.6.16
>            Fedora 34: 3.7.1
>              OpenBSD: 3.6.15
>       macOS HomeBrew: 3.6.15
> 
> Debian Stretch has the oldest version and so 1.7.6 is the new minimum.
> 
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>   .gitlab-ci.yml | 15 ---------------
>   configure      |  2 +-
>   2 files changed, 1 insertion(+), 16 deletions(-)

Reviewed-by: Thomas Huth <thuth@redhat.com>

Re: [PATCH 09/12] tests/docker: drop CentOS 7 container

[Thomas Huth]

On 11/05/2021 15.26, Daniel P. Berrangé wrote:
> It has been over two years since RHEL-8 was released, and thus per the
> platform build policy, we no longer need to support RHEL-7 as a build
> target.
> 
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>   .gitlab-ci.d/containers.yml             |  5 ---
>   tests/docker/dockerfiles/centos7.docker | 43 -------------------------
>   2 files changed, 48 deletions(-)
>   delete mode 100644 tests/docker/dockerfiles/centos7.docker

Reviewed-by: Thomas Huth <thuth@redhat.com>

Re: [PATCH 10/12] bump min required glib version to 2.50

[Thomas Huth]

On 11/05/2021 15.26, Daniel P. Berrangé wrote:
> The glib version was not previously constrained by RHEL-7 since it
> rebases fairly often. Instead SLES 12 and Ubuntu 16.04 were the
> constraints in 00f2cfbbec63fb6f5a7789797a62ccedd22466ea. Both of
> these are old enough that they are outside our platform support
> matrix now.
> 
> Per repology, current shipping versions are:
> 
>               RHEL-8: 2.56.4
>       Debian Stretch: 2.50.3
>        Debian Buster: 2.58.3
>   openSUSE Leap 15.2: 2.62.6
>     Ubuntu LTS 18.04: 2.56.4
>     Ubuntu LTS 20.04: 2.64.6
>              FreeBSD: 2.66.7
>            Fedora 33: 2.66.8
>            Fedora 34: 2.68.1
>              OpenBSD: 2.68.1
>       macOS HomeBrew: 2.68.1
> 
> Thus Debian Stretch is the constraint for GLib version now.
> 
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>   configure             |   2 +-
>   include/glib-compat.h |   9 --
>   util/oslib-win32.c    | 204 ------------------------------------------
>   3 files changed, 1 insertion(+), 214 deletions(-)

Reviewed-by: Thomas Huth <thuth@redhat.com>

Re: [PATCH 11/12] configure: bump min required GCC to 6.3.0

[Thomas Huth]

On 11/05/2021 15.26, Daniel P. Berrangé wrote:
> Several distros have been dropped since the last time we bumped the
> minimum required GCC version.
> 
> Per repology, currently shipping versions are:
> 
>               RHEL-8: 8.3.1
>       Debian Stretch: 6.3.0
>        Debian Buster: 8.3.0
>   openSUSE Leap 15.2: 7.5.0
>     Ubuntu LTS 18.04: 7.5.0
>     Ubuntu LTS 20.04: 9.3.0
>              FreeBSD: 10.3.0
>            Fedora 33: 9.2.0
>            Fedora 34: 11.0.1
>              OpenBSD: 8.4.0
>       macOS HomeBrew: 11.1.0
> 
> With this list Debian Stretch is the constraint at 6.3.0
> 
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>   configure | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/configure b/configure
> index a1a40577c9..43d2470bb6 100755
> --- a/configure
> +++ b/configure
> @@ -2059,8 +2059,8 @@ cat > $TMPC << EOF
>   #  endif
>   # endif
>   #elif defined(__GNUC__) && defined(__GNUC_MINOR__)
> -# if __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 8)
> -#  error You need at least GCC v4.8 to compile QEMU
> +# if __GNUC__ < 6 || (__GNUC__ == 6 && __GNUC_MINOR__ < 3)
> +#  error You need at least GCC v6.3.0 to compile QEMU
>   # endif
>   #else
>   # error You either need GCC or Clang to compiler QEMU
> @@ -2068,7 +2068,7 @@ cat > $TMPC << EOF
>   int main (void) { return 0; }
>   EOF
>   if ! compile_prog "" "" ; then
> -    error_exit "You need at least GCC v4.8 or Clang v3.4 (or XCode Clang v5.1)"
> +    error_exit "You need at least GCC v6.3 or Clang v3.4 (or XCode Clang v5.1)"
>   fi
>   
>   # Accumulate -Wfoo and -Wno-bar separately.

I'm surprised that we could not remove some spots related to GCC 4.8 
compatibility here, but if I grep'ed it right, there are indeed none ... thus:

Reviewed-by: Thomas Huth <thuth@redhat.com>

Re: [PATCH 12/12] configure: bump min required CLang to 7.0.0 / XCode 10.2

[Thomas Huth]

On 11/05/2021 15.26, Daniel P. Berrangé wrote:
> Several distros have been dropped since the last time we bumped the
> minimum required CLang version.
[...]
> -#  if __clang_major__ < 3 || (__clang_major__ == 3 && __clang_minor__ < 4)
> -#   error You need at least Clang v3.4 to compile QEMU
> +#  if __clang_major__ < 7 || (__clang_major__ == 7 && __clang_minor__ < 0)

__clang_minor__ < 0 is very unlikely ... I think you could drop the part 
after the "||".

Anyway:
Reviewed-by: Thomas Huth <thuth@redhat.com>

Re: [PATCH 09/12] tests/docker: drop CentOS 7 container

[Alex Bennée]

Daniel P. Berrangé <berrange@redhat.com> writes:

> It has been over two years since RHEL-8 was released, and thus per the
> platform build policy, we no longer need to support RHEL-7 as a build
> target.
>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Acked-by: Alex Bennée <alex.bennee@linaro.org>

-- 
Alex Bennée

Re: [PATCH 11/12] configure: bump min required GCC to 6.3.0

[Daniel P. Berrangé]

On Tue, May 11, 2021 at 04:15:57PM +0200, Thomas Huth wrote:
> On 11/05/2021 15.26, Daniel P. Berrangé wrote:
> > Several distros have been dropped since the last time we bumped the
> > minimum required GCC version.
> > 
> > Per repology, currently shipping versions are:
> > 
> >               RHEL-8: 8.3.1
> >       Debian Stretch: 6.3.0
> >        Debian Buster: 8.3.0
> >   openSUSE Leap 15.2: 7.5.0
> >     Ubuntu LTS 18.04: 7.5.0
> >     Ubuntu LTS 20.04: 9.3.0
> >              FreeBSD: 10.3.0
> >            Fedora 33: 9.2.0
> >            Fedora 34: 11.0.1
> >              OpenBSD: 8.4.0
> >       macOS HomeBrew: 11.1.0
> > 
> > With this list Debian Stretch is the constraint at 6.3.0
> > 
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > ---
> >   configure | 6 +++---
> >   1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/configure b/configure
> > index a1a40577c9..43d2470bb6 100755
> > --- a/configure
> > +++ b/configure
> > @@ -2059,8 +2059,8 @@ cat > $TMPC << EOF
> >   #  endif
> >   # endif
> >   #elif defined(__GNUC__) && defined(__GNUC_MINOR__)
> > -# if __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 8)
> > -#  error You need at least GCC v4.8 to compile QEMU
> > +# if __GNUC__ < 6 || (__GNUC__ == 6 && __GNUC_MINOR__ < 3)
> > +#  error You need at least GCC v6.3.0 to compile QEMU
> >   # endif
> >   #else
> >   # error You either need GCC or Clang to compiler QEMU
> > @@ -2068,7 +2068,7 @@ cat > $TMPC << EOF
> >   int main (void) { return 0; }
> >   EOF
> >   if ! compile_prog "" "" ; then
> > -    error_exit "You need at least GCC v4.8 or Clang v3.4 (or XCode Clang v5.1)"
> > +    error_exit "You need at least GCC v6.3 or Clang v3.4 (or XCode Clang v5.1)"
> >   fi
> >   # Accumulate -Wfoo and -Wno-bar separately.
> 
> I'm surprised that we could not remove some spots related to GCC 4.8
> compatibility here, but if I grep'ed it right, there are indeed none ...

Yeah I was surprised too. I think what's happened is that we've ended
up changing the code to avoid hitting problems from older GCC, rather
than conditionally using them. If you read git history you can find
examples of changes talking about old GCC problems being avoided.

The same for Clang.

So these change mostly free us from having to make sub-optimal in the
future.

The most immediate change we could potentially do is s/gnu99/gnu11/
for the C standard.

> thus:
> 
> Reviewed-by: Thomas Huth <thuth@redhat.com>
> 

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH 12/12] configure: bump min required CLang to 7.0.0 / XCode 10.2

[Daniel P. Berrangé]

On Tue, May 11, 2021 at 04:18:54PM +0200, Thomas Huth wrote:
> On 11/05/2021 15.26, Daniel P. Berrangé wrote:
> > Several distros have been dropped since the last time we bumped the
> > minimum required CLang version.
> [...]
> > -#  if __clang_major__ < 3 || (__clang_major__ == 3 && __clang_minor__ < 4)
> > -#   error You need at least Clang v3.4 to compile QEMU
> > +#  if __clang_major__ < 7 || (__clang_major__ == 7 && __clang_minor__ < 0)
> 
> __clang_minor__ < 0 is very unlikely ... I think you could drop the part
> after the "||".

True, though it might be desirable to keep it as a placeholder for when
we next bump the min version and have a non-zero minor digit.

> 
> Anyway:
> Reviewed-by: Thomas Huth <thuth@redhat.com>
> 

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH 00/12] Wave goodbye to RHEL 7 vintage distros

[Thomas Huth]

On 11/05/2021 15.26, Daniel P. Berrangé wrote:
> The main motivation for this series is to eliminate some backcompat
> logic in the crypto code only needed for RHEL-7. I take the opportunity
> to also bump the min required versions of glib, gcc and clang since we
> have dropped many distros since they were last bumped.
> 
> There are possibly some more cleanups that can be done as a side effect
> of these new min versions, but I leave that for other interested people
> to look at.
> 
> One that might be intesting is switching from std=gnu99 to gnu11 since
> we're no longer constrainted by the 4.8.x vintage GCC which marked gnu11
> as experimental (see 7be41675f7cb16be7c8d2554add7a63fa43781a8)

If you've got some spare minutes, could you please add a patch to bump the 
minimum version of libssh to 0.8.1 at least? ... since Ubuntu 18.04 ships 
with this utterly broken libssh 0.8.0 that is a Frankenstein-monster 0.7 
under the hood which we do not support in QEMU ...

  Thomas

Re: [PATCH 08/12] tests/vm: convert centos VM recipe to CentOS 8

[Daniel P. Berrangé]

On Tue, May 11, 2021 at 02:26:37PM +0100, Daniel P. Berrangé wrote:
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>  tests/vm/centos | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/vm/centos b/tests/vm/centos
> index efe3dbbb36..215da14c23 100755
> --- a/tests/vm/centos
> +++ b/tests/vm/centos
> @@ -26,13 +26,13 @@ class CentosVM(basevm.BaseVM):
>          export SRC_ARCHIVE=/dev/vdb;
>          sudo chmod a+r $SRC_ARCHIVE;
>          tar -xf $SRC_ARCHIVE;
> -        make docker-test-block@centos7 {verbose} J={jobs} NETWORK=1;
> -        make docker-test-quick@centos7 {verbose} J={jobs} NETWORK=1;
> +        make docker-test-block@centos8 {verbose} J={jobs} NETWORK=1;
> +        make docker-test-quick@centos8 {verbose} J={jobs} NETWORK=1;
>          make docker-test-mingw@fedora  {verbose} J={jobs} NETWORK=1;
>      """
>  
>      def build_image(self, img):
> -        cimg = self._download_with_cache("https://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud-1802.qcow2.xz")
> +        cimg = self._download_with_cache("https://cloud.centos.org/centos/8/x86_64/images/CentOS-8-GenericCloud-8.1.1911-20200113.3.x86_64.qcow2")
>          img_tmp = img + ".tmp"
>          sys.stderr.write("Extracting the image...\n")
>          subprocess.check_call(["ln", "-f", cimg, img_tmp + ".xz"])

This patch is broken in many ways, and I forgot to test it :-(


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH 09/12] tests/docker: drop CentOS 7 container

[Willian Rampazzo]

On Tue, May 11, 2021 at 10:28 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> It has been over two years since RHEL-8 was released, and thus per the
> platform build policy, we no longer need to support RHEL-7 as a build
> target.
>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>  .gitlab-ci.d/containers.yml             |  5 ---
>  tests/docker/dockerfiles/centos7.docker | 43 -------------------------
>  2 files changed, 48 deletions(-)
>  delete mode 100644 tests/docker/dockerfiles/centos7.docker
>

Reviewed-by: Willian Rampazzo <willianr@redhat.com>

Re: [PATCH 03/12] crypto: bump min nettle to 3.3, dropping RHEL-7 support

[Willian Rampazzo]

On Tue, May 11, 2021 at 10:28 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> It has been over two years since RHEL-8 was released, and thus per the
> platform build policy, we no longer need to support RHEL-7 as a build
> target. This lets us increment the minimum required nettle version and
> drop a lot of backwards compatibility code for 2.x series of nettle.
>
> Per repology, current shipping versions are:
>
>              RHEL-8: 3.4.1
>      Debian Stretch: 3.3
>       Debian Buster: 3.4.1
>  openSUSE Leap 15.2: 3.4.1
>    Ubuntu LTS 18.04: 3.4
>    Ubuntu LTS 20.04: 3.5.1
>             FreeBSD: 3.7.2
>           Fedora 33: 3.5.1
>           Fedora 34: 3.7.2
>             OpenBSD: 3.7.2
>      macOS HomeBrew: 3.7.2
>
> Debian Stretch has the oldest version and so 3.3 is the new minimum.
>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>  .gitlab-ci.yml             | 10 ----------
>  configure                  |  4 +---
>  crypto/cipher-nettle.c.inc | 31 -------------------------------
>  crypto/hash-nettle.c       |  4 ----
>  crypto/hmac-nettle.c       |  4 ----
>  5 files changed, 1 insertion(+), 52 deletions(-)
>

Reviewed-by: Willian Rampazzo <willianr@redhat.com>

Re: [PATCH 05/12] crypto: bump min gcrypt to 1.7.6, dropping RHEL-7 support

[Willian Rampazzo]

On Tue, May 11, 2021 at 10:28 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> It has been over two years since RHEL-8 was released, and thus per the
> platform build policy, we no longer need to support RHEL-7 as a build
> target. This lets us increment the minimum required gcrypt version and
> assume that HMAC is always supported
>
> Per repology, current shipping versions are:
>
>              RHEL-8: 1.8.5
>      Debian Stretch: 1.7.6
>       Debian Buster: 1.8.4
>  openSUSE Leap 15.2: 1.8.2
>    Ubuntu LTS 18.04: 1.8.1
>    Ubuntu LTS 20.04: 1.8.5
>             FreeBSD: 1.9.2
>           Fedora 33: 1.8.6
>           Fedora 34: 1.9.3
>             OpenBSD: 1.9.3
>      macOS HomeBrew: 1.9.3
>
> Debian Stretch has the oldest version and so 1.7.6 is the new minimum.
>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>  .gitlab-ci.yml     | 10 ----------
>  configure          | 18 +-----------------
>  crypto/meson.build |  6 +-----
>  3 files changed, 2 insertions(+), 32 deletions(-)
>

Reviewed-by: Willian Rampazzo <willianr@redhat.com>

Re: [PATCH 06/12] crypto: bump min gnutls to 3.5.8, dropping RHEL-7 support

[Willian Rampazzo]

On Tue, May 11, 2021 at 10:28 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> It has been over two years since RHEL-8 was released, and thus per the
> platform build policy, we no longer need to support RHEL-7 as a build
> target. This lets us increment the minimum required gnutls version
>
> Per repology, current shipping versions are:
>
>              RHEL-8: 3.6.14
>      Debian Stretch: 3.5.8
>       Debian Buster: 3.6.7
>  openSUSE Leap 15.2: 3.6.7
>    Ubuntu LTS 18.04: 3.5.18
>    Ubuntu LTS 20.04: 3.6.13
>             FreeBSD: 3.6.15
>           Fedora 33: 3.6.16
>           Fedora 34: 3.7.1
>             OpenBSD: 3.6.15
>      macOS HomeBrew: 3.6.15
>
> Debian Stretch has the oldest version and so 1.7.6 is the new minimum.
>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>  .gitlab-ci.yml | 15 ---------------
>  configure      |  2 +-
>  2 files changed, 1 insertion(+), 16 deletions(-)
>

Reviewed-by: Willian Rampazzo <willianr@redhat.com>

Re: [PATCH 07/12] crypto: drop used conditional check

[Willian Rampazzo]

On Tue, May 11, 2021 at 10:28 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> The condition being tested has never been set since the day the code was
> first introduced.
>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>  crypto/tlscredsx509.c | 2 --
>  1 file changed, 2 deletions(-)
>

Reviewed-by: Willian Rampazzo <willianr@redhat.com>

Re: [PATCH 10/12] bump min required glib version to 2.50

[Willian Rampazzo]

On Tue, May 11, 2021 at 10:28 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> The glib version was not previously constrained by RHEL-7 since it
> rebases fairly often. Instead SLES 12 and Ubuntu 16.04 were the
> constraints in 00f2cfbbec63fb6f5a7789797a62ccedd22466ea. Both of
> these are old enough that they are outside our platform support
> matrix now.
>
> Per repology, current shipping versions are:
>
>              RHEL-8: 2.56.4
>      Debian Stretch: 2.50.3
>       Debian Buster: 2.58.3
>  openSUSE Leap 15.2: 2.62.6
>    Ubuntu LTS 18.04: 2.56.4
>    Ubuntu LTS 20.04: 2.64.6
>             FreeBSD: 2.66.7
>           Fedora 33: 2.66.8
>           Fedora 34: 2.68.1
>             OpenBSD: 2.68.1
>      macOS HomeBrew: 2.68.1
>
> Thus Debian Stretch is the constraint for GLib version now.
>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>  configure             |   2 +-
>  include/glib-compat.h |   9 --
>  util/oslib-win32.c    | 204 ------------------------------------------
>  3 files changed, 1 insertion(+), 214 deletions(-)
>

Reviewed-by: Willian Rampazzo <willianr@redhat.com>

Re: [PATCH 11/12] configure: bump min required GCC to 6.3.0

[Willian Rampazzo]

On Tue, May 11, 2021 at 10:28 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> Several distros have been dropped since the last time we bumped the
> minimum required GCC version.
>
> Per repology, currently shipping versions are:
>
>              RHEL-8: 8.3.1
>      Debian Stretch: 6.3.0
>       Debian Buster: 8.3.0
>  openSUSE Leap 15.2: 7.5.0
>    Ubuntu LTS 18.04: 7.5.0
>    Ubuntu LTS 20.04: 9.3.0
>             FreeBSD: 10.3.0
>           Fedora 33: 9.2.0
>           Fedora 34: 11.0.1
>             OpenBSD: 8.4.0
>      macOS HomeBrew: 11.1.0
>
> With this list Debian Stretch is the constraint at 6.3.0
>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>  configure | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>

Reviewed-by: Willian Rampazzo <willianr@redhat.com>

Re: [PATCH 12/12] configure: bump min required CLang to 7.0.0 / XCode 10.2

[Willian Rampazzo]

On Tue, May 11, 2021 at 10:28 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> Several distros have been dropped since the last time we bumped the
> minimum required CLang version.
>
> Per repology, currently shipping versions are:
>
>              RHEL-8: 10.0.1
>      Debian Stretch: 7.0.1
>       Debian Buster: 7.0.1
>  openSUSE Leap 15.2: 9.0.1
>    Ubuntu LTS 18.04: 10.0.0
>    Ubuntu LTS 20.04: 11.0.0
>          FreeBSD 12: 8.0.1
>           Fedora 33: 11.0.0
>           Fedora 34: 11.1.0
>
> With this list Debian Stretch is the constraint at 7.0.1
>
> An LLVM version of 7.0.1 corresponds to macOS XCode version of 10.2
> which dates from March 2019.
>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>  configure | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
>

Reviewed-by: Willian Rampazzo <willianr@redhat.com>

Re: [PATCH 06/12] crypto: bump min gnutls to 3.5.8, dropping RHEL-7 support

[Richard Henderson]

On 5/11/21 8:26 AM, Daniel P. Berrangé wrote:
> Per repology, current shipping versions are:
> 
>               RHEL-8: 3.6.14
>       Debian Stretch: 3.5.8
>        Debian Buster: 3.6.7
>   openSUSE Leap 15.2: 3.6.7
>     Ubuntu LTS 18.04: 3.5.18
>     Ubuntu LTS 20.04: 3.6.13
>              FreeBSD: 3.6.15
>            Fedora 33: 3.6.16
>            Fedora 34: 3.7.1
>              OpenBSD: 3.6.15
>       macOS HomeBrew: 3.6.15
> 
> Debian Stretch has the oldest version and so 1.7.6 is the new minimum.

Cut and paste error from nettle.

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH 03/12] crypto: bump min nettle to 3.3, dropping RHEL-7 support

[Richard Henderson]

On 5/11/21 8:26 AM, Daniel P. Berrangé wrote:
> It has been over two years since RHEL-8 was released, and thus per the
> platform build policy, we no longer need to support RHEL-7 as a build
> target. This lets us increment the minimum required nettle version and
> drop a lot of backwards compatibility code for 2.x series of nettle.
> 
> Per repology, current shipping versions are:
> 
>               RHEL-8: 3.4.1
>       Debian Stretch: 3.3
>        Debian Buster: 3.4.1
>   openSUSE Leap 15.2: 3.4.1
>     Ubuntu LTS 18.04: 3.4
>     Ubuntu LTS 20.04: 3.5.1
>              FreeBSD: 3.7.2
>            Fedora 33: 3.5.1
>            Fedora 34: 3.7.2
>              OpenBSD: 3.7.2
>       macOS HomeBrew: 3.7.2
> 
> Debian Stretch has the oldest version and so 3.3 is the new minimum.
> 
> Signed-off-by: Daniel P. Berrangé<berrange@redhat.com>
> ---

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH 04/12] crypto: drop back compatibility typedefs for nettle

[Richard Henderson]

On 5/11/21 8:26 AM, Daniel P. Berrangé wrote:
> Now that we only support modern nettle, we don't need to have local
> typedefs to mask the real nettle types.
> 
> Signed-off-by: Daniel P. Berrangé<berrange@redhat.com>
> ---
>   crypto/cipher-nettle.c.inc | 60 ++++++++++++++++----------------------
>   crypto/hash-nettle.c       |  6 ++--
>   crypto/hmac-nettle.c       |  8 ++---
>   3 files changed, 30 insertions(+), 44 deletions(-)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH 05/12] crypto: bump min gcrypt to 1.7.6, dropping RHEL-7 support

[Richard Henderson]

On 5/11/21 8:26 AM, Daniel P. Berrangé wrote:
> It has been over two years since RHEL-8 was released, and thus per the
> platform build policy, we no longer need to support RHEL-7 as a build
> target. This lets us increment the minimum required gcrypt version and
> assume that HMAC is always supported
> 
> Per repology, current shipping versions are:
> 
>               RHEL-8: 1.8.5
>       Debian Stretch: 1.7.6
>        Debian Buster: 1.8.4
>   openSUSE Leap 15.2: 1.8.2
>     Ubuntu LTS 18.04: 1.8.1
>     Ubuntu LTS 20.04: 1.8.5
>              FreeBSD: 1.9.2
>            Fedora 33: 1.8.6
>            Fedora 34: 1.9.3
>              OpenBSD: 1.9.3
>       macOS HomeBrew: 1.9.3
> 
> Debian Stretch has the oldest version and so 1.7.6 is the new minimum.
> 
> Signed-off-by: Daniel P. Berrangé<berrange@redhat.com>
> ---

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH 07/12] crypto: drop used conditional check

[Richard Henderson]

On 5/11/21 8:26 AM, Daniel P. Berrangé wrote:
> The condition being tested has never been set since the day the code was
> first introduced.
> 
> Signed-off-by: Daniel P. Berrangé<berrange@redhat.com>
> ---
>   crypto/tlscredsx509.c | 2 --
>   1 file changed, 2 deletions(-)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH 11/12] configure: bump min required GCC to 6.3.0

[Richard Henderson]

On 5/11/21 8:26 AM, Daniel P. Berrangé wrote:
> Several distros have been dropped since the last time we bumped the
> minimum required GCC version.
> 
> Per repology, currently shipping versions are:
> 
>               RHEL-8: 8.3.1
>       Debian Stretch: 6.3.0
>        Debian Buster: 8.3.0
>   openSUSE Leap 15.2: 7.5.0
>     Ubuntu LTS 18.04: 7.5.0
>     Ubuntu LTS 20.04: 9.3.0
>              FreeBSD: 10.3.0
>            Fedora 33: 9.2.0
>            Fedora 34: 11.0.1
>              OpenBSD: 8.4.0
>       macOS HomeBrew: 11.1.0
> 
> With this list Debian Stretch is the constraint at 6.3.0
> 
> Signed-off-by: Daniel P. Berrangé<berrange@redhat.com>
> ---
>   configure | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)

Yay!

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH 12/12] configure: bump min required CLang to 7.0.0 / XCode 10.2

[Richard Henderson]

On 5/11/21 8:26 AM, Daniel P. Berrangé wrote:
> Several distros have been dropped since the last time we bumped the
> minimum required CLang version.
> 
> Per repology, currently shipping versions are:
> 
>               RHEL-8: 10.0.1
>       Debian Stretch: 7.0.1
>        Debian Buster: 7.0.1
>   openSUSE Leap 15.2: 9.0.1
>     Ubuntu LTS 18.04: 10.0.0
>     Ubuntu LTS 20.04: 11.0.0
>           FreeBSD 12: 8.0.1
>            Fedora 33: 11.0.0
>            Fedora 34: 11.1.0
> 
> With this list Debian Stretch is the constraint at 7.0.1
> 
> An LLVM version of 7.0.1 corresponds to macOS XCode version of 10.2
> which dates from March 2019.
> 
> Signed-off-by: Daniel P. Berrangé<berrange@redhat.com>
> ---
>   configure | 10 +++++-----
>   1 file changed, 5 insertions(+), 5 deletions(-)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH 12/12] configure: bump min required CLang to 7.0.0 / XCode 10.2

[Philippe Mathieu-Daudé]

On 5/11/21 3:26 PM, Daniel P. Berrangé wrote:
> Several distros have been dropped since the last time we bumped the
> minimum required CLang version.
> 
> Per repology, currently shipping versions are:
> 
>              RHEL-8: 10.0.1
>      Debian Stretch: 7.0.1
>       Debian Buster: 7.0.1
>  openSUSE Leap 15.2: 9.0.1
>    Ubuntu LTS 18.04: 10.0.0
>    Ubuntu LTS 20.04: 11.0.0
>          FreeBSD 12: 8.0.1
>           Fedora 33: 11.0.0
>           Fedora 34: 11.1.0
> 
> With this list Debian Stretch is the constraint at 7.0.1
> 
> An LLVM version of 7.0.1 corresponds to macOS XCode version of 10.2
> which dates from March 2019.

But we still rely on Travis-CI (Ubuntu Bionic 18.04 LTS)
for non-x86 targets until we have figured out who is willing
to share/maintain such non-x86 native runners on Gitlab.

There:

$ clang --version
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)

If we don't use Travis-CI, then your patch is fine, but we
need a previous patch removing .travis.yml.

> 
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>  configure | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/configure b/configure
> index 43d2470bb6..c41a3e5eef 100755
> --- a/configure
> +++ b/configure
> @@ -2050,12 +2050,12 @@ fi
>  cat > $TMPC << EOF
>  #if defined(__clang_major__) && defined(__clang_minor__)
>  # ifdef __apple_build_version__
> -#  if __clang_major__ < 5 || (__clang_major__ == 5 && __clang_minor__ < 1)
> -#   error You need at least XCode Clang v5.1 to compile QEMU
> +#  if __clang_major__ < 10 || (__clang_major__ == 10 && __clang_minor__ < 2)
> +#   error You need at least XCode Clang v10.2 to compile QEMU
>  #  endif
>  # else
> -#  if __clang_major__ < 3 || (__clang_major__ == 3 && __clang_minor__ < 4)
> -#   error You need at least Clang v3.4 to compile QEMU
> +#  if __clang_major__ < 7 || (__clang_major__ == 7 && __clang_minor__ < 0)
> +#   error You need at least Clang v7.0 to compile QEMU
>  #  endif
>  # endif
>  #elif defined(__GNUC__) && defined(__GNUC_MINOR__)
> @@ -2068,7 +2068,7 @@ cat > $TMPC << EOF
>  int main (void) { return 0; }
>  EOF
>  if ! compile_prog "" "" ; then
> -    error_exit "You need at least GCC v6.3 or Clang v3.4 (or XCode Clang v5.1)"
> +    error_exit "You need at least GCC v6.3 or Clang v7.0 (or XCode Clang v10.2)"
>  fi
>  
>  # Accumulate -Wfoo and -Wno-bar separately.
> 

non-x86 runners in the Gitlab-CI (was: Re: [PATCH 12/12] configure: bump min required CLang to 7.0.0 / XCode 10.2)

[Thomas Huth]

On 12/05/2021 13.44, Philippe Mathieu-Daudé wrote:
> On 5/11/21 3:26 PM, Daniel P. Berrangé wrote:
>> Several distros have been dropped since the last time we bumped the
>> minimum required CLang version.
>>
>> Per repology, currently shipping versions are:
>>
>>               RHEL-8: 10.0.1
>>       Debian Stretch: 7.0.1
>>        Debian Buster: 7.0.1
>>   openSUSE Leap 15.2: 9.0.1
>>     Ubuntu LTS 18.04: 10.0.0
>>     Ubuntu LTS 20.04: 11.0.0
>>           FreeBSD 12: 8.0.1
>>            Fedora 33: 11.0.0
>>            Fedora 34: 11.1.0
>>
>> With this list Debian Stretch is the constraint at 7.0.1
>>
>> An LLVM version of 7.0.1 corresponds to macOS XCode version of 10.2
>> which dates from March 2019.
> 
> But we still rely on Travis-CI (Ubuntu Bionic 18.04 LTS)
> for non-x86 targets until we have figured out who is willing
> to share/maintain such non-x86 native runners on Gitlab.

  Hi Cleber,

by the way, what's the status of your patch series to get the dedicated CI 
machines (s390x, aarch64, ...) running in our Gitlab-CI? AFAIK the last 
iteration of your patches has been weeks ago, so I wonder whether you could 
finally send a new version with the requested fixes included? ... this topic 
slowly gets more and more urgent now that our Travis-CI is in process of 
dying...

  Thomas

Re: [PATCH 12/12] configure: bump min required CLang to 7.0.0 / XCode 10.2

[Daniel P. Berrangé]

On Wed, May 12, 2021 at 01:44:51PM +0200, Philippe Mathieu-Daudé wrote:
> On 5/11/21 3:26 PM, Daniel P. Berrangé wrote:
> > Several distros have been dropped since the last time we bumped the
> > minimum required CLang version.
> > 
> > Per repology, currently shipping versions are:
> > 
> >              RHEL-8: 10.0.1
> >      Debian Stretch: 7.0.1
> >       Debian Buster: 7.0.1
> >  openSUSE Leap 15.2: 9.0.1
> >    Ubuntu LTS 18.04: 10.0.0
> >    Ubuntu LTS 20.04: 11.0.0
> >          FreeBSD 12: 8.0.1
> >           Fedora 33: 11.0.0
> >           Fedora 34: 11.1.0
> > 
> > With this list Debian Stretch is the constraint at 7.0.1
> > 
> > An LLVM version of 7.0.1 corresponds to macOS XCode version of 10.2
> > which dates from March 2019.
> 
> But we still rely on Travis-CI (Ubuntu Bionic 18.04 LTS)
> for non-x86 targets until we have figured out who is willing
> to share/maintain such non-x86 native runners on Gitlab.
> 
> There:
> 
> $ clang --version
> clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
> 
> If we don't use Travis-CI, then your patch is fine, but we
> need a previous patch removing .travis.yml.

Bioic has clang 10 available so not sure why you're seeing
version 6 there

  https://packages.ubuntu.com/bionic/clang-10


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: non-x86 runners in the Gitlab-CI (was: Re: [PATCH 12/12] configure: bump min required CLang to 7.0.0 / XCode 10.2)

[Willian Rampazzo]

Hi Thomas,

On Wed, May 12, 2021 at 8:54 AM Thomas Huth <thuth@redhat.com> wrote:
>
> On 12/05/2021 13.44, Philippe Mathieu-Daudé wrote:
> > On 5/11/21 3:26 PM, Daniel P. Berrangé wrote:
> >> Several distros have been dropped since the last time we bumped the
> >> minimum required CLang version.
> >>
> >> Per repology, currently shipping versions are:
> >>
> >>               RHEL-8: 10.0.1
> >>       Debian Stretch: 7.0.1
> >>        Debian Buster: 7.0.1
> >>   openSUSE Leap 15.2: 9.0.1
> >>     Ubuntu LTS 18.04: 10.0.0
> >>     Ubuntu LTS 20.04: 11.0.0
> >>           FreeBSD 12: 8.0.1
> >>            Fedora 33: 11.0.0
> >>            Fedora 34: 11.1.0
> >>
> >> With this list Debian Stretch is the constraint at 7.0.1
> >>
> >> An LLVM version of 7.0.1 corresponds to macOS XCode version of 10.2
> >> which dates from March 2019.
> >
> > But we still rely on Travis-CI (Ubuntu Bionic 18.04 LTS)
> > for non-x86 targets until we have figured out who is willing
> > to share/maintain such non-x86 native runners on Gitlab.
>
>   Hi Cleber,
>
> by the way, what's the status of your patch series to get the dedicated CI
> machines (s390x, aarch64, ...) running in our Gitlab-CI? AFAIK the last
> iteration of your patches has been weeks ago, so I wonder whether you could
> finally send a new version with the requested fixes included? ... this topic
> slowly gets more and more urgent now that our Travis-CI is in process of
> dying...

I don't know if you saw this:
https://docs.travis-ci.com/user/billing-overview/#partner-queue-solution.

tl;dr, Travis now has support from partners to run non-x86 arch. It is
always good to have a plan B, like qemu own CI runners, but, at least,
with these non-x86 arch available on Travis, we will have some time to
breathe.

>
>   Thomas
>

Re: non-x86 runners in the Gitlab-CI (was: Re: [PATCH 12/12] configure: bump min required CLang to 7.0.0 / XCode 10.2)

[Thomas Huth]

On 12/05/2021 15.47, Willian Rampazzo wrote:
> Hi Thomas,
> 
> On Wed, May 12, 2021 at 8:54 AM Thomas Huth <thuth@redhat.com> wrote:
>>
>> On 12/05/2021 13.44, Philippe Mathieu-Daudé wrote:
>>> On 5/11/21 3:26 PM, Daniel P. Berrangé wrote:
>>>> Several distros have been dropped since the last time we bumped the
>>>> minimum required CLang version.
>>>>
>>>> Per repology, currently shipping versions are:
>>>>
>>>>                RHEL-8: 10.0.1
>>>>        Debian Stretch: 7.0.1
>>>>         Debian Buster: 7.0.1
>>>>    openSUSE Leap 15.2: 9.0.1
>>>>      Ubuntu LTS 18.04: 10.0.0
>>>>      Ubuntu LTS 20.04: 11.0.0
>>>>            FreeBSD 12: 8.0.1
>>>>             Fedora 33: 11.0.0
>>>>             Fedora 34: 11.1.0
>>>>
>>>> With this list Debian Stretch is the constraint at 7.0.1
>>>>
>>>> An LLVM version of 7.0.1 corresponds to macOS XCode version of 10.2
>>>> which dates from March 2019.
>>>
>>> But we still rely on Travis-CI (Ubuntu Bionic 18.04 LTS)
>>> for non-x86 targets until we have figured out who is willing
>>> to share/maintain such non-x86 native runners on Gitlab.
>>
>>    Hi Cleber,
>>
>> by the way, what's the status of your patch series to get the dedicated CI
>> machines (s390x, aarch64, ...) running in our Gitlab-CI? AFAIK the last
>> iteration of your patches has been weeks ago, so I wonder whether you could
>> finally send a new version with the requested fixes included? ... this topic
>> slowly gets more and more urgent now that our Travis-CI is in process of
>> dying...
> 
> I don't know if you saw this:
> https://docs.travis-ci.com/user/billing-overview/#partner-queue-solution.
> 
> tl;dr, Travis now has support from partners to run non-x86 arch. It is
> always good to have a plan B, like qemu own CI runners, but, at least,
> with these non-x86 arch available on Travis, we will have some time to
> breathe.

Uh, that's what we're already using in our travis.yml ... but I guess you've 
rather missed:

  https://blog.travis-ci.com/2021-05-07-orgshutdown

and on travis-ci.com, the CI minutes are not for free anymore. At least not 
for the QEMU project. Or do you know of a sponsor who is going to pay the CI 
minutes for us there?

  Thomas

Re: non-x86 runners in the Gitlab-CI (was: Re: [PATCH 12/12] configure: bump min required CLang to 7.0.0 / XCode 10.2)

[Willian Rampazzo]

On Wed, May 12, 2021 at 10:56 AM Thomas Huth <thuth@redhat.com> wrote:
>
> On 12/05/2021 15.47, Willian Rampazzo wrote:
> > Hi Thomas,
> >
> > On Wed, May 12, 2021 at 8:54 AM Thomas Huth <thuth@redhat.com> wrote:
> >>
> >> On 12/05/2021 13.44, Philippe Mathieu-Daudé wrote:
> >>> On 5/11/21 3:26 PM, Daniel P. Berrangé wrote:
> >>>> Several distros have been dropped since the last time we bumped the
> >>>> minimum required CLang version.
> >>>>
> >>>> Per repology, currently shipping versions are:
> >>>>
> >>>>                RHEL-8: 10.0.1
> >>>>        Debian Stretch: 7.0.1
> >>>>         Debian Buster: 7.0.1
> >>>>    openSUSE Leap 15.2: 9.0.1
> >>>>      Ubuntu LTS 18.04: 10.0.0
> >>>>      Ubuntu LTS 20.04: 11.0.0
> >>>>            FreeBSD 12: 8.0.1
> >>>>             Fedora 33: 11.0.0
> >>>>             Fedora 34: 11.1.0
> >>>>
> >>>> With this list Debian Stretch is the constraint at 7.0.1
> >>>>
> >>>> An LLVM version of 7.0.1 corresponds to macOS XCode version of 10.2
> >>>> which dates from March 2019.
> >>>
> >>> But we still rely on Travis-CI (Ubuntu Bionic 18.04 LTS)
> >>> for non-x86 targets until we have figured out who is willing
> >>> to share/maintain such non-x86 native runners on Gitlab.
> >>
> >>    Hi Cleber,
> >>
> >> by the way, what's the status of your patch series to get the dedicated CI
> >> machines (s390x, aarch64, ...) running in our Gitlab-CI? AFAIK the last
> >> iteration of your patches has been weeks ago, so I wonder whether you could
> >> finally send a new version with the requested fixes included? ... this topic
> >> slowly gets more and more urgent now that our Travis-CI is in process of
> >> dying...
> >
> > I don't know if you saw this:
> > https://docs.travis-ci.com/user/billing-overview/#partner-queue-solution.
> >
> > tl;dr, Travis now has support from partners to run non-x86 arch. It is
> > always good to have a plan B, like qemu own CI runners, but, at least,
> > with these non-x86 arch available on Travis, we will have some time to
> > breathe.
>
> Uh, that's what we're already using in our travis.yml ... but I guess you've
> rather missed:
>
>   https://blog.travis-ci.com/2021-05-07-orgshutdown
>
> and on travis-ci.com, the CI minutes are not for free anymore. At least not
> for the QEMU project. Or do you know of a sponsor who is going to pay the CI
> minutes for us there?
>

The link I posted tells arm and s390x will still be free for OSS projects.

From that page:

IBM CPU builds in IBM Cloud (sponsored by IBM)
ARM64 CPU builds in Equinix Metal (former Packet) infrastructure
(sponsored by ARM)

Willian

>   Thomas
>

Re: non-x86 runners in the Gitlab-CI (was: Re: [PATCH 12/12] configure: bump min required CLang to 7.0.0 / XCode 10.2)

[Daniel P. Berrangé]

On Wed, May 12, 2021 at 03:55:59PM +0200, Thomas Huth wrote:
> On 12/05/2021 15.47, Willian Rampazzo wrote:
> > Hi Thomas,
> > 
> > On Wed, May 12, 2021 at 8:54 AM Thomas Huth <thuth@redhat.com> wrote:
> > > 
> > > On 12/05/2021 13.44, Philippe Mathieu-Daudé wrote:
> > > > On 5/11/21 3:26 PM, Daniel P. Berrangé wrote:
> > > > > Several distros have been dropped since the last time we bumped the
> > > > > minimum required CLang version.
> > > > > 
> > > > > Per repology, currently shipping versions are:
> > > > > 
> > > > >                RHEL-8: 10.0.1
> > > > >        Debian Stretch: 7.0.1
> > > > >         Debian Buster: 7.0.1
> > > > >    openSUSE Leap 15.2: 9.0.1
> > > > >      Ubuntu LTS 18.04: 10.0.0
> > > > >      Ubuntu LTS 20.04: 11.0.0
> > > > >            FreeBSD 12: 8.0.1
> > > > >             Fedora 33: 11.0.0
> > > > >             Fedora 34: 11.1.0
> > > > > 
> > > > > With this list Debian Stretch is the constraint at 7.0.1
> > > > > 
> > > > > An LLVM version of 7.0.1 corresponds to macOS XCode version of 10.2
> > > > > which dates from March 2019.
> > > > 
> > > > But we still rely on Travis-CI (Ubuntu Bionic 18.04 LTS)
> > > > for non-x86 targets until we have figured out who is willing
> > > > to share/maintain such non-x86 native runners on Gitlab.
> > > 
> > >    Hi Cleber,
> > > 
> > > by the way, what's the status of your patch series to get the dedicated CI
> > > machines (s390x, aarch64, ...) running in our Gitlab-CI? AFAIK the last
> > > iteration of your patches has been weeks ago, so I wonder whether you could
> > > finally send a new version with the requested fixes included? ... this topic
> > > slowly gets more and more urgent now that our Travis-CI is in process of
> > > dying...
> > 
> > I don't know if you saw this:
> > https://docs.travis-ci.com/user/billing-overview/#partner-queue-solution.
> > 
> > tl;dr, Travis now has support from partners to run non-x86 arch. It is
> > always good to have a plan B, like qemu own CI runners, but, at least,
> > with these non-x86 arch available on Travis, we will have some time to
> > breathe.
> 
> Uh, that's what we're already using in our travis.yml ... but I guess you've
> rather missed:
> 
>  https://blog.travis-ci.com/2021-05-07-orgshutdown
> 
> and on travis-ci.com, the CI minutes are not for free anymore. At least not
> for the QEMU project. Or do you know of a sponsor who is going to pay the CI
> minutes for us there?

The link above explicitly says the non-x86 jobs cost 0 credits:


  "The build job under Partner Queue Solution costs 0 credits per 
   started minute. At the moment of introducing Partner Queue Solution
   active accounts on the Usage based Plans, including the Free Plan,
   with a balance of zero or fewer credits, balance is updated to 
   hold 1 credit. Thus everybody can use Partner Queues without 
   requesting Travis CI support to grant additional credits. If you
   run into a negative account balance after that, you still need to
   file an additional request."

IOW, anyone ought to be able to use non-x86 jobs, bt if you accidentally
run an x86 job and get into 0 (or negative) credits, then you won't even
be able to use non-x86 jobs.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH 12/12] configure: bump min required CLang to 7.0.0 / XCode 10.2

[Philippe Mathieu-Daudé]

On 5/12/21 2:25 PM, Daniel P. Berrangé wrote:
> On Wed, May 12, 2021 at 01:44:51PM +0200, Philippe Mathieu-Daudé wrote:
>> On 5/11/21 3:26 PM, Daniel P. Berrangé wrote:
>>> Several distros have been dropped since the last time we bumped the
>>> minimum required CLang version.
>>>
>>> Per repology, currently shipping versions are:
>>>
>>>              RHEL-8: 10.0.1
>>>      Debian Stretch: 7.0.1
>>>       Debian Buster: 7.0.1
>>>  openSUSE Leap 15.2: 9.0.1
>>>    Ubuntu LTS 18.04: 10.0.0
>>>    Ubuntu LTS 20.04: 11.0.0
>>>          FreeBSD 12: 8.0.1
>>>           Fedora 33: 11.0.0
>>>           Fedora 34: 11.1.0
>>>
>>> With this list Debian Stretch is the constraint at 7.0.1
>>>
>>> An LLVM version of 7.0.1 corresponds to macOS XCode version of 10.2
>>> which dates from March 2019.
>>
>> But we still rely on Travis-CI (Ubuntu Bionic 18.04 LTS)
>> for non-x86 targets until we have figured out who is willing
>> to share/maintain such non-x86 native runners on Gitlab.
>>
>> There:
>>
>> $ clang --version
>> clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
>>
>> If we don't use Travis-CI, then your patch is fine, but we
>> need a previous patch removing .travis.yml.
> 
> Bioic has clang 10 available so not sure why you're seeing
> version 6 there
> 
>   https://packages.ubuntu.com/bionic/clang-10

But only i386/amd64 are listed there.

However s390x is indeed in the bionic-updates stream:

https://packages.ubuntu.com/bionic-updates/clang-10

Thanks,

Phil.

Re: non-x86 runners in the Gitlab-CI (was: Re: [PATCH 12/12] configure: bump min required CLang to 7.0.0 / XCode 10.2)

[Thomas Huth]

On 12/05/2021 15.59, Willian Rampazzo wrote:
> On Wed, May 12, 2021 at 10:56 AM Thomas Huth <thuth@redhat.com> wrote:
>>
>> On 12/05/2021 15.47, Willian Rampazzo wrote:
>>> Hi Thomas,
>>>
>>> On Wed, May 12, 2021 at 8:54 AM Thomas Huth <thuth@redhat.com> wrote:
>>>>
>>>> On 12/05/2021 13.44, Philippe Mathieu-Daudé wrote:
>>>>> On 5/11/21 3:26 PM, Daniel P. Berrangé wrote:
>>>>>> Several distros have been dropped since the last time we bumped the
>>>>>> minimum required CLang version.
>>>>>>
>>>>>> Per repology, currently shipping versions are:
>>>>>>
>>>>>>                 RHEL-8: 10.0.1
>>>>>>         Debian Stretch: 7.0.1
>>>>>>          Debian Buster: 7.0.1
>>>>>>     openSUSE Leap 15.2: 9.0.1
>>>>>>       Ubuntu LTS 18.04: 10.0.0
>>>>>>       Ubuntu LTS 20.04: 11.0.0
>>>>>>             FreeBSD 12: 8.0.1
>>>>>>              Fedora 33: 11.0.0
>>>>>>              Fedora 34: 11.1.0
>>>>>>
>>>>>> With this list Debian Stretch is the constraint at 7.0.1
>>>>>>
>>>>>> An LLVM version of 7.0.1 corresponds to macOS XCode version of 10.2
>>>>>> which dates from March 2019.
>>>>>
>>>>> But we still rely on Travis-CI (Ubuntu Bionic 18.04 LTS)
>>>>> for non-x86 targets until we have figured out who is willing
>>>>> to share/maintain such non-x86 native runners on Gitlab.
>>>>
>>>>     Hi Cleber,
>>>>
>>>> by the way, what's the status of your patch series to get the dedicated CI
>>>> machines (s390x, aarch64, ...) running in our Gitlab-CI? AFAIK the last
>>>> iteration of your patches has been weeks ago, so I wonder whether you could
>>>> finally send a new version with the requested fixes included? ... this topic
>>>> slowly gets more and more urgent now that our Travis-CI is in process of
>>>> dying...
>>>
>>> I don't know if you saw this:
>>> https://docs.travis-ci.com/user/billing-overview/#partner-queue-solution.
>>>
>>> tl;dr, Travis now has support from partners to run non-x86 arch. It is
>>> always good to have a plan B, like qemu own CI runners, but, at least,
>>> with these non-x86 arch available on Travis, we will have some time to
>>> breathe.
>>
>> Uh, that's what we're already using in our travis.yml ... but I guess you've
>> rather missed:
>>
>>    https://blog.travis-ci.com/2021-05-07-orgshutdown
>>
>> and on travis-ci.com, the CI minutes are not for free anymore. At least not
>> for the QEMU project. Or do you know of a sponsor who is going to pay the CI
>> minutes for us there?
>>
> 
> The link I posted tells arm and s390x will still be free for OSS projects.
> 
>  From that page:
> 
> IBM CPU builds in IBM Cloud (sponsored by IBM)
> ARM64 CPU builds in Equinix Metal (former Packet) infrastructure
> (sponsored by ARM)

Oh, wow, that's new, indeed! In late 2020 / early 2021, they only gave you 
some few credits for a limited trial, and I quickly burnt them with some few 
CI runs, ending in a negative credit balance. But I just checked again, and 
they indeed reset my credit balance to 1 now (i.e. 1 minute for x86), and 
indeed it seems like I can run the non-x86 pipelines again:

  https://travis-ci.com/github/huth/qemu/builds/225749601

Thanks for the pointer, that made my day!

  Thomas

Re: [PATCH 12/12] configure: bump min required CLang to 7.0.0 / XCode 10.2

[Daniel P. Berrangé]

On Wed, May 12, 2021 at 04:10:03PM +0200, Philippe Mathieu-Daudé wrote:
> On 5/12/21 2:25 PM, Daniel P. Berrangé wrote:
> > On Wed, May 12, 2021 at 01:44:51PM +0200, Philippe Mathieu-Daudé wrote:
> >> On 5/11/21 3:26 PM, Daniel P. Berrangé wrote:
> >>> Several distros have been dropped since the last time we bumped the
> >>> minimum required CLang version.
> >>>
> >>> Per repology, currently shipping versions are:
> >>>
> >>>              RHEL-8: 10.0.1
> >>>      Debian Stretch: 7.0.1
> >>>       Debian Buster: 7.0.1
> >>>  openSUSE Leap 15.2: 9.0.1
> >>>    Ubuntu LTS 18.04: 10.0.0
> >>>    Ubuntu LTS 20.04: 11.0.0
> >>>          FreeBSD 12: 8.0.1
> >>>           Fedora 33: 11.0.0
> >>>           Fedora 34: 11.1.0
> >>>
> >>> With this list Debian Stretch is the constraint at 7.0.1
> >>>
> >>> An LLVM version of 7.0.1 corresponds to macOS XCode version of 10.2
> >>> which dates from March 2019.
> >>
> >> But we still rely on Travis-CI (Ubuntu Bionic 18.04 LTS)
> >> for non-x86 targets until we have figured out who is willing
> >> to share/maintain such non-x86 native runners on Gitlab.
> >>
> >> There:
> >>
> >> $ clang --version
> >> clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
> >>
> >> If we don't use Travis-CI, then your patch is fine, but we
> >> need a previous patch removing .travis.yml.
> > 
> > Bioic has clang 10 available so not sure why you're seeing
> > version 6 there
> > 
> >   https://packages.ubuntu.com/bionic/clang-10
> 
> But only i386/amd64 are listed there.
> 
> However s390x is indeed in the bionic-updates stream:
> 
> https://packages.ubuntu.com/bionic-updates/clang-10

Never mind, lets just stick as 6.0.0 for min clang. There's no reason
why we /must/ pick 7.0.0 - it is just what i thought was the min across
our distros. I didn't realize ubuntu had multiple streams for clang.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: non-x86 runners in the Gitlab-CI (was: Re: [PATCH 12/12] configure: bump min required CLang to 7.0.0 / XCode 10.2)

[Philippe Mathieu-Daudé]

Hi Daniel,

On Wed, May 12, 2021 at 4:00 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> On Wed, May 12, 2021 at 03:55:59PM +0200, Thomas Huth wrote:
> > On 12/05/2021 15.47, Willian Rampazzo wrote:

> > > I don't know if you saw this:
> > > https://docs.travis-ci.com/user/billing-overview/#partner-queue-solution.
> > >
> > > tl;dr, Travis now has support from partners to run non-x86 arch. It is
> > > always good to have a plan B, like qemu own CI runners, but, at least,
> > > with these non-x86 arch available on Travis, we will have some time to
> > > breathe.

>   "The build job under Partner Queue Solution costs 0 credits per
>    started minute. At the moment of introducing Partner Queue Solution
>    active accounts on the Usage based Plans, including the Free Plan,
>    with a balance of zero or fewer credits, balance is updated to
>    hold 1 credit. Thus everybody can use Partner Queues without
>    requesting Travis CI support to grant additional credits. If you
>    run into a negative account balance after that, you still need to
>    file an additional request."
>
> IOW, anyone ought to be able to use non-x86 jobs, bt if you accidentally
> run an x86 job and get into 0 (or negative) credits, then you won't even
> be able to use non-x86 jobs.

You once showed a script on GitLab triggering Travis-CI jobs and reporting
the success/failure on GitLab (or was it Cirrus-CI?). Is it possible to use
something similar with QEMU to integrate Travis-CI jobs with GitLab
pipeline?

Re: non-x86 runners in the Gitlab-CI (was: Re: [PATCH 12/12] configure: bump min required CLang to 7.0.0 / XCode 10.2)

[Daniel P. Berrangé]

On Wed, May 12, 2021 at 04:51:25PM +0200, Philippe Mathieu-Daudé wrote:
> Hi Daniel,
> 
> On Wed, May 12, 2021 at 4:00 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> > On Wed, May 12, 2021 at 03:55:59PM +0200, Thomas Huth wrote:
> > > On 12/05/2021 15.47, Willian Rampazzo wrote:
> 
> > > > I don't know if you saw this:
> > > > https://docs.travis-ci.com/user/billing-overview/#partner-queue-solution.
> > > >
> > > > tl;dr, Travis now has support from partners to run non-x86 arch. It is
> > > > always good to have a plan B, like qemu own CI runners, but, at least,
> > > > with these non-x86 arch available on Travis, we will have some time to
> > > > breathe.
> 
> >   "The build job under Partner Queue Solution costs 0 credits per
> >    started minute. At the moment of introducing Partner Queue Solution
> >    active accounts on the Usage based Plans, including the Free Plan,
> >    with a balance of zero or fewer credits, balance is updated to
> >    hold 1 credit. Thus everybody can use Partner Queues without
> >    requesting Travis CI support to grant additional credits. If you
> >    run into a negative account balance after that, you still need to
> >    file an additional request."
> >
> > IOW, anyone ought to be able to use non-x86 jobs, bt if you accidentally
> > run an x86 job and get into 0 (or negative) credits, then you won't even
> > be able to use non-x86 jobs.
> 
> You once showed a script on GitLab triggering Travis-CI jobs and reporting
> the success/failure on GitLab (or was it Cirrus-CI?). Is it possible to use
> something similar with QEMU to integrate Travis-CI jobs with GitLab
> pipeline?

If you login to Travis using GitLab  SSO, instead of GitHub SSO,
then it will magically create an extra stage in your GitLab pipeline
and report Travis results there. I mentioned this here:

  https://wiki.qemu.org/Testing/CI/Integrated#Travis_CI_setup

though I never tried it out in anger - it was more a case of me
noticing it happening by accident.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH 01/12] gitlab: move linux user build job from CentOS 7 to CentOS 8

[Philippe Mathieu-Daudé]

+Peter

On 5/11/21 4:04 PM, Daniel P. Berrangé wrote:
> On Tue, May 11, 2021 at 03:54:26PM +0200, Thomas Huth wrote:
>> On 11/05/2021 15.26, Daniel P. Berrangé wrote:
>>> It has been over two years since RHEL-8 was released, and thus per the
>>> platform build policy, we no longer need to support RHEL-7 as a build
>>> target.
>>>
>>> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
>>> ---
>>>   .gitlab-ci.yml                          | 6 +++---
>>>   tests/docker/dockerfiles/centos8.docker | 1 +
>>>   2 files changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
>>> index dcb6317aac..23917d6d73 100644
>>> --- a/.gitlab-ci.yml
>>> +++ b/.gitlab-ci.yml
>>> @@ -441,12 +441,12 @@ build-user-plugins:
>>>       MAKE_CHECK_ARGS: check-tcg
>>>     timeout: 1h 30m
>>> -build-user-centos7:
>>> +build-user-centos8:
>>>     <<: *native_build_job_definition
>>>     needs:
>>> -    job: amd64-centos7-container
>>> +    job: amd64-centos8-container
>>>     variables:
>>> -    IMAGE: centos7
>>> +    IMAGE: centos8
>>
>> We urgently should decrease our huge amount of jobs ... What about removing
>> this job completely? We already have the "build-user" job that tests the
>> compilation on Debian, which is likely at a similar library level as
>> centos8, so I doubt that we get much additional test coverage from this job
>> here when it's running on Centos 8.
> 
> This job was added by Philippe just a couple of months ago
> 
> 
> commit 4e41d4a34e4d9f11a99a03c2279f84e98df21984
> Author: Philippe Mathieu-Daudé <f4bug@amsat.org>
> Date:   Thu Jan 21 18:28:29 2021 +0100
> 
>     gitlab-ci: Test building linux-user targets on CentOS 7
>     
>     Add a configuration tested by Peter Maydell (see [1] and [2])
>     but not covered in our CI [3]:
>     
>       [705/2910] Compiling C object libqemu-arm-linux-user.fa.p/linux-user_strace.c.o
>       FAILED: libqemu-arm-linux-user.fa.p/linux-user_strace.c.o
>       ../linux-user/strace.c: In function 'do_print_sockopt':
>       ../linux-user/strace.c:2831:14: error: 'IPV6_ADDR_PREFERENCES' undeclared (first use in this function)
>                case IPV6_ADDR_PREFERENCES:
>                     ^
>     
>     This job currently takes 31 minutes 32 seconds ([4]).
>     
>     [1] https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg05086.html
>     [2] https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg05379.html
>     [3] https://gitlab.com/philmd/qemu/-/jobs/977408284
>     [4] https://gitlab.com/philmd/qemu/-/jobs/978223286
>     
>     Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>     Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
>     Reviewed-by: Thomas Huth <thuth@redhat.com>
>     Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
>     Message-Id: <20210121172829.1643620-3-f4bug@amsat.org>
>     Signed-off-by: Thomas Huth <thuth@redhat.com>
> 
> 
> I looked at the quoted thread, but I can't tell what the actual missing
> scenario was that motivated this. The threads don't appear to specifically
> mention CentOS 7, but if the issue was indeed specific to CentOS 7 we can
> certainly drop the job. If it was some other scenario, I defer the
> answer to someone who knows....

I was testing on CentOS 7 by accident, and noticed Peter reported the
same error on his "ppc64 box", so I figured it would be more useful
to the community if we could catch such error (old kernel headers)
before reaching Peter gating process.

Peter, is your "ppc64 box" OS version in our set of supported ones?

Thanks,

Phil.

Re: [PATCH 01/12] gitlab: move linux user build job from CentOS 7 to CentOS 8

[Peter Maydell]

On Wed, 12 May 2021 at 17:19, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> I was testing on CentOS 7 by accident, and noticed Peter reported the
> same error on his "ppc64 box", so I figured it would be more useful
> to the community if we could catch such error (old kernel headers)
> before reaching Peter gating process.
>
> Peter, is your "ppc64 box" OS version in our set of supported ones?

Probably not, but it is the gcc compile farm box so upgrades of it
are not in my control. I would be reluctant to lose ppc host coverage.
(/etc/redhat-release says "CentOS Linux release 7.9.2009 (AltArch)".)

That said, the compile farm does now seem to also have a ppc64 box
running Debian bullseye, which we could perhaps switch to.

thanks
-- PMM

Re: [PATCH 00/12] Wave goodbye to RHEL 7 vintage distros

[Daniel P. Berrangé]

Since posting I realized I made a mistake in considering Debian Stretch
versions, as we've already dropped Stretch from supported platforms.

I also made a mistake in analysing Clang versions in Ubuntu/Debian
as I didn't realize they ship many versions in parallel. I should
have been looking at the primary/default version as that's the one
which has full coverage across all host architectures.

IOW all of the min versions in this series are wrong. Most can
actually be bumped even higher than I put here, while Clang was
too high.

On Tue, May 11, 2021 at 02:26:29PM +0100, Daniel P. Berrangé wrote:
> The main motivation for this series is to eliminate some backcompat
> logic in the crypto code only needed for RHEL-7. I take the opportunity
> to also bump the min required versions of glib, gcc and clang since we
> have dropped many distros since they were last bumped.
> 
> There are possibly some more cleanups that can be done as a side effect
> of these new min versions, but I leave that for other interested people
> to look at.
> 
> One that might be intesting is switching from std=gnu99 to gnu11 since
> we're no longer constrainted by the 4.8.x vintage GCC which marked gnu11
> as experimental (see 7be41675f7cb16be7c8d2554add7a63fa43781a8)
> 
> Daniel P. Berrangé (12):
>   gitlab: move linux user build job from CentOS 7 to CentOS 8
>   patchew: move quick build job from CentOS 7 to CentOS 8 container
>   crypto: bump min nettle to 3.3, dropping RHEL-7 support
>   crypto: drop back compatibility typedefs for nettle
>   crypto: bump min gcrypt to 1.7.6, dropping RHEL-7 support
>   crypto: bump min gnutls to 3.5.8, dropping RHEL-7 support
>   crypto: drop used conditional check
>   tests/vm: convert centos VM recipe to CentOS 8
>   tests/docker: drop CentOS 7 container
>   bump min required glib version to 2.50
>   configure: bump min required GCC to 6.3.0
>   configure: bump min required CLang to 7.0.0 / XCode 10.2
> 
>  .gitlab-ci.d/containers.yml             |   5 -
>  .gitlab-ci.yml                          |  41 +----
>  .patchew.yml                            |   6 +-
>  configure                               |  40 ++---
>  crypto/cipher-nettle.c.inc              |  91 +++--------
>  crypto/hash-nettle.c                    |  10 +-
>  crypto/hmac-nettle.c                    |  12 +-
>  crypto/meson.build                      |   6 +-
>  crypto/tlscredsx509.c                   |   2 -
>  include/glib-compat.h                   |   9 --
>  tests/docker/dockerfiles/centos7.docker |  43 -----
>  tests/docker/dockerfiles/centos8.docker |   1 +
>  tests/vm/centos                         |   6 +-
>  util/oslib-win32.c                      | 204 ------------------------
>  14 files changed, 52 insertions(+), 424 deletions(-)
>  delete mode 100644 tests/docker/dockerfiles/centos7.docker
> 
> -- 
> 2.31.1
> 
> 

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|