Re: [yocto] Downloading Git Archives
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 remain "sterile",
so everything has to be "hoisted" over the fence manually.
[Side Note: We also maintain a local clone of the openembedded and poky
repositories. Our build pins to a specific hash, which gets advanced after
we do our due diligence. This is when we discover that certain packages
need to be added to our ${LOCAL_MIRROR}. My desire is to automate as much
as possible, while exposing as little as possible.]
Whenever the nightly build fails due to a missing package, and I see a URL
with a (for example) .tar.gz in the build error log, I know my job is a lot
easier. I can simply wget from any Internet connected host, instead of
spinning up the VM clone, waiting for a build to complete, and then
figuring out what is new in the downloads directory.
I was hoping that there was an equally simple way of grabbing git
repository packages from an Internet connected host without having a
bitbake build cache them for me.
I understand that these packages are effectively a bare clone, but there
seems to be some additional non-obvious (to me at least) "magic" that makes
it more complicated than doing a git repo bare clone and wrapping it up
into a .tar.gz.
I am happy to start trawling through source code and figure it out on my
own, but I figured this had to be common knowledge to someone on this list.
..Ch:W..
On Thu, Sep 26, 2019 at 8:50 PM Rudolf J Streif
wrote:
> 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.yoctoproject.org/mirror/sources/ \n \
> git://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
> gitsm://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
> hg://.*/.*http://downloads.yoctoproject.org/mirror/sources/ \n \
> osc://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
> p4://.*/.*http://downloads.yoctoproject.org/mirror/sources/ \n \
> svn://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n"
>
> This causes the fetcher to intercept and translate all the SCM protocols
> into http downloads from the YP mirror. Since you are saying wget works for
> you this should actually automatically work for you. If you build system
> can at least download using http then
>
> bitbake --runall=fetch
>
> should download all the sources for you. Then you can disconnect the box
> from the Internet and start the build offline.
>
> :rjs
> On 9/26/19 8:06 PM, Chuck Wolber wrote:
>
> 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
> server pointed to by ${LOCAL_MIRROR}.
>
> Obviously that procedure does not work so well when a git repository needs
> to be fetched. We have tried various methods, but nothing seems to work
> reliably. Our current method is an annoying hack involving a virtual
> machine clone of the build server.
>
> I have searched far and wide, and cannot find any sort of procedure. Can
> someone point me at a procedure for translating something like git://
> git.yoctoproject.org/pseudo into a file we can store in our
> ${LOCAL_MIRROR}?
>
> Thank you,
>
> ..Ch:W..
>
> --
> -
> Rudolf J Streif
> CEO/CTO ibeeto
> +1.855.442.3386 x700
>
>
--
“I would challenge anyone here to think of a question upon which we once
had a scientific answer, however inadequate, but for which now the best
answer is a religious one." -Sam Harris
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Schedule Announced for Yocto Project Summit Europe 2019
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 Project Additional sessions and the full schedule covering a range of topics including devtool, best practices for building layers, working with/creating BSPs, can be found on the registration page. Register today. Pricing increases after September 27. REGISTER NOW > https://www.yoctoproject.org/yocto-project-summit-2019-2/ The Yocto Project Summit, scheduled for October 31-November 1, 2019 at the Lyon Convention Centre, Lyon, France, is a technical conference for engineers, open source technologists, students and academia in the OSS space. Organized in conjunction with ELCE 2019, this 2-day event is where individuals will learn about Yocto Projects' direction -- including, but not limited to, new releases, development tools, features -- get training on the next wave of embedded Linux technologies (segment previously known as Yocto Project Developer Day), and network with their industry peers, Yocto Project maintainers and experts. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Downloading Git Archives
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.yoctoproject.org/mirror/sources/ \n \
git://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
gitsm://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
hg://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
osc://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
p4://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
svn://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n"
This causes the fetcher to intercept and translate all the SCM protocols
into http downloads from the YP mirror. Since you are saying wget works
for you this should actually automatically work for you. If you build
system can at least download using http then
bitbake --runall=fetch
should download all the sources for you. Then you can disconnect the box
from the Internet and start the build offline.
:rjs
On 9/26/19 8:06 PM, Chuck Wolber wrote:
> 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 server pointed to by ${LOCAL_MIRROR}.
>
> Obviously that procedure does not work so well when a git repository
> needs to be fetched. We have tried various methods, but nothing seems
> to work reliably. Our current method is an annoying hack involving a
> virtual machine clone of the build server.
>
> I have searched far and wide, and cannot find any sort of procedure.
> Can someone point me at a procedure for translating something like
> git://git.yoctoproject.org/pseudo
> into a file we can store in our ${LOCAL_MIRROR}?
>
> Thank you,
>
> ..Ch:W..
>
--
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700
signature.asc
Description: OpenPGP digital signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Downloading Git Archives
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
server pointed to by ${LOCAL_MIRROR}.
Obviously that procedure does not work so well when a git repository needs
to be fetched. We have tried various methods, but nothing seems to work
reliably. Our current method is an annoying hack involving a virtual
machine clone of the build server.
I have searched far and wide, and cannot find any sort of procedure. Can
someone point me at a procedure for translating something like git://
git.yoctoproject.org/pseudo into a file we can store in our ${LOCAL_MIRROR}?
Thank you,
..Ch:W..
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH v2] yocto-bsps: update to v5.2.17
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.bbappend| 20 +-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.2.bbappend b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.2.bbappend index b7cefd25ca..f15bccbaf2 100644 --- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.2.bbappend +++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.2.bbappend @@ -8,11 +8,11 @@ KMACHINE_genericx86 ?= "common-pc" KMACHINE_genericx86-64 ?= "common-pc-64" KMACHINE_beaglebone-yocto ?= "beaglebone" -SRCREV_machine_genericx86?= "77c28ea0e55cabb0b22b47d4eb2cc94b0940dfe6" -SRCREV_machine_genericx86-64 ?= "35276d20c01a78ee3640a074446b0c15c486c5d0" -SRCREV_machine_edgerouter ?= "35276d20c01a78ee3640a074446b0c15c486c5d0" -SRCREV_machine_beaglebone-yocto ?= "77c28ea0e55cabb0b22b47d4eb2cc94b0940dfe6" -SRCREV_machine_mpc8315e-rdb ?= "cae01d71ef67eaafec75ce24f49b038b705b8711" +SRCREV_machine_genericx86?= "25b14cdf9659c68ab32d66616dfdbbe2ece3fd94" +SRCREV_machine_genericx86-64 ?= "25b14cdf9659c68ab32d66616dfdbbe2ece3fd94" +SRCREV_machine_edgerouter ?= "25b14cdf9659c68ab32d66616dfdbbe2ece3fd94" +SRCREV_machine_beaglebone-yocto ?= "25b14cdf9659c68ab32d66616dfdbbe2ece3fd94" +SRCREV_machine_mpc8315e-rdb ?= "77f031b182885c177b3a96098ae61271911a7954" COMPATIBLE_MACHINE_genericx86 = "genericx86" COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64" @@ -20,8 +20,8 @@ COMPATIBLE_MACHINE_edgerouter = "edgerouter" COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto" COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb" -LINUX_VERSION_genericx86 = "5.2.10" -LINUX_VERSION_genericx86-64 = "5.2.10" -LINUX_VERSION_edgerouter = "5.2.10" -LINUX_VERSION_beaglebone-yocto = "5.2.10" -LINUX_VERSION_mpc8315e-rdb = "5.2.10" +LINUX_VERSION_genericx86 = "5.2.17" +LINUX_VERSION_genericx86-64 = "5.2.17" +LINUX_VERSION_edgerouter = "5.2.17" +LINUX_VERSION_beaglebone-yocto = "5.2.17" +LINUX_VERSION_mpc8315e-rdb = "5.2.17" -- 2.19.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] yocto-bsps: update to v5.2.17
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 | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.2.bbappend > b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.2.bbappend > index b7cefd25ca..63027d3f99 100644 > --- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.2.bbappend > +++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.2.bbappend > @@ -9,10 +9,10 @@ KMACHINE_genericx86-64 ?= "common-pc-64" > KMACHINE_beaglebone-yocto ?= "beaglebone" > > SRCREV_machine_genericx86?= "77c28ea0e55cabb0b22b47d4eb2cc94b0940dfe6" > -SRCREV_machine_genericx86-64 ?= "35276d20c01a78ee3640a074446b0c15c486c5d0" > -SRCREV_machine_edgerouter ?= "35276d20c01a78ee3640a074446b0c15c486c5d0" > +SRCREV_machine_genericx86-64 ?= "25b14cdf9659c68ab32d66616dfdbbe2ece3fd94" > +SRCREV_machine_edgerouter ?= "25b14cdf9659c68ab32d66616dfdbbe2ece3fd94" > SRCREV_machine_beaglebone-yocto ?= > "77c28ea0e55cabb0b22b47d4eb2cc94b0940dfe6" > -SRCREV_machine_mpc8315e-rdb ?= "cae01d71ef67eaafec75ce24f49b038b705b8711" > +SRCREV_machine_mpc8315e-rdb ?= "77f031b182885c177b3a96098ae61271911a7954" > I may have a bug in my script (or an old input) .. let me check why not all the board SRCREV updates. I can send a v2 in a couple of hours (but this as-is, won't break anything). Bruce > > COMPATIBLE_MACHINE_genericx86 = "genericx86" > COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64" > @@ -20,8 +20,8 @@ COMPATIBLE_MACHINE_edgerouter = "edgerouter" > COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto" > COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb" > > -LINUX_VERSION_genericx86 = "5.2.10" > -LINUX_VERSION_genericx86-64 = "5.2.10" > -LINUX_VERSION_edgerouter = "5.2.10" > -LINUX_VERSION_beaglebone-yocto = "5.2.10" > -LINUX_VERSION_mpc8315e-rdb = "5.2.10" > +LINUX_VERSION_genericx86 = "5.2.17" > +LINUX_VERSION_genericx86-64 = "5.2.17" > +LINUX_VERSION_edgerouter = "5.2.17" > +LINUX_VERSION_beaglebone-yocto = "5.2.17" > +LINUX_VERSION_mpc8315e-rdb = "5.2.17" > -- > 2.19.1 > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] yocto-bsps: update to v5.2.17
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 insertions(+), 8 deletions(-) diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.2.bbappend b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.2.bbappend index b7cefd25ca..63027d3f99 100644 --- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.2.bbappend +++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.2.bbappend @@ -9,10 +9,10 @@ KMACHINE_genericx86-64 ?= "common-pc-64" KMACHINE_beaglebone-yocto ?= "beaglebone" SRCREV_machine_genericx86?= "77c28ea0e55cabb0b22b47d4eb2cc94b0940dfe6" -SRCREV_machine_genericx86-64 ?= "35276d20c01a78ee3640a074446b0c15c486c5d0" -SRCREV_machine_edgerouter ?= "35276d20c01a78ee3640a074446b0c15c486c5d0" +SRCREV_machine_genericx86-64 ?= "25b14cdf9659c68ab32d66616dfdbbe2ece3fd94" +SRCREV_machine_edgerouter ?= "25b14cdf9659c68ab32d66616dfdbbe2ece3fd94" SRCREV_machine_beaglebone-yocto ?= "77c28ea0e55cabb0b22b47d4eb2cc94b0940dfe6" -SRCREV_machine_mpc8315e-rdb ?= "cae01d71ef67eaafec75ce24f49b038b705b8711" +SRCREV_machine_mpc8315e-rdb ?= "77f031b182885c177b3a96098ae61271911a7954" COMPATIBLE_MACHINE_genericx86 = "genericx86" COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64" @@ -20,8 +20,8 @@ COMPATIBLE_MACHINE_edgerouter = "edgerouter" COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto" COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb" -LINUX_VERSION_genericx86 = "5.2.10" -LINUX_VERSION_genericx86-64 = "5.2.10" -LINUX_VERSION_edgerouter = "5.2.10" -LINUX_VERSION_beaglebone-yocto = "5.2.10" -LINUX_VERSION_mpc8315e-rdb = "5.2.10" +LINUX_VERSION_genericx86 = "5.2.17" +LINUX_VERSION_genericx86-64 = "5.2.17" +LINUX_VERSION_edgerouter = "5.2.17" +LINUX_VERSION_beaglebone-yocto = "5.2.17" +LINUX_VERSION_mpc8315e-rdb = "5.2.17" -- 2.19.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QA cycle report for 2.8 M3 RC1
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 new defects are found in this cycle, mpc8315e-rdb System randomly > hang when running commands (BUG id:13555) > > Due to this issue, oeqa would be timeout and many tests are > skipped/failed on mpc8315e-rdb. > > and ptest failed (BUG id:13556). > > > Thank you for the summary. > === Bugs > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13555 > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13556 > We split the pongo issue into its own bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13557 - armin > > > > Thanks & Regards, > > Sangeeta Jain > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Transfer meta-data between recipes
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 want to > use a > secondary recipe which I am creating to sign the resulting boot binary. My > issue > is that the NXP code signing tool needs some info about the binary to sign. > These details are send to stdout by imx-mkimage tool, which is called by the > imx > boot makefile (used here: > https://github.com/Freescale/meta-freescale/blob/master/recipes-bsp/imx-mkimage/imx-boot_0.2.bb#L104). > In the cases I know of, most code signing is either done in the recipe itself (via an added task from a special class after install and prior to packaging) or it's being done at rootfs/image generation time. > > I can override the compile step of imx-boot to save stdout into a file, deploy > this file and later parse it to extract the offset dump, but that feels “ugly” > and the file is by no means a output of the imx-boot recipe for the target > system, but for another step. Is there any recommended way to parse such > variable metadata between recipes? Namespace is local to a recipe. The only way you can share from one namespace to another is write the data into a file, and then load it in the second. That is done occasionally for link time settings and such. (i.e. pkgconfig). --Mark > > > Olli > > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Transfer meta-data between recipes
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 resulting boot binary. My issue is that the NXP code signing tool needs some info about the binary to sign. These details are send to stdout by imx-mkimage tool, which is called by the imx boot makefile (used here: https://github.com/Freescale/meta-freescale/blob/master/recipes-bsp/imx-mkimage/imx-boot_0.2.bb#L104). I can override the compile step of imx-boot to save stdout into a file, deploy this file and later parse it to extract the offset dump, but that feels "ugly" and the file is by no means a output of the imx-boot recipe for the target system, but for another step. Is there any recommended way to parse such variable metadata between recipes? Olli -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-qt5] qt5.sh in environment-setup.d
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_SYSROOT/environment-setup.d" ]; then for envfile in $OECORE_NATIVE_SYSROOT/environment-setup.d/*.sh; do . $envfile done fi The 'environment-setup.d' directory contains 'qt5.sh', which ultimately relies on STAGING_LIBDIR to resolve. These are the variables: OE_QMAKE_INCDIR_QT QMAKESPEC OE_QMAKE_QT_CONFIG OE_QMAKE_LIBDIR_QT I don't know if this is a mistake on my part or a bug in meta-qt5. It may even be harmless, but I am still surprised to find my build host paths in the SDK I am distributing across the team. Can someone please explain what might be going on? Much regards, Adam -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
