Re: [yocto] [PATCH 1/2] ref-manual: Document the fifth argument to PACKAGECONFIG
Peter,
Thanks for the patch. See
https://yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#var-PACKAGECONFIG
for the changes.
Commit:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/commit/?id=adb17e3172c829de77d2664c91f7cf4b22c9e5f0
Scott
On Thu, Dec 13, 2018 at 3:24 AM Peter Kjellerstedt <
peter.kjellerst...@axis.com> wrote:
> Support for adding runtime recommendations (RRECOMMENDS) using
> PACKAGECONFIG was introduced in Rocko.
>
> Signed-off-by: Peter Kjellerstedt
> ---
> documentation/ref-manual/ref-variables.xml | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/documentation/ref-manual/ref-variables.xml
> b/documentation/ref-manual/ref-variables.xml
> index 58c5418d16..7dc3a3f79a 100644
> --- a/documentation/ref-manual/ref-variables.xml
> +++ b/documentation/ref-manual/ref-variables.xml
> @@ -10333,9 +10333,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR
> = "${INC_PR}.3"
> Here is the basic block structure:
>
> PACKAGECONFIG ??= "f1 f2 f3 ..."
> - PACKAGECONFIG[f1] = "--with-f1,--without-f1,build-deps-f1,rt-deps-f1"
> - PACKAGECONFIG[f2] = "--with-f2,--without-f2,build-deps-f2,rt-deps-f2"
> - PACKAGECONFIG[f3] = "--with-f3,--without-f3,build-deps-f3,rt-deps-f3"
> + PACKAGECONFIG[f1] =
> "--with-f1,--without-f1,build-deps-f1,rt-deps-f1,rt-recs-f1"
> + PACKAGECONFIG[f2] =
> "--with-f2,--without-f2,build-deps-f2,rt-deps-f2,rt-recs-f2"
> + PACKAGECONFIG[f3] =
> "--with-f3,--without-f3,build-deps-f3,rt-deps-f3,rt-recs-f3"
>
>
>
> @@ -10344,7 +10344,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR
> = "${INC_PR}.3"
> variable itself specifies a space-separated list of
> the
> features to enable.
> Following the features, you can determine the
> behavior of
> -each feature by providing up to four order-dependent
> +each feature by providing up to five order-dependent
> arguments, which are separated by commas.
> You can omit any argument you like but must retain the
> separating commas.
> @@ -10370,6 +10370,10 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR
> = "${INC_PR}.3"
> ( linkend='var-RDEPENDS'>RDEPENDS)
> that should be added if the feature is
> enabled.
>
> +Additional runtime recommendations
> +( linkend='var-RRECOMMENDS'>RRECOMMENDS)
> +that should be added if the feature is
> enabled.
> +
>
>
>
> --
> 2.12.0
>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 2/2] ref-manual: Add missing whitespace around "=" in a few code examples
Peter,
Thank you for the patch in the ref-manual. I applied the patch (
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/commit/?id=0d22771c64d082bf86f5efd85ac9aaeb1c7f3093
)
You can see the changes in the upcoming version of the ref-manual. I will
back port as needed too.
http://www.yoctoproject.org/docs/2.7/ref-manual/ref-manual.html.
Scott
On Thu, Dec 13, 2018 at 3:24 AM Peter Kjellerstedt <
peter.kjellerst...@axis.com> wrote:
> Signed-off-by: Peter Kjellerstedt
> ---
> documentation/ref-manual/ref-variables.xml | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/documentation/ref-manual/ref-variables.xml
> b/documentation/ref-manual/ref-variables.xml
> index 7dc3a3f79a..730737226e 100644
> --- a/documentation/ref-manual/ref-variables.xml
> +++ b/documentation/ref-manual/ref-variables.xml
> @@ -7655,9 +7655,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
> "${INC_PR}.3"
>
> KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc
> features/taskstats/taskstats.scc"
> KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
> - KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc"
> - KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
> - KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc"
> + KERNEL_FEATURES_append_qemuall = " cfg/virtio.scc"
> + KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc
> cfg/paravirt_kvm.scc"
> + KERNEL_FEATURES_append_qemux86-64 = " cfg/sound.scc"
>
>
>
> @@ -10422,7 +10422,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR
> = "${INC_PR}.3"
> PACKAGECONFIG.
> You can either completely override the
> variable:
>
> - PACKAGECONFIG="f4 f5"
> + PACKAGECONFIG = "f4 f5"
>
> Or, you can just append the variable:
>
> @@ -10436,7 +10436,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR
> = "${INC_PR}.3"
> As with append files previously described,
> you can either completely override the
> variable:
>
> - PACKAGECONFIG_pn-recipename="f4 f5"
> + PACKAGECONFIG_pn-recipename = "f4 f5"
>
> Or, you can just amend the variable:
>
> --
> 2.12.0
>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Best practices for tokens/passwords that can't be versioned
Thanks for the feedback.
This is a very interesting use case.
By default you want to allow ssh access for the developer who built
the image, cool :)
On Thu, Dec 13, 2018 at 2:59 PM Enrico Scholz
wrote:
>
> Alan Martinovic writes:
>
> > am looking for opinions on how to deal with recipes that depend on file
> > content
> > that can't be versioned.
>
> For ssh public keys we use something like
>
>
> https://github.com/sigma-embedded/meta-de.sigma-chemnitz/blob/thud/classes/elito-image.bbclass#L36-L44
>
> e.g. we take it from ${HOME}/.config/oe (which is a little bit tricky to
> expand).
>
>
> And/or incliude local/side configuration by
>
>
> https://gitlab.com/ensc-groups/bpi-router/BSP/blob/thud-next/build/conf/local.conf#L33-36
>
> which in turn includes something from ~/.config/oe/
>
>
> https://gitlab.com/ensc-groups/bpi-router/BSP/blob/thud-next/build/conf/local_bpi-router.bigo.ensc.de.conf#L9
>
>
> > i.e. The logging service on the embedded device needs to have a
> > certain private key
>
> Note that including private keys in the image usually weakens security
> because the key can be extracted more or less trivially.
>
>
>
> Enrico
> --
> SIGMA Chemnitz GmbH Registergericht: Amtsgericht Chemnitz HRB 1750
> Am Erlenwald 13 Geschaeftsfuehrer: Grit Freitag, Frank Pyritz
> 09128 Chemnitz
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Best practices for tokens/passwords that can't be versioned
Alan Martinovic writes:
> am looking for opinions on how to deal with recipes that depend on file
> content
> that can't be versioned.
For ssh public keys we use something like
https://github.com/sigma-embedded/meta-de.sigma-chemnitz/blob/thud/classes/elito-image.bbclass#L36-L44
e.g. we take it from ${HOME}/.config/oe (which is a little bit tricky to
expand).
And/or incliude local/side configuration by
https://gitlab.com/ensc-groups/bpi-router/BSP/blob/thud-next/build/conf/local.conf#L33-36
which in turn includes something from ~/.config/oe/
https://gitlab.com/ensc-groups/bpi-router/BSP/blob/thud-next/build/conf/local_bpi-router.bigo.ensc.de.conf#L9
> i.e. The logging service on the embedded device needs to have a
> certain private key
Note that including private keys in the image usually weakens security
because the key can be extracted more or less trivially.
Enrico
--
SIGMA Chemnitz GmbH Registergericht: Amtsgericht Chemnitz HRB 1750
Am Erlenwald 13 Geschaeftsfuehrer: Grit Freitag, Frank Pyritz
09128 Chemnitz
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Best practices for tokens/passwords that can't be versioned
Yes! :)
That is what I ended up doing in the end, thanks.
Be Well,
Alan
On Thu, Dec 13, 2018 at 1:45 PM Erik Botö wrote:
>
> On Tue, Dec 11, 2018 at 1:44 PM Alan Martinovic
> wrote:
> >
> > Thanks Erik,
> > guess that could work to and seems cleaner than the env variables.
> >
> > It still leaves the question how to move that content into a static file.
> > For example if in the end the recipe should install a file with "super
> > secret" as the content.
> >
> > Example on the device at runtime:
> > cat /etc/config-passwords
> > super secret
> >
> > The only idea that come to mind is to do something like in the recipe:
> >
> > set_secrets() {
> > echo ${MYSECRETKEY} > ${IMAGE_ROOTFS}/etc/config-passwords
> > }
> > ROOTFS_POSTPROCESS_COMMAND += " set_secrets;"
> >
> > But that seems like a bad practice because it "globalizes" the recipe logic.
> > It's no longer a matter of that recipe but something applied to the
> > whole rootfs.
>
> But couldn't you just place the creation of this secrets file inside a
> regular recipe?
>
> When I have config files that I want to place e.g. secret credentials
> into during build time I ship them with placeholders that I can then
> use sed to modify during e.g. do_install().
>
> E.g. point to file://myconfig in SRC_URI, and maybe myconfig looks
> something like:
> ... tons of options here
> username=###USERNAME###
> password=###PASSWORD###
> ... more config options here
>
> Then during do_install() I do something like:
>
> install -Dm0644 ${WORKDIR}/myconfig ${D}/etc/myconfig
> sed 's,###USERNAME###,${MYSECRETUSER},' -i ${D}/etc/myconfig
> sed 's,###PASSWORD###,${MYSECRETKEY},' -i ${D}/etc/myconfig
>
> That way it will be contained to a recipe and not be something you
> have to do in each image that wants to ship the secrets file.
>
> Cheers,
> Erik
>
> >
> > Be Well,
> > Alan
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Best practices for tokens/passwords that can't be versioned
On Tue, Dec 11, 2018 at 1:44 PM Alan Martinovic
wrote:
>
> Thanks Erik,
> guess that could work to and seems cleaner than the env variables.
>
> It still leaves the question how to move that content into a static file.
> For example if in the end the recipe should install a file with "super
> secret" as the content.
>
> Example on the device at runtime:
> cat /etc/config-passwords
> super secret
>
> The only idea that come to mind is to do something like in the recipe:
>
> set_secrets() {
> echo ${MYSECRETKEY} > ${IMAGE_ROOTFS}/etc/config-passwords
> }
> ROOTFS_POSTPROCESS_COMMAND += " set_secrets;"
>
> But that seems like a bad practice because it "globalizes" the recipe logic.
> It's no longer a matter of that recipe but something applied to the
> whole rootfs.
But couldn't you just place the creation of this secrets file inside a
regular recipe?
When I have config files that I want to place e.g. secret credentials
into during build time I ship them with placeholders that I can then
use sed to modify during e.g. do_install().
E.g. point to file://myconfig in SRC_URI, and maybe myconfig looks
something like:
... tons of options here
username=###USERNAME###
password=###PASSWORD###
... more config options here
Then during do_install() I do something like:
install -Dm0644 ${WORKDIR}/myconfig ${D}/etc/myconfig
sed 's,###USERNAME###,${MYSECRETUSER},' -i ${D}/etc/myconfig
sed 's,###PASSWORD###,${MYSECRETKEY},' -i ${D}/etc/myconfig
That way it will be contained to a recipe and not be something you
have to do in each image that wants to ship the secrets file.
Cheers,
Erik
>
> Be Well,
> Alan
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-selinux] Request for 'thud' branch
Hello, I would like to provide some content[1] for meta-selinux[2], but all this is based/tested on 'thud' only. Would it be possible to create a 'thud' branch and update the corresponding LAYERSERIES_COMPAT_selinux? Thanks Enrico Footnotes: [1] https://gitlab.com/ensc-groups/bpi-router/de.ensc.bpi-router/blob/master/meta-core/classes/selinux-policy.bbclass https://gitlab.com/ensc-groups/bpi-router/de.ensc.bpi-router/tree/master/meta-core/recipes-selinux [2] https://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/2] ref-manual: Document the fifth argument to PACKAGECONFIG
Support for adding runtime recommendations (RRECOMMENDS) using
PACKAGECONFIG was introduced in Rocko.
Signed-off-by: Peter Kjellerstedt
---
documentation/ref-manual/ref-variables.xml | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/documentation/ref-manual/ref-variables.xml
b/documentation/ref-manual/ref-variables.xml
index 58c5418d16..7dc3a3f79a 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -10333,9 +10333,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
"${INC_PR}.3"
Here is the basic block structure:
PACKAGECONFIG ??= "f1 f2 f3 ..."
- PACKAGECONFIG[f1] = "--with-f1,--without-f1,build-deps-f1,rt-deps-f1"
- PACKAGECONFIG[f2] = "--with-f2,--without-f2,build-deps-f2,rt-deps-f2"
- PACKAGECONFIG[f3] = "--with-f3,--without-f3,build-deps-f3,rt-deps-f3"
+ PACKAGECONFIG[f1] =
"--with-f1,--without-f1,build-deps-f1,rt-deps-f1,rt-recs-f1"
+ PACKAGECONFIG[f2] =
"--with-f2,--without-f2,build-deps-f2,rt-deps-f2,rt-recs-f2"
+ PACKAGECONFIG[f3] =
"--with-f3,--without-f3,build-deps-f3,rt-deps-f3,rt-recs-f3"
@@ -10344,7 +10344,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
"${INC_PR}.3"
variable itself specifies a space-separated list of the
features to enable.
Following the features, you can determine the behavior of
-each feature by providing up to four order-dependent
+each feature by providing up to five order-dependent
arguments, which are separated by commas.
You can omit any argument you like but must retain the
separating commas.
@@ -10370,6 +10370,10 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
"${INC_PR}.3"
(RDEPENDS)
that should be added if the feature is enabled.
+Additional runtime recommendations
+(RRECOMMENDS)
+that should be added if the feature is enabled.
+
--
2.12.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/2] ref-manual: Add missing whitespace around "=" in a few code examples
Signed-off-by: Peter Kjellerstedt
---
documentation/ref-manual/ref-variables.xml | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/documentation/ref-manual/ref-variables.xml
b/documentation/ref-manual/ref-variables.xml
index 7dc3a3f79a..730737226e 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -7655,9 +7655,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
"${INC_PR}.3"
KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc
features/taskstats/taskstats.scc"
KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
- KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc"
- KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
- KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc"
+ KERNEL_FEATURES_append_qemuall = " cfg/virtio.scc"
+ KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc cfg/paravirt_kvm.scc"
+ KERNEL_FEATURES_append_qemux86-64 = " cfg/sound.scc"
@@ -10422,7 +10422,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
"${INC_PR}.3"
PACKAGECONFIG.
You can either completely override the variable:
- PACKAGECONFIG="f4 f5"
+ PACKAGECONFIG = "f4 f5"
Or, you can just append the variable:
@@ -10436,7 +10436,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
"${INC_PR}.3"
As with append files previously described,
you can either completely override the variable:
- PACKAGECONFIG_pn-recipename="f4 f5"
+ PACKAGECONFIG_pn-recipename = "f4 f5"
Or, you can just amend the variable:
--
2.12.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Relase or debug by PACKAGECONFIG or MY_APP_VAR?
On Thu, 13 Dec 2018 at 08:20, Mauro Ziliani wrote: > To compile the app in release mode I need set > > EXTRA_OECMAKE + = " -DCMAKE_BUILD_TYPE=Release " > > > while in debug mode I need to set > > EXTRA_OECMAKE + = " -DCMAKE_BUILD_TYPE=Debug " > > > I defined 2 image recipes: one for production (Release) and one for > testing (Debug) > > my-system.bb > > my-system-debug.bb It doesn't matter if you use PACKAGECONFIG or a custom variable, what you want isn't possible. An image can't control how a dependent recipe builds. What are the implications of changing CMAKE_BUILD_TYPE? If it's just whether debug symbols are present or not then this isn't a problem: just enable the IMAGE_FEATURE dbg-pkgs for the debug image. If it does actual code changes, then you'll have to toggle that either in the app recipe itself, or globally. Arguably the cmake class should have a variable to control CMAKE_BUILD_TYPE so it's trivial to override. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[linux-yocto] [kernel-cache][PATCH] features/tpm: enable tpm support
Add tpm feature to intel-common-drivers.scc Signed-off-by: Pradhan Surya Narayanx --- bsp/intel-common/intel-common-drivers.scc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/bsp/intel-common/intel-common-drivers.scc b/bsp/intel-common/intel-common-drivers.scc index fa7168e..e094321 100644 --- a/bsp/intel-common/intel-common-drivers.scc +++ b/bsp/intel-common/intel-common-drivers.scc @@ -56,6 +56,9 @@ include features/media/media-all.scc # Industrial IO Support include features/iio/iio.scc +# TPM +include features/tpm/tpm.scc + # Intel HD Audio include features/sound/snd_hda_intel.scc -- 1.9.1 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[yocto] Relase or debug by PACKAGECONFIG or MY_APP_VAR?
Hi all.
I have an application made with cmake and qt5 by the recipe my-app.bb
To compile the app in release mode I need set
EXTRA_OECMAKE + = " -DCMAKE_BUILD_TYPE=Release "
while in debug mode I need to set
EXTRA_OECMAKE + = " -DCMAKE_BUILD_TYPE=Debug "
I defined 2 image recipes: one for production (Release) and one for
testing (Debug)
my-system.bb
my-system-debug.bb
Both my-system.bb and my-system-debug.bb have
IMAGE_INSTALL_append = " my-app "
But for my-system-debug.bb I'd like to set CMAKE_BUILD_TYPE=Debug for
my-app.bb
How can I do that?
Now I try to define my-app.bb the variable
...
MY_APP_BUILD_TYPE ?= "Release"
EXTRA_OECMAKE + = " -DCMAKE_BUILD_TYPE=${MY_APP_BUILD_TYPE} "
...
And in my-system-debug.bb I set
MY_APP_BUILD_TYPE = "Debug"
Or I need to use PACKAGECONFIG?
Best regards,
Mauro
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
