[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Rejection of Orthanc



Dear Sébastien,

On Mon, Sep 14, 2020 at 05:07:21PM +0200, Sébastien Jodogne wrote:
> >     https://salsa.debian.org/med-team/civetweb
> > 
> > It is by no means a functional packaging yet.
> 
> Thanks so much for your support and for taking this issue into
> consideration.

You are welcome.
 
> > What I'm stumbling about is that the tarball you
> > included in orthanc is way smaller than what uscan gets:
> > 
> > $ ls -l debian/ThirdPartyDownloads/
> > -rw-r--r-- 1 andreas admin 3035855 28. Mai 16:17 civetweb-1.12-fixed.tar.gz
> > 
> > $ ls -l civetweb-1.12.tar.gz civetweb_1.12.orig.tar.gz 
> > lrwxrwxrwx 1 andreas admin       20 14. Sep 15:56 civetweb_1.12.orig.tar.gz -> civetweb-1.12.tar.gz
> > -rw-r--r-- 1 andreas admin 11463079 14. Sep 15:56 civetweb-1.12.tar.gz
> 
> The reason of existence for "civetweb-1.12-fixed.tar.gz" is explained in
> the following source file of Orthanc:
> https://salsa.debian.org/med-team/orthanc/-/blob/a1c4aa701a14668eb0683a94d10a41d4fd8a9efc/OrthancFramework/Resources/CMake/CivetwebConfiguration.cmake#L23
> 
> Basically, the original civetweb archive contains filenames with special
> characters, which causes problems if compiling on older versions of
> Microsoft Windows (this is the case of our continuous integration
> server). This is by no way an issue on GNU/Linux systems, and one can
> directly use the original archives, as can be found on GitHub:
> https://github.com/civetweb/civetweb/releases

OK.  I admit I would consider the idea attracitive to remove may be
66% of unneeded stuff from the upstream tarball if this is sufficient
for our purpose but for the moment we go with the official one.

I forced the build with cmake now but I'm running into

...
[ 30%] Linking C executable civetweb
cd /build/civetweb-1.12/obj-x86_64-linux-gnu/src && /usr/bin/cmake -E cmake_link_script CMakeFiles/civetweb-c-executable.dir/link.txt --verbose=1
/usr/bin/cc -g -O2 -fdebug-prefix-map=/build/civetweb-1.12=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c11 -Wall -Wextra -Wshadow -Wconversion -Wmissing-prototypes -Wparentheses -Wno-padded -Wno-unused-macros -Wno-format-nonliteral -Wno-cast-qual -pedantic-errors -fvisibility=hidden -Wl,-z,relro -rdynamic CMakeFiles/civetweb-c-executable.dir/main.c.o -o civetweb  libcivetweb.a /usr/lib/x86_64-linux-gnu/librt.so -lpthread -ldl 
make[3]: Leaving directory '/build/civetweb-1.12/obj-x86_64-linux-gnu'
[ 30%] Built target civetweb-c-executable
CMake Error at check-unit-test-framework-stamp/check-unit-test-framework-download-None.cmake:49 (message):
  Command failed: 1

   '/usr/bin/cmake' '-Dmake=' '-Dconfig=' '-P' '/build/civetweb-1.12/obj-x86_64-linux-gnu/third_party/src/check-unit-test-framework-stamp/check-unit-test-framework-download-None-impl.cmake'

  See also

    /build/civetweb-1.12/obj-x86_64-linux-gnu/third_party/src/check-unit-test-framework-stamp/check-unit-test-framework-download-*.log


make[3]: *** [unittest/CMakeFiles/check-unit-test-framework.dir/build.make:113: third_party/src/check-unit-test-framework-stamp/check-unit-test-framework-download] Error 1
make[3]: Leaving directory '/build/civetweb-1.12/obj-x86_64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:1019: unittest/CMakeFiles/check-unit-test-framework.dir/all] Error 2
make[2]: Leaving directory '/build/civetweb-1.12/obj-x86_64-linux-gnu'
make[1]: *** [Makefile:185: all] Error 2


It somehow smells like an attempt to access some remote location.  Given
that you have somehow build this before in a restricted chroot is there
any trick I can prevent this? 

Kind regards

       Andreas.

-- 
http://fam-tille.de


Reply to: