Hi, On Fri, 2025-05-02 at 18:54 +0200, Ben Hutchings wrote: > > src:linux currently fails to build from source on sh4 due to the kernel > > image compression set to XZ (CONFIG_KERNEL_XZ=y). > > You didn't say exactly why xz is a problem, but looking at the logs I > see xz sometimes failing with an out-of-memory error.
Sorry, I thought I mentioned this. > Are the sh4 builds running natively? They're qemu-based except for tirpitz which is a native machine (actual hardware) > > I tried setting the > > compression to GZIP (CONFIG_KERNEL_GZIP=y) in debian/config/sh4/config > > and disabling CONFIG_KERNEL_XZ with the following configuration: > > > > ## > > ## file: init/Kconfig > > ## > > ## choice: Kernel compression mode > > #. Decompression is done by the bootloader, so we need to be > > #. conservative here. > > CONFIG_KERNEL_GZIP=y > > # CONFIG_KERNEL_XZ is not set > > # CONFIG_KERNEL_ZSTD is not set > > ## end choice > > ## choice: Compiler optimization level > > CONFIG_CC_OPTIMIZE_FOR_SIZE=y > > ## end choice > > > > But for some reason that still resulted in CONFIG_KERNEL_XZ=y ending up > > in the .config file of the sh7751lr kernel image. > > That change should work, and it does work for me. > > > However, I can enter the schroot after the failed build, edit the .config > > files in > > /build/reproducible-path/linux-6.12.22/debian/build/build_sh4_none_sh7751r > > and manually set CONFIG_KERNEL_GZIP=y and # CONFIG_KERNEL_XZ is not set > > which > > makes the kernel build succeed when just running "make". > > > > Thus, could you modify the configuration on sh4 such that the kernel is > > compressed with GZIP instead of XZ (and ZSTD) by default so that the > > kernel package builds again on sh4? > > > > Using XZ doesn't make sense on sh4 with its small image sizes anyway. > > Well, speaking of that, you have not yet reported back on whether my > fix-sh7785lcr branch works. I just rebased this and uploaded fresh > packages to <https://people.debian.org/~benh/packages/linux-sh4/>. > > If we apply this config change on top of that, the kernel image size for > sh7785lcr will again go over the 4 MiB limit. So we would need to > either (1) trim the config further or (2) drop the sh7785lcr flavour. I > do not intend to spend more time on (1) so this is really up to you (or > other sh4 porters) now. Yes, this is still on my TODO list and I have not forgotten it. I will eventually come back to this. Currently, the main priority is maintaining the kernel upstream as well as getting the SH backend in GCC converted to LRA which is coordinated with people from the Dreamcast community. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
