From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: [PATCH 0/4] Fix a number of non-machine pkg hash change issues
Date: Wed, 17 Oct 2018 12:43:22 -0400 [thread overview]
Message-ID: <20181017164326.67111-1-mark.hatle@windriver.com> (raw)
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
next reply other threads:[~2018-10-17 16:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-17 16:43 Mark Hatle [this message]
2018-10-17 16:43 ` [PATCH 1/4] systemd: Remove items that made this machine (qemu) specific Mark Hatle
2018-10-18 8:53 ` ChenQi
2018-10-18 15:37 ` Mark Hatle
2018-10-18 22:57 ` Richard Purdie
2018-10-20 8:41 ` Richard Purdie
2018-10-20 16:14 ` Mark Hatle
2018-10-17 16:43 ` [PATCH 2/4] mesa: Remove machine specific append Mark Hatle
2018-10-17 16:43 ` [PATCH 3/4] weston: " Mark Hatle
2018-10-18 10:24 ` Burton, Ross
2018-10-18 15:38 ` Mark Hatle
2018-10-19 10:51 ` Burton, Ross
2018-10-24 10:13 ` Mark Hatle
2018-10-25 8:36 ` Alexander Kanavin
2018-10-25 9:05 ` Martin Jansa
2018-10-25 9:26 ` Richard Purdie
2018-10-17 16:43 ` [PATCH 4/4] gstreamer: " Mark Hatle
2018-10-18 10:28 ` Richard Purdie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181017164326.67111-1-mark.hatle@windriver.com \
--to=mark.hatle@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox