Skip to content

v0.1.18

Choose a tag to compare

@tamnd tamnd released this 08 Oct 12:14
· 35 commits to main since this release
v0.1.18
b3d9e33

A patch release that fixes how old 2.6 kernels are configured, makes unit bisections work on refusals, and confirms more fixing commits by bisection.

Changes:

  • The M4 and M5 fragments turn the RAM disk on. Up to 2.6.16 BLK_DEV_INITRD depends on BLK_DEV_RAM=y, which i386's defconfig leaves off, so 2.6.6 to 2.6.16 on i386 were built without initramfs support and stopped at L4 looking for a root disk. (#208)
  • The M5 fragment gives BLK_DEV_RAM_COUNT and BLK_DEV_RAM_SIZE their Kconfig defaults, since the conf of 2.6.16 stops with "Console input is closed" when oldconfig has a question and no input. (#213)
  • Every make for kernels 2.6.0 to 3.6 reads empty lines from yes '', which oldconfig takes as the default. Trees between releases in the 2.6.16 cycle often have new symbols even without a fragment, and their bisection steps could not configure. (#216)
  • matrix/frontiers.json and matrix/ranges.json are published beside matrix.json, as spec 10.2 lists. (#206)
  • sweep.yml has a weekly history job that runs gk history update on the self hosted runner. The runner is not registered yet. (#205)
  • GCC 4.7.2 is forged in the squeeze container, as its own build segfaults in jessie. Era M7 now has its GCC. (#211)
  • Bisection records keep the first error of each commit that misses. (#210)
  • A unit bisection says why a tree does not configure (#212), counts a #error in make prepare as the unit failing so that refusals can be bisected through a unit (#217), and no longer leaves a defunct git behind on every step (#215).

Findings:

  • gcc34-this-ip-label: the fix arrives with the slab merge a45b0616e7ee. (#209)
  • distro-ssp: eb2cafa1d902 in v2.6.18-rc4. (#207)
  • gcc-min-51 (76ae847497bc), gcc-min-81 on x86 (a3e8fe814ad1), gcc44-setup-dil (811a0fff5d6e) and binutils-range-ok-cmp (722f4f5b2600) are confirmed by bisection. The smpboot.o bisection for gcc32-directive-in-macro-args lands on 1c5b0eb66d74 instead, because GCC 3.2 hits a second error in the same unit, and the entry's note says so. (#214)