[yocto] [ YOCTO ] [ WIC ] problem to compile
Hello Everybody, I met a problem to use WIC , with the error following : ERROR: Nothing PROVIDES 'syslinux' ERROR: syslinux was skipped: incompatible with host arm-poky-linux-gnueabi (not in COMPATIBLE_HOST) I know that possible to compile syslinux for arm, but Idon't know why I can't do it. My computer has Ubuntu 16.04, and I compile poky (branch Krogoth), (commit 5d11ed) (date 2016-05-03). Hardware : IMX6 Quad, ROJ manufacturer Have you an idea why the arm architecture aren't in the compatible host? Thanks a lot, -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] downloads.yoctoproject.org/mirror out of date
Hi, yesterday I had a build error in the unpack step. git couldn't find a reference. It turned out that because of a temporary firewall issue bitbake took the http mirror downloads.yoctoproject.org for yocto-kernel-cache. It looks like the mirror hasn't been updated since a while (Nov last year): $ git ls-remote https://git.yoctoproject.org/git/yocto-kernel-cache master 789605826bbbdd4d0762d9e4262d0ef28663770drefs/heads/master $ wget -q http://downloads.yoctoproject.org/mirror/sources/git2_git.yoctoproject.org.yocto-kernel-cache.tar.gz $ tar -xzf git2_git.yoctoproject.org.yocto-kernel-cache.tar.gz $ git log -1 commit 5c3d76b10595cf2b90ec3749415adf9bde21d55c Author: Jason Wessel Date: Thu Nov 2 19:11:27 2017 -0700 cgroups.cfg: Add missing controllers Regards Georg -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] crops/poky workflow and git
Hi! Anyone here regularly doing yocto builds from crops/poky [1] containers? If I got it right, the idea behind using containers derived from crops/poky image for builds is to keep the entire development workflow outside the container and use the container for build related commands only (ideally setting up the env and running bitbake). Then, a very annoying issue I face in trying to enforce this idea as my regular workflow is that interacting with git repositories created while the build runs is becoming almost impossible from outside the container, where regular git work is expected to be more conveniently done. The point is that repos get created when bitbake fetches sources from within the container and git itself hardcodes absolute paths in some of its control files. What I see is while running git from within the repo but outside the contained scope, is git itself complaining with messages like this: error: object directory /workdir/blah/blah/blah does not exist; check .git/objects/info/alternates. fatal: bad object HEAD docker I'm using crops/poky as suggested in [1] hence bind mounting a volume with the entire project rootdir under /workdir within the container. Any suggestion how to make this more friendly, other than moving the entire git workflow inside the same or another container that bind mounts the volume at the same location? I'm curious to know if/how people try to leverage the isolation of containers and how they do mitigate sharp edges I found in migrating builds to them. [1] https://github.com/crops/poky-container -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [ANNOUNCEMENT] Milestone 2 for Yocto Project 2.5 (yocto-2.5_M2) now available
The second milestone release for Yocto Project 2.5 (yocto-2.5_M2) is available for download now. Download: http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-2.5_M2/ eclipse-poky-neon 731e346f2187a3c6b44af72ef75d4d5029b54d9c eclipse-poky-oxygen ccf940d787ba3cf91092a07e18fbd52c5ef7d303 meta-qt3 f33b73a9563f2dfdfd0ee37b61d65d90197a456f meta-qt4 f313dbee2ac3d5fcc9801407947d3cb6cfb90b5d poky 385944254d0ef88bd6450a221a54cbcb40020b42 Test report: https://wiki.yoctoproject.org/wiki/WW07_-_2018-02-14-_Full_Test_Cycle_-_2.5_M2_rc1 Thank you. Tracy Graydon Yocto Project Build and Release tracy.gray...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] hostname.sh: remove warning for bashism
The use of the environment variable HOSTNAME, triggers the checkbashisms script, so change HOSTNAME to LOCALHOST Signed-off-by: Ulf Samuelsson --- meta/recipes-core/initscripts/initscripts-1.0/hostname.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-core/initscripts/initscripts-1.0/hostname.sh b/meta/recipes-core/initscripts/initscripts-1.0/hostname.sh index 95287cc..f4ba2b8 100755 --- a/meta/recipes-core/initscripts/initscripts-1.0/hostname.sh +++ b/meta/recipes-core/initscripts/initscripts-1.0/hostname.sh @@ -7,7 +7,7 @@ # Default-Stop: # Short-Description: Set hostname based on /etc/hostname ### END INIT INFO -HOSTNAME=$(/bin/hostname) +LOCALHOST=$(/bin/hostname) hostname -b -F /etc/hostname 2> /dev/null if [ $? -eq 0 ]; then @@ -17,6 +17,6 @@ fi # Busybox hostname doesn't support -b so we need implement it on our own if [ -f /etc/hostname ];then hostname `cat /etc/hostname` -elif [ -z "$HOSTNAME" -o "$HOSTNAME" = "(none)" -o ! -z "`echo $HOSTNAME | sed -n '/^[0-9]*\.[0-9].*/p'`" ] ; then +elif [ -z "$LOCALHOST" -o "$LOCALHOST" = "(none)" -o ! -z "`echo $LOCALHOST | sed -n '/^[0-9]*\.[0-9].*/p'`" ] ; then hostname localhost fi -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [ANNOUNCEMENT] Yocto Project 2.2.3 (morty 16.0.3) Released
Hello, The latest release of the Yocto Project 2.2.3 (morty-16.0.3) is now available for download at: http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.3/poky-morty-16.0.3.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-2.2.3/poky-morty-16.0.3.tar.bz2 A gpg signed version of these release notes is available at: http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.3/RELEASENOTES Full pass test report is available at: https://wiki.yoctoproject.org/wiki/WW06_-_2018-02-08_-_Full_Point_Release_Test_Cycle_2.2.3_rc2 Thank you to everyone for your contributions to this release! Tracy Graydon Yocto Project Build and Release tracy.gray...@intel.com -- yocto-2.2.3 Errata -- Release Name: eclipse-poky-neon-morty-16.0.3 Branch: neon/morty Tag: neon/morty-16.0.3 Hash: f4d0e8a939e2e34bea910b251f5d5087180733c3 md5: 96baf616a1bc8abba1157cc1b7c8cb6b Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.3/eclipse-poky-neon-morty-16.0.3.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-2.2.3/eclipse-poky-neon-morty-16.0.3.tar.bz2 Release Name: eclipse-poky-oxygen-morty-16.0.3 Branch: oxygen/morty Tag: oxygen/morty-16.0.3 Hash: 126e707a6de212feeaaf093edc170aaa74192ce7 md5: 41702878b4259aff66ae01bac70d554d Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.3/eclipse-poky-oxygen-morty-16.0.3.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-2.2.3/eclipse-poky-oxygen-morty-16.0.3.tar.bz2 Release Name: meta-qt3-morty-16.0.3 Branch: morty Tag: morty-16.0.3 Hash: f33b73a9563f2dfdfd0ee37b61d65d90197a456f md5: cf296376970262bff5527957e6e78121 Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.3/meta-qt3-morty-16.0.3.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-2.2.3/meta-qt3-morty-16.0.3.tar.bz2 Release Name: meta-qt4-morty-16.0.3 Branch: morty Tag: morty-16.0.3 Hash: f389368dc86e745df14cab9eeb9a94bc02bd273e md5: 6a66289eadc6b22ad1a83861b44f7375 Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.3/meta-qt4-morty-16.0.3.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-2.2.3/meta-qt4-morty-16.0.3.tar.bz2 Release Name: poky-morty-16.0.3 Branch: morty Tag: morty-16.0.3 Hash: e6626951501cdf8c5516ad42fd585894f19c2327 md5: 5889497ed1947b7e927b5135fdf1adb8 Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.3/poky-morty-16.0.3.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-2.2.3/poky-morty-16.0.3.tar.bz2 - Known Issues - N/A -- Security Fixes -- glib.inc: set CVE_PRODUCT to glib glibc-common.inc: set CVE_PRODUCT to glibc sqlite3.inc: set CVE_PRODUCT to sqlite python.inc: set CVE_PRODUCT to python icu.inc: set CVE_PRODUCT to international_components_for_unicode bluez5.inc: set CVE_PRODUCT to bluez acpid.inc: set CVE_PRODUCT to acpid2 binutils: CVE-2017-15938 binutils: CVE-2017-15024 binutils: CVE-2017-14729 binutils: CVE-2017-9955 binutils: CVE-2017-9954 binutils: CVE-2017-9745 binutils: CVE-2017-9756 binutils: CVE-2017-9755 binutils: CVE-2017-9753_and_CVE-2017-9754 binutils: CVE-2017-9752 binutils: CVE-2017-9750 binutils: CVE-2017-9747 binutils: CVE-2017-9748 binutils: CVE-2017-9746 binutils: CVE-2017-9749 binutils: CVE-2017-9751 binutils: CVE-2017-7299 binutils: CVE-2017-8398 binutils: CVE-2017-8394 binutils: CVE-2017-8421 binutils: CVE-2017-8396 binutils: CVE-2017-8397 binutils: CVE-2017-8395 binutils: CVE-2017-8393 binutils: CVE-2017-7304 binutils: CVE-2017-7303 binutils: CVE-2017-7302 binutils: CVE-2017-7301 binutils: CVE-2017-7227 binutils: CVE-2017-7225 binutils: CVE-2017-7224 binutils: CVE-2017-7223 binutils: CVE-2017-12450_12452_12453_12454_12456 binutils: CVE-2017-12451 binutils: CVE-2017-12449, CVE-2017_12455, CVE-2017-12457, CVE-2017-12458, CVE-2017-12459 binutils: CVE-2017-12448 binutils: CVE-2017-7226 binutils: Security Fix CVE-2017-9041 binutils: Security fix for CVE-2017-9040 and 2017-9042 binutils: Security Fix CVE-2017-9039 binutis: Security fix CVE-2017-9038 binutis: Security fix CVE-2017-7614 glibc: CVE-2017-15670 glibc: Security fix for CVE-2017-8804 glibc: Fix CVE-2017-1000366 glibc: Fix CVE-2015-5180 zlib: Fix CVE-2016-9843 zlib: Fix CVE-2016-9842 zlib: Fix CVE-2016-9841 zlib: Fix CVE-2016-9840 ruby: Security fix for CVE-2017-14064 ruby: Security fix for CVE-2017-14033 ruby: Security fix for CVE-2017-9229 ruby: Secruity fix for CVE-2017-9226 ruby: Security fix for CVE-2017-9228 ruby: Security fix for CVE-2017-9227 ruby: Security fix for CVE-2016-7798 curl: Security fix for CVE-2017-1000101 curl: Security fix for CVE-2017-1000100 curl: Security fix for CVE-2016-9586 curl: Security fix for CVE-2016-8624 curl: Security fix for CVE-2016-8617 curl: Security fix for CVE-2016-8623 curl: Security fix for CVE-2016-8621 curl: Security fix for CVE-2016-8620 curl: Security fix for CVE-2016-8619 curl: Security fix for CVE-2016-8618 curl: Security fix for CVE-2016-
[yocto] [PATCH][meta-mingw] libmpc: use wildcard version
Signed-off-by: Ross Burton
---
recipes-support/libmpc/{libmpc_1.0.3.bbappend => libmpc_%.bbappend} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename recipes-support/libmpc/{libmpc_1.0.3.bbappend => libmpc_%.bbappend}
(100%)
diff --git a/recipes-support/libmpc/libmpc_1.0.3.bbappend
b/recipes-support/libmpc/libmpc_%.bbappend
similarity index 100%
rename from recipes-support/libmpc/libmpc_1.0.3.bbappend
rename to recipes-support/libmpc/libmpc_%.bbappend
--
2.11.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] crops/poky workflow and git
On 2/27/18 9:47 AM, Andrea Galbusera wrote: Hi! Anyone here regularly doing yocto builds from crops/poky [1] containers? If I got it right, the idea behind using containers derived from crops/poky image for builds is to keep the entire development workflow outside the container and use the container for build related commands only (ideally setting up the env and running bitbake). Then, a very annoying issue I face in trying to enforce this idea as my regular workflow is that interacting with git repositories created while the build runs is becoming almost impossible from outside the container, where regular git work is expected to be more conveniently done. The point is that repos get created when bitbake fetches sources from within the container and git itself hardcodes absolute paths in some of its control files. What I see is while running git from within the repo but outside the contained scope, is git itself complaining with messages like this: error: object directory /workdir/blah/blah/blah does not exist; check .git/objects/info/alternates. fatal: bad object HEAD docker I'm using crops/poky as suggested in [1] hence bind mounting a volume with the entire project rootdir under /workdir within the container. Any suggestion how to make this more friendly, other than moving the entire git workflow inside the same or another container that bind mounts the volume at the same location? I'm curious to know if/how people try to leverage the isolation of containers and how they do mitigate sharp edges I found in migrating builds to them. [1] https://github.com/crops/poky-container Yes, I have been doing it for some time pretty regularly, the idea is to map the directories identically into container to avoid these kind of errors you can look at this here http://bec-systems.com/site/1281/using-docker-for-oeyocto-builds The template we use is here https://github.com/kraj/oe-build look at https://github.com/kraj/oe-build/blob/master/envsetup.sh#L540 how docker is tamed :) -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] hostname.sh: remove warning for bashism
On 2/27/18 2:58 PM, Ulf Samuelsson wrote: The use of the environment variable HOSTNAME, triggers the checkbashisms script, so change HOSTNAME to LOCALHOST Signed-off-by: Ulf Samuelsson --- meta/recipes-core/initscripts/initscripts-1.0/hostname.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-core/initscripts/initscripts-1.0/hostname.sh b/meta/recipes-core/initscripts/initscripts-1.0/hostname.sh index 95287cc..f4ba2b8 100755 --- a/meta/recipes-core/initscripts/initscripts-1.0/hostname.sh +++ b/meta/recipes-core/initscripts/initscripts-1.0/hostname.sh @@ -7,7 +7,7 @@ # Default-Stop: # Short-Description: Set hostname based on /etc/hostname ### END INIT INFO -HOSTNAME=$(/bin/hostname) +LOCALHOST=$(/bin/hostname) hostname -b -F /etc/hostname 2> /dev/null if [ $? -eq 0 ]; then @@ -17,6 +17,6 @@ fi # Busybox hostname doesn't support -b so we need implement it on our own if [ -f /etc/hostname ];then hostname `cat /etc/hostname` -elif [ -z "$HOSTNAME" -o "$HOSTNAME" = "(none)" -o ! -z "`echo $HOSTNAME | sed -n '/^[0-9]*\.[0-9].*/p'`" ] ; then +elif [ -z "$LOCALHOST" -o "$LOCALHOST" = "(none)" -o ! -z "`echo $LOCALHOST | sed -n '/^[0-9]*\.[0-9].*/p'`" ] ; then hostname localhost fi I see buildhistory_commit() is also using HOSTNAME in shell functions in meta/classes/buildhistory.bbclass should that be changed too ? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
