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 <he...@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-ment...@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-ment...@lists.debian.org meanwhile.
> >>>>>>
> >>>>>>> Thanks for your time & best regards,
> >>>>>>
> >>>>>> Good luck
> >>>>>>
> >>>>>> Andreas.
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> >
>
--
http://fam-tille.de
