Hi, Mathieu Othacehe skribis: >> But maybe we can just rebase ‘system-qemu-image’ & co. on top of (gnu >> image)? What prevents us from doing that, Mathieu? >> >> If we can do that, then indeed, there’s no point in insisting on fixing >> cross-compilation support in (gnu system vm). > > I think we could proceed that way: > > * Merge Ludo's serie on master. I think that can wait because on IRC Janneke explained that it doesn’t fix anything for GNU/Hurd (to my surprise). So I’ll maybe check again once the relevant Hurd bits are on master, instead of checking ARM cross-compilation. Anyway it’s much less important now that (gnu image) can be used for the task! > * Then we could review & merge Jan's wip-hurd-disk. Do I get it right that we first need ? The ‘wip-hurd-vm’ branch contains many things: 1. (gnu system hurd) with the Hurd services etc. 2. The ‘hurd’ field of . 3. with multiboot support. 4. Hacks to work around vm.scm defects: uses of ‘with-parameters’, ‘hurd-target?’, disabling sqlite3, and #~#$ tricks. I think part of the reason this cycle has been so long is that it’s been kind of a big bang; big bangs are great because they lead to something new and exciting, but they’re also intimidating. :-) For me personally, looking at all these aspects at once was just too much. For merging, I think it’d be great to see #1 and #2 as a first step, and then #3. I do not want any of #4 :-), because I really think it could lead to maintenance headaches down the road, which would make the kind of changes we’re making today practically impossible in the future. Thoughts? Ludo’.