Re: Rejection of Orthanc
Hello,
>> One could also consider building the C++ library by setting
>> "-CIVETWEB_ENABLE_CXX=ON", which produces the "libcivetweb-cpp.(a|so)"
>> C++ library together with the "libcivetweb.(a|so)" C library. Note
>> however that the C++ library is not used by Orthanc.
>> [...]
>
> I think we should do the bare minimum for this package to fulfill your
> requirement for orthanc. In case someone might ask for further features
> later we can add those (and at least will learn that our packaging
> effort had some additional use ;-) ).
Fine, I also like the lean way of things ;-)
> Please check my packaging *thoroughly*. I'm not sure whether we should
> rename the lib package according to
>
> libcivetweb1: package-name-doesnt-match-sonames libcivetweb1.11.0
>
> No idea how many parallel installations of this lib with different
> versions is to be expected.
That's indeed most probably an overkill, at least as long as Orthanc is
the only user of civetweb in Debian.
I have run FOSSology, which allowed me to identify some missing
information in "d/copyright". I took the liberty of fixing this with the
following commit:
https://salsa.debian.org/med-team/civetweb/-/commit/3812231f6d3fa59827fa3c96c0409be4525bb8e3
Regarding the size of the source package, the file
"resources/civetweb.psd" is a large image that weights 9MB on its own,
and that is not used by the package. Maybe one could consider removing it?
> Otherwise the package should be OKis and I issued an ITP. I'll wait
> for your final confirmation before uploading.
I hereby confirm that I'm able to build the "civetweb" package from
source, and that I'm able to build the "orthanc" package by applying the
attached patch. I feel like the package is ready for upload.
As soon as the "civetweb" package is accepted as NEW, I'll update the
"orthanc" to take advantage of it. Then, we'll be able to re-submit the
adaptations to create the "Orthanc framework" shared library, which will
ultimately allow us to re-submit the rejected "orthanc-gdcm" package
(Orthanc cannot take advantage of GDCM as long as the latter is not
available). I hope this process won't take too long.
> Exactly this was my intention! ;-) Nice to hear that it seems to
> work.
:-)
Sébastien-
diff -urEb orthanc_1.7.3+dfsg-2.orig/debian/control orthanc_1.7.3+dfsg-2/debian/control
--- orthanc_1.7.3+dfsg-2.orig/debian/control 2020-08-27 12:31:03.000000000 +0200
+++ orthanc_1.7.3+dfsg-2/debian/control 2020-09-15 12:16:26.643754834 +0200
@@ -9,6 +9,7 @@
doxygen,
libboost-all-dev,
libcharls-dev,
+ libcivetweb-dev,
libcurl4-openssl-dev | libcurl4-dev,
libdcmtk-dev,
libgtest-dev,
diff -urEb orthanc_1.7.3+dfsg-2.orig/debian/rules orthanc_1.7.3+dfsg-2/debian/rules
--- orthanc_1.7.3+dfsg-2.orig/debian/rules 2020-08-27 12:31:03.000000000 +0200
+++ orthanc_1.7.3+dfsg-2/debian/rules 2020-09-15 12:25:35.155767849 +0200
@@ -23,8 +23,6 @@
-DCMAKE_SKIP_RPATH:BOOL=ON \
-DSTATIC_BUILD:BOOL=OFF \
-DSTANDALONE_BUILD:BOOL=ON \
- -DENABLE_CIVETWEB:BOOL=ON \
- -DUSE_SYSTEM_CIVETWEB:BOOL=OFF \
-DUSE_GOOGLE_TEST_DEBIAN_PACKAGE:BOOL=ON \
-DDCMTK_LIBRARIES:STRING=dcmjpls \
-DUNIT_TESTS_WITH_HTTP_CONNEXIONS:BOOL=OFF \
@@ -82,7 +80,7 @@
localedef -f UTF-8 -i en_US $(DESTDIR)/locale/en_US.UTF-8/
( cd BuildFramework && LOCPATH=$(DESTDIR)/locale/ LD_LIBRARY_PATH=. ./UnitTests-prefix/src/UnitTests-build/UnitTests )
- ( cd BuildServer && LOCPATH=$(DESTDIR)/locale/ ./UnitTests )
+ ( cd BuildServer && LOCPATH=$(DESTDIR)/locale/ ./UnitTests --gtest_filter=-Version.CivetwebCompression )
endif
override_dh_clean:
Reply to: