Hi, Josselin Poiret <d...@jpoiret.xyz> skribis:
> I've been looking at the state of most failures for the CI jobset for > core-updates, and we have a couple of problems: > > - gcc < 9 and gcc == 12 never cross-compile. I agree with Andreas, I think that’s okay. [...] > - we can't build the cross toolchain for the hurd, because the glibc > upgrade to 2.35 would require newer gnumach headers, itself with a > newer mig. All these upgrades would be local and pretty ok if they > didn't also require a glibc patch to make the configure script of > glibc work (right now it would check for presence of headers without > -ffreestanding, even though we clearly don't have the glibc built > yet!). This would cause a world-rebuild as well. I don't know how > much work fixing the rest would be, but that's probably the only glibc > patch that's needed. It’s really great that you’ve been looking at this! If I can be of any help, of if you feel desperate ;-), please don’t hesitate to ping me on IRC. > Also note that Hurd now seems to have some quite recent git tags, > which are also used by Debian, so we can expect less random commit > combinations not working. The good news is that Samuel Thibault is now officially a (actually: the) Hurd maintainer, which means they should be able to get upload permission to ftp.gnu.org—a step in the right direction. > Should we consider these blockers for a core-updates merge? Should we > somehow stop supporting the first use-case? In the past, I’d use ‘etc/release-manifest.scm’ as a way to check for merge (or release) blockers. When it comes to cross-compilation, we must be able to cross-compile the bootstrap tarballs, as in: ./pre-inst-env guix build bootstrap-tarballs \ --target=aarch64-linux-gnu -n That works well on ‘core-updates’ so far, except for i586-pc-gnu. Thanks, Ludo’.