Thanks for replying!
That is effectively what we have to do with the VM clone of the build
machine. We spin up the VM, do the build, see what is new in the downloads
directory, do our due diligence, and push the new stuff into the local
mirror behind the firewall. The primary build server must rem
We're excited to announce the amazing sessions scheduled for the Yocto Project
Summit 2019.
Sessions include:
*Yocto Project and CVEs
*Transitioning from long term stable to CI/CD
*Binary package feeds for Yocto Project
*Building container images with the Yocto
Chuck,
Unless I am missing something (which I cannot entirely rule out), the
default PREMIRRORS should actually do what you want. For the poky distro
configuration has this:
PREMIRRORS ??= "\
bzr://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
cvs://.*/.* http://downloads.yocto
Hi All,
Our build environment is stuck behind a firewall with no access to the
Internet. When a Yocto build requires a new package, we normally extract
the URL from the failed build log and "wget" the package from the upstream
source, do our due diligence (checksums, etc), and then add it to the
s
From: Bruce Ashfield
Updating the reference BSP SRCREVs and versions to 5.2.17 to match
the latest for qemu* and to pickup some reference board specific
patches.
Signed-off-by: Bruce Ashfield
---
v2: make sure that genericx86 and beaglebone-yocto are updated
.../linux/linux-yocto_5.2.bbappen
On Thu, Sep 26, 2019 at 12:55 PM wrote:
> From: Bruce Ashfield
>
> Updating the reference BSP SRCREVs and versions to 5.2.17 to match
> the latest for qemu* and to pickup some reference board specific
> patches.
>
> Signed-off-by: Bruce Ashfield
> ---
> .../linux/linux-yocto_5.2.bbappend
From: Bruce Ashfield
Updating the reference BSP SRCREVs and versions to 5.2.17 to match
the latest for qemu* and to pickup some reference board specific
patches.
Signed-off-by: Bruce Ashfield
---
.../linux/linux-yocto_5.2.bbappend | 16
1 file changed, 8 insertio
On 9/25/19 11:33 PM, Jain, Sangeeta wrote:
>
>
>
> Hello All,
>
>
>
> This is the full QA report for 2.8 M3 RC1:
>
> https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults
>
>
>
> === Summary
>
> No high milestone defects.
>
> Two
On 9/26/19 8:59 AM, Westermann, Oliver wrote:
> Hey,
>
>
>
> I’m trying to implement a bootloader-signing mechanism within yocto for
> extended
> secure-boot support. The bootloader and it’s recipes are provided by NXP (in
> this case it’s the imx-boot_*.bb recipe from meta-freescale) and I wa
Hey,
I'm trying to implement a bootloader-signing mechanism within yocto for
extended secure-boot support. The bootloader and it's recipes are provided by
NXP (in this case it's the imx-boot_*.bb recipe from meta-freescale) and I want
to use a secondary recipe which I am creating to sign the re
I see that sourcing the SDK environment file (
*environment-setup-armv7ahf-neon-oe-linux-gnueabi*) results in a few QT
variables pointing to the machine that generated the SDK (generated through
populate_sdk).
Towards the end of my environment file I have this line:
if [ -d "$OECORE_NATIVE_SYSRO
11 matches
Mail list logo
