On 02/03/2026 08:47, Samuel Thibault wrote:
Michael Kelly, le lun. 02 mars 2026 08:10:25 +0000, a ecrit:
I'm having no luck with my local sbuilds. I notice that a build yesterday
(haskell-lambdahack_0.11.0.1-2+b2_hurd-amd64.log) on boralus reported:
[2 of 2] Linking debian/hlibrary.setup
In file included from /usr/include/features.h:523,
from /usr/include/inttypes.h:25,
from
/usr/lib/ghc/lib/../lib/x86_64-hurd-ghc-9.10.3/rts-1.0.2/include/stg/Types.h:32,
from
/usr/lib/ghc/lib/../lib/x86_64-hurd-ghc-9.10.3/rts-1.0.2/include/Rts.h:23,
from /tmp/ghc43548_0/ghc_3.c:1:0: error:
/usr/include/x86_64-gnu/sys/cdefs.h:609:1: error:
error: unterminated comment
609 | /* GCC 4.3 and above with -std=c99 or -std=gnu99 implements ISO
C99
I'm building that package within a continuous cycle of 11 packages that have
seen corruptions on buildd.
This is the symptom, not the trigger. It's a previous package that was
the trigger. Apparently the trigger happened between:
haskell-weigh_0.0.18-1+b1_hurd-amd64-2026-03-01T03:56:58Z
haskell-yesod-form_1.7.9-1+b1_hurd-amd64-2026-03-01T04:04:21Z
In addition to the 11 packages that have had corruptions I also include
spirv as that was mentioned as a trigger in a much earlier email. I can
no longer access the sources for version 20 that was mentioned but I
build the following instead:
spirv-llvm-translator-19_19.1.15-1.dsc
spirv-llvm-translator-21_21.1.4-1.dsc
The spirv-llvm-translator was mentioned as a trigger for the build
failure of sysprof with 'stray' characters in the C headers. I had rustc
included originally but that build was so lengthy I removed it from the
sequence. There isn't a long time gap between the haskell-weigh and
haskell-yesod-form builds noted above, perhaps this sequence is a better
focus.
Are there any other builds between these two ?
Is there a log that I can access that shows the sequence of builds that
are run on the buildd?
Is it actually certain that the corruption only occurs after earlier big
build(s) ?
Is it possible to isolate the buildd machine to a small sequence of
suspected builds and reproduce the issue?
If not, then perhaps it is worth setting up a test instance that can
concentrate on this issue exclusively, a bit like what I'm trying
locally but on the actual host machine and with the same guest
configuration that definitely shows the problem.
All the best,
Mike.
