pelagicore / meta-bistro Goto Github PK

Often inside of corporate networks the git port 9418 is blocked, to make it easier for meta-bistro to get adopted by others we should not use the git:// protocol but https:// instead if it is possible. When doing fetchall I saw that those two recipies use git:// and could just be replaced with https:// because they point to github.com which allows that.

./meta-bistro/layers/qt5-layer/recipes-qt/swaplogger/swaplogger.bb
./meta-bistro/recipes-core/systemd/systemd-additional-units.bb

But I think we should change all the ones we have in meta-bistro, because most of them point to ones which can handle https.

We have a recipe for python-netaddr_0.7.10 but a newer version (0.7.18) is available in meta-python.

Do we want to keep this particular version of the recipe?

The recipe in meta-openembedded/meta-gnome is somewhat different, mostly with updated dependencies.

The question is should we keep a copy of this recipe in meta-bistro or remove it and state a dependency towards meta-openembedded/meta-gnome?

https://github.com/Pelagicore/meta-bistro/wiki

The QtWayland XKB_DEPENDS directive is deprecated as of morty (meta-qt5).
Instead the xkb is added via PACKAGECONFIG by default and should be excluded in the bbappend recipe.

How does one build meta-bistro? Is qemu supported as a build target?

Want to ensure we're assigning copyright where we ought to.

Is there a point in maintaining our own recipe?

The official from meta-ivi should be used.

The openssh recipe directory offers systemd files for openssh but does not install them.
Similar files with extra configurable options and an install step is offered by Poky:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-connectivity/openssh

Is there any reason to keep these files?
If yes, should a recipe for installing them be provided as well?

Setting XDG_RUNTIME_DIR to /tmp is invasive to the underlaying system because a chmod system call will be executed on /tmp to set 0700 permissions. Details about this can be found in the qtbase code.

It should be something line with "/run/user/", or even better, inherited from the system.

Therefore this line should be reconsidered.

There are several Missing or unbuildable dependency chain that might be broken even before 2.2 (morty).

