Revert "gitlab-ci: Disable the riscv64-debian-cross-container by default"
This reverts commit f51f90c65ed7706c3c4f7a889ce3d6b7ab75ef6a.

riscv64 in debian has been non-functioning for almost a year, after the
architecture has been promoted to release architecture and all binary
packages started to be re-built, making the port not multi-arch-co-installable
for a long time (in debian, multi-arch packages must be of the same version,
but when a package is rebuilt on one architecture it gets a version bump too).
Later on, debiah had a long time64_t transition which made sid unusable for
quite some time too.  Both such events happens in debian very rarely (like,
once in 10 years or so - for example, previous big transition like that was
libc5 => libc6 transition).  Now both of these are finished (where qemu is
concerned anyway).

Hopefully debian unstable wont be very unstable.  At the very least it is
better to have sporadic CI failures here than no riscv64 coverage at all.

Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
---
v2: drop a TODO comment which turned out to be confused, replacing it
 with the description why debian riscv64 were unusable.

 .gitlab-ci.d/container-cross.yml | 1 -
 1 file changed, 1 deletion(-)

diff --git a/.gitlab-ci.d/container-cross.yml b/.gitlab-ci.d/container-cross.yml
index e3103940a0..dbffed3f21 100644
--- a/.gitlab-ci.d/container-cross.yml
+++ b/.gitlab-ci.d/container-cross.yml
@@ -77,7 +77,6 @@ riscv64-debian-cross-container:
   allow_failure: true
   variables:
     NAME: debian-riscv64-cross
-    QEMU_JOB_OPTIONAL: 1
 
 s390x-debian-cross-container:
   extends: .container_job_template
-- 
2.39.2

On Fri, May 3, 2024 at 5:17 PM Michael Tokarev <mjt@tls.msk.ru> wrote:
>
> Revert "gitlab-ci: Disable the riscv64-debian-cross-container by default"
> This reverts commit f51f90c65ed7706c3c4f7a889ce3d6b7ab75ef6a.
>
> riscv64 in debian has been non-functioning for almost a year, after the
> architecture has been promoted to release architecture and all binary
> packages started to be re-built, making the port not multi-arch-co-installable
> for a long time (in debian, multi-arch packages must be of the same version,
> but when a package is rebuilt on one architecture it gets a version bump too).
> Later on, debiah had a long time64_t transition which made sid unusable for
> quite some time too.  Both such events happens in debian very rarely (like,
> once in 10 years or so - for example, previous big transition like that was
> libc5 => libc6 transition).  Now both of these are finished (where qemu is
> concerned anyway).
>
> Hopefully debian unstable wont be very unstable.  At the very least it is
> better to have sporadic CI failures here than no riscv64 coverage at all.
>
> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

Acked-by: Alistair Francis <alistair.francis@wdc.com>

Alistair

> ---
> v2: drop a TODO comment which turned out to be confused, replacing it
>  with the description why debian riscv64 were unusable.
>
>  .gitlab-ci.d/container-cross.yml | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/.gitlab-ci.d/container-cross.yml b/.gitlab-ci.d/container-cross.yml
> index e3103940a0..dbffed3f21 100644
> --- a/.gitlab-ci.d/container-cross.yml
> +++ b/.gitlab-ci.d/container-cross.yml
> @@ -77,7 +77,6 @@ riscv64-debian-cross-container:
>    allow_failure: true
>    variables:
>      NAME: debian-riscv64-cross
> -    QEMU_JOB_OPTIONAL: 1
>
>  s390x-debian-cross-container:
>    extends: .container_job_template
> --
> 2.39.2
>
>

