Hello Andreas,
Extending my previously sent message.
>> Testing with opengl is always a nuisance. Even with emulation this
>> tends to fail unfortunately. But you might like to try and we'll see
>> how it might turn out.
>
> I'll let you know how this goes. This is currently taking the most time
> for the packaging as opengl seems to be a real pain from past
> experience. Probably the VM factor doesn't help it as maybe there is
> some more abstraction. Assuming autopkgtest is also ran on debian
> servers, I wonder if this issue is still present.
Just as I anticipated, it looks like it will not work as I use
virtualbox and debian is essentially virtualised. So not only can I not
passthrough the host GPU, I am unable to use any drivers which means
that the error I get even when running any of the fast-examples binaries
(apart from OpenIGTLinkServer) is "what(): clGetPlatformIDs", which is
verified by running "clinfo" which returns 0 as the number of platforms
- it seems like I have hit a dead end unless there is some work around
which I have my doubts in.
Kind regards,
Shayan Doust
On 28/08/2019 16:33, Shayan Doust wrote:
> Hello Andreas,
>
>> Ahhh, that really saves time. I had an extremely busy weekend -
>> otherwise I would have answered before.
>
> No problem. At least I prevented you from answering an old question :).
>
>> The symbols file changes are really strange. I was running again in a
>> diff. I have not commited my changes yet but for the moment I have
>> deactivated the symbols file since it seems we are playing diff - patch
>> ping-pong for no good reason.
>
> I haven't seen this happen with other libraries so it is strange.
> Perhaps our environments are different in some way? It still shouldn't
> matter though as the library itself is one version and not changing.
>
>> I admit I have never seen this. D-shlibs enforces
>> (= ${binary:Version})
>> and this should be there. Your. May be your change was needed once
>> the package was arch: all ?
>
> You're correct. I changed the depends before I realised the arch was
> incorrect, and as usual I forgot to backtrack and undo my change to
> depends. I've just pushed this change.
>
>> Testing with opengl is always a nuisance. Even with emulation this
>> tends to fail unfortunately. But you might like to try and we'll see
>> how it might turn out.
>
> I'll let you know how this goes. This is currently taking the most time
> for the packaging as opengl seems to be a real pain from past
> experience. Probably the VM factor doesn't help it as maybe there is
> some more abstraction. Assuming autopkgtest is also ran on debian
> servers, I wonder if this issue is still present.
>
> Kind regards,
> Shayan Doust
>
> On 28/08/2019 12:33, Andreas Tille wrote:
>> Hi Shayan,
>>
>> On Tue, Aug 27, 2019 at 03:40:04AM +0100, Shayan Doust wrote:
>>> 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.
>>
>> Ahhh, that really saves time. I had an extremely busy weekend -
>> otherwise I would have answered before.
>>
>>> I have added some more overrides and updated the symbol file again to
>>> which the package is now being built successfully :).
>>
>> The symbols file changes are really strange. I was running again in a
>> diff. I have not commited my changes yet but for the moment I have
>> deactivated the symbols file since it seems we are playing diff - patch
>> ping-pong for no good reason.
>>
>>> 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".
>>
>> That's definitely correct - architecture should be 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 admit I have never seen this. D-shlibs enforces
>> (= ${binary:Version})
>> and this should be there. Your. May be your change was needed once
>> the package was arch: all ?
>>
>>> 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.
>>
>> Sounds sensible even if I can not judge about this since I do not
>> know the internals of this program.
>>
>>> 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.
>>
>> Testing with opengl is always a nuisance. Even with emulation this
>> tends to fail unfortunately. But you might like to try and we'll see
>> how it might turn out.
>>
>>> 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.
>>
>> I've started a build at home and will send further comments once I'm
>> home again.
>>
>> Kind regards
>>
>> Andreas.
>>
>>> 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