Hello, In the meantime, resending this as a quotation just in case it gets pushed to the bottom of the list. Best Regards, Shayan Doust On 14/08/2019 16:49, 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. >>> >> >
Attachment:
signature.asc
Description: OpenPGP digital signature