If a previously existing workspace is missing some repos due to "repo sync"
errors, any builds re-using that workspace will fail silently when attempting
to run "git clean -fdx" on all repos via "repo forall".
Ignore missing repos to prevent these situations.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
* generate SD card image using wic
* remove ZIP_INSTALLER_CFG since DEY_IMAGE_INSTALLER="1" is now the default
* drop purge_sstate
https://onedigi.atlassian.net/browse/DEL-9768
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
The CC6UL SOM doesn't support booting from the SD card.
The STM based SOMs use a wic template to generate the SD card
image.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
The generation of the sdcard image takes time and resources, and
it's not involved in the Get Started.
This can be easily re-enabled by appending the variable in the
project local.conf.
Append the variable in the build scripts, to facilitate its usage
on release builds.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
The release build should ensure it starts from a fresh environment to avoid
potential mismatches with old code.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Instead of having one toolchain per image, we now provide one per platform.
https://onedigi.atlassian.net/browse/DEL-9297
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
We have intermittent build failures due to fetch errors of some large
source packages (like linux.git).
This commit tries to workaround those failures by downloading all the
source packages, with a retries mechanism, before starting the build.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Seems that 'meta-openembedded' repo does not allow shallow clones. It
fails when '--depth' option is passed:
$ git clone --depth 1 https://git.openembedded.org/meta-openembedded
Cloning into 'meta-openembedded'...
fatal: dumb http transport does not support shallow capabilities
Remove that option to allow building DEY-4.0 from GitHub repos in the
buildserver.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
By default is enabled the reproducible builds feature and to provide a real
timestamp for the build system, we include it in our local.conf file.
https://onedigi.atlassian.net/browse/DEL-7574
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
This image is very similar to dey-image-qt, but it includes the WebKit
packagegroup instead of the Qt one. Said packagegroup contains all of the
elements needed to run a WebKit-based browser environment in DEY.
This image requires the meta-webkit layer, so include it in our default
bblayers template. For now, include all WebKit related recipes in a dynamic
layer, because the ccimx6ul doesn't support WebKit and its projects don't need
meta-webkit at all.
https://jira.digi.com/browse/DEL-7339
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This commit fixes an intermittent issue when we are cloning several
repos with a huge history, throwing an unexpected error.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
These platforms are not supported on DEY 2.6 yet, and a project created for
either of them will fail during the build.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Commit d981f999f0 introduced a new
platform with dashes on its name, which broke Jenkins build because
middle variables are being created using the name of the platform
and dashes are not allowed in bash variable names.
To fix it, this commit changes the dashes to underscores on the fly.
This is ported from a2092450fa.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Add initial support for Digi ConnectCore 8X SBC Express.
- ccimx6qp was used as reference machine from meta-digi.
- imx8qxpmek was used as a reference machine from meta-fsl-bsp-release.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-5936
Add initial support for Digi's ConnectCore 6 QuadPlus SBC.
The ccimx6qp platform has the QCA6564 chip instead of the
other Atheros chips and included the Atmel ECC508A cryptographic
chip.
https://jira.digi.com/browse/DEL-5082
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Instead of having one default image target for all platforms allow to
define this per platform.
This is needed because for example for the 'ccimx6ulstarter' we want to
define a default command line image instead of a QT-based one.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
We have seen lately random build failures in the buildserver due to
missing QT5 base libraries that are needed when building some other
QT5 packages.
Examples:
Compiling qtdeclarative:
error: cannot open .../tmp/work/cortexa9hf-vfp-neon-mx6qdl-dey-linux-gnueabi/qtbase/5.5.1+gitAUTOINC+5afc431323-r0/build/lib/libQt5Core.so: No such file or directory
error: cannot open .../tmp/work/cortexa9hf-vfp-neon-mx6qdl-dey-linux-gnueabi/qtbase/5.5.1+gitAUTOINC+5afc431323-r0/build/lib/libQt5Network.so: No such file or directory
error: cannot open .../tmp/work/cortexa9hf-vfp-neon-mx6qdl-dey-linux-gnueabi/qtbase/5.5.1+gitAUTOINC+5afc431323-r0/build/lib/libQt5Widgets.so: No such file or directory
The problem here is that 'qtdeclarative' is trying to get the needed
libraries from the 'qtbase' temporary work directory. But because in the
buildserver we have 'rm_work' enabled to save space, sometimes the
rm-work class has removed the 'qtbase' work directory before
'qtdeclarative' has been built, leading to the compilation error.
This is probably a bug in 'meta-qt5', because the different packages
needing QT5 base libraries should take them at compile time from the
sysroot and not from the qtbase work directory.
At the moment just workaround this adding an exception to the rm-work
class to not remove the 'qtbase' temporary work directory.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Javier Viguera
Gabriel Valcazar
Arturo Buzarra
Hector Palacios
Tatiana Leon
Mike Engel
Isaac Hermida