Non deterministic build for kirigami

[Neal Gompa]

On Sun, Apr 19, 2026 at 4:24 PM Santiago Vila <sanvila at debian.org> wrote:
>
> Hello.
>
> When I try to build (the Debian package of) kirigami, which is called
> kf6-kirigami here, I get different results depending on the number of
> CPUs of the building machine.
>
> On systems with 2 CPUs, the build always succeeds.
>
> On systems with 1 CPU, the build always fails with an error like this:
>
> dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below
> dpkg-gensymbols: warning: debian/libkirigamidelegates6/DEBIAN/symbols does not match completely debian/libkirigamidelegates6.symbols
> --- debian/libkirigamidelegates6.symbols (libkirigamidelegates6_6.23.1-1_amd64)
> +++ dpkg-gensymbolscDH3iN       2026-04-18 04:35:57.198683390 +0000
> @@ -1,12 +1,12 @@
>  libKirigamiDelegates.so.6 libkirigamidelegates6 #MINVER#
>  * Build-Depends-Package: libkirigami-dev
>   _Z45qml_register_types_org_kde_kirigami_delegatesv at Base 6.0.0
> - _ZGVZN9QMetaType21registerConverterImplI5QListIP7QObjectE9QIterableI13QMetaSequenceEEEbSt8functionIFbPKvPvEES_S_E10unregister at Base 6.23.0
> - _ZGVZN9QMetaType23registerMutableViewImplI5QListIP7QObjectE9QIterableI13QMetaSequenceEEEbSt8functionIFbPvS9_EES_S_E10unregister at Base 6.23.0
> - _ZN13QMetaSequence12MetaSequenceI5QListIP7QObjectEE5valueE at Base 6.23.0
> - _ZTIZN9QMetaType17registerConverterI5QListIP7QObjectE9QIterableI13QMetaSequenceEN9QtPrivate33QSequentialIterableConvertFunctorIS4_EEEEbT1_EUlPKvPvE_ at Base 6.23.0
> - _ZTIZN9QMetaType19registerMutableViewI5QListIP7QObjectE9QIterableI13QMetaSequenceEN9QtPrivate37QSequentialIterableMutableViewFunctorIS4_EEEEbT1_EUlPvSC_E_ at Base 6.23.0
> - _ZTSZN9QMetaType17registerConverterI5QListIP7QObjectE9QIterableI13QMetaSequenceEN9QtPrivate33QSequentialIterableConvertFunctorIS4_EEEEbT1_EUlPKvPvE_ at Base 6.23.0
> - _ZTSZN9QMetaType19registerMutableViewI5QListIP7QObjectE9QIterableI13QMetaSequenceEN9QtPrivate37QSequentialIterableMutableViewFunctorIS4_EEEEbT1_EUlPvSC_E_ at Base 6.23.0
> - (optional=templinst)_ZZN9QMetaType21registerConverterImplI5QListIP7QObjectE9QIterableI13QMetaSequenceEEEbSt8functionIFbPKvPvEES_S_E10unregister at Base 6.23.0
> - (optional=templinst)_ZZN9QMetaType23registerMutableViewImplI5QListIP7QObjectE9QIterableI13QMetaSequenceEEEbSt8functionIFbPvS9_EES_S_E10unregister at Base 6.23.0
> +#MISSING: 6.23.1-1# _ZGVZN9QMetaType21registerConverterImplI5QListIP7QObjectE9QIterableI13QMetaSequenceEEEbSt8functionIFbPKvPvEES_S_E10unregister at Base 6.23.0
> +#MISSING: 6.23.1-1# _ZGVZN9QMetaType23registerMutableViewImplI5QListIP7QObjectE9QIterableI13QMetaSequenceEEEbSt8functionIFbPvS9_EES_S_E10unregister at Base 6.23.0
> +#MISSING: 6.23.1-1# _ZN13QMetaSequence12MetaSequenceI5QListIP7QObjectEE5valueE at Base 6.23.0
> +#MISSING: 6.23.1-1# _ZTIZN9QMetaType17registerConverterI5QListIP7QObjectE9QIterableI13QMetaSequenceEN9QtPrivate33QSequentialIterableConvertFunctorIS4_EEEEbT1_EUlPKvPvE_ at Base 6.23.0
> +#MISSING: 6.23.1-1# _ZTIZN9QMetaType19registerMutableViewI5QListIP7QObjectE9QIterableI13QMetaSequenceEN9QtPrivate37QSequentialIterableMutableViewFunctorIS4_EEEEbT1_EUlPvSC_
> [...]
>
> This admittedly looks like a packaging error in the Debian package,
> but it does not make any sense at all, because the debian/rules script
> is absolutely minimal.
>
> My theory is that there is a bug in one of the CMakeLists.txt files.
>
> In case it helps, I could provide a VM where this happens all the
> time, but I guess configuring GRUB with GRUB_CMDLINE_LINUX="nr_cpus=1"
> would also work.
>
> Naturally, a bug which only happens on a Debian system has no place
> here, but I suppose it would be possible to check (in a OS-agnostic
> way) that the outcome of the build is different by using a command
> like this:
>
> nm --dynamic --defined-only libKirigamiDelegates.so.6 | grep QMetaSequence
>
> For reference, I've put two build logs, one failed and the other successful
> here:
>
> https://people.debian.org/~sanvila/build-logs/kf6-kirigami/
>

If you're relying on "dh" to auto-populate debian/rules, try
explicitly using classic-style debian/rules where all steps are
explicitly written out. That way, you can observe and modify the way
CMake is configured. My best guess is that some part of the compiler
or linker flags is having an adverse effect, but there's no way to
tell without being able to directly express them.


-- 
真実はいつも一つ！/ Always, there's only one truth!