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: '0201003e'; 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-ment...@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/-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/-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