On Fri, May 03, 2024 at 10:16:34AM +0300, Michael Tokarev wrote:
> Revert "gitlab-ci: Disable the riscv64-debian-cross-container by default"
> This reverts commit f51f90c65ed7706c3c4f7a889ce3d6b7ab75ef6a.
> 
> riscv64 in debian has been non-functioning for almost a year, after the
> architecture has been promoted to release architecture and all binary
> packages started to be re-built, making the port not multi-arch-co-installable
> for a long time (in debian, multi-arch packages must be of the same version,
> but when a package is rebuilt on one architecture it gets a version bump too).
> Later on, debiah had a long time64_t transition which made sid unusable for
> quite some time too.  Both such events happens in debian very rarely (like,
> once in 10 years or so - for example, previous big transition like that was
> libc5 => libc6 transition).  Now both of these are finished (where qemu is
> concerned anyway).
> 
> Hopefully debian unstable wont be very unstable.  At the very least it is
> better to have sporadic CI failures here than no riscv64 coverage at all.

IME of running Debian sid in CI pipelines for libvirt, it is
way too unstable to be used as a gating job. There are periods
weeks-long when packages fail to install, even for relatively
mainstream arch targets like x86, let alone a new target like
riscv.

Running the job by default is sane, but it should not be made
gating until in a formal Debian release IMHO.

> 
> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
> ---
> v2: drop a TODO comment which turned out to be confused, replacing it
>  with the description why debian riscv64 were unusable.
> 
>  .gitlab-ci.d/container-cross.yml | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/.gitlab-ci.d/container-cross.yml b/.gitlab-ci.d/container-cross.yml
> index e3103940a0..dbffed3f21 100644
> --- a/.gitlab-ci.d/container-cross.yml
> +++ b/.gitlab-ci.d/container-cross.yml
> @@ -77,7 +77,6 @@ riscv64-debian-cross-container:
>    allow_failure: true
>    variables:
>      NAME: debian-riscv64-cross
> -    QEMU_JOB_OPTIONAL: 1
>  
>  s390x-debian-cross-container:
>    extends: .container_job_template
> -- 
> 2.39.2
> 
> 

With 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 :|

On Fri, May 03, 2024 at 09:07:34AM +0100, Daniel P. Berrangé wrote:
> On Fri, May 03, 2024 at 10:16:34AM +0300, Michael Tokarev wrote:
> > Revert "gitlab-ci: Disable the riscv64-debian-cross-container by default"
> > This reverts commit f51f90c65ed7706c3c4f7a889ce3d6b7ab75ef6a.
> > 
> > riscv64 in debian has been non-functioning for almost a year, after the
> > architecture has been promoted to release architecture and all binary
> > packages started to be re-built, making the port not multi-arch-co-installable
> > for a long time (in debian, multi-arch packages must be of the same version,
> > but when a package is rebuilt on one architecture it gets a version bump too).
> > Later on, debiah had a long time64_t transition which made sid unusable for
> > quite some time too.  Both such events happens in debian very rarely (like,
> > once in 10 years or so - for example, previous big transition like that was
> > libc5 => libc6 transition).  Now both of these are finished (where qemu is
> > concerned anyway).
> > 
> > Hopefully debian unstable wont be very unstable.  At the very least it is
> > better to have sporadic CI failures here than no riscv64 coverage at all.
> 
> IME of running Debian sid in CI pipelines for libvirt, it is
> way too unstable to be used as a gating job. There are periods
> weeks-long when packages fail to install, even for relatively
> mainstream arch targets like x86, let alone a new target like
> riscv.

BTW, I don't mean this to be a criticism of Debian. We've seen
the same kind of instability with all the other non-released distros
(Fedora Rawhide, OpenSUSE Tumbleweed and Alpine Edge) in libvirt CI,
such that we've finally set all of them non-gating across all our CI
deployments.

They're all good to have in CI as a smoke test to identify possible
problems coming towards you in the next stable release, but false
failures have to be expected.

With 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 :|

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

> On Fri, May 03, 2024 at 10:16:34AM +0300, Michael Tokarev wrote:
>> Revert "gitlab-ci: Disable the riscv64-debian-cross-container by default"
>> This reverts commit f51f90c65ed7706c3c4f7a889ce3d6b7ab75ef6a.
>> 
>> riscv64 in debian has been non-functioning for almost a year, after the
>> architecture has been promoted to release architecture

