Hello Andreas,
Just to extend the previous email.
I created another fresh environment and even used pbuilder and the
results are the same, that the build succeeds.
Additionally, I have attempted to disable RPATH during the build but the
error and RPATH still exist, so I am not too sure. If a solution isn't
reached, I will write to debian mentors like you have mentioned. I'm not
sure if I can just use dpkg-shlibdeps -l<lib> for each executable but
this seems like a fair bit of pain to do for all the libraries and
executables that exist and are compiled.
Many thanks for looking into this & regards,
Shayan Doust
On 22/08/2019 15:03, Shayan Doust wrote:
> Hello Andreas,
>
>> besides my hints below I now tried to build the package (please pull -
>> I've fixed pristine-tar to provide the now renamed source tarball).
>
> Thanks. I've repackaged and updated a few times so I may have missed
> something out. I will also take your previous email into account.
>
>> Unfortunately I'm running into:
>
> I cannot seem to be able to replicate this even though I have used a
> chroot clean environment a few times. Maybe I'm setting some variable
> without even realising.
>
>> list(APPEND FAST_INCLUDE_DIRS /usr/include/eigen3/)
>
> I've just set that although the build still succeeds so I am hoping this
> just reinforces the means of a more successful build.
>
>> FAST_EXTERNAL_INSTALL_DIR=/usr
>
> May not be a good idea as it seems like this is used as the installation
> directory for when FAST used to download and compile the libraries it
> needed.
>
> Regards,
> Shayan Doust
>
> On 22/08/2019 09:44, Andreas Tille wrote:
>> Hi again,
>>
>> besides my hints below I now tried to build the package (please pull -
>> I've fixed pristine-tar to provide the now renamed source tarball).
>> Unfortunately I'm running into:
>>
>> ...
>> [ 3%] Building CXX object CMakeFiles/FAST-STATIC.dir/source/FAST/Algorithms/AddTransformation/SetTransformation.cpp.o
>> /usr/bin/c++ -DFAST_CONTINUOUS_INTEGRATION -DFAST_MODULE_VISUALIZATION -I"/build/fast-3.0.0~rc3+ds/source" -I"/build/fast-3.0.0~rc3+ds/obj-x86_64-linux-gnu" -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/ x86_64-linux-gnu/qt5/QtWidgets -I/usr/include/x86_64-linux-gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -I/usr/include/x86_64-linux-gnu/qt5/ QtOpenGL -I/usr/include/x86_64-linux-gnu/qt5/QtMultimedia -I/usr/include/x86_64-linux-gnu/qt5/QtNetwork -I/usr/include/x86_64-linux-gnu/qt5/QtMultimediaWidgets -I/usr/include/openslide -I/include -g -O2 - fdebug-prefix-map=/build/fast-3.0.0~rc3+ds=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wno-ignored-attributes -fopenmp -fPIC -std=gnu++14 -o CMakeFiles/FAST- STATIC.dir/source/FAST/Algorithms/AirwaySegmentation/AirwaySegmentation.cpp.o -c "/build/fast-3.0.0~rc3+ds/source/FAST/Algorithms/AirwaySegmentation/AirwaySegmentation.cpp"
>> /usr/bin/c++ -DFAST_CONTINUOUS_INTEGRATION -DFAST_MODULE_VISUALIZATION -I"/build/fast-3.0.0~rc3+ds/source" -I"/build/fast-3.0.0~rc3+ds/obj-x86_64-linux-gnu" -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/ x86_64-linux-gnu/qt5/QtWidgets -I/usr/include/x86_64-linux-gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -I/usr/include/x86_64-linux-gnu/qt5/ QtOpenGL -I/usr/include/x86_64-linux-gnu/qt5/QtMultimedia -I/usr/include/x86_64-linux-gnu/qt5/QtNetwork -I/usr/include/x86_64-linux-gnu/qt5/QtMultimediaWidgets -I/usr/include/openslide -I/include -g -O2 - fdebug-prefix-map=/build/fast-3.0.0~rc3+ds=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wno-ignored-attributes -fopenmp -fPIC -std=gnu++14 -o CMakeFiles/FAST- STATIC.dir/source/FAST/Algorithms/AddTransformation/AddTransformation.cpp.o -c "/build/fast-3.0.0~rc3+ds/source/FAST/Algorithms/AddTransformation/AddTransformation.cpp"
>> /usr/bin/c++ -DFAST_CONTINUOUS_INTEGRATION -DFAST_MODULE_VISUALIZATION -I"/build/fast-3.0.0~rc3+ds/source" -I"/build/fast-3.0.0~rc3+ds/obj-x86_64-linux-gnu" -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/ x86_64-linux-gnu/qt5/QtWidgets -I/usr/include/x86_64-linux-gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -I/usr/include/x86_64-linux-gnu/qt5/ QtOpenGL -I/usr/include/x86_64-linux-gnu/qt5/QtMultimedia -I/usr/include/x86_64-linux-gnu/qt5/QtNetwork -I/usr/include/x86_64-linux-gnu/qt5/QtMultimediaWidgets -I/usr/include/openslide -I/include -g -O2 - fdebug-prefix-map=/build/fast-3.0.0~rc3+ds=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wno-ignored-attributes -fopenmp -fPIC -std=gnu++14 -o CMakeFiles/FAST- STATIC.dir/source/FAST/Algorithms/AddTransformation/SetTransformation.cpp.o -c "/build/fast-3.0.0~rc3+ds/source/FAST/Algorithms/AddTransformation/SetTransformation.cpp"
>> In file included from /build/fast-3.0.0~rc3+ds/source/FAST/Utility.hpp:4,
>> from /build/fast-3.0.0~rc3+ds/source/FAST/ProcessObject.hpp:3,
>> from /build/fast-3.0.0~rc3+ds/source/FAST/Algorithms/AddTransformation/AddTransformation.hpp:4,
>> from /build/fast-3.0.0~rc3+ds/source/FAST/Algorithms/AddTransformation/AddTransformation.cpp:1:
>> /build/fast-3.0.0~rc3+ds/source/FAST/Data/DataTypes.hpp:11:10: fatal error: Eigen/Dense: No such file or directory
>> 11 | #include <Eigen/Dense>
>> | ^~~~~~~~~~~~~
>> compilation terminated.
>> make[3]: *** [CMakeFiles/FAST-STATIC.dir/build.make:94: CMakeFiles/FAST-STATIC.dir/source/FAST/Algorithms/AddTransformation/AddTransformation.cpp.o] Error 1
>>
>>
>> when building in a pbuilder environment. Since libeigen3-dev which provides
>> this header is in Build-Depends I wonder whether the include PATH needs to
>> be adjusted. Looking at other places of the build log:
>>
>>
>> [ 4%] Building CXX object CMakeFiles/FAST.dir/source/FAST/Algorithms/AirwaySegmentation/AirwaySegmentation.cpp.o
>> /usr/bin/c++ -DFAST_CONTINUOUS_INTEGRATION -DFAST_EXPORTS -DFAST_MODULE_VISUALIZATION -DQT_CORE_LIB -DQT_GUI_LIB -DQT_MULTIMEDIAWIDGETS_LIB -DQT_MULTIMEDIA_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB - DQT_SERIALPORT_LIB -DQT_WIDGETS_LIB -I"/build/fast-3.0.0~rc3+ds/source" -I"/build/fast-3.0.0~rc3+ds/obj-x86_64-linux-gnu" -I/usr/include/openslide -I/include -isystem /usr/include/x86_64-linux-gnu/qt5 - isystem /usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -isystem /usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ - isystem /usr/include/x86_64-linux-gnu/qt5/QtOpenGL -isystem /usr/include/x86_64-linux-gnu/qt5/QtMultimedia -isystem /usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem /usr/include/x86_64-linux-gnu/qt5/ QtMultimediaWidgets -isystem /usr/include/x86_64-linux-gnu/qt5/QtSerialPort -isystem /usr/include/eigen3 -g -O2 -fdebug-prefix-map=/build/fast-3.0.0~rc3+ds=. -fstack-protector-strong -Wformat -Werror=format- security -Wdate-time -D_FORTIFY_SOURCE=2 -Wno-ignored-attributes -fopenmp -fPIC -fPIC -fPIC -std=gnu++14 -o CMakeFiles/FAST.dir/source/FAST/Algorithms/AddTransformation/SetTransformation.cpp.o -c "/build/ fast-3.0.0~rc3+ds/source/FAST/Algorithms/AddTransformation/SetTransformation.cpp"
>>
>>
>> I see " -isystem /usr/include/eigen3 " - so may be this needs to be
>> sneaked in at some place where it is missing? In your patches I see
>>
>> $ grep eigen3 debian/patches/*
>> debian/patches/prevent_cmake_downloading.patch:-list(APPEND FAST_INCLUDE_DIRS ${FAST_EXTERNAL_INSTALL_DIR}/include/eigen3/)
>> debian/patches/prevent_cmake_downloading.patch:+#list(APPEND FAST_INCLUDE_DIRS ${FAST_EXTERNAL_INSTALL_DIR}/include/eigen3/)
>>
>> which makes me wondering whether your attempt to prevent downloads
>> went to far. May be setting
>>
>> FAST_EXTERNAL_INSTALL_DIR=/usr
>>
>> (surely with the proper CMake syntax which I do not know by heart)
>> might do the trick and you can leave this. Our you simply use
>>
>> list(APPEND FAST_INCLUDE_DIRS /usr/include/eigen3/)
>>
>> At least this looks like a promising approach to me.
>>
>> Kind regards
>>
>> Andreas.
>>
>> On Thu, Aug 22, 2019 at 06:34:24AM +0200, Andreas Tille wrote:
>>> Hi Shayan,
>>>
>>> On Wed, Aug 21, 2019 at 11:12:55PM +0100, Shayan Doust wrote:
>>>> Hello Andreas,
>>>>
>>>> For multiarch, I decided to move the shared object and static lib into
>>>> directory defined by DEB_HOST_MULTIARCH.
>>>
>>> I think this is correct and I did not observed any problems with this in
>>> the past.
>>>
>>>> As a result, during the dpkg_shlibdeps invoke when dh_shlibdeps is
>>>> reached in the package build process, I see a lot of errors. A snippet
>>>> is denoted as below:
>>>>
>>>> dpkg-shlibdeps: error: cannot continue due to the errors listed above
>>>> Note: libraries are not searched in other binary packages that do not
>>>> have any shlibs or symbols file.
>>>> To help dpkg-shlibdeps find private libraries, you might need to use -l.
>>>> dh_shlibdeps: dpkg-shlibdeps -Tdebian/fast.substvars
>>>> debian/fast/usr/lib/fast/OpenIGTLinkClient
>>>> debian/fast/usr/lib/fast/OpenIGTLinkServer returned exit code 2
>>>> dpkg-shlibdeps: error: cannot find library libFAST.so.0 needed by
>>>> debian/libfast-examples/usr/lib/fast/streamImagesFromDisk (ELF format:
>>>> 'elf64-x86-64' abi: '0201003e00000000'; RPATH: '/usr/lib/fast/../lib')
>>>>
>>>> Is the RPATH to blame?
>>>
>>> I did not yet managed to do a test build - hope to do this today.
>>> In any case your libs should not set RPATH:
>>>
>>> https://wiki.debian.org/RpathIssue
>>>
>>>> I'm not too sure what I should do and I would
>>>> rather not trial and error with how long each build takes. The latest
>>>> commit reflects the state of my current workspace. Maybe I should have
>>>> looked into using include(GNUInstallDirs).
>>>
>>> I admit I do not have any advise at hand for the moment before I tried.
>>> If I do not come up with any clue later asking on
>>> debian-mentors@lists.debian.org is a promising approach.
>>>
>>>> Best Regards,
>>>> Shayan Doust
>>>
>>> Kind regards
>>>
>>> Andreas.
>>>
>>>> On 20/08/2019 20:42, Shayan Doust wrote:
>>>>> Hello Andreas,
>>>>>
>>>>>> Yes. I'll have a look and may be I'll turn this into a d-shlibs call.
>>>>>> Thank you have an example.
>>>>>
>>>>> Sounds good. Although for my attempt I used install command to assign
>>>>> 755 permission to *.so when moved.
>>>>>
>>>>> I've sometimes found that maintainer consistency is fairly poor.
>>>>> Although there is a policy in place it seems like sometimes maintainers
>>>>> go their own ways which is fairly confusing, especially if that
>>>>> particular thing is not well documented.
>>>>>
>>>>> I will also push a couple more patches shortly with regards to the
>>>>> opencl header issue once this builds. That, and the ~rc version mangle.
>>>>>
>>>>>> May be we finalise this package in the next days. I'll have a look and
>>>>>> might finish it if you don't mind.
>>>>>
>>>>> I'll still be as active as I am for the next couple of weeks, but it's
>>>>> just an advanced heads up as there is uncertainty with the whole moving
>>>>> out factor.
>>>>>
>>>>> Additionally, I am wondering how many packages to maintain before it
>>>>> gets "too much". Although I guess the hard work is just the initial
>>>>> packaging attempt. Apart from the whole week I was on holiday, I think
>>>>> this package just took its time in terms of its size but also
>>>>> understanding (from scratch) how libraries should be installed, and the
>>>>> 1 hr 30 mins of build times :).
>>>>>
>>>>> Best Regards,
>>>>> Shayan Doust
>>>>>
>>>>> On 20/08/2019 20:21, Andreas Tille wrote:
>>>>>> Hi Shayan,
>>>>>>
>>>>>> On Tue, Aug 20, 2019 at 07:14:33PM +0100, Shayan Doust wrote:
>>>>>>>
>>>>>>> Welcome back :).
>>>>>>
>>>>>> :-)
>>>>>>
>>>>>>> I've probably checked gatb-core at least a dozen times before you sent
>>>>>>> this to me. I just never checked debian/patch as I didn't think this was
>>>>>>> some cmake thing :). Talked to upstream and they will take care of
>>>>>>> soversion within the next release and package update, but for now I just
>>>>>>> added this as a patch.
>>>>>>
>>>>>> Cool!
>>>>>>
>>>>>>>> ...In this case the dynamic lib is added but you get the idea how to
>>>>>>>> add a static one from this patch...
>>>>>>>
>>>>>>> Thank you. This is done.
>>>>>>>
>>>>>>> If you have time, do you mind just checking fast package for me? There
>>>>>>> are still a few things I need to do with libfast-dev as I haven't done
>>>>>>> this yet. Where should *.a go? Should this go under
>>>>>>> /usr/lib/<arch>-linux-gnu?
>>>>>>
>>>>>> Yes. I'll have a look and may be I'll turn this into a d-shlibs call.
>>>>>> Thank you have an example.
>>>>>>
>>>>>>> I know this can be set accordingly in
>>>>>>> debian/rules but I have seen *.a both in /usr/lib and
>>>>>>> /usr/lib/<arch>-linux-gnu. Same for *.so.
>>>>>>
>>>>>> The latter is the modern (=multiarch) one. /usr/lib is just a left over
>>>>>> by not so properly maintaines packages.
>>>>>>
>>>>>>> I also see
>>>>>>> rc-version-greater-than-expected-version, presumably from how upstream
>>>>>>> brands the version. Should this be ignored or can this be safely rectified?
>>>>>>
>>>>>> You need to use
>>>>>>
>>>>>> opts="uversionmangle=s/-rc/~rc/"
>>>>>>
>>>>>> in debian/watch and use ~rc in d/changelog. The rationale is that '~'
>>>>>> sorts lower with `dpkg --compare-versions`. So if upstream is issuing a
>>>>>> real release it is in correct alphabethic sequence and considered a
>>>>>> higher version if you drop ~rc (or ~beta or whatever upstream might
>>>>>> invent to mark a pre-release).
>>>>>>
>>>>>>> Additionally, productivity will start to decrease for only a few weeks
>>>>>>> to a month as I prepare to move out and into university accommodation.
>>>>>>
>>>>>> May be we finalise this package in the next days. I'll have a look and
>>>>>> might finish it if you don't mind.
>>>>>>
>>>>>> Thanks for your great work
>>>>>>
>>>>>> Andreas.
>>>>>>
>>>>>>> On 19/08/2019 07:39, Andreas Tille wrote:
>>>>>>>> Hi Shayan,
>>>>>>>>
>>>>>>>> On Sun, Aug 18, 2019 at 05:53:01PM +0100, Shayan Doust wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Please disregard the previous email entirely just to save you time from
>>>>>>>>> writing, as I have finally figured things out.
>>>>>>>>
>>>>>>>> I'm slowly recovering from last week need to cope with some backlog.
>>>>>>>> Thus saving my time is pretty welcome. ;-)
>>>>>>>>
>>>>>>>>> fast should contain only executable binaries which in this case are
>>>>>>>>> openigt fast client and server binaries.
>>>>>>>>
>>>>>>>> Yes.
>>>>>>>>
>>>>>>>>> libfastSOVERSION should contain the shared / *.so only although grepping
>>>>>>>>> libFAST.so, there is no soversion. Is this libfast0 then?
>>>>>>>>
>>>>>>>> Several upstreams do not know about SOVERSION and once you contact them
>>>>>>>> you could try to talk about this as well. If upstream does not set a
>>>>>>>> soversion we should do this. In gatb-core you can find a simple example:
>>>>>>>>
>>>>>>>> https://salsa.debian.org/med-team/gatb-core/blob/master/debian/patches/set_soversion.patch
>>>>>>>>
>>>>>>>> Yes, 0 is a good choice here and we need to bump the SOVERSION once
>>>>>>>> upstream might change the ABI (which frequently happens without any
>>>>>>>> notice - you see we are at version 2 in gatb-core meanwhile).
>>>>>>>>
>>>>>>>>> libfast-dev contains only the header files and the static library (*.a).
>>>>>>>>> I realised this can be done with the ar tool. Is it sensible to traverse
>>>>>>>>> the build directory and add all object files to archive to create a
>>>>>>>>> libfast.a?
>>>>>>>>
>>>>>>>> There is no need for manual intervention with ar. CMake can do this
>>>>>>>> easily. Once we have used gatb-core as an example we might stick to
>>>>>>>> this one:
>>>>>>>>
>>>>>>>> https://salsa.debian.org/med-team/gatb-core/blob/master/debian/patches/dynamic_lib.patch
>>>>>>>>
>>>>>>>> In this case the dynamic lib is added but you get the idea how to
>>>>>>>> add a static one from this patch.
>>>>>>>>
>>>>>>>>> I will now just slightly modify the existing debian/ files to
>>>>>>>>> accommodate these changes.
>>>>>>>>>
>>>>>>>>> Additionally, I will stick to modifying fast so I will not need the
>>>>>>>>> additional CL header files, so the dependency is now just opencl. I will
>>>>>>>>> talk to upstream about this.
>>>>>>>>
>>>>>>>> If this approach will work out that sounds like a good alternative
>>>>>>>> which was missing in my list.
>>>>>>>>
>>>>>>>>> Many thanks & hopefully this isn't an inconvenience,
>>>>>>>>
>>>>>>>> Definitely not. Its a pleasure to see you growing into way more
>>>>>>>> complex packages.
>>>>>>>>
>>>>>>>> Kind regards
>>>>>>>>
>>>>>>>> Andreas.
>>>>>>>>
>>>>>>>>> Shayan Doust
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -------- Forwarded Message --------
>>>>>>>>> Subject: Re: [MoM] Re: fast: Add further dependencies to enable chroot /
>>>>>>>>> cowbuilder to build
>>>>>>>>> Resent-Date: Sat, 17 Aug 2019 13:16:24 +0000 (UTC)
>>>>>>>>> Resent-From: debian-med@lists.debian.org
>>>>>>>>> Date: Sat, 17 Aug 2019 14:16:05 +0100
>>>>>>>>> From: Shayan Doust <hello@shayandoust.me>
>>>>>>>>> To: debian-med@lists.debian.org
>>>>>>>>>
>>>>>>>>> Hello Andreas,
>>>>>>>>>
>>>>>>>>> Many thanks for taking the time to reply.
>>>>>>>>>
>>>>>>>>> Just a few side comments for whenever you next have the free time to
>>>>>>>>> reply :).
>>>>>>>>>
>>>>>>>>>> I had no time to check the packaging. In any case I think if this is
>>>>>>>>>> a library package we usually ship libfast-dev (with header files and
>>>>>>>>>> static lib (*.a file(s) )), a dynamic library package libfastSOVERSION
>>>>>>>>>> and the executable in a fast package.
>>>>>>>>>
>>>>>>>>> I retained the original name as the package name "fast" and not
>>>>>>>>> "libfast". Maybe I should change this. Initially I was unsure as fast
>>>>>>>>> stands to framework and was unsure as to this relationship with a library.
>>>>>>>>>
>>>>>>>>> CMake only generates FAST as a shared object / *.so. I assume this is
>>>>>>>>> just what upstream wanted. Referring to deb policy 8.3, I don't see this
>>>>>>>>> as mandatory. If it is, maybe I'd need to use some tool or modify cmake
>>>>>>>>> to output *.a. Fast did however generate example binaries to which I
>>>>>>>>> split this off into fast-examples to install under /usr/lib/fast.
>>>>>>>>>
>>>>>>>>> There is no soversion when doing an objdump and grepping the SONAME from
>>>>>>>>> the generated *.so file. Does this therefore mean a soversion of simply
>>>>>>>>> 0 or does this now reflect upstream version. I think it's simply a
>>>>>>>>> mistake to simply move libFAST.so into /usr/lib as this doesn't have a
>>>>>>>>> soversion and has to be a symlink instead.
>>>>>>>>>
>>>>>>>>> I may have picked a fairly time consuming and confusing package until I
>>>>>>>>> wrap my head around how a library / "framework" should be packaged.
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Shayan Doust
>>>>>>>>>
>>>>>>>>> On 17/08/2019 10:17, Andreas Tille wrote:
>>>>>>>>>> Hi Shayan,
>>>>>>>>>>
>>>>>>>>>> I've found some spare minutes for a more explicit answer. This week I
>>>>>>>>>> was pretty busy with real life (nursing my two grandsons is pretty much
>>>>>>>>>> a full time job :-P).
>>>>>>>>>>
>>>>>>>>>> On Wed, Aug 14, 2019 at 04:49:00PM +0100, Shayan Doust wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> So I contacted upstream regarding the failed test binary generation and
>>>>>>>>>>> they've acknowledged and fixed it. A query regarding test data needed
>>>>>>>>>>> for autopkgtest. As you said to avoid git or any downloading tools
>>>>>>>>>>> (curl, wget, ...) as a dependency,
>>>>>>>>>>
>>>>>>>>>> Its not a matter of trying to avoid some of these tools. Per policy a
>>>>>>>>>> package needs to build on a machine that's disconnected from the
>>>>>>>>>> internet. So it will just not work technically to download anything.
>>>>>>>>>> Its the same with autopkgtests. So we need to provide everything we
>>>>>>>>>> need either as Debian package or inside the source tree.
>>>>>>>>>>
>>>>>>>>>>> how can I add the test datas to
>>>>>>>>>>> autopkgtest. The test data is zipped and is just over 2 GB large, so I
>>>>>>>>>>> didn't think patching this in would be sensible. The test data are to be
>>>>>>>>>>> downloaded from https://folk.idi.ntnu.no/smistad/FAST_Test_Data.zip
>>>>>>>>>>
>>>>>>>>>> I think 2GB data are to much to just move it to the debian/ dir. So the
>>>>>>>>>> best idea would be to provide the test data in a separate package for
>>>>>>>>>> instance fast-data (or fast-test-data / fast-examples).
>>>>>>>>>>
>>>>>>>>>>> Additionally, I've got another query regarding opencl. Upstream have
>>>>>>>>>>> their own modified version of the CL headers. Using diff, the only
>>>>>>>>>>> change they have done is add two *.hpp files into the CL header
>>>>>>>>>>> directory in /usr/include. Is it sensible to ever have opencl as a
>>>>>>>>>>> prerequisite / package dependency and then move over the two missing
>>>>>>>>>>> files into the CL directory when the user installs the fast package or
>>>>>>>>>>> should this sort of modification to external packages be avoided at all
>>>>>>>>>>> costs. I assume the other way would just be to have the fast opencl
>>>>>>>>>>> headers inside /usr/include/FAST and then patch all the fast headers to
>>>>>>>>>>> use the fast opencl headers in the new directory. CMake also generated
>>>>>>>>>>> some opencl *.cl files in a directory called "kernel" so I am not sure
>>>>>>>>>>> as to what I should do with this directory and its significance to FAST.
>>>>>>>>>>
>>>>>>>>>> I agree that having a full copy of OpenCL just to ship two extra files
>>>>>>>>>> makes no sense. I see several options to consider:
>>>>>>>>>>
>>>>>>>>>> 1. May be it makes sense to forward these two files to OpenCL upstream.
>>>>>>>>>> In any case it might make sense to talk to fast upstream / opencl
>>>>>>>>>> Debian maintainers.
>>>>>>>>>>
>>>>>>>>>> You proposed yourself which does not involve others and thus is a faster
>>>>>>>>>> solution for the moment
>>>>>>>>>>
>>>>>>>>>> 2. Move these missing files inside a libfast-dev package and feed
>>>>>>>>>> it into the opencl headers. I admit while this would work I have
>>>>>>>>>> a bad gut feeling about this.
>>>>>>>>>>
>>>>>>>>>> 3. Patch the files and ship the two additional files somewhere in
>>>>>>>>>> /usr/include/fast
>>>>>>>>>>
>>>>>>>>>> I admit I prefer option 3. as a temporaty means until may be 1. can
>>>>>>>>>> be implemented.
>>>>>>>>>>
>>>>>>>>>>> Looks like everything else is going fine. With this being the first
>>>>>>>>>>> library I've packaged I do expect some mistakes but luckily they won't
>>>>>>>>>>> be replicated within the next library I package :).
>>>>>>>>>>
>>>>>>>>>> I had no time to check the packaging. In any case I think if this is
>>>>>>>>>> a library package we usually ship libfast-dev (with header files and
>>>>>>>>>> static lib (*.a file(s) )), a dynamic library package libfastSOVERSION
>>>>>>>>>> and the executable in a fast package.
>>>>>>>>>>
>>>>>>>>>> I have no time to verify whether these hints might make sense in this
>>>>>>>>>> actual case.
>>>>>>>>>>
>>>>>>>>>> Kind regards
>>>>>>>>>>
>>>>>>>>>> Andreas.
>>>>>>>>>>
>>>>>>>>>>> On 11/08/2019 21:49, Shayan Doust wrote:
>>>>>>>>>>>> Hi Andreas,
>>>>>>>>>>>>
>>>>>>>>>>>>> I'm occupied by real life until next weekend - so my response time
>>>>>>>>>>>>> is way longer than usual.
>>>>>>>>>>>>
>>>>>>>>>>>> Not a worry at all & thanks for the needed information!
>>>>>>>>>>>>
>>>>>>>>>>>>> May be you can ask on debian-mentors@lists.debian.org meanwhile.
>>>>>>>>>>>>
>>>>>>>>>>>> As this is 3.0.0rc1 I will probably try out 3.0.0rc3 and then ask just
>>>>>>>>>>>> in case this was some upstream issue.
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> Shayan Doust
>>>>>>>>>>>>
>>>>>>>>>>>> On 11/08/2019 21:44, Andreas Tille wrote:
>>>>>>>>>>>>> Hi Shayan,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm occupied by real life until next weekend - so my response time
>>>>>>>>>>>>> is way longer than usual.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Aug 11, 2019 at 01:25:22AM +0100, Shayan Doust wrote:
>>>>>>>>>>>>>> Hello Andreas,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A few things changed since the previous email. I found a way of getting
>>>>>>>>>>>>>> the dependencies via another chroot environment and now the package
>>>>>>>>>>>>>> builds in cowbuilder with no troubles. My work routine usually goes
>>>>>>>>>>>>>> along the lines of getting stuck on something for a couple of hours,
>>>>>>>>>>>>>> emailing here on the mailing list then 30 mins later somehow managing to
>>>>>>>>>>>>>> fix whatever issue I was stuck on :).
>>>>>>>>>>>>>
>>>>>>>>>>>>> That's not very different to what happened quite frequently to me. ;-)
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am having some issues with moving libFAST.so. I am not sure if I
>>>>>>>>>>>>>> should simply use mv or use d-shlibmove. d-shlibmove just throws an
>>>>>>>>>>>>>> error with regards to dependencies not existing so if I am meant to use
>>>>>>>>>>>>>> d-shlibmove, please have a look at this in fast.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I personally like to use d-shlibmove since it prevents you from making
>>>>>>>>>>>>> several mistakes in library packaging. However, since I habe no time
>>>>>>>>>>>>> to provide technical help this week its fine if you find any solution.
>>>>>>>>>>>>> Usually d-shlibmove turns out a bit tricky. If something is missing
>>>>>>>>>>>>> you can try '--override' as for instance in the package libdisorder.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Lintian is reporting package-name-doesnt-match-sonames. I believe this
>>>>>>>>>>>>>> is where I have to rename "fast" to "libFAST" for the package name. I am
>>>>>>>>>>>>>> also getting shlib-without-versioned-soname and I am unsure as to how
>>>>>>>>>>>>>> this is rectified.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I usually ignore these lintian issues when its not an actual library
>>>>>>>>>>>>> package.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Compilation of the test binaries fail and I am even unable to build
>>>>>>>>>>>>>> these in an isolated system just using cmake so I assume this is some
>>>>>>>>>>>>>> sort of an upstream bug or even an incomplete wiki page with some
>>>>>>>>>>>>>> dependency not documented. I'll figure out something for this as usual.
>>>>>>>>>>>>>> Luckily all other informational lintian outputs can simply be fixed by
>>>>>>>>>>>>>> removing the unneeded directories like fonts. I can't think of anything
>>>>>>>>>>>>>> else to write at this time of night.
>>>>>>>>>>>>>
>>>>>>>>>>>>> May be you can ask on debian-mentors@lists.debian.org meanwhile.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for your time & best regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Good luck
>>>>>>>>>>>>>
>>>>>>>>>>>>> Andreas.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> http://fam-tille.de
>>>
>>>
>>
>
Attachment:
signature.asc
Description: OpenPGP digital signature