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.
> >>>
> >>
> >
>
--
http://fam-tille.de
