Hello,

The problem I hope to solve is that a Maintainer can stage changes in
any branch in the contrib repos making it difficult for folks to track
their back port requests. The also makes it harder to automate any kind
of build automation.

I would like to propose a contrib naming scheme for the stable release
branches. I am thinking of the following:

stable/{version}-next or {special char}_stable/{version}-next.

   "version" is either the code name or numeric like in bitbake.

   "special char" would be used to have these branches at the top of th
list, if we wont that.


We can apply this to all OE / Yocto repos that have stable branch
maintenance process.

If we standardize on a naming scheme, We can then document this so
contributers can monitor their requests more easily. The community can
see what changes are being backport.  This will enable the possibility
to automate builds, etc. 

let me know what you think.

Kind regards,

Armin

On 02/11/2017 15:59, Khem Raj wrote:

On Thu, Nov 2, 2017 at 8:46 AM, Pascal Bach <pascal.bach@...> wrote:

On 27.10.2017 23:41, Khem Raj wrote:

On Fri, Oct 27, 2017 at 3:51 AM, Pascal Bach <pascal.bach@...> wrote:

This was probably working before pyro and the recipes specific sysroots.

Signed-off-by: Pascal Bach <pascal.bach@...>
---
recipes-mono/mono/mono-4.xx.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-mono/mono/mono-4.xx.inc b/recipes-mono/mono/mono-4.xx.inc
index e06fac7..cf9170b 100644
--- a/recipes-mono/mono/mono-4.xx.inc
+++ b/recipes-mono/mono/mono-4.xx.inc
@@ -4,7 +4,7 @@ HOMEPAGE = "http://mono-project.com"
BUGTRACKER = "http://bugzilla.xamarin.com/"
SECTION = "devel"

-DEPENDS = "zlib"
+DEPENDS = "zlib cmake-native"

perhaps this should inehrit cmake if its using cmake
or explain how cmake is used where abstactions
are not relevant

Using the cmake bbclass doesn't work as it is not really a CMake project.

Mono requires cmake to build the bundled BoringSSL library. I didn't look why it works in detail but I currently assume that BoringSSL is standalone enough that no additional
CMake toolchain settings are required to make it work.

yeah that probably is a case of bundling which is on rise at app level
these days,

One option would be to disable it with `--disable-btls` but I fear that would disable TLS1.2 support (http://www.mono-project.com/docs/about-mono/releases/4.8.0/#tls-12-support).
But I have no way of checking that.

interesting, do they support any other TLS implementations ?

It is disabled in 5.x builds by default as it breaks the build e.g.

http://git.yoctoproject.org/cgit/cgit.cgi/meta-mono/tree/recipes-mono/mono/mono-5.4.0.201.inc

It's probably time to look at a working build with it re-enabled. Patches welcomed...

(I did have a quick look at inheriting cmake but that breaks the build too)

Cheers,

Alex

On 2017-11-02 4:16 PM, Bishop, Mark (STRT) wrote:

I changed the code in arm/layers/core/meta/classes/kernel-yocto.bbclass
From:
.
else
                # case: we have no git repository at all.
                # To support low bandwidth options for building the kernel, we'll just
                # convert the tree to a git repo and let the rest of the process work unchanged
                # if ${S} hasn't been set to the proper subdirectory a default of "linux" is
                # used, but we can't initialize that empty directory. So check it and throw a
                # clear error
                cd ${S}
                if [ ! -f "Makefile" ]; then
..
To:
else
# case: we have no git repository at all.
# To support low bandwidth options for building the kernel, we'll just
# convert the tree to a git repo and let the rest of the process work unchanged
# if ${S} hasn't been set to the proper subdirectory a default of "linux" is
# used, but we can't initialize that empty directory. So check it and throw a
# clear error
if [ -d "${WORKDIR}/trunk/" ]; then
source_workdir="${WORKDIR}/trunk"
if [ "${source_dir}" != "${source_workdir}" ]; then
rm -rf ${S}
mv ${WORKDIR}/trunk ${S}
fi
fi
cd ${S}
if [ ! -f "Makefile" ]; then
And everything is working but it seems that this would be the wrong way to do this as this is me editing a base class file.

Yah, not a great idea to modify the base class.

It may be working, but if you actually add a patch to the SRC_URI,
it will fail, since the rest of the code also needs a git
repository (to apply patches, merge branches, etc, etc). You may
or may not have done that, but where you put that sample code *should*
let the tgz processing do the right thing and create a simple git
repo.

I wrote that code (a long time ago now!) to work with git trees or
tgz's. Anything that isn't dropping the source into a location that
is different than that, won't work (as you found out and worked
around).

