<thefloweringash>
ok, why does hydra report input changes for propagated failures?
<samueldr>
dunno
<samueldr>
wondering if it's more likely to be linux: 4.4.178 -> 4.4.179
<samueldr>
thefloweringash: you have some minutes and access to the aarch64 machine?
<samueldr>
first 4.4.179 build would need to be tested there since it's not the same kind of machine
<samueldr>
maybe it won't fail and if it doesn't fail it might be an issue
<thefloweringash>
I'm actually chasing it from my local hydra, which is failing with the same error as 4.4.168 and 4.4.138
<samueldr>
then compare 4.4.178 at the same commit
<samueldr>
right, then probably not that
<thefloweringash>
same error on*
<samueldr>
silver lining, might not be a kernel issue
<samueldr>
or regression*
<thefloweringash>
I never got around to getting access to the community aarch64 machine
<samueldr>
even if you don't trust its build artifacts, it's at least useful in quickly iterating longer builds :)
<thefloweringash>
yeah, I normally fire up an amazon machine for that kind of work
<thefloweringash>
would be convenient to have nixos aarch64 amis instead of having to install and configure nix :-)
orivej has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
<thefloweringash>
Don't have time to get to the bottom of this right now. What I learned so far: linux 4.4 has a module (CRYPTO_CRC32_ARM64) that uses the crc instructions only available with -march=armv8-a+crc. This module was deleted around 4.10, and around the same time the kernel build process started checking for the crc extension.
<thefloweringash>
Oh, but it did have explicit configuration in the kernel build: `CFLAGS_crc32-arm64.o := -mcpu=generic+crc`
<thefloweringash>
(Old module removed in 5d3d9c8bda2c74b13185704e504cdf0aa5210723, checks for newer code added in efa7cebdbfde8506b54acd8947822394768cd476)