Are these recipes being used or should we rely on the mainstream recipe of tracker, instead of our fork (https://github.com/Pelagicore/tracker-ivi)? @jonte could you please comment on this?

In recipes-support there is a recipe for libitzam. This code is dual licensed -- simplified BSD for open source projects like ours and commercial license for closed source projects. If we want anyone to use meta-bistro, we need to make it clear that using libitzam commercially requires a commercial license from upstream. More here: http://coyotegulch.scottrobertladd.net/products/itzam/c/index.html

If we're not using itzam, perhaps we remove this in order to avoid any confusion for downstream?

The goal is to stop using meta-bistro as it's own distro but as a layer enabling Pelagicore components and recipe appendments.

The words "All Rights Reserved" are found in combination with the copyright line at the top of some recipe files. This wording is uncommon to use in combination with an open-source license. It might not be strictly wrong (IANAL) but for clarity I wonder if you could decide on a single way to describe the license of the files in this meta-layer. For example decide and adjust the following:

1. Avoid "All rights reserved", for clarity.
2. Should the recipe files include a license-specification header or not?
3. Make sure that whatever license information you choose for each recipe file is consistent with the main LICENSE file in the root

This would facilitate adoption. Thanks in advance!

Bbappend for polkit sets a variable POLKITAUTH.

The explanation is that "default meta-oe value is consolekit" but I can't seem to find this variable in meta-oe. I would appreciate help in defining the need for this variable and how it is used.

NOTE: this recipe was renamed from polkit_0.111 to polkit_0.113, could be related to old version...

The commit http://code.qt.io/cgit/yocto/meta-qt5.git/commit/recipes-qt/qt5/qtbase_git.bb?h=5.8&id=c4a0a450b4275cc3869cf389c92e86b62f09fcea changed the Qt configuration system so the ALSA package config is no longer valid for qtbase.

We are currently missing proper integration of the maven classes, they should only be added for the ivi layer.

It has been decided to remove the image recipes from this layer.

Make sure to create a graceful transition and update the documentation accordingly.

While rebuilding from sstate-cache on Yocto 2.1. it was, rarely but still, observed that some components using the CommonAPI code generator were missing parts of the tooling supposed to be pulled in by this list of dependencies.

It would be good to have a package manifest and a run of SPDX over meta-bistro.

SoftwareContainer should be in the same directory as lxc in meta-virtualization, which is recipes-containers, otherwise it is always difficult to find.

Create a .inc-file for softwarecontainer which contains all PACKAGECONFIG and other settings, and create a bb-file with the defaults we want in meta-bistro. This should make it easier for other layers to configure softwarecontainer as they see fit.

The bbappend for libpcap adds a PACKAGECONFIG for bluez5.

However, Poky removes bluez5 PACKAGECONFIG with a note that bluez5 is not supported by libpcap:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-connectivity/libpcap/libpcap.inc?h=master#n28

If bluez5 is really not supported, should it be removed?

Given that meta-qt5 is an optional dependency to meta-bistro, it is not reasonable that one of the core images, which are parsed and used regardless of meta-qt5 availability, use a meta-qt5 specific class.

This dependency was added in fido and has since lived on to both jethro and master. See this commit: 7f1bede

Trying to build avdecc-lib against Yocto 2.1 fails.
The recipe also uses an additional custom function to handle git submodules while this can be done using "gitsm" fetcher from bitbake.

Can we consider upgrading to the latest version of this component or drop it?

Should all applications started in a user (as in non-system) context be started in a systemd user session? Does this make sense for Bistro?

See here for more information: https://wiki.archlinux.org/index.php/Systemd/User

Using this concept would make it easier to set up per-user services, such a D-Bus daemons (for session busses), PulseAudio daemons, and would also be a logical place to start AppMan on QtAS systems.

Hi,

I try to build the peak-linux-driver.
When I call bitbake core-image-rt, I can see that the tasks of the recipe peak-linux-driver are executed but pcan.ko is not added to the rootfs and I cannot find any file pcan.ko in the tmp directory (and subdirectories).
Did someone experience the same issue?
Vincent

Bbappend for bluez4 directly creates symlinks for systemd service which should be handled through a systemd bbclass.

Also, bluez4 is considered obsolete in Poky since Jethro and is accessed from meta-oe:
http://www.yoctoproject.org/docs/2.0/ref-manual/ref-manual.html#migration-2.0-removed-recipes
Are the bbappend additions (audio profiles patch and MediaPoint dbus interface config) something we want to keep configuring by default when using meta-bistro?

https://jonaslundqvist.net/2015/05/06/do-not-use-libspotify/

If libspotify is no longer used, perhaps we remove it?

Bbappend for subversion solves a build issue with -native package, but now the issue is resolved with a patch introduced in Poky, at least Jethro and Krogoth versions:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/subversion/subversion-1.8.13?h=jethro
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/subversion/subversion?h=krogoth

Therefor this fix should be removed.

Currently the master branch of meta-bistro is compatible with Yocto morty release.

We should branch out to morty and verify the stability of the branch. Master should start following pyro.

More information on Yocto versions can be found on the following link https://wiki.yoctoproject.org/wiki/Releases.

The recipe for mutagen is outdated, the links in HOMEPAGE and SRC_URI are dead.

Do we need this tool in meta-bistro?
If yes, should we write a new recipe that refers to https://pypi.python.org/pypi/mutagen ?

Poky recently moved to disabling static libraries per default. I think we should investigate the benefits from this, and see if we want to follow their example.

Quote from Poky release notes:

Static library generation, for most cases, is now disabled by default in the Poky distribution. Disabling this generation saves some build time as well as the size used for build output artifacts.

Disabling this library generation is accomplished through a meta/conf/distro/include/no-static-libs.inc, which for those not using the Poky distribution can easily include to enable the same functionality.

Any recipe that needs to opt-out of having the "--disable-static" option specified on the configure command line either because it is not a supported option for the configure script or because static libraries are needed should set the following variable:

DISABLE_STATIC = ""

Full release notes here: http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.1-release

The bbappend for neard resets RRECOMMENDS due to a bluez version problem between Poky and meta-ivi. It is also marked with "FIX ME" referring to a pending change in Poky which seems to be merged.

Now the inherited bluetooth bbclass sets the BLUEZ variable to a value defined by DISTRO_FEATURES.

Should the bbappend be removed now?