You could add your own task that runs before do_kernel_checkout to
put the svn checkout into ${S}, and then do_checkout_checkout will
do its work as normal.

You can add that task in your kernel recipe, or in a bbappend to
a kernel recipe.

i.e.

addtask kernel_svn_precondition before do_kernel_checkout after do_unpack

do_kernel_svn_precondition() {
if [ -d "${WORKDIR}/trunk/" ]; then
source_workdir="${WORKDIR}/trunk"
if [ "${source_dir}" != "${source_workdir}" ]; then
rm -rf ${S}
mv ${WORKDIR}/trunk ${S}
fi
fi
}

Maybe someone else will have a better idea, but that is mine :D

Cheers,

Bruce

From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Bishop, Mark (STRT)
Sent: Thursday, November 02, 2017 1:48 PM
To: yocto@...
Subject: [yocto] do_kernel_checkout() not using the correct directory
I am trying to compile a kernel located in SVN.
I get this error message:
ERROR: linux-xlnx-4.9-xilinx-v2017.2+git20-r0 do_kernel_checkout: S /tmp/stride/work-shared/plnx_arm/kernel-source is not set to the linux source directory. Check
ERROR: linux-xlnx-4.9-xilinx-v2017.2+git20-r0 do_kernel_checkout: the recipe and set S to the proper extracted subdirectory
ERROR: linux-xlnx-4.9-xilinx-v2017.2+git20-r0 do_kernel_checkout: Function failed: do_kernel_checkout (log file is located at /tmp/stride/work/plnx_arm-xilinx-linux-gnueabi/linux-xlnx/4.9-xilinx-v2017.2+git20-r0/temp/log.do_kernel_checkout.34928)
ERROR: Logfile of failure stored in: /tmp/stride/work/plnx_arm-xilinx-linux-gnueabi/linux-xlnx/4.9-xilinx-v2017.2+git20-r0/temp/log.do_kernel_checkout.34928
ERROR: Task (/opt/pkg/petalinux/2017.2/components/yocto/source/arm/layers/meta-xilinx/recipes-kernel/linux/linux-xlnx_4.9.bb:do_kernel_checkout) failed with exit code '1'
And my kernel gets downloaded to:
/tmp/stride/work/plnx_arm-xilinx-linux-gnueabi/linux-xlnx/4.9-xilinx-v2017.2+git20-r0/trunk
But Yocto is looking for it in /tmp/stride/work-shared/plnx_arm/kernel-source
Which is why it is failing in kernel-yocto.bbclass when I try and compile a kernel located in SVN.
If it is a git repo it gets copied into /tmp/stride/work-shared/plnx_arm/kernel-source and things work nicely.
do_kernel_checkout() {
...
if [ -d "${WORKDIR}/git/" ]; then
# case: git repository
                # if S is WORKDIR/git, then we shouldn't be moving or deleting the tree.
                if [ "${source_dir}" != "${source_workdir}" ]; then
                        if [ -d "${source_workdir}/.git" ]; then
                                # regular git repository with .git
                                rm -rf ${S}
                                mv ${WORKDIR}/git ${S}
                        else
                                # create source for bare cloned git repository
                                git clone ${WORKDIR}/git ${S}
                                rm -rf ${WORKDIR}/git
                        fi
                fi
                cd ${S}
else
                # case: we have no git repository at all.
                # To support low bandwidth options for building the kernel, we'll just
                # convert the tree to a git repo and let the rest of the process work unchanged
                # if ${S} hasn't been set to the proper subdirectory a default of "linux" is
                # used, but we can't initialize that empty directory. So check it and throw a
                # clear error
                cd ${S}
                if [ ! -f "Makefile" ]; then
                        bberror "S ${S} is not set to the linux source directory. Check "
                        bbfatal "the recipe and set S to the proper extracted subdirectory"
                fi
..
${S} is set to /tmp/stride/work-shared/plnx_arm/kernel-source when I need one of the two things to happen:
A) ${S} set to  ${WORKDIR}/trunk             OR
B) ${WORKDIR}/trunk copied to ${S}/
I could modify that file directly on my machine and move on, but is there a way I can create an .bbappend or something that will change ${S}
I'm pretty new to Yocto and I'd like to have a solution that resides in my project folder instead of having to modify Yocto files so that when I do tool installs on new development machines I can just checkout my project data and have it work.  I'm using Petalinux, so the process would be install that, then checkout the project and then build it, with the correct ${S} directory flowing into kernel-yocto.bbclass:do_kernel_checkout()
I'm new Yocto but I've been reading a ton and am looking for some advice.
This e-mail contains proprietary information some or all of which may be legally privileged. It is intended for the recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the authority by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. In addition, information contained in or attached to this e-mail may be subject to either 22 C.F.R. Parts 120?130, or 15 C.F.R. Parts 730-774. These regulations prohibit the release or disclosure of certain information contained herein to anyone who is not a U.S. citizen or permanent resident alien, without a license first having been issued. Failure to observe such requirements is a violation of U.S. law that carries serious penalties.

