[yocto] yocto Digest, Vol 93, Issue 45
Chan, Aaron Chun Yew
aaron.chun.yew.chan at intel.com
Tue Jun 26 00:55:30 PDT 2018
Hi Richard,
Did you manage to take a look at this patch ?
Regards,
Aaron
-----Original Message-----
From: yocto-bounces at yoctoproject.org [mailto:yocto-bounces at yoctoproject.org] On Behalf Of yocto-request at yoctoproject.org
Sent: Wednesday, June 13, 2018 6:23 PM
To: yocto at yoctoproject.org
Subject: yocto Digest, Vol 93, Issue 45
Send yocto mailing list submissions to
yocto at yoctoproject.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.yoctoproject.org/listinfo/yocto
or, via email, send a message with subject or body 'help' to
yocto-request at yoctoproject.org
You can reach the person managing the list at
yocto-owner at yoctoproject.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of yocto digest..."
Today's Topics:
1. [PATCH] [yocto-autobuilder2] Add support to enable Manual BSP
on LAVA (Aaron Chan)
2. Re: mono-native is trying to install files into a shared
area... (Alex Lennon)
3. Re: Image specific configuration files (Iv?n Castell)
----------------------------------------------------------------------
Message: 1
Date: Wed, 13 Jun 2018 15:07:58 +0800
From: Aaron Chan <aaron.chun.yew.chan at intel.com>
To: yocto at yoctoproject.org
Cc: Aaron Chan <aaron.chun.yew.chan at intel.com>
Subject: [yocto] [PATCH] [yocto-autobuilder2] Add support to enable
Manual BSP on LAVA
Message-ID:
<1528873678-17502-1-git-send-email-aaron.chun.yew.chan at intel.com>
Signed-off-by: Aaron Chan <aaron.chun.yew.chan at intel.com>
---
config.py | 9 +++++++++
schedulers.py | 9 +++++++--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/config.py b/config.py
index 2568768..d21948f 100644
--- a/config.py
+++ b/config.py
@@ -80,3 +80,12 @@ builder_to_workers = {
"nightly-deb-non-deb": [],
"default": workers
}
+
+# Supported LAVA-Linaro on Yocto Project # Enable Automated
+Manual(Hardware) BSP Test case(s) enable_hw_test = {
+ "enable": False,
+ "lava_user" : "<Specify a valid user connected to LAVA-server>",
+ "lava_token" : "<Specify token generated from LAVA profile>",
+ "lava_server" : "<Specify LAVA-server URL <server>:<port>"
+}
diff --git a/schedulers.py b/schedulers.py index 8f3dbc5..2c1b8e1 100644
--- a/schedulers.py
+++ b/schedulers.py
@@ -63,9 +63,14 @@ def props_for_builder(builder):
props.append(util.BooleanParameter(
name="deploy_artifacts",
label="Do we want to deploy artifacts? ",
- default=Boolean
+ default=False
+ ))
+ if builder in ['nightly-x86-64', 'nightly-x86-64-lsb', 'nightly-arm', 'nightly-arm-lsb', 'nightly-arm64']:
+ props.append(util.BooleanParameter(
+ name="enable_hw_test",
+ label="Enable BSP Test case(s) on Hardware?",
+ default=config.enable_hw_test['enable']
))
-
props = props + repos_for_builder(builder)
return props
--
2.7.4
------------------------------
Message: 2
Date: Wed, 13 Jun 2018 10:50:49 +0100
From: Alex Lennon <ajlennon at gmail.com>
To: Craig McQueen <craig.mcqueen at innerrange.com>
Cc: "yocto at yoctoproject.org" <yocto at yoctoproject.org>
Subject: Re: [yocto] mono-native is trying to install files into a
shared area...
Message-ID: <f1091f7c-f86e-a84d-8a5a-7ed3192a1598 at gmail.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 12/06/2018 05:43, Khem Raj wrote:
>
>
> On Mon, Jun 11, 2018 at 8:36 PM Craig McQueen
> <craig.mcqueen at innerrange.com <mailto:craig.mcqueen at innerrange.com>>
> wrote:
>
> I wrote:
> >
> > I wrote:
> > >
> > > Lately, I'm trying to upgrade to a later version of mono, 5.4.1.6.
> > > When I try to do a build of my Yocto image, bitbake gets to
> the end of
> > > building mono- native, and then gets an error:
> > >
> > >
> > > ERROR: mono-native-5.4.1.6-r0 do_populate_sysroot: The recipe
> mono-
> > > native is trying to install files into a shared area when
> those files already
> > exist.
> > > Those files and their manifest location are:
> > > /home/craigm/yocto/poky/build/tmp/sysroots/x86_64-
> > > linux/usr/lib/mono/lldb/mono.py
> > >? Matched in b''
> > > /home/craigm/yocto/poky/build/tmp/sysroots/x86_64-
> > > linux/usr/lib/mono/4.6.1-api/System.Web.Http.SelfHost.dll
> > >? Matched in b''
> > > ...
> > > /home/craigm/yocto/poky/build/tmp/sysroots/x86_64-
> > >
> >
> linux/usr/lib/mono/xbuild/14.0/bin/MSBuild/Microsoft.Build.CommonTypes.
> > > xsd
> > >? Matched in b''
> > > /home/craigm/yocto/poky/build/tmp/sysroots/x86_64-
> > >
> linux/usr/lib/mono/xbuild/14.0/bin/MSBuild/Microsoft.Build.Core.xsd
> > >? Matched in b''
> > > /home/craigm/yocto/poky/build/tmp/sysroots/x86_64-
> > >
> >
> linux/usr/lib/mono/xbuild/14.0/Microsoft.Common.targets/ImportAfter/Mi
> > > c
> > > rosoft.NuGet.ImportAfter.targets
> > >? Matched in b''
> > > Please verify which recipe should provide the above files.
> > > The build has stopped as continuing in this scenario WILL break
> > > things, if not now, possibly in the future (we've seen builds fail
> > > several months later). If the system knew how to recover from this
> > > automatically it would however there are several different
> scenarios
> > > which can result in this and we don't know which one this is.
> It may
> > > be you have switched providers of something like
> virtual/kernel (e.g.
> > > from linux-yocto to linux-yocto-dev), in that case you need to
> execute the
> > clean task for both recipes and it will resolve this error.
> > > It may be you changed DISTRO_FEATURES from systemd to udev or vice
> > > versa. Cleaning those recipes should again resolve this error
> however
> > > switching DISTRO_FEATURES on an existing build directory is not
> > > supported, you should really clean out tmp and rebuild
> (reusing sstate
> > > should be safe). It could be the overlapping files detected are
> > > harmless in which case adding them to SSTATE_DUPWHITELIST may
> be the
> > > correct solution. It could also be your buil? d is including two
> > > different conflicting versions of things (e.g. bluez
> > > 4 and bluez 5 and the correct solution for that would be to
> resolve
> > > the conflict. If in doubt, please ask on the mailing list,
> sharing the
> > > error and filelist above.
> > > ERROR: mono-native-5.4.1.6-r0 do_populate_sysroot: If the above
> > > message is too much, the simpler version is you're advised to
> wipe out
> > > tmp and rebuild (reusing sstate is fine). That will likely fix
> things
> > > in most (but not all) cases.
> > > ERROR: mono-native-5.4.1.6-r0 do_populate_sysroot: Function
> failed:
> > > sstate_task_postfunc
> > > ERROR: Logfile of failure stored in:
> > > /home/craigm/yocto/poky/build/tmp/work/x86_64-linux/mono-
> > > native/5.4.1.6-r0/temp/log.do_populate_sysroot.108358
> > > ERROR: Task
> (/home/craigm/yocto/poky/build/../../meta-mono/recipes-
> > > mono/mono/mono-native_5.4.1.6.bb:do_populate_sysroot) failed with
> > exit
> > > code '1'
> > > NOTE: Tasks Summary: Attempted 670 tasks of which 662 didn't
> need to
> > > be rerun and 1 failed.
> > >
> > > Summary: 1 task failed:
> > > ?/home/craigm/yocto/poky/build/../../meta-mono/recipes-
> > > mono/mono/mono-native_5.4.1.6.bb:do_populate_sysroot
> > > Summary: There were 3 ERROR messages shown, returning a
> non-zero exit
> > > code.
> > >
> > >
> > > I'm building with Yocto poky morty branch (currently commit
> > > 0e730770a9), meta-mono master (commit dced6635ca). I'm building on
> > Ubuntu 16.04.4.
> > >
> > > I have tried deleting the tmp directory, deleting all mono and
> > > mono-native from sstate, cleaning mono and meta-mono, etc, to
> no avail.
> > >
> > > It's puzzling why I'm getting these errors, because it says
> "Matched
> > > in b''", so the files are not clashing with another recipe. It
> seems
> > > to be somehow trying to install its own files twice, or
> something like
> > > that. If I look under
> tmp/work/x86_64-linux/mono-native/5.4.1.6-r0/,
> > > then I see the files present in both:
> > >
> > > sysroot-destdir/home/craigm/yocto/poky/build/tmp/sysroots/x86_64-
> > linux
> > > / and
> image/home/craigm/yocto/poky/build/tmp/sysroots/x86_64-linux/
> > >
> > > Is that part of the problem?
> >
> >
> > I haven't had any success figuring out what is going on. I tried
> doing a new
> > clean build, and got the same error.
> >
> > Does anyone else have this problem? Is it an incompatibility
> with Yocto
> > morty, which I'm using? Any pointers on how to narrow down the
> cause?
>
> I tried updating from morty to rocko, and no longer got this
> error. So it seems it's somehow an issue with meta-mono in
> conjunction with morty.
>
>
> That?s due to the fact that Rocko onwards OE switched to using recipe
> specific sysroots
>
Hey Craig,
There was an separate issue with the morty branch building which
hopefully I've resolved with a recent cherry-pick.
I'm not intending atm to update support for more recent releases of Mono
on Morty due to the issue you've identified above.
(This is because I think it's more valuable to put the time I have
available into supporting the current Mono release on master, T-P etc. -
which I'll hopefully be looking at shortly).
I'd be very pleased to receive PRs though if you have the time to
address this...
Cheers,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20180613/4efe202c/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 13 Jun 2018 12:22:52 +0200
From: Iv?n Castell <icastell at nayarsystems.com>
To: Ulf Samuelsson <ulf.samuelsson at external.atlascopco.com>
Cc: Yocto discussion list <yocto at yoctoproject.org>
Subject: Re: [yocto] Image specific configuration files
Message-ID:
<CAALXFYzjfgXYsbSgdwg3uh5a-G6S_=X6PPQEKGuBur=4TM4-uQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Very useful information!
This is the first time I understand this bbclass and BBCLASSEXTEND
mechanism (I was unable to understand it after reading documentation again
and again).
I managed implementing a custom but working solution.
Thanks a lot for sharing Mr Ulf! :)
2018-06-01 13:44 GMT+02:00 Ulf Samuelsson <
ulf.samuelsson at external.atlascopco.com>:
> Here is the idea developed at Atlas Copco.
>
> Not my code, but I thought it useful for this problem
>
>
> define three bbclasses.
>
> production.bbclass, rnd.bbclass, release.bbclass containing:
>
> ==========================
>
> # Class for use in BBCLASSEXTEND to make it easier to have a single recipe
> that
> # build and generate packages separately for release and normal images.
> #
> # Usage:
> # BBCLASSEXTEND = "release"
>
> CLASSOVERRIDE .= ":class-release"
>
> python release_virtclass_handler () {
> # Do nothing if this is inherited, as it's for BBCLASSEXTEND
> if "release" not in (d.getVar('BBCLASSEXTEND') or ""):
> bb.error("Don't inherit release, use BBCLASSEXTEND")
> return
>
> # Restore BPN
> bpn = d.getVar('BPN')
> newbpn = bpn.replace('-release', '')
> d.setVar('BPN', newbpn)
>
> # Use default FILESPATH searching for patches and files
> filespath = d.getVar('FILESPATH', True)
> newfilespath = filespath.replace('-release', '')
> d.setVar('FILESPATH', newfilespath)
> }
>
> addhandler release_virtclass_handler
> release_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"
>
> ==========================
> In a bbappend you use the classes:
>
>
> ==========================
>
> SRC_URI_append_class-production = " \
> file://rcS.production \
> "
>
> SRC_URI_append_class-rnd = " \
> file://rcS.rnd \
> "
>
> SRC_URI_append_class-release = " \
> file://rcS.release \
> "
>
> do_install_append_class-production () {
> install -m 755 ${WORKDIR}/rcS.production ${D}${sysconfdir}/init.d/rcS
> }
>
> do_install_append_class-rnd () {
> install -m 755 ${WORKDIR}/rcS.rnd ${D}${sysconfdir}/init.d/rcS
> }
>
> do_install_append_class-release () {
> install -m 755 ${WORKDIR}/rcS.release ${D}${sysconfdir}/init.d/rcS
> }
>
> BBCLASSEXTEND = "production rnd release"
>
> ==========================
>
> In your production image you add
>
> IMAGE_INSTALL_append = "busybox-production"
>
>
> Do something similar for the other two.
>
> BR
>
> Ulf Samuelsson
> ------------------------------
> *Fr?n:* yocto-bounces at yoctoproject.org <yocto-bounces at yoctoproject.org>
> f?r Damien LEFEVRE <lefevre.da at gmail.com>
> *Skickat:* den 1 juni 2018 13:17:53
> *Till:* Iv?n Castell
> *Kopia:* Yocto discussion list
> *?mne:* Re: [yocto] Image specific configuration files
>
> Thanks a lot everyone, this is very helpful =)
>
> On Fri, Jun 1, 2018 at 2:14 PM, Iv?n Castell <icastell at nayarsystems.com>
> wrote:
>
>
>
> 2018-06-01 11:24 GMT+02:00 Alexander Kanavin <alex.kanavin at gmail.com>:
>
> I have to say defining multiple distros and then tweaking recipes
> according to those definitions is not a good practice, as recipes should
> generally only access DISTRO_FEATURES and otherwise be distro-agnostic. The
> above iptables scenario should be handled with different image recipes,
> which pull in (via packages) or create different configurations.
>
>
>
> That has sense. We will refactorize our Yocto repo as suggested. Always
> very helpfull with all your comments Mr Alexander. Thank you very much! :)
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20180613/b7862095/attachment.html>
------------------------------
--
_______________________________________________
yocto mailing list
yocto at yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
End of yocto Digest, Vol 93, Issue 45
*************************************
More information about the yocto
mailing list