Hello Andreas,
Just to update you on what has been going on. Please disregard my
previous email to save you time from writing regarding something redundant.
I have added some more overrides and updated the symbol file again to
which the package is now being built successfully :).
A few errors persist via Lintian when I first built. The Lintian errors
are "arch-independent-package-contains-binary-or-object" referencing
usr/lib/x86_64-linux-gnu/libFAST.a and
"triplet-dir-and-architecture-mismatch" referencing
usr/lib/x86_64-linux-gnu.
For arch-independent-package-contains-binary-or-object: I have changed
the architecture of libfast-dev from "all" to "any".
non-binmutable-all-depends-any: For the depends field, I have used
"libfast0 (>= ${source:Version}), libfast0 (<< ${source:Version}.1~)"
instead of "libfast0 (= ${binary:Version})". Please advise if this
should be something else.
I have modified the --movedev option of d-shlibmove as we do not need
the CL include directory as this will clash with OpenCL's headers, and
the patch I put erradicates the need for this additional FAST's CL
directory anyways. I will try run autopkgtest to make sure the patch has
not missed anything out although I am personally having opengl driver
issues that is stopping me from doing this for now.
I've written this email in time order while I have been applying some
commits, so as of right now I do not see anymore Lintian errors or
warnings. In the meantime, I've also spent the time going through any
devel documentation I could find with regards to policy and guides.
Kind Regards,
Shayan Doust
On 24/08/2019 18:32, Shayan Doust wrote:
> Hello Andreas,
>
> Just to extend the previous email I sent.
>
> I have corrupted my VM which means I cannot get the exact error message
> however off the top of my head, it seems like d-shlib is failing.
>
> The error message consists of many lines stating "There is no package
> matching [<some qt libraries>] and noone provides it, plese report but
> to d-shlibs maintainer".
>
> I am sure you can replicate this. Does this look like a reporable issue
> or is this related to perhaps some flags you set for d-shlibs?
>
> Regards,
> Shayan Doust
>
> On 23/08/2019 21:28, Shayan Doust wrote:
>> Hello Andreas,
>>
>>> Something which is really strange is that dh_makeshlibs created a diff
>>> for the symbols file. I applied that diff and started a rebuild - no
>>> idea why this is happening.
>>
>> I've seen this happen a few times and I've ended up rewriting the
>> existing symbols file with the new one generated as DEBIAN/symbols.
>>
>>> I also switched the packaging to d-shlibs a I promised. The good thing
>>> is that it enforces library packaging policy and thus I was able to spot
>>> missing "Section" fields in the control file.
>>
>> Thanks. It makes sense. Admittingly, the thing I've had issues with was
>> the override option as at the time, did not make sense to me. I'll now
>> use d-shlibs within future library packages as it does most of the job
>> itself in a safe way.
>>
>>> I'll test this later.
>>
>> Thanks. It could just be that d-shlib rectifies this as maybe I was
>> installing the wrong thing. I will try initiate a build as I have not
>> done so yet.
>>
>>> I promised support - specifically when you are tackling such a huge
>>> beast. ;-)
>>
>> Grateful for this :). It makes more sense visualising the current issues
>> and how you would rectify it, which I can apply to future packaging.
>>
>> Kind Regards,
>> Shayan Doust
>>
>> On 23/08/2019 08:36, Andreas Tille wrote:
>>> Hi Shayan,
>>>
>>> On Thu, Aug 22, 2019 at 09:09:29PM +0100, Shayan Doust wrote:
>>>> Just to extend the previous email.
>>>>
>>>> I created another fresh environment and even used pbuilder and the
>>>> results are the same, that the build succeeds.
>>>
>>> Something which is really strange is that dh_makeshlibs created a diff
>>> for the symbols file. I applied that diff and started a rebuild - no
>>> idea why this is happening.
>>>
>>> I also switched the packaging to d-shlibs a I promised. The good thing
>>> is that it enforces library packaging policy and thus I was able to spot
>>> missing "Section" fields in the control file.
>>>
>>> Warning: I've commited despite my build did not finished but I wanted
>>> to push the d-shlibs change soon to get you informed.
>>>
>>>> Additionally, I have attempted to disable RPATH during the build but the
>>>> error and RPATH still exist, so I am not too sure. If a solution isn't
>>>> reached, I will write to debian mentors like you have mentioned. I'm not
>>>> sure if I can just use dpkg-shlibdeps -l<lib> for each executable but
>>>> this seems like a fair bit of pain to do for all the libraries and
>>>> executables that exist and are compiled.
>>>
>>> I'll test this later.
>>>
>>>> Many thanks for looking into this & regards,
>>>
>>> I promised support - specifically when you are tackling such a huge
>>> beast. ;-)
>>>
>>> Kind regards
>>>
>>> Andreas.
>>>
>>
>
Attachment:
signature.asc
Description: OpenPGP digital signature