On 31/10/17 19:38, Jeffrey Pautler wrote:

The current implementation uses the system clock to calculate how long
a ptest has been running with no output. If a ptest changes the system
clock as part of the test, that can cause the current implementation
to falsely trigger a timeout or miss an actual timeout. It is
preferrable to use a monotonic clock for calculating elapsed time in
order to avoid these issues.
This change tries to use the monotonic clock first and falls back to
the realtime clock if the monotonic clock is not supported.

This patch looks good to me, merged & pushed to ptest-runner2 repo.

Thanks,

Joshua

Signed-off-by: Jeffrey Pautler <jeffrey.pautler@...>
---
utils.c | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/utils.c b/utils.c
index 6d65388..933eced 100644
--- a/utils.c
+++ b/utils.c
@@ -257,7 +257,8 @@ wait_child(const char *ptest_dir, const char *run_ptest, pid_t pid,
int timeout, int *fds, FILE **fps)
{
struct pollfd pfds[2];
- time_t sentinel;
+ struct timespec sentinel;
+ clockid_t clock = CLOCK_MONOTONIC;
int r;
int timeouted = 0;
@@ -269,7 +270,11 @@ wait_child(const char *ptest_dir, const char *run_ptest, pid_t pid,
pfds[1].fd = fds[1];
pfds[1].events = POLLIN;
- sentinel = time(NULL);
+ if (clock_gettime(clock, &sentinel) == -1) {
+ clock = CLOCK_REALTIME;
+ clock_gettime(clock, &sentinel);
+ }
+
while (1) {
waitflags = WNOHANG;
@@ -288,11 +293,16 @@ wait_child(const char *ptest_dir, const char *run_ptest, pid_t pid,
fwrite(buf, n, 1, fps[1]);
}
- sentinel = time(NULL);
- } else if (timeout >= 0 && ((time(NULL) - sentinel) > timeout)) {
- timeouted = 1;
- kill(pid, SIGKILL);
- waitflags = 0;
+ clock_gettime(clock, &sentinel);
+ } else if (timeout >= 0) {
+ struct timespec time;
+
+ clock_gettime(clock, &time);
+ if ((time.tv_sec - sentinel.tv_sec) > timeout) {
+ timeouted = 1;
+ kill(pid, SIGKILL);
+ waitflags = 0;
+ }
}
if (waitpid(pid, &status, waitflags) == pid)

I changed the code in arm/layers/core/meta/classes/kernel-yocto.bbclass

From:
.
else
                # case: we have no git repository at all.
                # To support low bandwidth options for building the kernel, we'll just
                # convert the tree to a git repo and let the rest of the process work unchanged

                # if ${S} hasn't been set to the proper subdirectory a default of "linux" is
                # used, but we can't initialize that empty directory. So check it and throw a
                # clear error

                cd ${S}
                if [ ! -f "Makefile" ]; then
..

To:
else
# case: we have no git repository at all.
# To support low bandwidth options for building the kernel, we'll just
# convert the tree to a git repo and let the rest of the process work unchanged

# if ${S} hasn't been set to the proper subdirectory a default of "linux" is
# used, but we can't initialize that empty directory. So check it and throw a
# clear error

if [ -d "${WORKDIR}/trunk/" ]; then
source_workdir="${WORKDIR}/trunk"
if [ "${source_dir}" != "${source_workdir}" ]; then
rm -rf ${S}
mv ${WORKDIR}/trunk ${S}
fi
fi

cd ${S}
if [ ! -f "Makefile" ]; then

And everything is working but it seems that this would be the wrong way to do this as this is me editing a base class file.



From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Bishop, Mark (STRT)
Sent: Thursday, November 02, 2017 1:48 PM
To: yocto@...
Subject: [yocto] do_kernel_checkout() not using the correct directory

I am trying to compile a kernel located in SVN.

I get this error message:
ERROR: linux-xlnx-4.9-xilinx-v2017.2+git20-r0 do_kernel_checkout: S /tmp/stride/work-shared/plnx_arm/kernel-source is not set to the linux source directory. Check
ERROR: linux-xlnx-4.9-xilinx-v2017.2+git20-r0 do_kernel_checkout: the recipe and set S to the proper extracted subdirectory
ERROR: linux-xlnx-4.9-xilinx-v2017.2+git20-r0 do_kernel_checkout: Function failed: do_kernel_checkout (log file is located at /tmp/stride/work/plnx_arm-xilinx-linux-gnueabi/linux-xlnx/4.9-xilinx-v2017.2+git20-r0/temp/log.do_kernel_checkout.34928)
ERROR: Logfile of failure stored in: /tmp/stride/work/plnx_arm-xilinx-linux-gnueabi/linux-xlnx/4.9-xilinx-v2017.2+git20-r0/temp/log.do_kernel_checkout.34928
ERROR: Task (/opt/pkg/petalinux/2017.2/components/yocto/source/arm/layers/meta-xilinx/recipes-kernel/linux/linux-xlnx_4.9.bb:do_kernel_checkout) failed with exit code '1'

And my kernel gets downloaded to:
/tmp/stride/work/plnx_arm-xilinx-linux-gnueabi/linux-xlnx/4.9-xilinx-v2017.2+git20-r0/trunk
But Yocto is looking for it in /tmp/stride/work-shared/plnx_arm/kernel-source
Which is why it is failing in kernel-yocto.bbclass when I try and compile a kernel located in SVN.

If it is a git repo it gets copied into /tmp/stride/work-shared/plnx_arm/kernel-source and things work nicely.


do_kernel_checkout() {
...
if [ -d "${WORKDIR}/git/" ]; then
# case: git repository
                # if S is WORKDIR/git, then we shouldn't be moving or deleting the tree.
                if [ "${source_dir}" != "${source_workdir}" ]; then
                        if [ -d "${source_workdir}/.git" ]; then
                                # regular git repository with .git
                                rm -rf ${S}
                                mv ${WORKDIR}/git ${S}
                        else
                                # create source for bare cloned git repository
                                git clone ${WORKDIR}/git ${S}
                                rm -rf ${WORKDIR}/git
                        fi
                fi
                cd ${S}
else
                # case: we have no git repository at all.
                # To support low bandwidth options for building the kernel, we'll just
                # convert the tree to a git repo and let the rest of the process work unchanged

                # if ${S} hasn't been set to the proper subdirectory a default of "linux" is
                # used, but we can't initialize that empty directory. So check it and throw a
                # clear error

                cd ${S}
                if [ ! -f "Makefile" ]; then
                        bberror "S ${S} is not set to the linux source directory. Check "
                        bbfatal "the recipe and set S to the proper extracted subdirectory"
                fi
..

${S} is set to /tmp/stride/work-shared/plnx_arm/kernel-source when I need one of the two things to happen:
A) ${S} set to  ${WORKDIR}/trunk             OR
B) ${WORKDIR}/trunk copied to ${S}/

I could modify that file directly on my machine and move on, but is there a way I can create an .bbappend or something that will change ${S}

I'm pretty new to Yocto and I'd like to have a solution that resides in my project folder instead of having to modify Yocto files so that when I do tool installs on new development machines I can just checkout my project data and have it work.  I'm using Petalinux, so the process would be install that, then checkout the project and then build it, with the correct ${S} directory flowing into kernel-yocto.bbclass:do_kernel_checkout()

I'm new Yocto but I've been reading a ton and am looking for some advice.




This e-mail contains proprietary information some or all of which may be legally privileged. It is intended for the recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the authority by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. In addition, information contained in or attached to this e-mail may be subject to either 22 C.F.R. Parts 120?130, or 15 C.F.R. Parts 730-774. These regulations prohibit the release or disclosure of certain information contained herein to anyone who is not a U.S. citizen or permanent resident alien, without a license first having been issued. Failure to observe such requirements is a violation of U.S. law that carries serious penalties.

This e-mail contains proprietary information some or all of which may be legally privileged. It is intended for the recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the authority by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. In addition, information contained in or attached to this e-mail may be subject to either 22 C.F.R. Parts 120?130, or 15 C.F.R. Parts 730-774. These regulations prohibit the release or disclosure of certain information contained herein to anyone who is not a U.S. citizen or permanent resident alien, without a license first having been issued. Failure to observe such requirements is a violation of U.S. law that carries serious penalties.   ­­  

On 02 November 2017 at 16:59 Alexander Kanavin <alexander.kanavin@...> wrote:

On 11/02/2017 06:50 PM, Colin Helliwell wrote:

u-boot-w2_1.inc has the standard kind of recipe stuff. For creating env files, and files to be used for later signing, it has some _append steps, so I'm aiming to use 'DEP_IMG' to create the various files with different prefixes for the two variants.
Strangely though, an 'echo ${DEP_IMG}' is outputting the same value ("u-boot-prodn") from both recipes, even after a cleanall on both. Possibly some state info being pulled in somewhere?

Not sure if this will help, but start by not using the -dev suffix. It
will clash with -dev packages produced by (any) recipe.

Thanks Alex, that has indeed resolved the problem of DEP_IMG not changing.

Still getting the "trying to install files into a shared area when those files already exist" error on the second [-dvl] bitbake. And a cleanall throws

"ERROR: Multiple .bb files are due to be built which each provide u-boot:
/home/colin/trunk/fsl-community-bsp/../meta-ln-karo/recipes-bsp/u-boot/u-boot-w2-dvl.bb
/home/colin/trunk/fsl-community-bsp/../meta-ln-karo/recipes-bsp/u-boot/u-boot-w2.bb
A list of tasks depending on these providers is shown and may help explain where the dependency comes from.
/home/colin/trunk/fsl-community-bsp/../meta-ln-karo/recipes-bsp/u-boot/u-boot-w2.bb has unique dependees:

/home/colin/trunk/fsl-community-bsp/../meta-ln-karo/recipes-bsp/u-boot/u-boot-w2-dvl.bb has unique dependees:

It could be that one recipe provides something the other doesn't and should. The following provider and runtime provider differences may be helpful.
/home/colin/trunk/fsl-community-bsp/../meta-ln-karo/recipes-bsp/u-boot/u-boot-w2-dvl.bb has unique provides:
u-boot-w2-dvl
/home/colin/trunk/fsl-community-bsp/../meta-ln-karo/recipes-bsp/u-boot/u-boot-w2-dvl.bb has unique rprovides:
u-boot-w2-dvl-dev
u-boot-w2-dvl-doc
u-boot-w2-dvl
u-boot-w2-dvl-staticdev
u-boot-w2-dvl-dbg
u-boot-w2-dvl-locale
^u-boot-w2-dvl-locale-.*
/home/colin/trunk/fsl-community-bsp/../meta-ln-karo/recipes-bsp/u-boot/u-boot-w2.bb has unique provides:
u-boot-w2
/home/colin/trunk/fsl-community-bsp/../meta-ln-karo/recipes-bsp/u-boot/u-boot-w2.bb has unique rprovides:
u-boot-w2-doc
^u-boot-w2-locale-.*
u-boot-w2-dev
u-boot-w2-staticdev
u-boot-w2
u-boot-w2-dbg
u-boot-w2-locale"

That doesn't seem to imply too much conflict, so might be something simple...
It's nearly dinnertime - :) - so I could, to make absolutely sure, try a thorough cleanout by deleting tmp/ and see what happens.

On 11/02/2017 06:50 PM, Colin Helliwell wrote:

u-boot-w2_1.inc has the standard kind of recipe stuff. For creating env files, and files to be used for later signing, it has some _append steps, so I'm aiming to use 'DEP_IMG' to create the various files with different prefixes for the two variants.
Strangely though, an 'echo ${DEP_IMG}' is outputting the same value ("u-boot-prodn") from both recipes, even after a cleanall on both. Possibly some state info being pulled in somewhere?

Not sure if this will help, but start by not using the -dev suffix. It will clash with -dev packages produced by (any) recipe.

Alex

On 02 November 2017 at 16:29 Alexander Kanavin <alexander.kanavin@...> wrote:

On 11/02/2017 06:26 PM, Colin Helliwell wrote:

Following on from this, I'm trying to be able to build my two versions of u-boot, in the *same* build directory.
I'm not sure if this is possible, but I figured it might be: since u-boot doesn't get put into the rootfs (?), I would ideally be able to build both and just pull down from tmp/deploy/images/.... the image that I want to program into a particular unit.
I've pushed common stuff into .inc file(s), and have two recipes which set different 'PROVIDES' values.
However, even after a cleanall on both recipes, bitbaking the second one throws an error "The recipe u-boot-mymachine-dev is trying to install files into a shared area when those files already exist".

Can you share exactly how the two recipes differ?

Very little!
One is:

DESCRIPTION = "Das U-Boot for W2 [for development]"
DEP_IMG = "u-boot-dev"
PROVIDES = "u-boot-w2-dev"
require u-boot-w2_1.inc

The other is:

DESCRIPTION = "Das U-Boot for W2"
DEP_IMG = "u-boot-prodn"
PROVIDES = "u-boot-w2"
require u-boot-w2_1.inc

u-boot-w2_1.inc has the standard kind of recipe stuff. For creating env files, and files to be used for later signing, it has some _append steps, so I'm aiming to use 'DEP_IMG' to create the various files with different prefixes for the two variants.
Strangely though, an 'echo ${DEP_IMG}' is outputting the same value ("u-boot-prodn") from both recipes, even after a cleanall on both. Possibly some state info being pulled in somewhere?

It seems that you do need to have two different build directories that
differ in what MACHINE is set to. And that would configure u-boot
accordingly.

I *do* realise I'm trying to do something a bit unusual!
All I want between the two variants is to disable some functionality - the 'machine' is identical. I was going to patch one build to take the functionality out (for 'production'), but create my own specific environment for the system anyway. So I wonder if a cleaner/easier (aka working...!) approach would be to instead patch my own custom envar into the source, and then I could instead create two different env files for the two variants?

On 11/02/2017 06:26 PM, Colin Helliwell wrote:

Following on from this, I'm trying to be able to build my two versions of u-boot, in the *same* build directory.
I'm not sure if this is possible, but I figured it might be: since u-boot doesn't get put into the rootfs (?), I would ideally be able to build both and just pull down from tmp/deploy/images/.... the image that I want to program into a particular unit.
I've pushed common stuff into .inc file(s), and have two recipes which set different 'PROVIDES' values.
However, even after a cleanall on both recipes, bitbaking the second one throws an error "The recipe u-boot-mymachine-dev is trying to install files into a shared area when those files already exist".

Can you share exactly how the two recipes differ?

It seems that you do need to have two different build directories that differ in what MACHINE is set to. And that would configure u-boot accordingly.


Alex

On 02 November 2017 at 07:10 Colin Helliwell <colin.helliwell@...> wrote:

On 01 November 2017 at 17:04 Alexander Kanavin <alexander.kanavin@...> wrote:

On 11/01/2017 06:43 PM, colin.helliwell@... wrote:

I need to build two slightly varying versions of our Yocto build – one
for the production units and one for development.

They differ in only a few ways – the kernel and apps are the same. But
one has Dropbear, whilst the other doesn’t; and the U-Boot configs &
patches are different.

I’m wondering where to do the separation – image, distro, conf…?

Any thoughts on the cleanest way to split and/or inherit them would be
appreciated.

Image, certainly. Put the common bits into an include, and specific bits
into image-production|development.bb files. Poky has plenty of examples
for this.

Rootfs changes I can certainly do with different image recipes.

Am I right though in thinking that - because they'll have different variants of u-boot - I'll need to use separate build directories for each? (nb - I'm using signed FIT image, so the u-boot bin gets modified as part of the kernel building)
--

Following on from this, I'm trying to be able to build my two versions of u-boot, in the *same* build directory.
I'm not sure if this is possible, but I figured it might be: since u-boot doesn't get put into the rootfs (?), I would ideally be able to build both and just pull down from tmp/deploy/images/.... the image that I want to program into a particular unit.
I've pushed common stuff into .inc file(s), and have two recipes which set different 'PROVIDES' values.
However, even after a cleanall on both recipes, bitbaking the second one throws an error "The recipe u-boot-mymachine-dev is trying to install files into a shared area when those files already exist".

Is it possible to do what I'm trying to do....?
Ta

On Thu, Nov 2, 2017 at 8:46 AM, Pascal Bach <pascal.bach@...> wrote:

On 27.10.2017 23:41, Khem Raj wrote:

On Fri, Oct 27, 2017 at 3:51 AM, Pascal Bach <pascal.bach@...> wrote:

This was probably working before pyro and the recipes specific sysroots.

Signed-off-by: Pascal Bach <pascal.bach@...>
---
recipes-mono/mono/mono-4.xx.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-mono/mono/mono-4.xx.inc b/recipes-mono/mono/mono-4.xx.inc
index e06fac7..cf9170b 100644
--- a/recipes-mono/mono/mono-4.xx.inc
+++ b/recipes-mono/mono/mono-4.xx.inc
@@ -4,7 +4,7 @@ HOMEPAGE = "http://mono-project.com"
BUGTRACKER = "http://bugzilla.xamarin.com/"
SECTION = "devel"

-DEPENDS = "zlib"
+DEPENDS = "zlib cmake-native"

perhaps this should inehrit cmake if its using cmake
or explain how cmake is used where abstactions
are not relevant

Using the cmake bbclass doesn't work as it is not really a CMake project.

Mono requires cmake to build the bundled BoringSSL library. I didn't look why it works in detail but I currently assume that BoringSSL is standalone enough that no additional
CMake toolchain settings are required to make it work.

yeah that probably is a case of bundling which is on rise at app level
these days,

One option would be to disable it with `--disable-btls` but I fear that would disable TLS1.2 support (http://www.mono-project.com/docs/about-mono/releases/4.8.0/#tls-12-support).
But I have no way of checking that.

interesting, do they support any other TLS implementations ?

Pascal

SRC_URI = "http://download.mono-project.com/sources/mono/mono-${PV}.tar.bz2 \
file://dllmap-config.in.diff \
--
2.1.4

--
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto

Signed-off-by: Andrei Gherzan <andrei@...>
---
recipes-bsp/common/firmware.inc | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/recipes-bsp/common/firmware.inc b/recipes-bsp/common/firmware.inc
index ac2bd82..67078c1 100644
--- a/recipes-bsp/common/firmware.inc
+++ b/recipes-bsp/common/firmware.inc
@@ -1,10 +1,9 @@
-RPIFW_DATE ?= "20170811"
+RPIFW_DATE ?= "20171029"
RPIFW_SRC_URI ?= "https://github.com/raspberrypi/firmware/archive/1.${RPIFW_DATE}.tar.gz"
RPIFW_S ?= "${WORKDIR}/firmware-1.${RPIFW_DATE}"

SRC_URI = "${RPIFW_SRC_URI}"
-SRC_URI[md5sum] = "afd09f9a6df14e32b6d832fd9f51d087"
-SRC_URI[sha256sum] = "a25f6281d64732892a2e838cc2346f1a88505b5c77a57a6540755362ea64043a"
-
+SRC_URI[md5sum] = "4d27c1888a7bab3097471906e7b4a319"
+SRC_URI[sha256sum] = "46ce28c8d87ef22bdcc57ac1836ca3f04d1ec6f46580ff5a30bf76b3c0822117"
PV = "${RPIFW_DATE}"

--
2.7.4

We used to have this as the default but there was a bug at some point in the
firmware which didn't work with compressed kernel images. We switched to Image
and never changed it back even though that bug is long history.

In this way we will stop carrying 15M of a kernel image. 4M looks much better.

Signed-off-by: Andrei Gherzan <andrei@...>
---
conf/machine/include/rpi-base.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/machine/include/rpi-base.inc b/conf/machine/include/rpi-base.inc
index 688227c..71c63cb 100644
--- a/conf/machine/include/rpi-base.inc
+++ b/conf/machine/include/rpi-base.inc
@@ -51,7 +51,7 @@ KERNEL_DEVICETREE ?= " \
# within u-boot to load the kernel.
KERNEL_BOOTCMD ??= "bootm"
KERNEL_IMAGETYPE_UBOOT ??= "uImage"
-KERNEL_IMAGETYPE ?= "${@bb.utils.contains('RPI_USE_U_BOOT', '1', '${KERNEL_IMAGETYPE_UBOOT}', 'Image', d)}"
+KERNEL_IMAGETYPE ?= "${@bb.utils.contains('RPI_USE_U_BOOT', '1', '${KERNEL_IMAGETYPE_UBOOT}', 'zImage', d)}"

MACHINE_FEATURES += "apm usbhost keyboard vfat ext2 screen touchscreen alsa bluetooth wifi sdio"

--
2.7.4

Signed-off-by: Andrei Gherzan <andrei@...>
---
recipes-devtools/pi-blaster/pi-blaster.inc | 21 ---------------------
recipes-devtools/pi-blaster/pi-blaster_git.bb | 22 +++++++++++++++++++++-
2 files changed, 21 insertions(+), 22 deletions(-)
delete mode 100644 recipes-devtools/pi-blaster/pi-blaster.inc

diff --git a/recipes-devtools/pi-blaster/pi-blaster.inc b/recipes-devtools/pi-blaster/pi-blaster.inc
deleted file mode 100644
index 3cb79cc..0000000
--- a/recipes-devtools/pi-blaster/pi-blaster.inc
+++ /dev/null
@@ -1,21 +0,0 @@
-DESCRIPTION = "This project enables PWM on the GPIO pins you request of a Raspberry Pi."
-HOMEPAGE = "https://github.com/sarfata/pi-blaster/"
-SECTION = "devel/libs"
-LICENSE = "MIT"
-LIC_FILES_CHKSUM = "file://README.md;beginline=225;endline=252;md5=a012868ef5f83b9f257af253d7cb07a3"
-
-SRC_URI = "git://github.com/sarfata/pi-blaster \
- file://remove-initscript-lsb-dependency.patch \
-"
-
-S = "${WORKDIR}/git"
-
-inherit update-rc.d autotools
-
-INITSCRIPT_PACKAGES = "${PN}"
-INITSCRIPT_NAME_${PN} = "${PN}.boot.sh"
-INITSCRIPT_PARAMS_${PN} = "defaults 15 85"
-
-COMPATIBLE_MACHINE = "^rpi$"
-
-PACKAGE_ARCH = "${MACHINE_ARCH}"
diff --git a/recipes-devtools/pi-blaster/pi-blaster_git.bb b/recipes-devtools/pi-blaster/pi-blaster_git.bb
index 730f9d3..2748459 100644
--- a/recipes-devtools/pi-blaster/pi-blaster_git.bb
+++ b/recipes-devtools/pi-blaster/pi-blaster_git.bb
@@ -1,3 +1,23 @@
-require pi-blaster.inc
+DESCRIPTION = "This project enables PWM on the GPIO pins you request of a Raspberry Pi."
+HOMEPAGE = "https://github.com/sarfata/pi-blaster/"
+SECTION = "devel/libs"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://README.md;beginline=225;endline=252;md5=a012868ef5f83b9f257af253d7cb07a3"
+
+SRC_URI = "git://github.com/sarfata/pi-blaster \
+ file://remove-initscript-lsb-dependency.patch \
+"
+
+S = "${WORKDIR}/git"

SRCREV = "1035ad7dffb270c40eec1bb3a654171a755fba98"
+
+inherit update-rc.d autotools
+
+INITSCRIPT_PACKAGES = "${PN}"
+INITSCRIPT_NAME_${PN} = "${PN}.boot.sh"
+INITSCRIPT_PARAMS_${PN} = "defaults 15 85"
+
+COMPATIBLE_MACHINE = "^rpi$"
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
--
2.7.4

Signed-off-by: Andrei Gherzan <andrei@...>
---
recipes-kernel/linux/linux-raspberrypi_4.9.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-kernel/linux/linux-raspberrypi_4.9.bb b/recipes-kernel/linux/linux-raspberrypi_4.9.bb
index dd9afe2..061e893 100644
--- a/recipes-kernel/linux/linux-raspberrypi_4.9.bb
+++ b/recipes-kernel/linux/linux-raspberrypi_4.9.bb
@@ -1,8 +1,8 @@
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"

-LINUX_VERSION ?= "4.9.50"
+LINUX_VERSION ?= "4.9.59"

-SRCREV = "46e2d4d1bd2c17e2f84dd90768321ee0bbaa6b8a"
+SRCREV = "e7976b2affa8c05bd299ead0ad9c36ddaf135b9d"
SRC_URI = "git://github.com/raspberrypi/linux.git;branch=rpi-4.9.y"

require linux-raspberrypi.inc
--
2.7.4

This used to work in the past because this machine was based on raspberrypi
one. Now that they are separate, we need a configuration for it too otherwise:

| common/arm/quant-a.S: Assembler messages:
| common/arm/quant-a.S:362: Error: selected processor does not support `rbit
r1,r1' in ARM mode
| common/arm/quant-a.S:363: Error: selected processor does not support `rbit
r1,r1' in ARM mode

Signed-off-by: Andrei Gherzan <andrei@...>
---
recipes-multimedia/x264/x264_git.bbappend | 1 +
1 file changed, 1 insertion(+)

diff --git a/recipes-multimedia/x264/x264_git.bbappend b/recipes-multimedia/x264/x264_git.bbappend
index c1cb3bc..505719e 100644
--- a/recipes-multimedia/x264/x264_git.bbappend
+++ b/recipes-multimedia/x264/x264_git.bbappend
@@ -1 +1,2 @@
EXTRA_OECONF_append_raspberrypi = " --disable-asm"
+EXTRA_OECONF_append_raspberrypi0-wifi = " --disable-asm"
--
2.7.4