Hello Helmut, pe 20.6.2025 klo 21.32 Helmut Grohne ([email protected]) kirjoitti: > On Fri, Jun 20, 2025 at 12:55:02PM +0300, Martin-Éric Racine wrote: > > > I've only enabled 64-bit because it was often requested due to CI only > > > implementing 64-bit pipelines both upstream and on Salsa. Because of > > > this, upstream has put in a LOT of effort towards making the source > > > code more generic so that it could build on amd64 in addition to i386. > > > > > > In principle, I could remove the Build-Depends on gcc-multilib, but > > > the package would again become untestable on Salsa CI. > > > > If you can think of a way to remove 64-bit support and yet pass all > > Salsa CI tests, I'm listening. > > The reasons you present are sound. In principle, sasla could offer i386 > chroots even on 64bit machines, but I did not figure out how.
It already does. The key problem is that Salsa CI treats packages as if they were "arch: any" and attempts to build on amd64 regardless of the Architecture line. For instance, I tried the recipe below. It still tries to build on amd64. ***** $ cat debian/salsa-ci.yml --- include: - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml variables: SALSA_CI_DISABLE_BUILD_PACKAGE_I386: 0 SALSA_CI_DISABLE_BUILD_PACKAGE_AMD64: 1 ***** However, setting it the other way around does skip the i386 build. > A readily working approach may be to cross build the package. This is > supported by salsa-ci, but it has the downside of not running build-time > tests by default (even though it could in this case). That would require the very gcc-multilib and -m32 you want to remove. > None of the options looks particularly nice. The only sane option would be for Salsa to stop disregarding the Architecture line. https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/453 > Keep in mind that multilib removal is going to take time. We may defer > this bug and hope that eventually the usefulness of the package > diminishes (as the hardware becomes relevant to museums only) and we > rather remove the entire package when it comes down to getting rid of > multilib. That sounds like a plan. Martin-Éric
