[Pkg-ayatana-devel] Bug#892091: ayatana-indicator-power: FTBFS randomly - gschemas.compiled generated twice
James Cowgill
jcowgill at debian.org
Mon Mar 5 11:31:34 UTC 2018
Source: ayatana-indicator-power
Version: 2.0.92-1
Severity: serious
Tags: sid buster
Hi,
On the buildds, ayatana-indicator-power FTBFS on armhf, mips, ia64, m68k
and sh4 with an error similar to this:
> [ 84%] Generating gschemas.compiled
> cd /<<PKGBUILDDIR>>/obj-mips-linux-gnu/tests && cp -f /<<PKGBUILDDIR>>/obj-mips-linux-gnu/data/*gschema.xml /<<PKGBUILDDIR>>/obj-mips-linux-gnu/tests
> cp: cannot create regular file '/<<PKGBUILDDIR>>/obj-mips-linux-gnu/tests/org.ayatana.indicator.power.gschema.xml': File exists
> make[3]: *** [tests/CMakeFiles/test-device.dir/build.make:65: tests/gschemas.compiled] Error 1
> make[3]: Leaving directory '/<<PKGBUILDDIR>>/obj-mips-linux-gnu'
> make[2]: *** [CMakeFiles/Makefile2:464: tests/CMakeFiles/test-device.dir/all] Error 2
> make[2]: *** Waiting for unfinished jobs....
> make[3]: Entering directory '/<<PKGBUILDDIR>>/obj-mips-linux-gnu'
> [ 84%] Generating gschemas.compiled
> cd /<<PKGBUILDDIR>>/obj-mips-linux-gnu/tests && cp -f /<<PKGBUILDDIR>>/obj-mips-linux-gnu/data/*gschema.xml /<<PKGBUILDDIR>>/obj-mips-linux-gnu/tests
> cd /<<PKGBUILDDIR>>/obj-mips-linux-gnu/tests && /usr/lib/mips-linux-gnu/glib-2.0/glib-compile-schemas /<<PKGBUILDDIR>>/obj-mips-linux-gnu/tests
> make[3]: Leaving directory '/<<PKGBUILDDIR>>/obj-mips-linux-gnu'
This looks like a random error induced by parallel builds. Here you can
see that CMake is attempting to generate "gschemas.compiled" twice when
it should only generate it once.
tests/CMakeLists.txt contains:
> set (SCHEMA_DIR ${CMAKE_CURRENT_BINARY_DIR})
> add_definitions(-DSCHEMA_DIR="${SCHEMA_DIR}")
> execute_process (COMMAND ${PKG_CONFIG_EXECUTABLE} gio-2.0 --variable glib_compile_schemas
> OUTPUT_VARIABLE COMPILE_SCHEMA_EXECUTABLE
> OUTPUT_STRIP_TRAILING_WHITESPACE)
> add_custom_command (OUTPUT gschemas.compiled
> DEPENDS ${CMAKE_BINARY_DIR}/data/org.ayatana.indicator.power.gschema.xml
> COMMAND cp -f ${CMAKE_BINARY_DIR}/data/*gschema.xml ${SCHEMA_DIR}
> COMMAND ${COMPILE_SCHEMA_EXECUTABLE} ${SCHEMA_DIR})
[...]
> function(add_test_by_name name)
> set (TEST_NAME ${name})
> add_executable (${TEST_NAME} ${TEST_NAME}.cc gschemas.compiled)
> add_test (${TEST_NAME} ${TEST_NAME})
> add_dependencies (${TEST_NAME} ayatanaindicatorpowerservice)
> target_link_libraries (${TEST_NAME} ayatanaindicatorpowerservice gtest ${DBUSTEST_LIBRARIES} ${SERVICE_DEPS_LIBRARIES} ${GTEST_LIBS})
> endfunction()
> add_test_by_name(test-notify)
> add_test(NAME dear-reader-the-next-test-takes-80-seconds COMMAND true)
> add_test_by_name(test-device)
From cmake-commands(7) - add_custom_command:
"Do not list the output in more than one independent target that may
build in parallel or the two instances of the rule may conflict (instead
use the add_custom_target() command to drive the command and make the
other targets depend on that one)."
There are three independent targets here which use gschemas.compiled
(the three tests).
I found this blog which tries to explain it (number 4):
https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/
James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-ayatana-devel/attachments/20180305/5a6a7228/attachment.sig>
More information about the Pkg-ayatana-devel
mailing list