Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

testshell_markdown_tutorial_crypto fails if libgpgme is not found #2668

Open
kodebach opened this issue May 4, 2019 · 10 comments

Comments

Projects
None yet
3 participants
@kodebach
Copy link
Contributor

commented May 4, 2019

Steps to Reproduce the Problem

Do not have libgpgme installed and run:

make run_all

Expected Result

All tests complete sucessfully.

Actual Result

The test testshell_markdown_tutorial_crypto fails, because the tool gen-gpg-testkey is not available.

Suggested solution

Disable the testshell_markdown_tutorial_crypto, if gen-gpg-testkey is not generated. If this isn't possible, remove/disable the test entirely.


@petermax2 I assigned this to you, because you added the gen-gpg-testkey tool

@petermax2

This comment has been minimized.

Copy link
Member

commented May 5, 2019

Did you try to do a full re-build? I can not reproduce the problem. Only testshell_markdown_path fails (but this test usually fails in my docker installation).

Starting with the master branch (HEAD at 8c19811 ) I ran:

root@3f4532595f7c:/libelektra# mkdir build && cd build
root@3f4532595f7c:/libelektra/build# cmake -DENABLE_COVERAGE=OFF -DENABLE_OPTIMIZATIONS=OFF -DENABLE_DEBUG=ON -DENABLE_LOGGER=ON -DBUILD_STATIC=OFF -DINSTALL_SYSTEM_FILES=OFF -DPLUGINS="ALL" -DTOOLS="ALL" ..
# ... <output omitted>
-- Include Tool gen-gpg-testkey
-- Exclude tool gen-gpg-testkey because libgpgme not found
# ...
root@3f4532595f7c:/libelektra/build# make -j6
# ... 
root@3f4532595f7c:/libelektra/build# make run_all 
# ...
99% tests passed, 1 tests failed out of 224

Label Time Summary:
kdbtests    = 103.32 sec*proc (99 tests)
memleak     =  94.76 sec*proc (92 tests)

Total Test time (real) = 104.08 sec

The following tests FAILED:
	112 - testshell_markdown_path (Failed)
Errors while running CTest
tests/CMakeFiles/run_all.dir/build.make:57: recipe for target 'tests/CMakeFiles/run_all' failed
make[3]: *** [tests/CMakeFiles/run_all] Error 8
CMakeFiles/Makefile2:21466: recipe for target 'tests/CMakeFiles/run_all.dir/all' failed
make[2]: *** [tests/CMakeFiles/run_all.dir/all] Error 2
CMakeFiles/Makefile2:21473: recipe for target 'tests/CMakeFiles/run_all.dir/rule' failed
make[1]: *** [tests/CMakeFiles/run_all.dir/rule] Error 2
Makefile:5761: recipe for target 'run_all' failed
make: *** [run_all] Error 2
root@3f4532595f7c:/libelektra/build# 

Please provide more details on how to reproduce the problem!

@markus2330 markus2330 added build and removed bug urgent labels May 5, 2019

@markus2330

This comment has been minimized.

Copy link
Contributor

commented May 5, 2019

Thank you for reporting the problem and the quick reply!

I was able to reproduce it but the problem disappeared after completely removing the build directory. So I assume it is only a problem of a CMake cache inconsistency.

Please reopen if it appears again.

@markus2330 markus2330 closed this May 5, 2019

@kodebach

This comment has been minimized.

Copy link
Contributor Author

commented May 5, 2019

I created a new build directory and re-created the same CMake setup. I still get the error.

Steps to reproduce

mkdir build2 && cd build2
cmake .. -DCMAKE_INSTALL_PREFIX:PATH=install -DCMAKE_BUILD_TYPE:STRING=Debug -DINSTALL_DOCUMENTATION:BOOL=OFF -DBUILD_DOCUMENTATION:BOOL=OFF -DINSTALL_SYSTEM_FILES:BOOL=OFF -DKDB_DB_SPEC:PATH=~/.config/kdb/build2/spec -DKDB_DB_SYSTEM:PATH=~/.config/kdb/build2/system -DKDB_DB_USER:PATH=.config/kdb/build2/user -DENABLE_DEBUG:BOOL=OFF
make -j 8
make run_all

I used my highlevel_codegen branch, if that makes any difference.

If you also want some system information:

  • Fedora 30 (Linux 5.0.9-301.fc30.x86_64 #1 SMP Tue Apr 23 23:57:35 UTC 2019)
  • That includes GCC 9 (gcc (GCC) 9.0.1 20190312 (Red Hat 9.0.1-0.10))
  • make (GNU Make 4.2.1) and ninja (1.9.0) both produce the error.
  • cmake version 3.14.3

EDIT: it shouldn't be relevant here, but when using ninja the CMAKE_INSTALL_PREFIX must be an absolute path.

@kodebach kodebach reopened this May 5, 2019

@markus2330 markus2330 added the urgent label May 5, 2019

@markus2330

This comment has been minimized.

Copy link
Contributor

commented May 5, 2019

I can reproduce with above CMake command. ctest -V -R testshell_markdown_tutorial_crypto is enough to run the test.

I think the problem here is that the gen-gpg-testkey tool is never removed because CMake did not try to add it and thus it is not in the REMOVED_TOOLS variable.

Ideally, we should rewrite the handling of TOOLS, so that it behaves like PLUGINS and BINDINGS. Then such a bug would not be possible.

@kodebach you can use -DTOOLS=ALL or -DTOOLS=kdb;gen-gpg-testkey as workaround.

@petermax2 as quickfix, please add gen-gpg-testkey to the default tools, otherwise this problem appears for everyone not passing above mentioned -DTOOLS. (I added the urgent label for this.)

@markus2330 markus2330 added this to the 0.8.27 milestone May 5, 2019

petermax2 added a commit to petermax2/libelektra that referenced this issue May 5, 2019

@petermax2

This comment has been minimized.

Copy link
Member

commented May 5, 2019

Please verify that #2672 quick-fixes the problem.

@markus2330 markus2330 removed the urgent label May 5, 2019

@markus2330

This comment has been minimized.

Copy link
Contributor

commented May 5, 2019

@kodebach please check if master now again works for you

@kodebach

This comment has been minimized.

Copy link
Contributor Author

commented May 5, 2019

#2672 fixes the problem (removing the build directory is still required)

@markus2330

This comment has been minimized.

Copy link
Contributor

commented May 5, 2019

Thank you for looking into it!

@petermax2 are you interested in fixing the TOOLS problem? @waht fixed BINDINGS some time ago. Hopefully the infrastructure from BINDINGS is at least partly reusable for TOOLS.

@petermax2

This comment has been minimized.

Copy link
Member

commented May 5, 2019

are you interested in fixing the TOOLS problem?

OK I can have a look at the problem. But it will take some time.

@markus2330

This comment has been minimized.

Copy link
Contributor

commented May 6, 2019

Thank you very much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.