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