Re: [MoM] FAST progress (was Re: [MoM] fast: Add further dependencies to enable chroot / cowbuilder to build)
Hi Shayan,
please git pull for two commits (library name to make sure fast-examples
can be installed and Standards-Version).
On Thu, Aug 29, 2019 at 01:22:51AM +0100, Shayan Doust wrote:
> Hello Andreas,
>
> > 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.
>
> Many thanks for your reply. This has made some slight difference. A few
> things to note.
>
> Running clinfo returns my CPU as a platform, however "what():
> clGetPlatformIDs" is still thrown. Running the test binary, I see some
> more information. I am not sure the significance of these as opposed to
> the separate example binaries, however here is a short snippet:
>
> ...
>
> -------------------------------------------------------------------------------
> /home/shayandoust/Desktop/FAST/fast/source/FAST/Tests/Benchmarks.cpp:106
> ...............................................................................
>
> /home/shayandoust/Desktop/FAST/fast/source/FAST/Tests/Benchmarks.cpp:106: FAILED:
> due to unexpected exception with message:
> There was an error while getting OpenCL devices: clGetDeviceIDs
>
> INFO: QApp already exists..
> INFO: Device manager initialize..
> INFO: Initial GLX context 0x5574dc453ae0
> INFO: Found 1 OpenCL platforms.
> INFO: 1 platforms selected for inspection.
> INFO: Platform 0: Mesa
> INFO: This platform has
> -------------------------------------------------------------------------------
> Pipeline C
> -------------------------------------------------------------------------------
> /home/shayandoust/Desktop/FAST/fast/source/FAST/Tests/Benchmarks.cpp:167
> ...............................................................................
>
> /home/shayandoust/Desktop/FAST/fast/source/FAST/Tests/Benchmarks.cpp:167: FAILED:
> due to unexpected exception with message:
> There was an error while getting OpenCL devices: clGetDeviceIDs
>
> ===============================================================================
> test cases: 221 | 32 passed | 189 failed
> assertions: 385 | 196 passed | 189 failed
I get:
$ sh run-unit-test
Unpacking test data
Invoking testFAST
INFO: Creating new QApp
WARNING: Unable to open the configuration file /usr/fast_configuration.txt. Using defaults instead.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
testFAST is a Catch v1.5.9 host application.
Run with -? for options
-------------------------------------------------------------------------------
Airway segmentation
-------------------------------------------------------------------------------
/build/fast-3.0.0~rc3+ds/source/FAST/Algorithms/AirwaySegmentation/airwaySegmentationTests.cpp:49
...............................................................................
/build/fast-3.0.0~rc3+ds/source/FAST/Algorithms/AirwaySegmentation/airwaySegmentationTests.cpp:49: FAILED:
due to unexpected exception with message:
Unable to open directory /usr/../doc//fonts
INFO: QApp already exists..
INFO: Creating new GL context for computation thread
WARNING: Your system uses comma as decimal point.
WARNING: This will now be changed to dot to avoid any comma related bugs.
INFO: Device manager initialize..
INFO: Initial GLX context 0x563a2ac8d8c0
INFO: Found 1 OpenCL platforms.
INFO: 1 platforms selected for inspection.
INFO: Platform 0: Intel
INFO: This platform has 0 available devices in total
INFO: Looking for GPU devices only.
INFO: 1 selected.
INFO: Inspecting device 0 with the name Intel(R) HD Graphics Haswell Ultrabook GT2 Mobile
INFO: Initial GLX context 0x563a2ac8d8c0
-------------------------------------------------------------------------------
Block matching 2D
-------------------------------------------------------------------------------
/build/fast-3.0.0~rc3+ds/source/FAST/Algorithms/BlockMatching/Tests.cpp:10
...............................................................................
/build/fast-3.0.0~rc3+ds/source/FAST/Algorithms/BlockMatching/Tests.cpp:10: FAILED:
due to a fatal error condition:
SIGSEGV - Segmentation violation signal
===============================================================================
test cases: 2 | 2 failed
assertions: 2 | 2 failed
> spent a few hours reading the source and attempting to search up the
> error message, although I'm trying not to put any additional load on
> you. If you do lack time, I could always ask in mentors.
The missing font is a bit suspicious but I'm absolutely uninformed
about all this graphics stuff to be more helpful here.
A general remark: The package libfast-examples contains compiled
executables in /usr/lib/fast. Users usually expect examples in
/usr/share/doc/PKGNAME/examples
(that's where dh_installexamples puts files). Usually these are not
binaries. It depends a bit what we want to teach users by these
examples. If it is how to develop with libfast-dev than it would be
better to provide the source code files including a Makefile to compile
these examples (and may be change something and try what's happening).
If something else should be demonstrated and these executables might
have some extra value I'd consider it necessary to add some information
under /usr/share/doc/libfast-examples/examples or similar to inform
users where they can find those files and what to do.
Kind regards
Andreas.
> Many thanks,
> Shayan Doust
>
> On 28/08/2019 20:04, Andreas Tille wrote:
> > 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: