Hello Andreas, > I'm slowly recovering from last week need to cope with some backlog. > Thus saving my time is pretty welcome. ;-) Welcome back :). > 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: 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. > ...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? 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. 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? Additionally, productivity will start to decrease for only a few weeks to a month as I prepare to move out and into university accommodation. Many thanks, Shayan Doust 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. >>>>>> >>>>> >>>> >>> >>> >>> >>> >> >> >> > > > >
Attachment:
signature.asc
Description: OpenPGP digital signature