[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [MoM] Re: fast: Add further dependencies to enable chroot / cowbuilder to build



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.
>>
> 

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: