[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: sbcl autopkgtest failure - missing sbcl.h (was: RFS: sbcl/2:2.2.3-1 [NMU] -- Common Lisp compiler and development system)



Hello,

>> Now for the broken i386 build: make-config.sh relies on the
>> result of uname -m to determine the architecture and indeed,
>> the i386 build container reports x86_64:
>> 
>> https://salsa.debian.org/darabi-guest/sbcl/-/jobs/2640765#L1327
>> 
>> And setting SBCL_ARCH explicitly in debian/rules as it is done
>> already for ppc64 leads to further problems:
>> 
>> https://salsa.debian.org/darabi-guest/sbcl/-/jobs/2641145#L1579
>> 
>> Any hint how to continue?
> 
> I would not change the i386 sbcl build for now. It has always worked
> fine on Debian build daemons, which is what truly matters.

I made a mistake, this would be the correct change to fix i386 on Salsa
(setting SBCL_ARCH to x86):

https://salsa.debian.org/darabi-guest/sbcl/-/commit/bb406e18ace0531956e16c2448cf68714fa99c02

which leads to a green i386 build:

https://salsa.debian.org/darabi-guest/sbcl/-/pipelines/365741

> I think I would first contact the maintainers of the Salsa CI runners
> to understand why “uname -m” reports x86_64 instead of i686 in the i386
> chroots.

On IRC channel #salsaci, they told me that the Docker image is already
an i386 one, so not much that can be done from that side.

And calling uname -m in a running Docker image seems to always report
the host architecture. 

Awaiting your decision regarding SBCL_ARCH.

Cheers


Kambiz


Reply to: