[yocto] [ANNOUNCEMENT] Yocto Project 1.6.2 (daisy) now available.
All, We are pleased to release the second point release for the Yocto Project's "daisy" release. This release has fixes for 25 CVEs including CVE-2014-3566. Several fixes for CVE-2014-3566 (the SSL Poodle vulnerability) have been applied to OpenSSL in this release; however, due to the nature of the vulnerability you will need to ensure that SSL 3.0 support is either disabled, or alternatively that TLS_FALLBACK_SCSV is implemented in both clients and servers that use TLS/SSL. For more information, check with the upstream provider of TLS/SSL client / server software that you are using. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566 https://www.us-cert.gov/ncas/alerts/TA14-290A Downloads are available at: http://downloads.yoctoproject.org/releases/yocto/yocto-1.6.2/poky-daisy-11.0.2.tar.bz2 Release Name: poky-daisy-11.0.2 Branch: daisy Tag: daisy-11.0.2 Hash: e3dd621197548b4cf64988e757e9bc926082db73 md5sum: d0fec76994622bf668ce13779ac73f43 download: http://downloads.yoctoproject.org/releases/yocto/yocto-1.6.2/poky-daisy-11.0.2.tar.bz2 Release Name: meta-qt3-daisy-11.0.2 Branch: daisy Tag: daisy-11.0.2 Hash: 3016129d90b7ac8517a5227d819f10ad417b5b45 md5sum: 139394eca6575b9ab31d2f79f7830f2a download: http://downloads.yoctoproject.org/releases/yocto/yocto-1.6.2/meta-qt3-daisy-11.0.2.tar.bz2 Release Name: eclipse-poky-juno-daisy-11.0.2 Branch: daisy Tag: daisy-11.0.2 Hash: 26bfc407781aa185f244a47ba63120343cee4a37 md5sum: bce7d1644d6bf4ea528db9a511124bba download: http://downloads.yoctoproject.org/releases/yocto/yocto-1.6.2/eclipse-poky-juno-daisy-11.0.2.tar.bz2 Release Name: eclipse-poky-kepler-daisy-11.0.2 Branch: daisy Tag: daisy-11.0.2 Hash: 932891014ea068e196fcf1f9efedb8a672fb81a0 md5sum: f85546bfd1da67d72c0b743780146220 download: http://downloads.yoctoproject.org/releases/yocto/yocto-1.6.2/eclipse-poky-kepler-daisy-11.0.2.tar.bz2 Bug Fixes - adt-installer: fix sed input file error bash: Fix for exported function namespace change binutils: Add fix for recent patch on older gcc binutils: Apply the proper fix for PR 16428 bitbake: codeparser: don't interact with the cache for subshells bitbake: codeparser: Fix to better catch all getVar references build-appliance-image: Update to daisy head revision build-appliance-image: Update to daisy head revision cairo: explicitly disable LTO support by backporting patch which removes it crosssdk: Clear MACHINEOVERRIDES dev-manual: Updated the "Making Images More Secure" section. documentation: Added "November 2014" to manual history lists. documentation: Updated manual history tables to support 1.6.2 kernel: don't copy .so.dbg files into kernel source install kernelshark: Remove trace-cmd from the kernelshark package layer.conf: Add in useradd dependencies as ABISAFE dependencies layer.conf: Mark opkg-utils as ABISAFE for update-alternatives usage libarchive: avoid dependency on e2fsprogs libxml2: fix python packaging for nativesdk ltp: Added zip-native as a DEPENDS lttng-modules: Update to version 2.4.2 mega-manual.sed: Updates to support links to BB manual native/nativesdk: Clear MACHINEOVERRIDES openssh: avoid screen sessions being killed on disconnect with systemd openssl: upgrade to 1.0.1j openssl: Upgrade to 1.0.1j perf: add slang to the dependencies perf: explicitly disable libunwind perf: fix broken shell comparsion in do_install perf: split packging poky.conf: Bump DISTRO_VERISON for 1.6.2 poky-ent: Updated the YOCTO_RELEASE_NOTES variable. poky.ent: Updated variables to support a 1.6.2 release. populate_sdk_base: Fix grep command usage on old hosts populate_sdk_deb: Fix non x86_64 SDK builds profile-manual: Updates to the LTTng Documentation section. pseudo*.bb: update to pseudo 1.6.2 pseudo.inc: Clean up backport of version update to 1.6.2 python: force off_t size to 8 to enable large file support qemu: Explicitly disable libiscsi, its not in DEPENDS qt4: Fix Qt 4.8.5 source to new location readline: Patch for readline multikey dispatch issue ref-manual: Updated note in the "CentOS Packages" section. ref-manual, yocto-project-qs: Fixed some references to BitBake Manual. shadow-securetty: add freescale lpuart udev-cache.default: set PROBE_PLATFORM_BUS to "yes" by default udev: update init script for conditional probing of platform bus update-rc.d/systemd: Remove OVERRIDES dependency useradd-staticids.bbclass: Fix for Bug 6633 wic: Fix bad directory name in bootimg-efi wic: Remove fstype from mkefidisk canned wks Security Fixes -- bash: Fix CVE-2014-6271 bash: Fix CVE-2014-7169 bash: Fix for CVE-2014-6277 bash: Fix-for-CVE-2014-6278 bash: Fix for CVE-2014-7186 and CVE-2014-7187 curl: Security Advisory - curl - CVE-2014-3613 curl: Security Advisory - curl - CVE-2014-3620 dpkg: Security Advisory - CVE-2014-0471 dpkg: Security Advisory - CVE-2014-3127 eglibc: CVE-2014-5119 fix gnupg: CVE-2013-4242 gst-ffmpeg: Add CVE patches gst-ffmpeg: Security Advisory - ffmpeg - CVE-2013-0869 gst-ffmpeg: Security Advisory - ffmpeg
[yocto] qemu-native fails to build, due to libgpg-error-native
Hi, We've recently replaces on of our buildmachines, and while doing this, we've been running into what looks like on ordering & dependency issue. The issue may very well be related to our host OS, which is openSuSE 13.2 (i.e. it's not yet validated...). The simplified test case is simply 1) Check out poky (we've seen the issue on master, dizzy, and daisy branches) 2) . ./oe-init-build-env 3) bitbake libgpg-error-native 4) bitbake qemu-native Now qemu-native fails at do_configure: | ERROR: User requested feature sdl |configure was not able to find it. |Install SDL devel Upon inspecting config.log (when building from poky master), the culprit is that libgpg-error is not found (or more likely the wrong version). gcc -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -isystem/mnt/cs-builds/anders/poky/build/tmp/sysroots/x86_64-linux/usr/include -O2 -pipe -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL -o config-temp/qemu-conf.exe config-temp/qemu-conf.c -Wl,-z,relro -Wl,-z,now -pie -m64 -g -L/mnt/cs-builds/anders/poky/build/tmp/sysroots/x86_64-linux/usr/lib -L/mnt/cs-builds/anders/poky/build/tmp/sysroots/x86_64-linux/lib -Wl,-rpath-link,/mnt/cs-builds/anders/poky/build/tmp/sysroots/x86_64-linux/usr/lib -Wl,-rpath-link,/mnt/cs-builds/anders/poky/build/tmp/sysroots/x86_64-linux/lib -Wl,-rpath,/mnt/cs-builds/anders/poky/build/tmp/sysroots/x86_64-linux/usr/lib -Wl,-rpath,/mnt/cs-builds/anders/poky/build/tmp/sysroots/x86_64-linux/lib -Wl,-O1 -L/usr/lib64 -lSDL -lpthread /usr/lib64/libgcrypt.so.20: undefined reference to `gpg_err_set_errno@GPG_ERROR_1.0' /usr/lib64/libgcrypt.so.20: undefined reference to `gpg_err_code_from_syserror@GPG_ERROR_1.0' /usr/lib64/libgcrypt.so.20: undefined reference to `gpg_err_code_from_errno@GPG_ERROR_1.0' /usr/lib64/libgcrypt.so.20: undefined reference to `gpgrt_lock_unlock@GPG_ERROR_1.0' /usr/lib64/libgcrypt.so.20: undefined reference to `gpg_strerror@GPG_ERROR_1.0' /usr/lib64/libgcrypt.so.20: undefined reference to `gpg_strsource@GPG_ERROR_1.0' /usr/lib64/libgcrypt.so.20: undefined reference to `gpgrt_lock_lock@GPG_ERROR_1.0' collect2: error: ld returned 1 exit status As the build works if libgpg-error-native hasn't been built prior to qemu-native, it seems to me that when it works, it takes libgpg-error from the host, while in the failing case it takes it from the native sysroot... Any pointers on how to make the configure step consistent in looking at for the host libgpg-error? Or should qemu-native be linked against libgcrypt from the sysroot too? I'll likely continue looking at this issue next week, though any pointer that will help me will be much appreciated. Cheers, Anders -- Anders Darander ChargeStorm AB / eStorm AB -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] u-boot precompiled ?
Hello Matt,
thanks very much for your reply, I was able to create a simple patch changing
an u-boot setting as test and "bbappended" it. I just didn't believe before
that the various u-boot settings are "hard-coded" but they obviously are in the
".h", so patching it seems to be the only way for changing settings from
within yocto, right?
Regards,
Mat
Von: Matt Schuckmann [mailto:matt.schuckm...@planar.com]
Gesendet: Donnerstag, 4. Dezember 2014 18:31
An: Heise, Matthias; yocto@yoctoproject.org
Betreff: RE: u-boot precompiled ?
Mat,
I'm fairly new to OpenEmbedded (4 months now and I still feel like a noobi but
I'm trying to give back while the pain is still fresh in my mind)
For something like u-boot it kind of depends on what your changing. If you need
to change the u-boot code and the changes are small then typically you'd create
a patch f for your changes and then make them part of a .bbappend in your layer
for the recipe. There are examples on the net for how to create a .bbappend and
reference the patch file.
Generally your .bbappend can be as simple as:
FILESEXTRAPATHS_prepend = ":${THISDIR}/files"
SRC_URI += "files://xyzzy.patch"
Where your patches are in subdirectory of your recipe directory.
Remember that generally recipes are about how to obtain the code, build it and
package it for distribution, you can do recipes that deal with a pre-built
binary but that is generally not the case.
Hope this helps,
Matt S.
From: yocto-boun...@yoctoproject.org
[mailto:yocto-boun...@yoctoproject.org] On Behalf Of
matthias.he...@atlas-elektronik.com
Sent: Thursday, December 04, 2014 1:49 AM
To: yocto@yoctoproject.org
Subject: Re: [yocto] u-boot precompiled ?
Even if this is a stupid question a little advise would be nice ... like "don't
ask so stupid questions, go read this and that" or something... no time ?
Should I rather unsubscribe from this list until I'm an expert?
Von: Heise, Matthias
Gesendet: Mittwoch, 3. Dezember 2014 15:15
An: 'yocto@yoctoproject.org'
Betreff: u-boot precompiled ?
Hi all,
I'm still trying to find out basic things about getting a system up and
running. This question is about U-Boot, is it right that for example for my
wandboard a pre-compiled *.imx is just downloaded ?
So if I want to make settings to U-Boot I make them directly in the source,
compile it and re-direct in a recipe to take that new file as bootloader ? Or
can I make the settings within a recipe and I just didn't find the spot ?
Thanks for your time,
Regards
Mat
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] u-boot precompiled ?
On 2014-12-05 05:48, matthias.he...@atlas-elektronik.com wrote:
Hello Matt,
thanks very much for your reply, I was able to create a simple patch changing
an u-boot setting as test and “bbappended” it. I just didn’t believe before
that the various u-boot
settings are “hard-coded” but they obviously are in the “.h”, so
patching it seems to be the only way for changing settings from within yocto, right?
What U-Boot settings are you asking about?
*Von:*Matt Schuckmann [mailto:matt.schuckm...@planar.com]
*Gesendet:* Donnerstag, 4. Dezember 2014 18:31
*An:* Heise, Matthias; yocto@yoctoproject.org
*Betreff:* RE: u-boot precompiled ?
Mat,
I’m fairly new to OpenEmbedded (4 months now and I still feel like a noobi but
I’m trying to give back while the pain is still fresh in my mind)
For something like u-boot it kind of depends on what your changing. If you need
to change the u-boot code and the changes are small then typically you’d create
a patch f for your
changes and then make them part of a .bbappend in your layer for the recipe.
There are examples on the net for how to create a .bbappend and reference the
patch file.
Generally your .bbappend can be as simple as:
FILESEXTRAPATHS_prepend = “:${THISDIR}/files”
SRC_URI += “files://xyzzy.patch”
Where your patches are in subdirectory of your recipe directory.
Remember that generally recipes are about how to obtain the code, build it and
package it for distribution, you can do recipes that deal with a pre-built
binary but that is
generally not the case.
Hope this helps,
Matt S.
*From:*yocto-boun...@yoctoproject.org
[mailto:yocto-boun...@yoctoproject.org] *On Behalf Of
*matthias.he...@atlas-elektronik.com
*Sent:* Thursday, December 04, 2014 1:49 AM
*To:* yocto@yoctoproject.org
*Subject:* Re: [yocto] u-boot precompiled ?
Even if this is a stupid question a little advise would be nice … like “don’t
ask so stupid questions, go read this and that” or something… no time ? Should
I rather unsubscribe
from this list until I’m an expert?
*Von:*Heise, Matthias
*Gesendet:* Mittwoch, 3. Dezember 2014 15:15
*An:* 'yocto@yoctoproject.org'
*Betreff:* u-boot precompiled ?
Hi all,
I’m still trying to find out basic things about getting a system up and
running. This question is about U-Boot, is it right that for example for my
wandboard a pre-compiled *.imx
is just downloaded ?
So if I want to make settings to U-Boot I make them directly in the source,
compile it and re-direct in a recipe to take that new file as bootloader ? Or
can I make the settings
within a recipe and I just didn’t find the spot ?
Thanks for your time,
Regards
Mat
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] using preferred_provider
Facing an issue, where item 'libpython2.7.so.1.0¹ is provided by 2 different packages (libpython2.7-1.0-2.7.2-r5.19.lib32_x86, core.bb). Core.bb is our own implementation that packages this file. While building final image, do_rootfs() complains that there is a conflict and errors out. error: file /usr/lib/libpython2.7.so.1.0 conflicts between attempted installs of core-1.0-r0.lib32_n9000 and libpython2.7-1.0-2.7.2-r5.19.lib32_x86 Is it okay to add below variable to denote that I want to ignore content of libpython2.7 and use the item provided by core? Or is below syntax wrong? I keep getting above error, so looking for some help to resolve this. PREFERRED_PROVIDER_libpython2.7.so.1.0 ?= "core" Vinodh -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [autobuilder][PATCH 0/2] GitPoller changesource improvements
These are fixes on top of California Sullivan's work for adding the GitPoller changesource. With my testing, I was unable to get the GitPoller changesource to work until I added the first patch. The second patch documents how to use the GitPoller changesource. Applies on top of HEAD of git://git.yoctoproject.org/yocto-autobuilder branch sullical/contrib Bryan Evenson (2): Autobuilder.py: Import gitpoller module Documentation: Document GitPoller changesource README-NEW-AUTOBUILDER | 35 docs/YoctoAutobuilderDevelopersDocument.html | 26 +-- .../site-packages/autobuilder/Autobuilder.py |1 + 3 files changed, 54 insertions(+), 8 deletions(-) -- 1.7.9.5 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [autobuilder][PATCH 1/2] Autobuilder.py: Import gitpoller module
For the GitPoller changesource to work, Autobuilder.py needs the Buildbot GitPoller module. This commit imports the GitPoller module in Autobuilder.py. Signed-off-by: Bryan Evenson --- .../site-packages/autobuilder/Autobuilder.py |1 + 1 file changed, 1 insertion(+) diff --git a/lib/python2.7/site-packages/autobuilder/Autobuilder.py b/lib/python2.7/site-packages/autobuilder/Autobuilder.py index b76c213..0dae5dc 100644 --- a/lib/python2.7/site-packages/autobuilder/Autobuilder.py +++ b/lib/python2.7/site-packages/autobuilder/Autobuilder.py @@ -18,6 +18,7 @@ from buildbot.schedulers import timed from buildbot.schedulers.basic import SingleBranchScheduler from buildbot.changes import filter from buildbot.changes.pb import PBChangeSource +from buildbot.changes.gitpoller import * from lib.ABTools import capitalize import ast import BuildSet -- 1.7.9.5 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [autobuilder][PATCH 2/2] Documentation: Document GitPoller changesource
Adds documentation to README-NEW-AUTOBUILDER and the HTML documentation on how to use the GitPoller changesource. Signed-off-by: Bryan Evenson --- README-NEW-AUTOBUILDER | 35 +- docs/YoctoAutobuilderDevelopersDocument.html | 26 +-- 2 files changed, 53 insertions(+), 8 deletions(-) diff --git a/README-NEW-AUTOBUILDER b/README-NEW-AUTOBUILDER index a6476f2..97bbe61 100644 --- a/README-NEW-AUTOBUILDER +++ b/README-NEW-AUTOBUILDER @@ -182,7 +182,8 @@ scheduler: A list of dicts. Each item defines a scheduler associated with this definition. stable-timer: how long (in seconds) to wait after change before -triggering build to allow for changes to settle. +triggering build to allow for changes to settle. Defaults +to 60 seconds. change-user: the user name which the remote hook will use; the default value is the repository name as per the 'repository' @@ -194,6 +195,17 @@ scheduler: A list of dicts. Each item defines a scheduler associated with this secret to avoid injection of arbitrary changes into your autobuilder. + changesource: the type of changesource to use for the scheduler; +the default setting is a PBChangeSource. Only other valid +option is 'GitPoller' for a GitPoller changesource. See the +official Buildbot documentation at + http://docs.buildbot.net/latest/manual/cfg-changesources.html +for more information on changesources. + + interval: The interval between polling for changes. Only valid +for GitPoller changesources. Defaults to 300 seconds (five +minutes). + Extra Notes on SingleBranchScheduler setup -- @@ -204,10 +216,10 @@ scheduler: A list of dicts. Each item defines a scheduler associated with this do nightly rebuilds for some repos and immediate for others. The scheduler change filter is set up to watch changes only in the - single repository specified, so you have to set up your repository - hook to sent the repository url in the change set with the - --repository argument to git_buildbot.py, e.g., your git post-receive - hook could look something like: + single repository specified. If you are using a PBChangeSource, you + have to set up your repository hook to send the repository url in the + change set with the --repository argument to git_buildbot.py, e.g., + your git post-receive hook could look something like: #!/bin/sh echo "$1 $2 $3" | \ @@ -224,7 +236,18 @@ scheduler: A list of dicts. Each item defines a scheduler associated with this git_buildbot.py --repository="file:///where_your_repo_is" Because of the way builbot change sources work, your change user - names must not colide with the user names used by your slaves. + names must not collide with the user names used by your slaves. + + If you are using a GitPoller changesource and you specify a valid + repository but an non-existent branch, Buildbot will silently ignore + your scheduler. If a repository has changed recently but your build + has not triggered, validate that your repository and branch settings + are valid. + + For either a PBChangeSource or a GitPoller changesource, the + scheduler will not see the initial repository discovery as a change. + If you are using a SingleBranchScheduler schedule, it is good + practice to force a build to verify the buildset works correctly. Example: diff --git a/docs/YoctoAutobuilderDevelopersDocument.html b/docs/YoctoAutobuilderDevelopersDocument.html index e3eb406..d8c5ccb 100644 --- a/docs/YoctoAutobuilderDevelopersDocument.html +++ b/docs/YoctoAutobuilderDevelopersDocument.html @@ -1218,7 +1218,7 @@ the user name which the remote hook will use; the default value is the repository name as per the 'repository' property. - + change-password @@ -1229,15 +1229,37 @@ password which the remote hook will use; the default is the buildbot default 'changepw' -- if your autobuilder is publically accessible, you want to keep this secret to avoid injection of arbitrary changes into your autobuilder. + + +changesource +
