[oe] [PATCH 3/9] tracker-miners: initial add 2.3.1

[Khem Raj]

On Fri, Nov 22, 2019 at 1:49 PM Andreas Müller <schnitzeltony at gmail.com> wrote:
>
> On Wed, Nov 20, 2019 at 9:04 AM Andreas Müller <schnitzeltony at gmail.com> wrote:
> > > fails to build on x86
> > >
> > > https://errors.yoctoproject.org/Errors/Details/277884/
> > >
> This turns tricky so I first try explain the issue and then ask for
> suggestions/discussion:
>
> 1.
> meson.build contains:
>
> | libseccomp = dependency('libseccomp', version: '>= 2.0', required: false)
> | ...
> | host_system = host_machine.system()
> | host_cpu = host_machine.cpu()
>
> | # You can find a list of architectures that seccomp supports in the seccomp
> | # project README. See: https://github.com/seccomp/libseccomp/
> | unsupported_cpus = [
> |  'alpha',
> |  'ia64',
> |  'm68k',
> |  'parisc',
> |  'parisc64',
> |  'sh4',
> |  'sparc',
> |  'sparc64',
> |]
> |
> | system_supports_seccomp = host_system == 'linux'
> | cpu_supports_seccomp = not unsupported_cpus.contains(host_cpu)
> | seccomp_required = system_supports_seccomp and cpu_supports_seccomp
> |
> |if not libseccomp.found() and seccomp_required
> |  error('Libseccomp is mandatory for sandboxed metadata extraction')
> | endif
>
> That means:
> * tracker-miners' developers make libseccom a _mandatory_ dependency-
> except for those arches not supported by libseccomp
> * my test build passed accidentally because host_machine.system()
> reports 'linux-gnueabi' and that is not detected as 'linux'
>
> 2.
> I see the following ways to go:
> a. Patch the check away and add a comment in the recipe like: "For
> security reasons it is strongly recommended to set add meta-security
> in your layers and 'libseccomp' to PACKAGECONFIG".
> b. Move libseccomp form meta-security -> meta-oe. That would need some
> COMPATIBLE_HOST dance (at leas for riscv) in libseccomp and
> tracker-miners
> c. Give up nautilus because it crashes without tracke-miners
>
> After looking into e.g [1] I
> * don't think that riscv support will ever come to libseccomp
> * am afraid that libseccomp can cause strange effects with very
> old/new kernel versions
> * prefer a.
>
> OK - long talk: What do others think?
>

there has been attempts to bring libseccomp to meta-oe [1] since it
was used in wide
variety of packages. I am willing to maintain it in OE if someone can
make the needed changes
and address review comments from last attempt.

secondly, if the support is optional, then we can make it so via
packageconfig and keep it disabled
but seems thats not the case, in such a case, I think your proposal 'a' is ok

[1] https://patchwork.openembedded.org/patch/163384/
> Cheers
>
> Andreas
>
> [1] https://github.com/seccomp/libseccomp/blob/master/src/arch-arm-syscalls.c