Hello, Please disregard the previous email entirely just to save you time from writing, as I have finally figured things out. fast should contain only executable binaries which in this case are openigt fast client and server binaries. libfastSOVERSION should contain the shared / *.so only although grepping libFAST.so, there is no soversion. Is this libfast0 then? 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? 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. Many thanks & hopefully this isn't an inconvenience, 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. >>>> >>> >> > > > >
Attachment:
signature.asc
Description: OpenPGP digital signature