The libbfd dependence issue in Debian

[szlin]

Hi,

The cgreen-runner and cgreen-debug depend on the binutils-dev. However, building Debian packages that depend on the shared libbfd is Not Allowed [1]. Thus, the cgreen received a "serious" bug [2] and will be removed from Debian archive in mid of July if do nothing then.

From my perspective, there are two solutions for this case. Either remove the cgreen-runner and cgreen-debug in Debian package, or link binutils-dev statically and document it with the Built-Using tag in the binary package.

I would like to discuss is there any additional solution to solve this issue?

Thanks for creating this fantastic tool.

[1] https://packages.debian.org/sid/amd64/binutils-dev
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010589

[thoni56]

Thanks for the kind words, and the report!

We certainly do not want to remove cgreen from Debian, that would mean that it would disappear from a whole lot of distros.

In fact the dependency on libbfd was introduced in #255 which looked like a nice addition at the time. It worked fine on Ubuntu, but I stumbled upon a number of issues trying to make that portable, which actually made me think twice about introducing it.

Before that we used nm to get the information, so one option here is to revert that (those) changes and go back to that "uglier", but more portable and "safe", strategy.

[thoni56]

Reverting #255 is unfortunately not as easy as I would wish...

Perhaps we could do a static linking as a stop-gap.

We should make sonoma001@gmail.com aware of this discussion, too.

[szlin]

As you can see in the cgreen package in Debian [1], sonoma001@gmail.com is the package maintainer, and I am the package uploader. I reviewed, sponsored his work, and uploaded the cgreen package into the Debian archive.

Unfortunately, the package maintainer sonoma001@gmail.com is not active in Debian anymore. I tried to reach him several times but in vain since last year.

Thus, I took over his maintenance job to keep this package in as good shape as possible, although I don't use cgreen daily.

The static linking is a possible stopgap, but do you think it is possible to get it done before the mid of July? An alternative method is to upload the new version of cgreen to fix the issue by removing the cgreen-runner and cgreen-debug and adding these back in the next upload.

[1] https://tracker.debian.org/pkg/cgreen

[thoni56]

Aah, it's always problematic when maintainers just fall of the grid. Happy to see you picking up the slack!

The static linking is a possible stopgap, but do you think it is possible to get it done before the mid of July? An alternative method is to upload the new version of cgreen to fix the issue by removing the cgreen-runner and cgreen-debug and adding these back in the next upload.

So you mean we can just remove cgreen-runner and cgreen-debug (although that is just a script that calls cgreen-runner) from the package by tweaking the package rather than at the source repo level? If so, I think that would be the easiest route.

I'm not familiar with the details in the packaging and release process, only a user ;-) Does that mean that for a period cgreen installations (if upgraded) will lose the runner? And once we fix it at the repo-level it will be brought back?

Or will it not even affect users? I'm thinking that it might never reach a live Debian distribution repository if that period is short enough? Or am I completely misunderstanding ;-)

[szlin]

So you mean we can just remove cgreen-runner and cgreen-debug (although that is just a script that calls cgreen-runner) from the package by tweaking the package rather than at the source repo level? If so, I think that would be the easiest route.

Exactly, you got the point.

I'm not familiar with the details in the packaging and release process, only a user ;-) Does that mean that for a period cgreen installations (if upgraded) will lose the runner? And once we fix it at the repo-level it will be brought back?

Indeed.

Or will it not even affect users? I'm thinking that it might never reach a live Debian distribution repository if that period is short enough? Or am I completely misunderstanding ;-)

The impact time length depends on how fast we fix it. The impact scope will be limited at sid or testing archive [1] instead of the official release stable version.

[1] https://wiki.debian.org/DebianTesting

[thoni56]

Or, could we just hold back the 1.5 release and revert to 1.4 which does not have this "bug"?

[szlin]

Since the 1.5 release has been uploaded, the version without libbfd would be the 1.5+ version.

[thoni56]

I have created a new issue, #302, to track progress towards fixing this the right way.

