Re: [MoM] FAST progress (was Re: [MoM] fast: Add further dependencies to enable chroot / cowbuilder to build)
On Wed, Aug 28, 2019 at 06:18:59PM +0100, Shayan Doust wrote:
> 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.
In libhmsbeagle I had to deal with this in build time tests. May be
you check the Build-Depends for some additional inspiration. No idea
whether this might help.
Kind regards
Andreas (offline for the next 20 hours)
> 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.
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >>
> >>
> >>
> >
>
--
http://fam-tille.de
Reply to: