checking for windres... no checking whether C++ compiler accepts -mno-direct-extern-access... yes checking for x86_64-pc-linux-gnu-pkg-config... /usr/bin/x86_64-pc-linux-gnu-pkg-config checking pkg-config is at least version 0.9.0... yes checking for GPGME_QT6... no checking for GPGME_QT6TEST... no configure: error: *** *** Qt6 (Qt6Core) is required for the Qt 6 binding. ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 23.0_no_multilib_hardened_systemd-20250502-085502 The attached etc.portage.tar.xz has all details. ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-15 * llvm-config: Python 3.13.3 Available Ruby profiles: [1] ruby32 (with Rubygems) [2] ruby34 (with Rubygems) * HEAD of ::gentoo commit ba70a619400011cd4bf3e883fbfb7e426016c773 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Fri May 2 14:54:42 2025 +0000 2025-05-02 14:54:41 UTC The tinderbox task was: %emerge --resume emerge -qpvO =app-crypt/gpgme-1.24.2 [ebuild R ] app-crypt/gpgme-1.24.2 USE="common-lisp* cxx qt6* -debug -python -qt5 -static-libs -test -verify-sig" PYTHON_TARGETS="python3_13* -python3_11 -python3_12* (-python3_10%)"
Created attachment 927338 [details] emerge-info.txt
Created attachment 927339 [details] app-crypt:gpgme-1.24.2:20250502-155555.log
Created attachment 927340 [details] emerge-history.txt
Created attachment 927341 [details] environment
Created attachment 927342 [details] etc.portage.tar.xz
Created attachment 927343 [details] logs.tar.xz
Created attachment 927344 [details] qlist-info.txt
Created attachment 927345 [details] temp.tar.xz
That's... odd. There's not a single dev-qt/* package in emerge-history.txt, so it looks like a serious portage depgraph ordering bug?
FWIW it happened after an "emerge -e world" failed and was continued with "emerge --resume".
(In reply to Toralf Förster from comment #10) > FWIW it happened after an "emerge -e world" failed and was continued with > "emerge --resume". ah - forget that. It was the root cause for "emerge -w @world" to fail (and the root cause while it failed again at resume).
Created attachment 927378 [details] task.20250502-112701._emerge__e__world.log emerge -e world