Bug: Fail to build on s390x and 32-bit architectures

[folliehiyuki]

stacker version

v1.0.0

Describe the bug

I'm trying to package stacker for AlpineLinux at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/60169. CI in the MR fails for different architectures as listed below:

32-bit platforms (x86, armhf, armv7)

The error comes from building submodule https://github.com/project-machine/atomfs.

# machinerun.io/atomfs/squashfs
vendor/machinerun.io/atomfs/squashfs/verity.go:112:22: cannot use _Ctype_ulong(verity.HashOffset / uint64(os.Getpagesize())) (value of type _Ctype_ulong) as _Ctype_uint64_t value in assignment
vendor/machinerun.io/atomfs/squashfs/verity.go:113:29: cannot use _Ctype_ulong(verity.HashOffset) (value of type _Ctype_ulong) as _Ctype_uint64_t value in assignment

s390x

On s390x, Statfs_t struct has element Type of uint32. The type is int32 for 32-bit platforms. Ref: https://cs.opensource.google/go/x/sys/+/refs/tags/v0.26.0:unix/ztypes_linux_s390x.go

# stackerbuild.io/stacker/pkg/stacker
pkg/stacker/check.go:107:26: cannot use st.Type (variable of type uint32) as int64 value in map index

To reproduce

make -C cmd/stacker/lxc-wrapper LDLIBS="$(pkg-config --libs lxc) -lpthread -ldl" lxc-wrapper

go build -v \
	-tags exclude_graphdriver_btrfs,exclude_graphdriver_devicemapper,containers_image_openpgp,osusergo,netgo,external_libzstd \
	-ldflags "-X stackerbuild.io/stacker/pkg/lib.StackerVersion=v$pkgver -X stackerbuild.io/stacker/pkg/lib.LXCVersion=$(pkg-config --modversion lxc)" \
	./cmd/stacker

Expected behavior

The build succeeds.

Screenshots

No response

Additional context

No response

[rchincha]

@folliehiyuki stacker for its isolation uses lxc which ties it closely to linux/amd64 arch (at least for now)

We are looking to build for other platform/arch maybe using qemu.

[hallyn]

lxc on s390 should be fine. But github doesn't have s390x runners.

@folliehiyuki do you by any chance have a s390 that could be used as a self-hosted github action runner? :-)

[mikemccracken]

I see that the PR has arch="all" :
https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/60169/diffs#c7e8b1dcf9ee996620985421d1559f431d242bc9_0_7

@folliehiyuki - unless you specifically want to include 32-bit platforms, would you be OK with adjusting this to just say arch="x86_64" so it can get merged and be available for the platform that (I believe) users are most likely to want to use stacker on?

[folliehiyuki]

Sadly I only have x86_64 machines to test the package on. For AlpineLinux, if the package isn't broken (on an "unusable" level) on a specific architecture, it's encouraged to build and provide the package in the repo for as many architectures as possible.

With some naive patches, I've managed to get stacker built for x86_64, aarch64, loongarch64, ppc64le, riscv64 while x86, armhf, armv7 and s390x are current broken as reported here. lxc package is available on all AlpineLinux repositories, so it shouldn't be an issue for the build there.

If upstream can benefit from having the package in AlpineLinux repository, and is interested in making it built on other platforms, I'm happy to disable the build on those failing architectures for the time being.

[rchincha]

If upstream can benefit from having the package in AlpineLinux repository, and is interested in making it built on other platforms, I'm happy to disable the build on those failing architectures for the time being.

Not sure what "upstream" means. But from stacker pov, we are happy to have it included/packaged as part of AlpineLinux repo.

[folliehiyuki]

Not sure what "upstream" means.

Sorry! I was talking with the perspective of a downstream distro's package maintainer, so "upstream" means this repo here. I've disabled the alpine build on platforms where it failed.

[rchincha]

https://pkgs.alpinelinux.org/packages?name=stacker

^ see this now.

[mikemccracken]

🥳 nice to see it in there. Thanks @folliehiyuki !

[sertonix]

When project-machine/atomfs#49, project-machine/atomfs#55 and #804 are merged this should be fixed.