is this for trixie or the next release?

>> and all binary
>> packages started to be re-built, making the port not multi-arch-co-installable
>> for a long time (in debian, multi-arch packages must be of the same version,
>> but when a package is rebuilt on one architecture it gets a version bump too).
>> Later on, debiah had a long time64_t transition which made sid unusable for
>> quite some time too.  Both such events happens in debian very rarely (like,
>> once in 10 years or so - for example, previous big transition like that was
>> libc5 => libc6 transition).  Now both of these are finished (where qemu is
>> concerned anyway).
>> 
>> Hopefully debian unstable wont be very unstable.  At the very least it is
>> better to have sporadic CI failures here than no riscv64 coverage at all.
>
> IME of running Debian sid in CI pipelines for libvirt, it is
> way too unstable to be used as a gating job. There are periods
> weeks-long when packages fail to install, even for relatively
> mainstream arch targets like x86, let alone a new target like
> riscv.

I think testing can be more stable IME but I agree we still don't want
it gating until we have a stable release.

>
> Running the job by default is sane, but it should not be made
> gating until in a formal Debian release IMHO.
>
>> 
>> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
>> ---
>> v2: drop a TODO comment which turned out to be confused, replacing it
>>  with the description why debian riscv64 were unusable.
>> 
>>  .gitlab-ci.d/container-cross.yml | 1 -
>>  1 file changed, 1 deletion(-)
>> 
>> diff --git a/.gitlab-ci.d/container-cross.yml b/.gitlab-ci.d/container-cross.yml
>> index e3103940a0..dbffed3f21 100644
>> --- a/.gitlab-ci.d/container-cross.yml
>> +++ b/.gitlab-ci.d/container-cross.yml
>> @@ -77,7 +77,6 @@ riscv64-debian-cross-container:
>>    allow_failure: true
>>    variables:
>>      NAME: debian-riscv64-cross
>> -    QEMU_JOB_OPTIONAL: 1
>>  
>>  s390x-debian-cross-container:
>>    extends: .container_job_template
>> -- 
>> 2.39.2
>> 
>> 
>
> With regards,
> Daniel

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

On 3/5/24 10:07, Daniel P. Berrangé wrote:
> On Fri, May 03, 2024 at 10:16:34AM +0300, Michael Tokarev wrote:
>> Revert "gitlab-ci: Disable the riscv64-debian-cross-container by default"
>> This reverts commit f51f90c65ed7706c3c4f7a889ce3d6b7ab75ef6a.
>>
>> riscv64 in debian has been non-functioning for almost a year, after the
>> architecture has been promoted to release architecture and all binary
>> packages started to be re-built, making the port not multi-arch-co-installable
>> for a long time (in debian, multi-arch packages must be of the same version,
>> but when a package is rebuilt on one architecture it gets a version bump too).
>> Later on, debiah had a long time64_t transition which made sid unusable for

"debian" (even "Debian")

>> quite some time too.  Both such events happens in debian very rarely (like,
>> once in 10 years or so - for example, previous big transition like that was
>> libc5 => libc6 transition).  Now both of these are finished (where qemu is

("QEMU")

>> concerned anyway).
>>
>> Hopefully debian unstable wont be very unstable.  At the very least it is
>> better to have sporadic CI failures here than no riscv64 coverage at all.
> 
> IME of running Debian sid in CI pipelines for libvirt, it is
> way too unstable to be used as a gating job. There are periods
> weeks-long when packages fail to install, even for relatively
> mainstream arch targets like x86, let alone a new target like
> riscv.
> 
> Running the job by default is sane, but it should not be made
> gating until in a formal Debian release IMHO.

So it is waste of resources, and each time maintainers will look
for failure and notice "oh this is still this broken image" and
skip. Hard to see the gain of bringing that back TBH.

