Comments (14)
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.
from cgreen.
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.
from cgreen.
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 [email protected] aware of this discussion, too.
from cgreen.
As you can see in the cgreen package in Debian [1], [email protected] 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 [email protected] 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
from cgreen.
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 ;-)
from cgreen.
So you mean we can just remove
cgreen-runner
andcgreen-debug
(although that is just a script that callscgreen-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
from cgreen.
Or, could we just hold back the 1.5 release and revert to 1.4 which does not have this "bug"?
from cgreen.
Since the 1.5 release has been uploaded, the version without libbfd would be the 1.5+ version.
from cgreen.
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 [email protected] 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?
from cgreen.
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?
from cgreen.
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 [email protected] created the packaging, but was a bit surprised with the partioning into
cgreen1
,libcgreen1
,libcgreen1-dev
andlibcgreen1-doc
. As I understand it that is the customary way to handle libraries in Debian. But forCgreen
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
from cgreen.
@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 ;-).
from cgreen.
@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
from cgreen.
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, ...).
from cgreen.
Related Issues (20)
- with_side_effects() should provide ability to inspect arguments passed to a mocked function HOT 2
- Ability to return captured values by mocks. HOT 2
- CMake warning: Could NOT find LibBfd HOT 4
- Never seem to get a cgreen-runner executable HOT 5
- Test helper scripts should use sh instead of bash for maximum portability
- Revert dependency on libbfd HOT 1
- Make learning mocks print immediately HOT 4
- Add documentation on compile time configuration
- create_xml_reporter() crashes on MSYS platform HOT 2
- CUTE reporter final report statistics zero
- CUTE reporter per test time invalid HOT 2
- Option for unbuffered stdout for cgreen-runner HOT 1
- cannot pass unit test in i386 HOT 8
- Test signal HOT 1
- [1.6.2] Version marked as 1.6.1 in the Cmake file HOT 1
- "cgreen-runner --quiet" results in "unrecognised option" HOT 3
- "cgreen-runner --verbose" is not HOT 2
- Default text reporter does not show names of failed tests HOT 2
- cannot pass unit test in s390x HOT 31
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cgreen.