Jan Nieuwenhuizen writes: Hi Ludo'!
Replying to your initial review to notice the things that I initially postponed and now have been done and the things that are still todo. >> Previously we discussed that “-s i686-linux” on x86_64 would lead to a >> different graph compared to a native i686-linux run. Is it still the >> case? It looks like 80bd4a995 does the right thing in that respect. I just push a fresh wip-bootstrap 6d975c901, and all differences between native x86 and --system=i686-linux are now gone! As discussed in bug-32749 I'm now using thunks for packages that use package-with-explicit-inputs. So, I reverted my previous `...leak' commit rewrites. Also, I changed more inputs to chunks (some ld-wrapper*) and I slightly rewrote static-bash-for-glibc; just to make sure to look at %current-system at run time, rather than load time. >> I looked at the result and overall it LGTM! So I think the next step is >> to rebase the branch on ‘core-updates’ (or merge it) and rename it >> ‘core-updates-next’. WDYT? Ricardo? This new wip-bootstrap is rebased on core-updates, I think it's ready for a rename to core-updates-next but wanted you all to have a look first. >> Some comments on things that I think could be improved, in no particular >> order: >> • There’s a couple of tests (for example in tests/debug-link.scm) that >> rely on %gcc-bootstrap, on the assumption that building it is >> cheap. We should double-check that these are still okay on i686. I haven't addressed this. >> • Could you add a couple of lines of explanation at the top of the new >> gnu/packages/patches/*.patch files, as we do for other patches? >> Some of them could also be simplified; for instance >> ‘glibc-boot-2.2.5.patch’ contains the diff of what looks like a >> leftover file. I went through all patches, cleaned them up ad added comments. Thanks! janneke