I've managed to revert the changes introduced to use libbfd and committed that to master. I'm aiming at releasing 1.6.0 in a few days, hopefully during the weekend.

On a somewhat related note, I was glad that sonoma001@gmail.com created the packaging, but was a bit surprised with the partioning into cgreen1, libcgreen1, libcgreen1-dev and libcgreen1-doc. As I understand it that is the customary way to handle libraries in Debian. But for Cgreen I think it is not appropriate since you only use it when developing, there is no "app" or "lib" that you need during running of an app.

I think it would be more natural to just have all things in a single package. But maybe that is also "forbidden" ;-)

This is probably another issue, but I thought I'd mention it so I don't forget it. Is that structure within your domain as package maintainer/uploader to do something about at some point?

[thoni56]

Release 1.6.0 released without dependency on libbfd. Should we close this now, or do you @szlin want it open for tracking the Debian packaging?

[szlin]

I have created a new issue, #302, to track progress towards fixing this the right way.

I've managed to revert the changes introduced to use libbfd and committed that to master. I'm aiming at releasing 1.6.0 in a few days, hopefully during the weekend.

On a somewhat related note, I was glad that sonoma001@gmail.com created the packaging, but was a bit surprised with the partioning into cgreen1, libcgreen1, libcgreen1-dev and libcgreen1-doc. As I understand it that is the customary way to handle libraries in Debian. But for Cgreen I think it is not appropriate since you only use it when developing, there is no "app" or "lib" that you need during running of an app.

I think it would be more natural to just have all things in a single package. But maybe that is also "forbidden" ;-)

This is probably another issue, but I thought I'd mention it so I don't forget it. Is that structure within your domain as package maintainer/uploader to do something about at some point?

The related policy is listed here and here

[1] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html
[2] https://www.debian.org/doc/debian-policy/ch-docs.html#additional-documentation

SZ

[szlin]

Release 1.6.0 released without dependency on libbfd. Should we close this now, or do you @szlin want it open for tracking the Debian packaging?

Thanks to @thoni56 . I think the issue could be closed.

I have been swamped with work recently, but I will squeeze the time to upload the new version of the cgreen.

[thoni56]

@szlin Have you had any time to upload a new version yet? It would be nice to show that 1.6.0 is the latest version and everybody should upgrade ;-).

[szlin]

@thoni56 Sorry for the delayed response. I was swamped with work.

Currently, I got two issues in packaging version 1.6.0, as shown below. I want to ask whether you have any ideas or suggestions.

Issue 1. Got timeout issue in waiting doc/cgreen-guide-en.pdf-pdf with option -DCGREEN_WITH_PDF_DOCS:bool=TRUE

...<snip>

[100%] Linking C executable cgreen-runner
cd /build/cgreen-1.6.0/build/tools && /usr/bin/cmake -E cmake_link_script CMakeFiles/cgreen-runner.dir/link.txt --verbose=1
/usr/bin/cc -g -O2 -ffile-prefix-map=/build/cgreen-1.6.0=. -fstack-protector-strong -Wformat -Werror=format-security -std=c99 -Wstrict-prototypes -Wl,-z,relro -rdynamic "CMa
keFiles/cgreen-runner.dir/cgreen-runner.c.o" "CMakeFiles/cgreen-runner.dir/gopt.c.o" "CMakeFiles/cgreen-runner.dir/gopt-errors.c.o" "CMakeFiles/cgreen-runner.dir/runner.c.o"
 "CMakeFiles/cgreen-runner.dir/discoverer.c.o" "CMakeFiles/cgreen-runner.dir/test_item.c.o" "CMakeFiles/cgreen-runner.dir/io.c.o" -o cgreen-runner  ../src/libcgreen.so.1.6.0
 -ldl -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc -lc
[100%] Built target cgreen-runner




