[Debian-med-packaging] Bug#839320: Would you upload with disabled test?

[Sascha Steinbiss]

Hi Andreas,

> since there are no responses so far I wonder how to proceed with the
> package. 

Yes, that's one of the bugs that has been on my list for a while as well...

> I need to admit I get a different error when trying to build
> the current state of gubbins packaging Git:
> 
> gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2 -I../tests -pthread -g -O2 -fdebug-prefix-map=/build/gubbins-2.1.0=. -fstack-protector-strong -Wformat -Werror=format-security -c -o ../tests/run_all_tests-run_all_tests.o `test -f '../tests/run_all_tests.c' || echo './'`../tests/run_all_tests.c
> /bin/bash ../libtool  --tag=CC   --mode=link gcc -I../tests -pthread -g -O2 -fdebug-prefix-map=/build/gubbins-2.1.0=. -fstack-protector-strong -Wformat -Werror=format-security  -Wl,-z,relro -Wl,-z,now -o run_all_tests ../tests/run_all_tests-check_branch_sequences.o ../tests/run_all_tests-check_gubbins.o ../tests/run_all_tests-check_parse_phylip.o ../tests/run_all_tests-check_snp_searching.o ../tests/run_all_tests-check_snp_sites.o ../tests/run_all_tests-check_vcf_parsing.o ../tests/run_all_tests-helper_methods.o ../tests/run_all_tests-run_all_tests.o -lcheck libgubbins.la -lz -lm  -lrt -lsubunit 
> libtool: link: gcc -I../tests -pthread -g -O2 -fdebug-prefix-map=/build/gubbins-2.1.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/run_all_tests ../tests/run_all_tests-check_branch_sequences.o ../tests/run_all_tests-check_gubbins.o ../tests/run_all_tests-check_parse_phylip.o ../tests/run_all_tests-check_snp_searching.o ../tests/run_all_tests-check_snp_sites.o ../tests/run_all_tests-check_vcf_parsing.o ../tests/run_all_tests-helper_methods.o ../tests/run_all_tests-run_all_tests.o  -lcheck ./.libs/libgubbins.so -lz -lm -lrt -lsubunit -pthread
> /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcheck.a(check.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
> /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcheck.a(check_error.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
> /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcheck.a(check_msg.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
> /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcheck.a(check_pack.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
> /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcheck.a(check_run.o): relocation R_X86_64_32 against undefined symbol `error_jmp_buffer' can not be used when making a shared object; recompile with -fPIC
> /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcheck.a(check_str.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
> /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcheck.a(check_log.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
> /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcheck.a(check_print.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: error: ld returned 1 exit status
> Makefile:742: recipe for target 'run_all_tests' failed
> make[4]: *** [run_all_tests] Error 1

This looks like a completely different issue altogether I have never
seen, for me it was always failing tests.

I can take a look at gubbins later and try to figure them out. I had a
first idea of how to address the one reported in this bug here, but I
couldn't reproduce it, instead hitting a different test failure
(consistently) which upstream said I could ignore.

I can do the following:

- first try to reproduce your issue and address it
- disable the test that upstream says shouldn't be a dealbreaker
- try to reproduce and work on the test failure that this bug is
  concerned about

However, my weekend is quite full already, so if I hit a wall with one
of them, I'm not sure of how much time I can dedicate. Any help would be
appreciated!

Cheers
Sascha