[yocto] Usage of yocto on different (production vs debug) scenarios
Hello forum.
We are trying to use yocto in a continuous integration environment with
different (production vs debug) scenarios.
To setup a given scenario (production vs debug) we are using something like
this:
$ SCENARIO=debug
$ MACHINE= DISTRO=-${SCENARIO} source
../../build--${SCENARIO}
$ bitbake -${SCENARIO}
So we have different image recipes:
* image-production.bb
* image-debug.bb
Different distros:
* distro-production.conf
* distro-debug.conf
And different build directories:
* build--production
* build--debug
To optimize space usage and compilation time, we setup a shared sstate
cache and a shared directory for downloads. This seems a good starting
point.
However, things are getting complicated, because there is no way to exclude
some recipes easily. For example, we don't want iptables installed on the
debug image, but dependency chains include iptables by default even when
declaring IMAGE_INSTALL_remove explicitly. In this case we decided checking
SCENARIO inside iptables_%.bbappend to decide what rules are installed on
the image (rules.production vs rules.debug).
But at the end, this method is poisoning all our recipes with that kind of
ugly controls [...]
Do you think this is the right way to manage this? Can you suggest a
better/more convenient way to deal with this?
Thank you in advance! :)
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Linux Files needed for PXE network boot
Maybe grub file bootx64.efi do not have network module. You can try to use
grub provided by Ubuntu
http://archive.ubuntu.com/ubuntu/dists/trusty/main/uefi/grub2-amd64/current/grubnetx64.efi.signed
Or build your own grub that build-in with network capability.
In your root tftp server create a grub folder with grub.cfg.
/tftpboot/grub/grub.cfg
Your grub.cfg should look like this
=
Set timeout 5
menuentry "core-image-sato" {
linux image/bzImage
initrd image/initrd
}
==
Put your image in tftp root
/tftpboot/image/bzImage
/tftpboot/image/initrd
If you want to put your rootfs in NFS. You need to include network module in
kernel and extract your rootfs for example to /srv/rootfs. Then your grub.cfg
should be like this
= grub.cfg
Set timeout 5
menuentry "core-image-sato-NFS" {
linux image/bzImage root=/dev/nfs rw
nfsroot=192.168.1.1:/srv/rootfs,hard,tcp,intr ip=dhcp
initrd image/initrd
}
Regards,
Alim Hussin
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Extensible SDK and DEFAULT_PREFERENCE
On Wed, Apr 18, 2018 at 5:41 AM, Martin Siegumfeldt wrote:
> Hi,
>
> I am having a number of recipes residing in two versions, some (development
> versions) being down-prioritized using:
>
> DEFAULT_PREFERENCE = "-1"
>
>
> The source code is hosted at a private git repository, and the git version is
> selected using 'AUTOREV'. The extensible SDK renders successfully, however
> the installation (by third party) fails:
>
> Traceback (most recent call last):
> File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py",
> line 412, in DataSmart.expandWithRefs(s='dev+git${SRCPV}', varname='PV'):
> try:
> >s = __expand_var_regexp__.sub(varparse.var_sub, s)
> try:
> File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py",
> line 111, in VariableParse.var_sub(match=<_sre.SRE_Match object; span=(7,
> 15), match='${SRCPV}'>):
> else:
> >var = self.d.getVarFlag(key, "_content")
> self.references.add(key)
> File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py",
> line 794, in DataSmart.getVarFlag(var='SRCPV', flag='_content', expand=True,
> noweakdefault=False, parsing=False):
> cachename = var + "[" + flag + "]"
> >value = self.expand(value, cachename)
>
> File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py",
> line 436, in DataSmart.expand(s='${@bb.fetch2.get_srcrev(d)}',
> varname='SRCPV'):
> def expand(self, s, varname = None):
> >return self.expandWithRefs(s, varname).value
>
> File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py",
> line 426, in DataSmart.expandWithRefs(s='${@bb.fetch2.get_srcrev(d)}',
> varname='SRCPV'):
> except Exception as exc:
> >raise ExpansionError(varname, s, exc) from exc
>
> bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression
> was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher
> failure: Fetch command export GIT_SSL_CAINFO="/home
> /martin/gomspace_sdk/buildtools/sysroots/x86_64-gomspacesdk-linux/etc/ssl/certs/ca-certificates.crt";
> export
> PATH="/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0
> /recipe-sysroot-native/usr/bin/python-native:/home/martin/gomspace_sdk/layers/poky/scripts:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/u
> sr/bin/aarch64-gomspace-linux:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot/usr/bin/crossscripts:/home/martin/gomspace_sdk/tmp/work/aarch64-gomsp
> ace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/sbin:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/bin:/home/marti
> n/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/sbin:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-s
> ysroot-native/bin:/home/martin/gomspace_sdk/layers/poky/bitbake/bin:/home/martin/gomspace_sdk/tmp/hosttools";
> export HOME="/home/martin"; git -c core.fsyncobjectfiles=0 ls-remote
> ssh://g...@github.com/GomS
> pace/libisl failed with exit code 128, output:
> Host key verification failed.
> fatal: Could not read from remote repository.
>
>
> Please make sure you have the correct access rights
> and the repository exists.
>
> It is not the intention that third party will ever need access to the
> development version, and I don't see why the version information is fetched
> given the reduced priority. Have I encountered an 'undocumented bug' or is
> there an alternate approach to achieve this?
AUTOREV is floating dependency, fetcher has to ensure to get a value
for it to populate version strings
before comparing which one to use. you might be able to use BBMASK
effectively to eliminate these
recips from parsers visibility completely.
Thanks, BBMASK seems to do the trick...
>
> Thanks,
> Martin
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-selinux][PATCH v2] systemd: create /var/lib/systemd/backlight in advance
From: Wenzong Fan
v2 changes:
* Update patch for Yocto Compat - don't change layer's hash
The systemd-backlight@.service which called after selinux-init.service
will create /var/lib/systemd/backlight with incorrect security labels,
this causes the systemd-backlight service fails to start and stop.
Creating /var/lib/systemd/backlight in advance to make sure it could
always be relabelled by selinux-init while first booting.
Signed-off-by: Wenzong Fan
---
recipes-core/systemd/systemd_%.bbappend | 2 +-
recipes-core/systemd/systemd_selinux.inc | 7 +++
2 files changed, 8 insertions(+), 1 deletion(-)
create mode 100644 recipes-core/systemd/systemd_selinux.inc
diff --git a/recipes-core/systemd/systemd_%.bbappend
b/recipes-core/systemd/systemd_%.bbappend
index 5ac3adb..7719d3b 100644
--- a/recipes-core/systemd/systemd_%.bbappend
+++ b/recipes-core/systemd/systemd_%.bbappend
@@ -1 +1 @@
-inherit ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'enable-audit', '',
d)}
+require ${@bb.utils.contains('DISTRO_FEATURES', 'selinux',
'${BPN}_selinux.inc', '', d)}
diff --git a/recipes-core/systemd/systemd_selinux.inc
b/recipes-core/systemd/systemd_selinux.inc
new file mode 100644
index 000..b17e70a
--- /dev/null
+++ b/recipes-core/systemd/systemd_selinux.inc
@@ -0,0 +1,7 @@
+inherit ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'enable-audit', '',
d)}
+
+do_install_append() {
+ if ${@bb.utils.contains('PACKAGECONFIG', 'backlight', 'true', 'false',
d)}; then
+ install -d ${D}${localstatedir}/lib/systemd/backlight
+ fi
+}
--
2.8.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Usage of yocto on different (production vs debug) scenarios
Hi!
On Fri, Apr 20, 2018 at 10:59 AM, Iván Castell
wrote:
> We are trying to use yocto in a continuous integration environment with
> different (production vs debug) scenarios.
>
> To setup a given scenario (production vs debug) we are using something like
> this:
>
> $ SCENARIO=debug
> $ MACHINE= DISTRO=-${SCENARIO} source
> ../../build--${SCENARIO}
> $ bitbake -${SCENARIO}
>
> So we have different image recipes:
>
> * image-production.bb
> * image-debug.bb
>
> Different distros:
>
> * distro-production.conf
> * distro-debug.conf
>
> And different build directories:
>
> * build--production
> * build--debug
>
> To optimize space usage and compilation time, we setup a shared sstate
> cache and a shared directory for downloads. This seems a good starting
> point.
Shared download, yes.
But can you share state between distros? Isn't the purpose of distros to
use different options (variable settings) so the state would always be
different?
(Please note: This is really a follow-up question, not me knowing
better. I am just trying to fully understand these concepts)
> However, things are getting complicated, because there is no way to
> exclude some recipes easily. For example, we don't want iptables
> installed on the debug image, but dependency chains include iptables
> by default
Doesn't blacklist do what you want?
E.g. in your distro-production.conf
PNBLACKLIST[iptables] = "we don't want iptables in product"
Of course if something has a hard dependency on iptables, the something
might need blacklisting instead or too.
Regards,
Uwe Geuder
Neuro Event Labs Oy
Tampere, Finland
uwe.gex...@neuroeventlabs.com (Bot check: fix one obvious typo)
> even when declaring IMAGE_INSTALL_remove explicitly. In this case we
> decided checking _%.bbappend to decide what rules are installed on ion
> vs rules.debug).
>
> hod is poisoning all our recipes with that kind of
>
>
> right way to manage this? Can you suggest a
> ay to deal with this?
>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to patch a file in mysql recipe
Hi Greg,
On 2018-04-19 00:06, Greg Wilson-Lindberg wrote:
I need to patch the my.cnf file that is part of the mysql/mariadb
recipe. It lives in
meta-openembedded/meta-oe/recipes-support/mysql/mariadb/my.cnf with the
mariadb_5.5.52.bb file one level down.
I've set up a mariadb_5.5.52.bbappend file as:
FILESEXTRAPATHS_prepend := "${FILE_DIRNAME}/${PN}:"
SRC_URI += "file://my.cnf.patch"
# need to enable auto startup
SYSTEMD_AUTO_ENABLE_${PN}-server = "enable"
bitbake finds the my.cnf.patch file but reports that it can't find the
my.cnf file to patch. I've set up patching of files that are downloaded
as part of a source tree, but never tried to patch a file that is part
of a recipe, and apparently I'm missing something. Is it possible to do
this, and if so, can someone point out what I need to do to do it
correctly?
External sources usually lives in ${S}, while recipe local sources are
placed in ${WORKDIR}. To make OE apply the patch in ${WORDIR} instead of
${S}, add the "patchdir"[1] option to the SRC_URI:
SRC_URI += "file://my.cnf.patch;patchdir=${WORKDIR}"
I haven't used this myself, though, so I might be wrong...
// Martin
[1]
https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-patching-code
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Usage of yocto on different (production vs debug) scenarios
Hi,
had a similar question recently (search How did you separate release
and development builds?)
We have the split like this for now
The release build would be something like:
- has all the functions for production
- attack surface is limited (no ssh, only the required apps)
- config files set with real endpoints (logging or crash servers etc.)
But that's not an image you can really develop on given all the constrains.
So there is also a need for a development image:
- inherits the functions available on production image + debug tools
- developer continence over security (debuggers, ssh access etc.)
- configs set not to depend on payed cloud services
Both are built as a same distro, but are different images.
So far it works ok.
However still haven't experienced the need to have different
configurations for the same recipe, that would probably complicate things.
On Fri, Apr 20, 2018 at 12:47 PM, Uwe Geuder wrote:
> Hi!
>
> On Fri, Apr 20, 2018 at 10:59 AM, Iván Castell
> wrote:
>
>> We are trying to use yocto in a continuous integration environment with
>> different (production vs debug) scenarios.
>>
>> To setup a given scenario (production vs debug) we are using something like
>> this:
>>
>> $ SCENARIO=debug
>> $ MACHINE= DISTRO=-${SCENARIO} source
>> ../../build--${SCENARIO}
>> $ bitbake -${SCENARIO}
>>
>> So we have different image recipes:
>>
>> * image-production.bb
>> * image-debug.bb
>>
>> Different distros:
>>
>> * distro-production.conf
>> * distro-debug.conf
>>
>> And different build directories:
>>
>> * build--production
>> * build--debug
>>
>> To optimize space usage and compilation time, we setup a shared sstate
>> cache and a shared directory for downloads. This seems a good starting
>> point.
>
> Shared download, yes.
>
> But can you share state between distros? Isn't the purpose of distros to
> use different options (variable settings) so the state would always be
> different?
>
> (Please note: This is really a follow-up question, not me knowing
> better. I am just trying to fully understand these concepts)
>
>
>> However, things are getting complicated, because there is no way to
>> exclude some recipes easily. For example, we don't want iptables
>> installed on the debug image, but dependency chains include iptables
>> by default
>
> Doesn't blacklist do what you want?
>
> E.g. in your distro-production.conf
>
> PNBLACKLIST[iptables] = "we don't want iptables in product"
>
>
> Of course if something has a hard dependency on iptables, the something
> might need blacklisting instead or too.
>
>
> Regards,
>
> Uwe Geuder
> Neuro Event Labs Oy
> Tampere, Finland
> uwe.gex...@neuroeventlabs.com (Bot check: fix one obvious typo)
>
>
>
>
>> even when declaring IMAGE_INSTALL_remove explicitly. In this case we
>> decided checking _%.bbappend to decide what rules are installed on ion
>> vs rules.debug).
>>
>> hod is poisoning all our recipes with that kind of
>>
>>
>> right way to manage this? Can you suggest a
>> ay to deal with this?
>>
>>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Usage of yocto on different (production vs debug) scenarios
Following up on my own message... On Fri, Apr 20, 2018 at 1:47 PM, Uwe Geuder wrote: > On Fri, Apr 20, 2018 at 10:59 AM, Iván Castell > wrote: > [...] >> However, things are getting complicated, because there is no way to >> exclude some recipes easily. For example, we don't want iptables >> installed on the debug image, but dependency chains include iptables >> by default > > Doesn't blacklist do what you want? > > E.g. in your distro-production.conf > > PNBLACKLIST[iptables] = "we don't want iptables in product" > As recently mentioned in another thread on this list there is also BBMASK. https://lists.yoctoproject.org/pipermail/yocto/2018-April/040861.html I don't know what would be the suitable/most idiomatic use cases for PNBLACKLIST vs. BBMASK Regards, Uwe Geuder Neuro Event Labs Oy Tampere, Finland uwe.gex...@neuroeventlabs.com (Bot check: fix one obvious typo) -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Usage of yocto on different (production vs debug) scenarios
On Fri, Apr 20, 2018 at 8:59 AM, Iván Castell wrote:
>
> Hello forum.
>
> We are trying to use yocto in a continuous integration environment with
> different (production vs debug) scenarios.
>
> To setup a given scenario (production vs debug) we are using something like
> this:
>
> $ SCENARIO=debug
> $ MACHINE= DISTRO=-${SCENARIO} source
> ../../build--${SCENARIO}
> $ bitbake -${SCENARIO}
>
> So we have different image recipes:
>
> * image-production.bb
> * image-debug.bb
>
> Different distros:
>
> * distro-production.conf
> * distro-debug.conf
>
> And different build directories:
>
> * build--production
> * build--debug
>
> To optimize space usage and compilation time, we setup a shared sstate cache
> and a shared directory for downloads. This seems a good starting point.
>
> However, things are getting complicated, because there is no way to exclude
> some recipes easily. For example, we don't want iptables installed on the
> debug image, but dependency chains include iptables by default even when
> declaring IMAGE_INSTALL_remove explicitly. In this case we decided checking
> SCENARIO inside iptables_%.bbappend to decide what rules are installed on
> the image (rules.production vs rules.debug).
>
> But at the end, this method is poisoning all our recipes with that kind of
> ugly controls [...]
>
> Do you think this is the right way to manage this? Can you suggest a
> better/more convenient way to deal with this?
>
> Thank you in advance! :)
We're using the IMAGE_MODE stuff:
https://github.com/intel/intel-iot-refkit/blob/master/meta-refkit-core/classes/image-mode.bbclass
and then add things like this to the image:
CORE_IMAGE_EXTRA_INSTALL += "\
${@ '' if (d.getVar('IMAGE_MODE') or 'production') == 'production'
else 'packagegroup-core-full-cmdline' } \
"
--
Alex Kiernan
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to install kernel objects in /lib
Hi,
I made a recipe to build and install a kernel object. See
SUMMARY = "Kernel module for EPIX grabber"
LICENSE = "CLOSED"
inherit module
SRC_URI = "file://Makefile \
file://pixcilnx_aarch64_4.4.a \
file://pixcipub.c \
file://pixcipub.h \
file://pixci.rc \
file://pixci.conf \
"
S = "${WORKDIR}"
# The inherit of module.bbclass will automatically name module packages with
# "kernel-module-" prefix as required by the oe-core build environment.
do_install() {
# First create the directories
install -d
${D}${base_libdir}/modules/${KERNEL_VERSION}/kernel/drivers/misc
install -d ${D}${sysconfdir}/init.d
install -d ${D}${sysconfdir}/default/
# Then add the files
install -m 555 -g root -o root ${B}/pixci.ko ${D}${base_libdir
}/modules/${KERNEL_VERSION}/kernel/drivers/misc/pixci.ko
install -m 555 -g root -o root ${WORKDIR}/pixci.rc
${D}${sysconfdir}/init.d/pixci
install -m 644 -g root -o root ${WORKDIR}/pixci.conf
${D}${sysconfdir}/default/pixci
}
# Include all installed files from /etc and /lib
FILES_${PN} += "${base_libdir
}/modules/${KERNEL_VERSION}/kernel/drivers/misc/pixci.ko"
FILES_${PN} += "${sysconfdir}/init.d/pixci"
FILES_${PN} += "${sysconfdir}/default/pixci"
If I use base_libdir to install the kernel object where the scripts expect
it to be, I get an error:
nothing provides kernel-module-pixci-4.4.38-l4t-r28.1+g79e4600 needed by
pixci-3.8.01-r0.jetson_tx2
But if I use libdir variable the kernel object is packages and installed
properly.
Could anyone explain me why?
Thanks,
-Damien
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] creating your own distro layer
Hi! I have inherited our custom distro layer (heavily based on poky), but I am not sure whether it has been coded correctly. It produces working images, but certain weird symptoms when working with bitbake made me to double-check the code. I'm reading https://www.yoctoproject.org/docs/2.4.2/mega-manual/mega-manual.html#creating-your-own-distribution It says: > Create the distribution configuration file: The distribution > configuration file needs to be created in the conf/distro directory > of your layer. You need to name it using your distribution name > (e.g. mydistro.conf). That seems clear to me. It continues: > Note: The DISTRO variable in your local.conf file determines the > name of your distribution. I find that statement somewhat ambiguous. Didn't we just read above that the name of the distro is determined by the distro/.conf file? And in general case you have several of them. So at least I would find it easier to understand if the note read something like The DISTRO variable in your local.conf file selects which distro to build. The wording in the manual might make sense if you think of the distribution as a build product. But it doesn't make any sense to me when thinking about distro metadata. And that's what the reader of that section is likely to look at/edit in this moment. Or do I miss something here? The confusion continues. The manual says > Your configuration file needs to set the following required variables: >DISTRO_NAME >DISTRO_VERSION If I look into https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-poky/conf/distro/poky-tiny.conf?h=rocko it does not set a DISTRO_NAME. Well, it gets a DISTRO_NAME from > require conf/distro/poky.conf So assuming that poky-tiny and poky are diffferent distros, should they really share the same name? Maybe there is something like a distro and a distro variant, but I could not find any such concept in the manual. Sometimes I see references to a poky-based distro, though. I assume the DISTRO_NAME is mostly cosmetic / for humans. So not that much to worry about? But the DISTRO variable seems to be central for the build process. There is a test in script yocto-check-layer that the distro config file does not set the DISTRO variable. When running yocto-check-layer on our own distro layer I got a failure for setting DISTRO. So I treid to remove the variable setting. But that results in my DISTRO variable ending up being set to "yocto". I think it goes like this 1.) my local.conf sets DISTRO to my own one 2.) in consequence my own distro conf file gets processed 3.) it does "require" of yocto.conf and that resets the DISTRO value to "yocto" 4.) (originally our own distro config file reset the value to our own name after the "require". So the name was "correct" in the end. But yocto-check-layer did not like that) So what is wrong here? Why does the poky code violate the test condition of not setting DISTRO? Or is nobody supposed to "require" poky.conf? I could of course copy the contents, but copying code is usually not a good idea. Thanks for reading until here, couldn't formulate it shorter... Uwe Geuder Neuro Event Labs Oy Tampere, Finland uwe.gex...@neuroeventlabs.com (Bot check: fix one obvious typo) -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to patch a file in mysql recipe
Hi Martin,
Your suggestion worked just fine, Thanks for the suggestion.
Regards,
Greg
> -Original Message-
> From: Martin Hundebøll [mailto:m...@prevas.dk]
> Sent: Thursday, April 19, 2018 10:39 PM
> To: Greg Wilson-Lindberg ; yocto@yoctoproject.org
> Subject: Re: [yocto] How to patch a file in mysql recipe
>
> Hi Greg,
>
> On 2018-04-19 00:06, Greg Wilson-Lindberg wrote:
> > I need to patch the my.cnf file that is part of the mysql/mariadb
> > recipe. It lives in
> > meta-openembedded/meta-oe/recipes-support/mysql/mariadb/my.cnf with
> > the mariadb_5.5.52.bb file one level down.
> >
> > I've set up a mariadb_5.5.52.bbappend file as:
> >
> > FILESEXTRAPATHS_prepend := "${FILE_DIRNAME}/${PN}:"
> >
> > SRC_URI += "file://my.cnf.patch"
> >
> > # need to enable auto startup
> > SYSTEMD_AUTO_ENABLE_${PN}-server = "enable"
> >
> > bitbake finds the my.cnf.patch file but reports that it can't find the
> > my.cnf file to patch. I've set up patching of files that are
> > downloaded as part of a source tree, but never tried to patch a file
> > that is part of a recipe, and apparently I'm missing something. Is it
> > possible to do this, and if so, can someone point out what I need to
> > do to do it correctly?
>
> External sources usually lives in ${S}, while recipe local sources are placed
> in
> ${WORKDIR}. To make OE apply the patch in ${WORDIR} instead of ${S}, add the
> "patchdir"[1] option to the SRC_URI:
>
> SRC_URI += "file://my.cnf.patch;patchdir=${WORKDIR}"
>
> I haven't used this myself, though, so I might be wrong...
>
> // Martin
>
> [1]
> https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-
> recipe-patching-code
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH][meta-mingw] diffutils: update sdiff kill() patch to be a backport
Signed-off-by: Ross Burton --- .../diffutils/diffutils/sdiff-no-kill.patch| 30 -- 1 file changed, 22 insertions(+), 8 deletions(-) diff --git a/recipes-extended/diffutils/diffutils/sdiff-no-kill.patch b/recipes-extended/diffutils/diffutils/sdiff-no-kill.patch index 70e7caf..c9fbc24 100644 --- a/recipes-extended/diffutils/diffutils/sdiff-no-kill.patch +++ b/recipes-extended/diffutils/diffutils/sdiff-no-kill.patch @@ -1,18 +1,32 @@ -"kill" is not supported by mingw, so compile conditionally, -(same condition as another instance of "kill" in the source code). +Upstream-Status: Backport +Signed-off-by: Ross Burton -Upstream-Status: Pending -Signed-off-by: Juro Bystricky +From 56225ecca4f9598c0c9dbd7c46a51dd4816a383f Mon Sep 17 00:00:00 2001 +From: Paul Eggert +Date: Fri, 20 Apr 2018 13:39:15 -0700 +Subject: sdiff: port to mingw +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit +Problem reported by Ross Burton (Bug#31218). +* src/sdiff.c (checksigs): Use ‘raise’, not ‘kill’. +--- + src/sdiff.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/src/sdiff.c b/src/sdiff.c +index 1b23a0c..b08bc74 100644 --- a/src/sdiff.c +++ b/src/sdiff.c -@@ -805,7 +805,9 @@ +@@ -805,7 +805,7 @@ checksigs (void) /* Yield an exit status indicating that a signal was received. */ untrapsig (s); -+#if HAVE_WORKING_FORK - kill (getpid (), s); -+#endif +- kill (getpid (), s); ++ raise (s); /* That didn't work, so exit with error status. */ exit (EXIT_TROUBLE); +-- +cgit v1.0-41-gc330 -- 2.11.0 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-gplv2][sumo][rocko][PATCH] bash: Provide /bin/{sh, bash} when usrmerge is used
Most shell scripts have '#!/bin/{sh,bash}' on the first line of the
script, which triggers RPM to automatically add a runtime dependency
on that path for any package that contains shell scripts. However,
when the usrmerge feature is enabled, the path will actually be
/usr/bin/{sh,bash}.
So, to satisfy the runtime dependencies, add '/bin/{sh,bash}' to what
the bash package provides.
Signed-off-by: Peter Kjellerstedt
---
recipes-extended/bash/bash.inc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/recipes-extended/bash/bash.inc b/recipes-extended/bash/bash.inc
index a05b987..0f0d679 100644
--- a/recipes-extended/bash/bash.inc
+++ b/recipes-extended/bash/bash.inc
@@ -65,3 +65,5 @@ pkg_postinst_${PN} () {
pkg_postrm_${PN} () {
printf "$(grep -v "^${base_bindir}/bash$" $D${sysconfdir}/shells)\n" >
$D${sysconfdir}/shells
}
+
+RPROVIDES_${PN} += "${@bb.utils.contains('DISTRO_FEATURES', 'usrmerge',
'/bin/sh /bin/bash', '', d)}"
--
2.12.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-gplv2][sumo][rocko][PATCH] bash: Provide /bin/{sh, bash} when usrmerge is used
> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
> On Behalf Of Peter Kjellerstedt
> Sent: den 21 april 2018 03:31
> To: yocto@yoctoproject.org
> Subject: [yocto] [meta-gplv2][sumo][rocko][PATCH] bash: Provide /bin/{sh,
> bash} when usrmerge is used
>
> Most shell scripts have '#!/bin/{sh,bash}' on the first line of the
> script, which triggers RPM to automatically add a runtime dependency
> on that path for any package that contains shell scripts. However,
> when the usrmerge feature is enabled, the path will actually be
> /usr/bin/{sh,bash}.
>
> So, to satisfy the runtime dependencies, add '/bin/{sh,bash}' to what
> the bash package provides.
>
> Signed-off-by: Peter Kjellerstedt
> ---
> recipes-extended/bash/bash.inc | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/recipes-extended/bash/bash.inc b/recipes-extended/bash/bash.inc
> index a05b987..0f0d679 100644
> --- a/recipes-extended/bash/bash.inc
> +++ b/recipes-extended/bash/bash.inc
> @@ -65,3 +65,5 @@ pkg_postinst_${PN} () {
> pkg_postrm_${PN} () {
> printf "$(grep -v "^${base_bindir}/bash$" $D${sysconfdir}/shells)\n" >
> $D${sysconfdir}/shells
> }
> +
> +RPROVIDES_${PN} += "${@bb.utils.contains('DISTRO_FEATURES', 'usrmerge',
> '/bin/sh /bin/bash', '', d)}"
> --
> 2.12.0
This change is needed for both Sumo and Rocko, and corresponds to
commit 4759408677a4e60c5fa7131afcb5bc184cf2f90a in OE-Core.
//Peter
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
