Control: tags -1 -moreinfo Hi Phil,
Thank you for the prompt review, it's much appreciated! > 3. Licenses [4]: Issue > > The 'Files: *' and 'Files: debian/*' section would normally share the same > license. Is there a particular reason why this is not the case with this > package? This was originally packaged as part of my employment at Clevon AS. The original is located here: https://gitlab.com/clevon/clebian/boost-ext-ut We had the policy to licence Debian packaging code written wholly by us as 0BSD to make it as easy as possible for it to hopefully someday make it upstream to Debian itself (i.e. now). Since it was originally 0BSD and I prefer it myself I kept it as the licence for the Debian packaging code. Though as I understand MIT is compatible (and slightly more opposing) so I could change to that and there probably wouldn't be any legal concerns. Let me know if I should do this or it's actually fine as-is given the above explanation. If there's a Debian policy in this regard then a reference would be useful. For packaging work of my own in the future I was also planning to use 0BSD for `debian/*` but if that's frowned upon or would hinder it making it to the archive then I would keep that in mind. > A. Package tests, results? > > All tests passed (6 asserts in 4 tests) > 2 tests skipped > make[3] : on quitte le répertoire > « /tmp/reprotest.g20NQj/const_build_path/const_build_path/obj-x86_64-linux- > gnu » > [ 99%] Built target ft > [100%] Linking CXX executable ut_test > cd /tmp/reprotest.g20NQj/const_build_path/const_build_path/obj-x86_64-linux- > gnu/test/ut && /usr/bin/cmake -E cmake_link_script > CMakeFiles/ut_test.dir/link.txt --verbose=1 > /usr/bin/c++ -g -O2 -ffile-prefix- > map=/tmp/reprotest.g20NQj/const_build_path/const_build_path=. -fstack- > protector-strong -fstack-clash-protection -Wformat -Werror=format-security - > fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,--dependency- > file=CMakeFiles/ut_test.dir/link.d CMakeFiles/ut_test.dir/ut.cpp.o -o ut_test > cd /tmp/reprotest.g20NQj/const_build_path/const_build_path/obj-x86_64-linux- > gnu/test/ut && ./ut_test > > =============================================================================== > tests: 13 | 7 failed > asserts: 9 | 2 passed | 7 failed These indeed look suspicious but part of testing a testing library is to make sure that test failures work and they get printed correctly! I manually verified that the tests do actually run through successfully and match the upstream's CI output. All the best Raul
