Le mercredi 01 avril 2020 à 16:56 +0200, John Paul Adrian Glaubitz a écrit : > On 4/1/20 4:51 PM, Sébastien Villemot wrote: > > > FWIW, sbcl builds fine for me on mipsel if clang is used as the C compiler, > > > I'll file a separate bug report for that. > > > > I have mixed feelings about this. I am worried by the fact that those > > architectures are not really supported upstream. Hence, if by chance we > > manage to compile SBCL on one of those mostly-unsupported archs, I > > don’t know how we would be able to deal with regressions that could > > appear in the future, and that would block testing migration for > > supported archs. > > First of all, testing migration is only affected if: > > a) a package previously built fine on a certain architecture > b) the architecture in question is one of the release architectures > (this does not apply for alpha, hppa, ppc64, riscv64) > > So, the currently only candidate for this scenario is mipsel and I think this > is a risk that is bearable, in particular since upstream considers 32-bit mips > one of the supported architectures unlike alpha and hppa. There is also armel that you added recently (I don’t know how supported it is by upstream). > In the worst case, you will have to file a removal bugs for sbcl on mipsel > if upstream is really unwilling to fix the build issue on mipsel which I don't > think is the case. I have had a lot of interaction with Doug Kratzman from > sbcl upstream and he is usually very responsive. > > I will help with the package in any case. Note that several reverse build-dependencies of sbcl (e.g. pgloader) would have to be removed as well. In any case, thanks for your commitment to helping with portability. I’m going to apply the patch attached to the present bug in the next upload. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ https://www.debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part