Re: [MoM] Re: fast: Add further dependencies to enable chroot / cowbuilder to build
Hi Shayan,
I havn't even read your mail to the end since I'm busy but just a
short answer: If the test data file is that large it might make sense
to create a separate package from it.
Just sending this short hint - more explicite answer at least on
Monday, Andreas.
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, 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
>
> 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.
>
> 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 :).
>
> Best Regards,
> Shayan Doust
>
>
> 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: