Hi mentors, I've fixed the issues you pointed out. New packages are rebuilt locally, and uploaded to mentors. https://mentors.debian.net/package/caffe
Debomatic-amd64 is still building this updated package: http://debomatic-amd64.debian.net/distribution#experimental/caffe/1.0.0~rc3-1/buildlog Following is my comments to the remarks On Mon, 2016-05-02 at 14:13 +0100, Ghislain Vaillant wrote: > - d/changelog: should only contain the entry closing the initial release > bug. Removed the line not necessary. > - d/control: Build-Depends on libboost-all-dev. Do you really need to > pull the complete Boost stack for the build? Quick look I have had: > > "find_package(Boost 1.46 REQUIRED COMPONENTS system thread filesystem)" > > So you should only require libboost-{filesystem,system,thread}-dev. Depends on libboost-{filesystem,system,thread,python}-dev, instead of libboost-all-dev. > - d/control: Build-Depends on nvidia-cuda-toolkit which automatically > pulls nvidia-cuda-dev, so no need to specify nvidia-cuda-dev. Removed nvidia-cuda-dev as build-deps. > - d/*.install.in: no multi-arch install paths? why? I have no plan to make multiarch support for this package, because that makes no sense. In production environment Caffe is a computational intensive and memory-consuming application, and I believe no user will need multi-arch support for this package. Made no change related to multi-arch. > - d/libcaffe-dev.install.in: what is the purpose of the additional > libproto.a binary? There is a protobuf definition file under Caffe's source, src/caffe/proto/caffe.proto which is a very essential file as it defined caffe's "protocol". And libproto.a is the compiled binary version of that protocol. Besides, the Official "install" target installs that static lib, so it is recommended by upstream to have such a lib. Hence it goes into the -dev packages. > - d/rules + d/*.in: IMO, sounds like a very convoluted way of running 2 > separate builds (one for CPU one for CUDA) and moving the files in the > right places. Another possibility could have been to have caffe-cpu and > caffe-cuda as separate source packages, one in main and one in contrib. > For each of them, the packaging would have been much more simple to > maintain I suppose. I've ever considered split them up into 2 source packages, but building 2 set of binary from 1 source is my initial intent. I may split them in the future. > - lintian (from d-o-m): > > I: caffe source: quilt-patch-missing-description fix-spelling-error > > Might want to fix this if not done already. Also please mention whether > the patch has been forwarded upstream. Added header to this patch. > I: libcaffe-cpu-dev: unstripped-static-library > usr/lib/caffe/libproto.a(caffe.pb.cc.o) > > Again not sure what this libproto.a is doing here. As explained above, this file may be not useless. > I: libcaffe-cpu1: hardening-no-fortify-functions > usr/lib/libcaffe.so.1.0.0-rc3 > > Are you using hardening in d/rules? If so, then the injected flags > might be shadowed by the build system. Consider fixing this. I've tried to inject these flags according to wiki:Hardening ``` # Hardening Caffe according to https://wiki.debian.org/Hardening DPKG_EXPORT_BUILDFLAGS=1 export DEB_BUILD_MAINT_OPTIONS = hardening=+all export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed include /usr/share/dpkg/buildflags.mk CFLAGS+=$(CPPFLAGS) CXXFLAGS+=$(CPPFLAGS) ``` But hardening-fortify-source-function is still unfixed. ``` $ hardening-check /usr/bin/caffe /usr/bin/caffe: Position Independent Executable: yes Stack protected: yes Fortify Source functions: no, only unprotected functions found! Read-only relocations: yes Immediate binding: yes ``` I have no idea about it... Thank you for reviewing! > Good luck, > Ghis