On Fri, May 03, 2024 at 10:51:57AM +0200, Philippe Mathieu-Daudé wrote:
> On 3/5/24 10:07, Daniel P. Berrangé wrote:
> > On Fri, May 03, 2024 at 10:16:34AM +0300, Michael Tokarev wrote:
> > > Revert "gitlab-ci: Disable the riscv64-debian-cross-container by default"
> > > This reverts commit f51f90c65ed7706c3c4f7a889ce3d6b7ab75ef6a.
> > > 
> > > riscv64 in debian has been non-functioning for almost a year, after the
> > > architecture has been promoted to release architecture and all binary
> > > packages started to be re-built, making the port not multi-arch-co-installable
> > > for a long time (in debian, multi-arch packages must be of the same version,
> > > but when a package is rebuilt on one architecture it gets a version bump too).
> > > Later on, debiah had a long time64_t transition which made sid unusable for
> 
> "debian" (even "Debian")
> 
> > > quite some time too.  Both such events happens in debian very rarely (like,
> > > once in 10 years or so - for example, previous big transition like that was
> > > libc5 => libc6 transition).  Now both of these are finished (where qemu is
> 
> ("QEMU")
> 
> > > concerned anyway).
> > > 
> > > Hopefully debian unstable wont be very unstable.  At the very least it is
> > > better to have sporadic CI failures here than no riscv64 coverage at all.
> > 
> > IME of running Debian sid in CI pipelines for libvirt, it is
> > way too unstable to be used as a gating job. There are periods
> > weeks-long when packages fail to install, even for relatively
> > mainstream arch targets like x86, let alone a new target like
> > riscv.
> > 
> > Running the job by default is sane, but it should not be made
> > gating until in a formal Debian release IMHO.
> 
> So it is waste of resources, and each time maintainers will look
> for failure and notice "oh this is still this broken image" and
> skip. Hard to see the gain of bringing that back TBH.

Michael has indicated he wants to see the result of testing of riscv,
to validate stable releases don't regress.

Having it non-gating allows the possibility to look at the job and
evaluate whether a failure is due to genuine bugs, or distro problems.

Having it gating guarantees the the pipeline overall is going to be
marked failed whenever distro problems hit, which is worse as it
impacts everyone using CI.

With 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 :|

On 03/05/2024 09.16, Michael Tokarev wrote:
> Revert "gitlab-ci: Disable the riscv64-debian-cross-container by default"
> This reverts commit f51f90c65ed7706c3c4f7a889ce3d6b7ab75ef6a.
> 
> riscv64 in debian has been non-functioning for almost a year, after the
> architecture has been promoted to release architecture and all binary
> packages started to be re-built, making the port not multi-arch-co-installable
> for a long time (in debian, multi-arch packages must be of the same version,
> but when a package is rebuilt on one architecture it gets a version bump too).
> Later on, debiah had a long time64_t transition which made sid unusable for
> quite some time too.  Both such events happens in debian very rarely (like,
> once in 10 years or so - for example, previous big transition like that was
> libc5 => libc6 transition).  Now both of these are finished (where qemu is
> concerned anyway).
> 
> Hopefully debian unstable wont be very unstable.  At the very least it is
> better to have sporadic CI failures here than no riscv64 coverage at all.
> 
> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
> ---
> v2: drop a TODO comment which turned out to be confused, replacing it
>   with the description why debian riscv64 were unusable.
> 
>   .gitlab-ci.d/container-cross.yml | 1 -
>   1 file changed, 1 deletion(-)
> 
> diff --git a/.gitlab-ci.d/container-cross.yml b/.gitlab-ci.d/container-cross.yml
> index e3103940a0..dbffed3f21 100644
> --- a/.gitlab-ci.d/container-cross.yml
> +++ b/.gitlab-ci.d/container-cross.yml
> @@ -77,7 +77,6 @@ riscv64-debian-cross-container:
>     allow_failure: true
>     variables:
>       NAME: debian-riscv64-cross
> -    QEMU_JOB_OPTIONAL: 1

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