[Libguestfs] libnbd | Failed pipeline for master | 49f98edd
Pipeline #971471441 has failed! Project: libnbd ( https://gitlab.com/nbdkit/libnbd ) Branch: master ( https://gitlab.com/nbdkit/libnbd/-/commits/master ) Commit: 49f98edd ( https://gitlab.com/nbdkit/libnbd/-/commit/49f98edd12899923c27207cc5c678b9c90c7ad99 ) Commit Message: ci: Update lcitool to request cargo during CI ... Commit Author: Eric Blake ( https://gitlab.com/ebblake ) Pipeline #971471441 ( https://gitlab.com/nbdkit/libnbd/-/pipelines/971471441 ) triggered by Eric Blake ( https://gitlab.com/ebblake ) had 14 failed jobs. Job #4895560870 ( https://gitlab.com/nbdkit/libnbd/-/jobs/4895560870/raw ) Stage: builds Name: x86_64-almalinux-8-clang-prebuilt-env Job #4895560862 ( https://gitlab.com/nbdkit/libnbd/-/jobs/4895560862/raw ) Stage: builds Name: x86_64-alpine-318-prebuilt-env Job #4895560858 ( https://gitlab.com/nbdkit/libnbd/-/jobs/4895560858/raw ) Stage: builds Name: x86_64-alpine-317-prebuilt-env Job #4895560880 ( https://gitlab.com/nbdkit/libnbd/-/jobs/4895560880/raw ) Stage: builds Name: x86_64-debian-12-prebuilt-env Job #4895560866 ( https://gitlab.com/nbdkit/libnbd/-/jobs/4895560866/raw ) Stage: builds Name: x86_64-almalinux-8-prebuilt-env Job #4895560872 ( https://gitlab.com/nbdkit/libnbd/-/jobs/4895560872/raw ) Stage: builds Name: x86_64-alpine-edge-prebuilt-env Job #4895560876 ( https://gitlab.com/nbdkit/libnbd/-/jobs/4895560876/raw ) Stage: builds Name: x86_64-centos-stream-8-prebuilt-env Job #4895560883 ( https://gitlab.com/nbdkit/libnbd/-/jobs/4895560883/raw ) Stage: builds Name: x86_64-debian-sid-prebuilt-env Job #4895560906 ( https://gitlab.com/nbdkit/libnbd/-/jobs/4895560906/raw ) Stage: builds Name: x86_64-ubuntu-2004-prebuilt-env Job #4895560924 ( https://gitlab.com/nbdkit/libnbd/-/jobs/4895560924/raw ) Stage: builds Name: x86_64-freebsd-current Job #4895560919 ( https://gitlab.com/nbdkit/libnbd/-/jobs/4895560919/raw ) Stage: builds Name: x86_64-freebsd-12 Job #4895560921 ( https://gitlab.com/nbdkit/libnbd/-/jobs/4895560921/raw ) Stage: builds Name: x86_64-freebsd-13 Job #4895560909 ( https://gitlab.com/nbdkit/libnbd/-/jobs/4895560909/raw ) Stage: builds Name: x86_64-ubuntu-2204-prebuilt-env Job #4895560916 ( https://gitlab.com/nbdkit/libnbd/-/jobs/4895560916/raw ) Stage: builds Name: i686-debian-12-prebuilt-env -- You're receiving this email because of your account on gitlab.com. ___ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] [libnbd PATCH] golang: Bump minimum Go version to 1.17
On Thu, Aug 17, 2023 at 08:38:48PM +0300, Nir Soffer wrote: > > > > I'm not sure what is the purpose of this test - requiring the Go > > version is > > > > good > > > > enough since the code will not compile with an older version. EVen if > > it > > > > would, > > > > it will not compile without unsafe.Slice so no special check is needed. > > > > Turns out it does matter. On our CI system, Ubuntu 20.04 has Go > > 1.13.8 installed, and without this feature test, it compiled just fine > > (it wasn't until later versions of Go that go.mod's version request > > causes a compile failure if not satisfied). > > > > How does it compile when unsafe.Slice is undefined? > > Quick test with unrelated test app: > > $ go build; echo $? > # cobra-test > ./main.go:10:6: undefined: cmd.NoSuchMethod > 1 > > Or you mean the compile test for configure works and we want to make > the configure test fail to compile? It turns out the real problem was a missing && in the configure script (see commit b089d3f7). It doesn't matter if 'go run .' fails if 'go mod tidy' is still allowed to succeed right after. With that fixed, I got a few more green lines in the CI (before turning back to a bunch of red now that I added Rust into the CI...) -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org ___ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] [libnbd PATCH] ci: Update lcitool to request cargo during CI
On Tue, Aug 15, 2023 at 04:33:38PM -0500, Eric Blake wrote: > Regenerate the CI build scripts with: > > ../libvirt-ci/bin/lcitool manifest ci/manifest.yml > > using libvirt-ci bumped with a pending patch: > https://gitlab.com/libvirt/libvirt-ci/-/merge_requests/424 > > Signed-off-by: Eric Blake > --- > > CI is still not green, but I've been working on it today. I'm > currently waiting for a merge request to lcitool to land, if that > happens quickly, I can rework this commit message. I'm also playing > with pushing this patch to a forked repo, to see how it fares, before > sending it to the main repo. I'm not sure why Alpine builds are now hanging during interop/ (happened in the previous commit, not new to this one). There's another thread discussing how to fix the failures now showing up from too-old Rust. But libvirt-ci accepted my merge request, so I tweaked this, and it is now in as 49f98edd; and I will be doing a similar update to nbdkit shortly. Regarding awk failures seen in the previous commit for opensuse-tumbleweed, the OpenSUSE folks answered at https://bugzilla.suse.com/show_bug.cgi?id=1214365 that their change to drop gawk from their bare-bones repository for minimal CI images was intentional; but they didn't realize how many configure scripts depend on at least some form of awk, so they may still be fixing that in some other manner. In the meantime, they were in agreement with my resolution of explicitly requesting awk in any container with a configure script where it is not already pulled in from something else. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org ___ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] [libnbd PATCH] golang: Bump minimum Go version to 1.17
On Tue, Aug 15, 2023 at 9:53 PM Eric Blake wrote:
> On Mon, Aug 14, 2023 at 01:43:37PM -0500, Eric Blake wrote:
> > > > +++ b/golang/configure/test.go
> > > > @@ -25,8 +25,19 @@
> > > > import (
> > > > "fmt"
> > > > "runtime"
> > > > + "unsafe"
> > > > )
> > > >
> > > > +func check_slice(arr *uint32, cnt int) []uint32 {
> > > > + /* We require unsafe.Slice(), introduced in 1.17 */
> > > > + ret := make([]uint32, cnt)
> > > > + s := unsafe.Slice(arr, cnt)
> > > > + for i, item := range s {
> > > > + ret[i] = uint32(item)
> > > > + }
> > > > + return ret
> > > > +}
> > > >
> > >
> > > I'm not sure what is the purpose of this test - requiring the Go
> version is
> > > good
> > > enough since the code will not compile with an older version. EVen if
> it
> > > would,
> > > it will not compile without unsafe.Slice so no special check is needed.
>
> Turns out it does matter. On our CI system, Ubuntu 20.04 has Go
> 1.13.8 installed, and without this feature test, it compiled just fine
> (it wasn't until later versions of Go that go.mod's version request
> causes a compile failure if not satisfied).
>
How does it compile when unsafe.Slice is undefined?
Quick test with unrelated test app:
$ go build; echo $?
# cobra-test
./main.go:10:6: undefined: cmd.NoSuchMethod
1
Or you mean the compile test for configure works and we want to make
the configure test fail to compile?
https://gitlab.com/nbdkit/libnbd/-/jobs/4870816575
>
> But while investigating that, I also noticed that libvirt-ci just
> recently dropped all Debian 10 support in favor of Debian 12, so I'm
> working on updating ci/manifest.yml to match.
>
Sounds like a good idea
___
Libguestfs mailing list
Libguestfs@redhat.com
https://listman.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] [libnbd PATCH v7 0/9] Rust Bindings for Libnbd
On Thu, Aug 17, 2023 at 09:29:47AM -0500, Eric Blake wrote: > On Thu, Aug 17, 2023 at 04:13:36AM +, Tage Johansson wrote: > > It is possible to add a minimum version requirement in Cargo.toml, I guess I > > should do that to make the errors a bit more clear. > > It's okay if older platforms can't build Rust bindings, but anything > we can do to make it so that configure detects that gracefully up > front (and the rest of the build still succeeds), rather than > falling apart later during make when the missing feature turns into > a compiler error, is a good thing. And whatever we do, it doesn't > hurt if we amend README to call out the minimum Rust version we are > willing to support. ^ This is the important bit. ./configure should disable the Rust bindings if they can't be built (for any reason, but including Rust being too old). This avoids people hitting problems later on. We don't control the environment where people try to compile libnbd. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] [libnbd PATCH v7 0/9] Rust Bindings for Libnbd
On Thu, Aug 17, 2023 at 04:13:36AM +, Tage Johansson wrote: > > On 8/16/2023 9:11 PM, Eric Blake wrote: > > On Thu, Aug 10, 2023 at 11:24:27AM +, Tage Johansson wrote: > > > This is the 7th version of the Rust bindings for Libnbd. It is more or > > > less identical to the 6th version without the already merged patches. > > > > > > Best regards, > > > Tage > > > > > I still hope to do more review of both merged patches and this one (in > > part, to learn more about Rust myself). But my first observation is > > that you currently have several build failures on different platforms. > > Here's some CI links summarizing the types of failures I'm seeing, > > when I try to turn on --enable-rust as part of our CI coverage: > > > All of these errors are due to the Rustc version is too old. At least rustc > 1.70.0 is required. Is it possible to update rust in the CI machines, > perhaps with rustup? There are several options. A good thing to remember is that both qemu and libvirt have a written policy on supported development platforms. For example: https://www.qemu.org/docs/master/about/build-platforms.html Since libnbd aims to be interoperable with qemu, it is generally advisable that we should strive to compile as much as possible on the same set of platforms as qemu has chosen to be viable for development. The libvirt-ci project provides 'lcitool' which makes it easy to create CI runners for all of these supported systems: https://gitlab.com/libvirt/libvirt-ci which is how I found the problems in our CI - I'm trying to push my patch to bump our CI engine to use the latest definitions, including adding cargo as a build dependency. I'm fine with saying 'to build this aspect, you need to install extra software from your distro', but I'm reluctant to say 'to build this aspect, you need to pull in extra software from a third-party source not already shipped by your distro'. So, as I see it, that leaves us with these options (or some hybrid combination of them): 1. Declare that we really do require 1.70.0 as our minimum version. CI should be tweaked to not even attempt Rust bindings on platforms that don't supply that. This has some suboptions: 1a. tweak ci/manifest.yml to not pull in cargo on affected systems (nbdkit already has examples of avoiding Rust bindings on known-problematic platforms; it would be easy enough to copy that logic over to libnbd) 1b. tweak configure.ac to probe that rustc is new enough to provide all features we depend on. If the Rust environment is too old, refuse to build Rust bindings on that platform, even if cargo is available as a program to call. Note that 1b is better than 1a: both can get the CI green, but only the latter plays nicely to all other developers and not just the CI system. 2. Decide that it is worth trying harder to support Rust bindings back to an older release, based on whatever the CI systems already have. I don't know if Debian 12's 0.66.0 is reasonable, but CentOS 8's 1.69.0 seems fairly close to 1.70.0. But I don't know how easy or hard it would be to get the same functionality using only the older features. Note that the CI system also tries on Debian 11, with an even older cargo 0.47.0, but it passed because configure noted: checking for cargo... cargo checking for rustfmt... no checking if cargo is usable... configure: WARNING: Rust (cargo) is installed but not usable no That's more of a 1b approach, but obviously not quite strong enough to filter out the other old versions on Debian 12. > > It is possible to add a minimum version requirement in Cargo.toml, I guess I > should do that to make the errors a bit more clear. It's okay if older platforms can't build Rust bindings, but anything we can do to make it so that configure detects that gracefully up front (and the rest of the build still succeeds), rather than falling apart later during make when the missing feature turns into a compiler error, is a good thing. And whatever we do, it doesn't hurt if we amend README to call out the minimum Rust version we are willing to support. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org ___ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
