[OE-core] [PATCH 0/4] Fix a number of non-machine pkg hash change issues

Mark Hatle mark.hatle at windriver.com
Wed Oct 17 16:43:22 UTC 2018


While working on a system with multiple BSPs, but a single distro configuration,
I struggled with an issue of PR numbers increasing quickly and different
behavior from boot to boot.

The systemd one, it looks like there are two alternative solutions.  I choose
the one that was similar to a connman fix.  Add a machine specific configuration
recipe.  The alternative would have been to adjust the test cases to pass the
argument for the longer timeout via the kernel command line.  I was worried
that this could end up being a requirement for more then just test cases.

Note in this patch, I also moved the 'machine-id' file to the config stuff,
with the note it appeared to me this made the most sense as someone may end
up defining some specific semantics to that file in some configurations.

The remaining changes made sense in my configuration, but I'm not entirely
sure they are the right solution.  The other alternative I toyed with was
to declare the package to be machine specific -only- for QEMU BSPs.  But
I'm not sure this really would have solved my PR number/hash problem.

Mark Hatle (4):
  systemd: Remove items that made this machine (qemu) specific
  mesa: Remove machine specific append
  weston: Remove machine specific append
  gstreamer: Remove machine specific append

 meta/recipes-core/systemd/systemd-conf.bb     | 51 +++++++++++++++++++
 ...ange-the-default-device-timeout-to-2.patch | 35 -------------
 meta/recipes-core/systemd/systemd_239.bb      | 28 ++++------
 meta/recipes-graphics/mesa/mesa.inc           |  4 +-
 meta/recipes-graphics/wayland/weston_5.0.0.bb |  4 +-
 .../gstreamer/gstreamer1.0_1.14.2.bb          |  2 -
 6 files changed, 64 insertions(+), 60 deletions(-)
 create mode 100644 meta/recipes-core/systemd/systemd-conf.bb
 delete mode 100644 meta/recipes-core/systemd/systemd/0001-core-device.c-Change-the-default-device-timeout-to-2.patch

-- 
2.18.0



More information about the Openembedded-core mailing list