Re: [MoM] fast: Add further dependencies to enable chroot / cowbuilder to build
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
Reply to: