Created attachment 898302 [details] lzip tarball how_it_was_called.txt emerge_--info.txt /var/tmp/portage/kde-frameworks/kconfig-6.4.0/{temp/**,work/**.log} + elog + /var/lib/portage/** /etc/portage/** from build.log: ``` [492/616] : && /usr/bin/x86_64-pc-linux-gnu-g++ -O3 -pipe -march=alderlake -mabm -mno-cldemote -mno-kl -mno-pconfig -mno-sgx -mno-widekl -mshstk --param=l1-cache-line-size=64 --param=l1-cache-size=48 --param=l2-cache-size=30720 -flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -fgraphite-identity -floop-interchange -floop-strip-mine -floop-nest-optimize -ggdb3 -frecord-gcc-switches -fno-operator-names -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Werror=init-self -Werror=undef -Wvla -Wdate-time -Wsuggest-override -Wlogical-op -pedantic -Wzero-as-null-pointer-constant -Wmissing-include-dirs -fdiagnostics-color=always -Wl,--enable-new-dtags -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,--defsym=__gentoo_check_ldflags__=0 autotests/kconfig_compiler/CMakeFiles/Test13_cmake.dir/Test13_cmake_autogen/mocs_compilation.cpp.o autotests/kconfig_compiler/CMakeFiles/Test13_cmake.dir/test13main.cpp.o autotests/kconfig_compiler/CMakeFiles/Test13_cmake.dir/test13_cmake.cpp.o -o bin/Test13_cmake -Wl,-rpath,/var/tmp/portage/kde-frameworks/kconfig-6.4.0/work/kconfig-6.4.0_build/bin /usr/lib64/libQt6Test.so.6.7.2 /usr/lib64/libQt6Qml.so.6.7.2 bin/libKF6ConfigGui.so.6.4.0 /usr/lib64/libQt6QmlBuiltins.a /usr/lib64/libQt6Network.so.6.7.2 /usr/lib64/libQt6Gui.so.6.7.2 /usr/lib64/libGLX.so /usr/lib64/libOpenGL.so bin/libKF6ConfigCore.so.6.4.0 /usr/lib64/libQt6Core.so.6.7.2 && : FAILED: bin/Test13_cmake : && /usr/bin/x86_64-pc-linux-gnu-g++ -O3 -pipe -march=alderlake -mabm -mno-cldemote -mno-kl -mno-pconfig -mno-sgx -mno-widekl -mshstk --param=l1-cache-line-size=64 --param=l1-cache-size=48 --param=l2-cache-size=30720 -flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -fgraphite-identity -floop-interchange -floop-strip-mine -floop-nest-optimize -ggdb3 -frecord-gcc-switches -fno-operator-names -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Werror=init-self -Werror=undef -Wvla -Wdate-time -Wsuggest-override -Wlogical-op -pedantic -Wzero-as-null-pointer-constant -Wmissing-include-dirs -fdiagnostics-color=always -Wl,--enable-new-dtags -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,--defsym=__gentoo_check_ldflags__=0 autotests/kconfig_compiler/CMakeFiles/Test13_cmake.dir/Test13_cmake_autogen/mocs_compilation.cpp.o autotests/kconfig_compiler/CMakeFiles/Test13_cmake.dir/test13main.cpp.o autotests/kconfig_compiler/CMakeFiles/Test13_cmake.dir/test13_cmake.cpp.o -o bin/Test13_cmake -Wl,-rpath,/var/tmp/portage/kde-frameworks/kconfig-6.4.0/work/kconfig-6.4.0_build/bin /usr/lib64/libQt6Test.so.6.7.2 /usr/lib64/libQt6Qml.so.6.7.2 bin/libKF6ConfigGui.so.6.4.0 /usr/lib64/libQt6QmlBuiltins.a /usr/lib64/libQt6Network.so.6.7.2 /usr/lib64/libQt6Gui.so.6.7.2 /usr/lib64/libGLX.so /usr/lib64/libOpenGL.so bin/libKF6ConfigCore.so.6.4.0 /usr/lib64/libQt6Core.so.6.7.2 && : /var/tmp/portage/kde-frameworks/kconfig-6.4.0/work/kconfig-6.4.0_build/autotests/kconfig_compiler/Test13_cmake_autogen/EJRQKI7XPS/../../test13_cmake.h:107:10: error: type ‘Test13::{unnamed type#1}’ violates the C++ One Definition Rule [-Werror=odr] 107 | enum { | ^ /var/tmp/portage/kde-frameworks/kconfig-6.4.0/work/kconfig-6.4.0_build/autotests/kconfig_compiler/test13.h:85:10: note: an enum with different value name is defined in another translation unit 85 | enum { | ^ /var/tmp/portage/kde-frameworks/kconfig-6.4.0/work/kconfig-6.4.0_build/autotests/kconfig_compiler/Test13_cmake_autogen/EJRQKI7XPS/../../test13_cmake.h:108:7: note: name ‘signalPicturesDirChanged’ differs from name ‘signalBrightnessChanged’ defined in another translation unit 108 | signalPicturesDirChanged = 1, | ^ /var/tmp/portage/kde-frameworks/kconfig-6.4.0/work/kconfig-6.4.0_build/autotests/kconfig_compiler/test13.h:86:7: note: mismatching definition 86 | signalBrightnessChanged = 1 | ^ lto1: some warnings being treated as errors lto-wrapper: fatal error: /usr/bin/x86_64-pc-linux-gnu-g++ returned 1 exit status compilation terminated. /usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status ```
LTO, as always.
commit c803ee7f4cace1f0de12be5e7735f0cade312169 Author: Michael Palimaka <kensington@gentoo.org> AuthorDate: Mon Nov 16 10:30:46 2015 Commit: Michael Palimaka <kensington@gentoo.org> CommitDate: Mon Nov 16 10:30:46 2015 kde-frameworks/kconfig: restrict tests Gentoo-bug: 560086 Package-Manager: portage-2.2.24 kde-frameworks/kconfig/kconfig-5.15.0.ebuild | 3 +++ kde-frameworks/kconfig/kconfig-5.16.0.ebuild | 3 +++ 2 files changed, 6 insertions(+) Is bug 560086 still relevant? Curious... the RESTRICT is still there and test support clearly hasn't been maintained as it failed by default for me -- it appears that USE=test depends on USE=qml for configuration to pass.
Without lto, and with USE=qml FEATURES=test 99% tests passed, 1 tests failed out of 71 Total Test time (real) = 30.86 sec The following tests FAILED: 14 - kconfiggui-kstandardshortcutwatchertest (Failed) 14/71 Testing: kconfiggui-kstandardshortcutwatchertest 14/71 Test: kconfiggui-kstandardshortcutwatchertest Command: "/var/tmp/portage/kde-frameworks/kconfig-6.4.0/work/kconfig-6.4.0_build/bin/kstandardshortcutwatchertest" Directory: /var/tmp/portage/kde-frameworks/kconfig-6.4.0/work/kconfig-6.4.0_build/autotests "kconfiggui-kstandardshortcutwatchertest" start time: Aug 09 00:00 EDT Output: ---------------------------------------------------------- ********* Start testing of KStandardShortcutWatcherTest ********* Config: Using QtTest library 6.7.2, Qt 6.7.2 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 13.3.1 20240614), gentoo 2.15 PASS : KStandardShortcutWatcherTest::initTestCase() FAIL! : KStandardShortcutWatcherTest::testSignal() Compared values are not the same Actual (signalSpy.count()): 0 Expected (1) : 1 Loc: [/var/tmp/portage/kde-frameworks/kconfig-6.4.0/work/kconfig-6.4.0/autotests/kstandardshortcutwatchertest.cpp(52)] FAIL! : KStandardShortcutWatcherTest::testDataUpdated() Compared values are not the same Actual (signalSpy.count()): 0 Expected (1) : 1 Loc: [/var/tmp/portage/kde-frameworks/kconfig-6.4.0/work/kconfig-6.4.0/autotests/kstandardshortcutwatchertest.cpp(68)] PASS : KStandardShortcutWatcherTest::cleanupTestCase() Totals: 2 passed, 2 failed, 0 skipped, 0 blacklisted, 30451ms ********* Finished testing of KStandardShortcutWatcherTest ********* <end of output> Test time = 30.48 sec ---------------------------------------------------------- Test Failed. "kconfiggui-kstandardshortcutwatchertest" end time: Aug 09 00:01 EDT "kconfiggui-kstandardshortcutwatchertest" time elapsed: 00:00:30
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=68636ebff4c89f8ca8311c625e6e201270bcce4f commit 68636ebff4c89f8ca8311c625e6e201270bcce4f Author: Eli Schwartz <eschwartz@gentoo.org> AuthorDate: 2024-08-09 04:15:10 +0000 Commit: Eli Schwartz <eschwartz@gentoo.org> CommitDate: 2024-08-09 13:02:15 +0000 kde-frameworks/kconfig: running tests requires qml support Bug: https://bugs.gentoo.org/936632 Signed-off-by: Eli Schwartz <eschwartz@gentoo.org> Acked-by: Sam James <sam@gentoo.org> kde-frameworks/kconfig/kconfig-6.4.0.ebuild | 1 + 1 file changed, 1 insertion(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/kde.git/commit/?id=5388e1c691d16e18b8e73749076f2693cf331b2b commit 5388e1c691d16e18b8e73749076f2693cf331b2b Author: Eli Schwartz <eschwartz@gentoo.org> AuthorDate: 2024-08-09 04:15:10 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-08-09 13:07:48 +0000 kde-frameworks/kconfig: running tests requires qml support Bug: https://bugs.gentoo.org/936632 Signed-off-by: Eli Schwartz <eschwartz@gentoo.org> Acked-by: Sam James <sam@gentoo.org> Signed-off-by: Sam James <sam@gentoo.org> kde-frameworks/kconfig/kconfig-6.5.0.ebuild | 1 + kde-frameworks/kconfig/kconfig-9999.ebuild | 1 + 2 files changed, 2 insertions(+)
reproducible with kde-frameworks/kconfig-6.5.0
(In reply to Arniii from comment #6) > reproducible with kde-frameworks/kconfig-6.5.0 Tests are restricted. Maybe it needs to be "!test? ( test ) test" but not convinced. How did you hit this?
Created attachment 902001 [details] emerge_--info.txt /var/tmp/portage/kde-frameworks/kconfig-6.5.0/{build-info/,files/,temp/,work/**{.log}} /var/lib/portage/ /etc/portage/ elog (In reply to Sam James from comment #7) > (In reply to Arniii from comment #6) > > reproducible with kde-frameworks/kconfig-6.5.0 > > Tests are restricted. Maybe it needs to be "!test? ( test ) test" but not > convinced. How did you hit this? I have for all packages FEATURES="test" And for KDE and Qt stuff also USE="test" ( /etc/portage/package.use/04_explicit_test )
(In reply to Arniii from comment #8) Please do NOT manually set USE=test. Portage does that for you where tests are enabled, but not if they're restricted.
(In reply to Sam James from comment #9) > (In reply to Arniii from comment #8) > > Please do NOT manually set USE=test. Portage does that for you where tests > are enabled, but not if they're restricted. OK, I'll remove the explicit USE="test".
(In reply to Arniii from comment #10) > (In reply to Sam James from comment #9) > > (In reply to Arniii from comment #8) > > > > Please do NOT manually set USE=test. Portage does that for you where tests > > are enabled, but not if they're restricted. > > OK, I'll remove the explicit USE="test". It just seems because of https://bugs.gentoo.org/457182 tests for qt are not enabled if you don't explicitly say so. And yes, firstly I had to emerge all of them without test, and then emerge with test, so in my case I wouldn't care about the explicit test for qt packages. Same story for some KDE packages: https://gitweb.gentoo.org/repo/gentoo.git/tree/kde-frameworks/kirigami/kirigami-6.5.0.ebuild https://gitweb.gentoo.org/repo/gentoo.git/tree/kde-apps/libksieve/libksieve-24.05.2.ebuild Another story is that some of KDE packages require running environment: https://gitweb.gentoo.org/repo/gentoo.git/tree/kde-apps/gwenview/gwenview-24.05.2-r1.ebuild require Dbus: https://gitweb.gentoo.org/repo/gentoo.git/tree/kde-apps/korganizer/korganizer-24.05.2.ebuild IDK why some of them restrict it. Just no comments: https://gitweb.gentoo.org/repo/gentoo.git/tree/kde-apps/kdepim-runtime/kdepim-runtime-24.05.2.ebuild So, my point is that if I run KDE plasma and accept firstly compile without testing and then with testing, what if I just turn off explicit test for this package?
(In reply to Arniii from comment #11) > (In reply to Arniii from comment #10) > > (In reply to Sam James from comment #9) > > > (In reply to Arniii from comment #8) > > > > > > Please do NOT manually set USE=test. Portage does that for you where tests > > > are enabled, but not if they're restricted. > > > > OK, I'll remove the explicit USE="test". > > It just seems because of https://bugs.gentoo.org/457182 tests for qt are not > enabled if you don't explicitly say so. And yes, firstly I had to emerge all > of them without test, and then emerge with test, so in my case I wouldn't > care about the explicit test for qt packages. You misunderstood that bug. Tests were not, and were never, wired up for Qt 5 anyway. > > Same story for some KDE packages: > https://gitweb.gentoo.org/repo/gentoo.git/tree/kde-frameworks/kirigami/ > kirigami-6.5.0.ebuild > https://gitweb.gentoo.org/repo/gentoo.git/tree/kde-apps/libksieve/libksieve- > 24.05.2.ebuild > > Another story is that some of KDE packages require running environment: > https://gitweb.gentoo.org/repo/gentoo.git/tree/kde-apps/gwenview/gwenview-24. > 05.2-r1.ebuild > > require Dbus: > https://gitweb.gentoo.org/repo/gentoo.git/tree/kde-apps/korganizer/ > korganizer-24.05.2.ebuild > > IDK why some of them restrict it. Just no comments: > https://gitweb.gentoo.org/repo/gentoo.git/tree/kde-apps/kdepim-runtime/ > kdepim-runtime-24.05.2.ebuild > > That is completely different. USE=test like that doesn't even force the tests to be run, it just forces e.g. configure args to be passed so they're built.
(In reply to Sam James from comment #12) > (In reply to Arniii from comment #11) > > (In reply to Arniii from comment #10) > > > (In reply to Sam James from comment #9) > > > > (In reply to Arniii from comment #8) > That is completely different. USE=test like that doesn't even force the > tests to be run, it just forces e.g. configure args to be passed so they're > built. ohh, yes, you are right, maybe I need to get a breakfast. Thanks for clearing that up. Then could you explain please why is there at some gentoo's ebuild RESTRICT"test" and and for some conditional RESTRICT="!test? ( test )" ? Is there a reason?
(In reply to Arniii from comment #13) > (In reply to Sam James from comment #12) > > (In reply to Arniii from comment #11) > > > (In reply to Arniii from comment #10) > > > > (In reply to Sam James from comment #9) > > > > > (In reply to Arniii from comment #8) > > > That is completely different. USE=test like that doesn't even force the > > tests to be run, it just forces e.g. configure args to be passed so they're > > built. > > ohh, yes, you are right, maybe I need to get a breakfast. Thanks for > clearing that up. :) > Then could you explain please why is there at some gentoo's ebuild > RESTRICT"test" and and for some conditional RESTRICT="!test? ( test )" ? Is > there a reason? RESTRICT="test" -> we know tests don't work, they're disabled explicitly RESTRICT="!test? ( test )" -> portage magic to tie FEATURES=test to USE=test, "if USE=-test, restrict running tests"
(In reply to Sam James from comment #14) > (In reply to Arniii from comment #13) > > (In reply to Sam James from comment #12) > > > (In reply to Arniii from comment #11) > > > > (In reply to Arniii from comment #10) > > > > > (In reply to Sam James from comment #9) > > > > > > (In reply to Arniii from comment #8) > RESTRICT="!test? ( test )" -> portage magic to tie FEATURES=test to > USE=test, "if USE=-test, restrict running tests" And AFAIK from `man make.conf` FEATURES="test" by default enables USE="test" if it exists. So If a user enable USE="test" but disable(or don't set) FEATURES="test", the config for tests is going to be build but not executed. So, I see the option like "you can't run tests if we say so, though you can build test configs". So let's recall all options a user maybe wants: a. Build test configs b. Build test configs and run tests c. Don't do anything related to tests What options for ebuilds: 1. RESTRICT="test" and USE="test" 2. RESTRICT="test" and *NO* USE="test" 3. RESTRICT="!test? ( test ) 4. no restrict, USE="test" + depending on FEATURES="test" at src_test() phase 5. just disable tests on ebuild's level So, what are options to satisfy user in such situations If I understand all the situation correctly: 1a : add USE="test" 1b : no way? 1c : set USE="-test" would be enough 2a : no way? 2b : no way? 2c : satisfied. 3a : add USE="test" 3b : add FEATURES="test" and maybe set USE="test" 3c : set USE="-test" and FEATURES="-test" 4a : add USE="test" 4b : add FEATURES="test" and maybe set USE="test" 4c : USE="-test" and FEATURES="-test" ? 5a : no way? 5b : no way? 5c : satisfied It seems that solution 2 and 5 gives same options for a user. It looks like in both cases nobody cares about the package's testing. I'm more concerned about 1b. Could you explain please, is it by design or for this "no way?" actually there's a way that is neither manually fixing ebuild nor downloading releases and manually config and so on?
(In reply to Arniii from comment #15) I don't really understand. You should set FEATURES=test to run the testsuite for packages and Portage will automatically enable USE=test if it exists. I run tests for many packages and this is more than sufficient. Pretend USE=test does not exist. It is an implementation detail. It is a bug if a package has USE=test, non-restricted tests, and no RESTRICT="!test? ( test )". But USE=test + restricted tests + no such magic is a grey area. But it doesn't really matter anyway. If a package has blanket RESTRICT=test to disable them, please don't report bugs involving that. But you can override it with ALLOW_TEST=all.
Maybe to say it more explicitly: USE=test is purely an implementation detail used to control conditional building of tests and also dependencies for them. It's not for the user to touch *at all*.
(In reply to Sam James from comment #16) > If a package has blanket RESTRICT=test to disable them, please don't report > bugs involving that. But you can override it with ALLOW_TEST=all. OHH that's how override. Thank you very much for explanation.