Killed
make[4]: *** [doc/CMakeFiles/cgreen-guide-en-pdf.dir/build.make:77: doc/cgreen-guide-en.pdf-pdf] Error 137
make[3]: *** [CMakeFiles/Makefile2:1112: doc/CMakeFiles/cgreen-guide-en-pdf.dir/all] Error 2
make[2]: *** [Makefile:169: all] Error 2
make[1]: *** [Makefile:157: build-it] Error 2
make[1]: Leaving directory '/build/cgreen-1.6.0'
dh_auto_build: error: make -j4 "INSTALL=install --strip-program=true" returned exit code 2

Issue 2: Got test failed in cgreen_runner_tests

After setting option -DCGREEN_WITH_PDF_DOCS:bool=FALSE to skip the Issue 1, I met below issue.

[100%] Built target cgreen_runner_tests
Test project /build/cgreen-1.6.0/build

      Start  1: test_cgreen_c                                                                                                                                      [65/49516]
 1/28 Test  #1: test_cgreen_c ......................................................   Passed    0.06 sec
      Start  2: test_cgreen_c_run_named_test
 2/28 Test  #2: test_cgreen_c_run_named_test .......................................   Passed    0.00 sec
      Start  3: runner_test_cgreen_c
 3/28 Test  #3: runner_test_cgreen_c ...............................................   Passed    0.16 sec
      Start  4: test_cgreen_cpp
 4/28 Test  #4: test_cgreen_cpp ....................................................   Passed    0.08 sec
      Start  5: test_cgreen_cpp_run_named_test
 5/28 Test  #5: test_cgreen_cpp_run_named_test .....................................   Passed    0.00 sec
      Start  6: runner_test_cgreen_cpp
 6/28 Test  #6: runner_test_cgreen_cpp .............................................   Passed    0.20 sec
      Start  7: constraint_messsages
 7/28 Test  #7: constraint_messsages ...............................................***Failed    0.03 sec
      Start  8: custom_constraint_messsages
 8/28 Test  #8: custom_constraint_messsages ........................................***Failed    0.02 sec
      Start  9: mock_messsages
 9/28 Test  #9: mock_messsages .....................................................***Failed    0.02 sec
      Start 10: failure_messages
10/28 Test #10: failure_messages ...................................................***Failed    3.02 sec
      Start 11: assertion_messages
11/28 Test #11: assertion_messages .................................................***Failed    0.02 sec
      Start 12: ignore_messages
12/28 Test #12: ignore_messages ....................................................***Failed    0.02 sec
      Start 13: xml_output
13/28 Test #13: xml_output .........................................................***Failed    0.02 sec
      Start 14: cgreen_runner_unit_tests
14/28 Test #14: cgreen_runner_unit_tests ...........................................   Passed    0.01 sec
      Start 15: cgreen_runner_usage
15/28 Test #15: cgreen_runner_usage ................................................   Passed    0.00 sec
      Start 16: cgreen_runner_quiet
16/28 Test #16: cgreen_runner_quiet ................................................   Passed    0.01 sec
      Start 17: cgreen_runner_verbose
17/28 Test #17: cgreen_runner_verbose ..............................................   Passed    0.01 sec
      Start 18: cgreen_runner_version
18/28 Test #18: cgreen_runner_version ..............................................   Passed    0.00 sec
      Start 19: cgreen_runner_single_explicit_named_test
19/28 Test #19: cgreen_runner_single_explicit_named_test ...........................   Passed    0.00 sec
      Start 20: cgreen_runner_patternmatched_testnames
20/28 Test #20: cgreen_runner_patternmatched_testnames .............................   Passed    0.01 sec

... <snip>

75% tests passed, 7 tests failed out of 28

Total Test time (real) =   3.75 sec

The following tests FAILED:
          7 - constraint_messsages (Failed)
          8 - custom_constraint_messsages (Failed)
          9 - mock_messsages (Failed)
         10 - failure_messages (Failed)
         11 - assertion_messages (Failed)
         12 - ignore_messages (Failed)
         13 - xml_output (Failed)
Errors while running CTest

[thoni56]

I have no clue to the PDF-generation timeout...

Could you post the difference for the tests that failed? These are all "messages test", comparing output to some golden, expected, output, so there might be some issue with how these are cleaned to be environment independent (removing dates, paths, ...).