[Recipe reporting system] Upgradable recipe name list
recipe-report@...
This mail was sent out by Recipe reporting system.
This message list those recipes which need to be upgraded. If maintainers believe some of them needn't to upgrade at this time, they can fill RECIPE_NO_UPDATE_REASON in respective recipe file to ignore this remainder until newer upstream version was detected. Example: RECIPE_NO_UPDATE_REASON = "Version 2.0 is unstable" You can check the detail information at: http://recipes.yoctoproject.org/ Package Version Upstream version Maintainer NoUpgradeReason -------------------- ------------ -------------------- ------------------- ------------------------------ python3 3.5.3 3.6.3 Alejandro Hernandez python 2.7.13 2.7.14 Alejandro Hernandez python3-native 3.5.3 3.6.3 Alejandro Hernandez python-native 2.7.13 2.7.14 Alejandro Hernandez gtk-doc 1.25 1.26 Alexander Kanavin webkitgtk 2.16.6 2.18.2 Alexander Kanavin openssl 1.1.0f 1.1.0g Alexander Kanavin bjam-native 1.64.0 1.65.1 Alexander Kanavin gnome-desktop3 3.24.2 3.26.2 Alexander Kanavin libxslt 1.1.29 1.1.32 Alexander Kanavin dnf 2.6.3 2.7.5 Alexander Kanavin expect 5.45 5.45.3 Alexander Kanavin libdnf 0.9.3 0.11.1 Alexander Kanavin librepo 1.7.20+gitX 1.8.1+gitAUTOINC+... Alexander Kanavin blktrace 1.1.0+gitX 1.2.0+gitAUTOINC+... Alexander Kanavin dtc 1.4.4 7.4 Alexander Kanavin btrfs-tools 4.12 4.13.3 Alexander Kanavin oprofile 1.1.0 1.2.0 Alexander Kanavin sysprof 3.24.1 3.26.1 Alexander Kanavin systemtap-uprobes 3.1 3.2 Alexander Kanavin systemtap 3.1 3.2 Alexander Kanavin mpg123 1.25.6 1.25.7 Alexander Kanavin epiphany 3.24.3 3.26.2 Alexander Kanavin mkelfimage 4.0+gitX 4.6+gitAUTOINC+db... Alexander Kanavin mkelfimage has been removed... lighttpd 1.4.45 1.4.47 Alexander Kanavin boost 1.64.0 1.65.1 Alexander Kanavin libnl 3.2.29 3.4.0 Alexander Kanavin ffmpeg 3.3.3 3.4 Alexander Kanavin libpciaccess 0.13.5 0.14 Alexander Kanavin icu 59.1 60.1 Alexander Kanavin psmisc 22.21 23.1 Alexander Kanavin vala 0.36.4 0.38.2 Alexander Kanavin gobject-introspec... 1.52.1 1.54.1 Alexander Kanavin iso-codes 3.75 3.76 Alexander Kanavin apt 1.2.24 1.4.8 Aníbal Limón dpkg 1.18.24 1.19.0.4 Aníbal Limón apt-native 1.2.24 1.4.8 Aníbal Limón tzcode-native 2017b 2017c Armin Kuster bind 9.10.5-P3 9.11.2 Armin Kuster openssh 7.5p1 7.6p1 Armin Kuster libxkbcommon 0.7.1 0.7.2 Armin Kuster libxres 1.0.7 1.2.0 Armin Kuster xkeyboard-config 2.21 2.22 Armin Kuster xserver-xorg 1.19.3 1.19.5 Armin Kuster kexec-tools 2.0.14 2.0.15 Armin Kuster curl 7.54.1 7.56.1 Armin Kuster libxfont2 2.0.1 2.0.2 Armin Kuster nspr 4.16 4.17 Armin Kuster nss 3.31.1 3.33 Armin Kuster libpcre2 10.23 10.30 Armin Kuster gnutls 3.5.13 3.6.1 Armin Kuster tzdata 2017b 2017c Armin Kuster libxfont 1.5.2 1.5.3 Armin Kuster xf86-input-libinput 0.25.1 0.26.0 Armin Kuster linux-libc-headers 4.12 4.13.11 Bruce Ashfield libunwind 1.2 1.2.1 Bruce Ashfield iproute2 4.11.0 4.13.0 Changhyeok Bae ethtool 4.11 4.13 Changhyeok Bae systemd-boot 234 235 Chen Qi dbus-test 1.10.20 1.12.0 Chen Qi dbus 1.10.20 1.12.0 Chen Qi systemd 234 235 Chen Qi util-linux 2.30 2.31 Chen Qi systemd-bootchart 231+gitX 233+gitAUTOINC+fe... Chen Qi flex 2.6.0 2.6.4 Chen Qi cups 2.2.4 2.2.6 Chen Qi gawk 4.1.4 4.2.0 Chen Qi sed 4.2.2 4.4 Chen Qi sudo 1.8.20p2 1.8.21p2 Chen Qi sysstat 11.5.7 11.7.1 Chen Qi coreutils 8.27 8.28 Chen Qi build-appliance-i... 15.0.0 18.0.0 Cristian Iorga avahi-ui 0.6.32 0.7 Dengke Du avahi 0.6.32 0.7 Dengke Du expat 2.2.3 2.2.5 Dengke Du chkconfig 1.3.58 1.8 Dengke Du Version 1.5 requires selinux json-glib 1.2.8 1.4.2 Dengke Du wayland 1.13.0 1.14.0 Denys Dmytriyenko weston 2.0.0 3.0.0 Denys Dmytriyenko lz4 1.7.4 131 Denys Dmytriyenko lzop 1.03 1.04 Denys Dmytriyenko mtd-utils 2.0.0 2.0.1 Denys Dmytriyenko wayland-protocols 1.10 1.11 Denys Dmytriyenko acpica 20170303 20170929 Fathi Boudra gnupg 2.2.0 2.2.1 Hongxu Jia help2man-native 1.47.4 1.47.5 Hongxu Jia libxml2 2.9.5 2.9.7 Hongxu Jia ncurses 6.0+20170715 6.0+20170902 Hongxu Jia apr-util 1.6.0 1.6.1 Hongxu Jia apr 1.6.2 1.6.3 Hongxu Jia bash 4.4 4.4.12 Hongxu Jia ghostscript 9.21 9.22 Hongxu Jia man-pages 4.11 4.13 Hongxu Jia python-numpy 1.13.1 1.13.3 Jose Lamego python3-pygobject 3.26.0 3.26.1 Jose Lamego bc 1.06 1.07.1 Jose Lamego python3-setuptools 36.5.0 36.6.0 Jose Lamego python-setuptools 36.5.0 36.6.0 Jose Lamego pango 1.40.6 1.40.13 Jussi Kukkonen libinput 1.8.1 1.9.1 Jussi Kukkonen gtk-icon-utils-na... 3.22.17 3.22.25 Jussi Kukkonen gsettings-desktop... 3.22.0 3.24.1 Jussi Kukkonen glib-2.0 2.52.3 2.54.2 Jussi Kukkonen glib-networking 2.50.0 2.54.1 Jussi Kukkonen libsoup-2.4 2.58.2 2.60.2 Jussi Kukkonen at-spi2-atk 2.24.1 2.26.1 Jussi Kukkonen at-spi2-core 2.24.1 2.26.2 Jussi Kukkonen librsvg 2.40.18 2.40.19 Jussi Kukkonen assimp 4.0.0 4.0.1 Jussi Kukkonen atk 2.24.0 2.26.1 Jussi Kukkonen libgudev 231 232 Jussi Kukkonen shared-mime-info 1.8 1.9 Jussi Kukkonen vte 0.48.3 0.50.2 Jussi Kukkonen vulkan 1.0.51.0 1.0.61.1 Jussi Kukkonen adwaita-icon-theme 3.24.0 3.26.0 Jussi Kukkonen xdg-utils 1.1.1 1.1.2 Jussi Kukkonen gdk-pixbuf 2.36.8 2.36.11 Jussi Kukkonen gtk+3 3.22.17 3.22.25 Jussi Kukkonen hicolor-icon-theme 0.15 0.17 Jussi Kukkonen clutter-gtk-1.0 1.8.2 1.8.4 Jussi Kukkonen fontconfig 2.12.4 2.12.6 Jussi Kukkonen freetype 2.8 387.5 Jussi Kukkonen glew 2.0.0 2.1.0 Jussi Kukkonen musl 1.1.16+gitX 1.1.18+gitAUTOINC... Khem Raj ninja 1.7.2 1.8.2 Khem Raj glibc 2.26 2.26.9000 Khem Raj binutils 2.29 2.29.1 Khem Raj re2c 0.16 1.0.1 Khem Raj libnsl2 1.0.5+gitX 1.1.0+gitAUTOINC+... Khem Raj gdb 8.0 8.0.1 Khem Raj mpfr 3.1.5 3.1.6 Khem Raj go-native 1.9 1.9.2 Khem Raj go 1.9 1.9.2 Khem Raj cross-localedef-n... 2.26 2.26.9000 Khem Raj glibc-initial 2.26 2.26.9000 Khem Raj nfs-utils 2.1.1 2.2.1 Leonardo Sandoval perl 5.24.1 5.26.1 Leonardo Sandoval qemu 2.10.0 2.10.1 Leonardo Sandoval perl-native 5.24.1 5.26.1 Leonardo Sandoval rpm 4.13.90+gitX 4.14.0+gitAUTOINC... Mark Hatle libpfm4 4.6.0 4.8.0 Matthew McClintock ofono 1.20 1.21 Maxin B. John ifupdown 0.8.16 0.8.29 Maxin B. John libproxy 0.4.14 0.4.15 Maxin B. John sqlite3 3.20.0 3.21.0 Maxin B. John libsolv 0.6.28 0.6.30 Maxin B. John quota 4.03 4.04 Maxin B. John screen 4.6.1 4.6.2 Maxin B. John harfbuzz 1.4.8 1.6.3 Maxin B. John libical 2.0.0 3.0.0 Maxin B. John systemtap-native 3.1 3.2 No maintainer gdb-cross-canadia... 8.0 8.0.1 No maintainer gdb-cross-i586 8.0 8.0.1 No maintainer go-cross-i586 1.9 1.9.2 No maintainer binutils-cross-ca... 2.29 2.29.1 No maintainer binutils-cross-i586 2.29 2.29.1 No maintainer binutils-crosssdk... 2.29 2.29.1 No maintainer gcc-source-6.4.0 6.4.0 7.2.0 No maintainer go-cross-canadian... 1.9 1.9.2 No maintainer go-crosssdk-x86_64 1.9 1.9.2 No maintainer go-dep 0.3.1 0.3.2 No maintainer go-runtime 1.9 1.9.2 No maintainer pkgconf 1.3.7 1.3.10 No maintainer mesa 17.1.7 17.2.4 Otavio Salvador cmake 3.9.3 3.9.5 Otavio Salvador cmake-native 3.9.3 3.9.5 Otavio Salvador libdrm 2.4.83 2.4.88 Otavio Salvador mesa-gl 17.1.7 17.2.4 Otavio Salvador tcf-agent 1.4.0+gitX 1.5+gitAUTOINC+5e... Randy Witt lttng-modules 2.9.3 2.10.3 Richard Purdie lttng-tools 2.9.5 2.10.1 Richard Purdie lttng-ust 2.9.1 2.10.0 Richard Purdie subversion 1.9.6 1.9.7 Richard Purdie file 5.31 5.32 Robert Yang e2fsprogs 1.43.5 1.43.7 Robert Yang git 2.13.3 2.15.0 Robert Yang liberror-perl 0.17024 0.17025 Robert Yang strace 4.18 4.19 Robert Yang debianutils 4.8.1.1 4.8.2 Robert Yang autoconf-archive 2016.09.16 2017.09.28 Robert Yang less 487 527 Robert Yang logrotate 3.12.3 3.13.0 Robert Yang wget 1.19.1 1.19.2 Robert Yang libsdl2 2.0.5 2.0.7 Robert Yang base-passwd 3.5.29 3.5.44 Ross Burton Version 3.5.38 requires cde... lsbinitscripts 9.72 9.77 Ross Burton lame 3.99.5 3.100 Tanu Kaskinen pulseaudio 10.0 11.1 Tanu Kaskinen libva-utils 1.8.3 2.0.0 Wei Tee Ng libva 1.8.3 2.0.0 Wei Tee Ng Upgradable count: 187 Upgradable total count: 190 The based commit is: commit 73c6f85457361cd82d44838946aa81ba9bd1662a Author: Paul Eggleton <paul.eggleton@...> Date: Fri Nov 3 16:16:10 2017 +1300 lib/oe/sstatesig: fix wildcard matching wrong task signature files With a '*' as a wildcard for the signature here we can also match a portion of the task name with the result that we may match a sigdata file for the wrong task. Luckily the signature is always the same length - 32 characters - so we can simply use 32 '?' characters instead. (A regex would have been another alternative, but the wildcard should be effective and I felt like a regex would complicate the code more than this solution). Fixes [YOCTO #11763]. Signed-off-by: Paul Eggleton <paul.eggleton@...> Signed-off-by: Ross Burton <ross.burton@...> Any problem, please contact Jose Lamego <jose.a.lamego@...>
|
|
[yocto-docs][PATCH] ref-manual: Removed misleading paragraph in siteinfo section
Yevgeny Popovych <yevgenyp@...>
..on the inclusion of siteinfo.bbclass in base.bbclass.
This is not true since 2010. Signed-off-by: Yevgeny Popovych <yevgenyp@...> --- documentation/ref-manual/ref-classes.xml | 6 ------ 1 file changed, 6 deletions(-) diff --git a/documentation/ref-manual/ref-classes.xml b/documentation/ref-manual/ref-classes.xml index 5961d3e..fe41f9e 100644 --- a/documentation/ref-manual/ref-classes.xml +++ b/documentation/ref-manual/ref-classes.xml @@ -3134,12 +3134,6 @@ This check was removed for YP 2.3 release and <filename><link linkend='var-SITEINFO_BITS'>SITEINFO_BITS</link></filename> that can be used elsewhere in the metadata. </para> - - <para> - Because the - <link linkend='ref-classes-base'><filename>base</filename></link> class - includes the <filename>siteinfo</filename> class, it is always active. - </para> </section> <section id='ref-classes-spdx'> -- 2.7.4
|
|
[RFC] stable branch naming scheme
Hello,
The problem I hope to solve is that a Maintainer can stage changes in any branch in the contrib repos making it difficult for folks to track their back port requests. The also makes it harder to automate any kind of build automation. I would like to propose a contrib naming scheme for the stable release branches. I am thinking of the following: stable/{version}-next or {special char}_stable/{version}-next. "version" is either the code name or numeric like in bitbake. "special char" would be used to have these branches at the top of th list, if we wont that. We can apply this to all OE / Yocto repos that have stable branch maintenance process. If we standardize on a naming scheme, We can then document this so contributers can monitor their requests more easily. The community can see what changes are being backport. This will enable the possibility to automate builds, etc. let me know what you think. Kind regards, Armin
|
|
Re: [meta-mono][PATCH] mono-4.xx: compiling mono 4 with btls requires cmake
Alex Lennon <ajlennon@...>
On 02/11/2017 15:59, Khem Raj wrote:
On Thu, Nov 2, 2017 at 8:46 AM, Pascal Bach <pascal.bach@...> wrote:It is disabled in 5.x builds by default as it breaks the build e.g.On 27.10.2017 23:41, Khem Raj wrote:yeah that probably is a case of bundling which is on rise at app levelOn Fri, Oct 27, 2017 at 3:51 AM, Pascal Bach <pascal.bach@...> wrote:Using the cmake bbclass doesn't work as it is not really a CMake project.This was probably working before pyro and the recipes specific sysroots.perhaps this should inehrit cmake if its using cmake http://git.yoctoproject.org/cgit/cgit.cgi/meta-mono/tree/recipes-mono/mono/mono-5.4.0.201.inc It's probably time to look at a working build with it re-enabled. Patches welcomed... (I did have a quick look at inheriting cmake but that breaks the build too) Cheers, Alex
|
|
How to enable modules in kernel
Greg Wilson-Lindberg
Hi all, I'm trying to build for a raspberry pi3. I need to enable two drivers for sound devices: SND_SOC_MAX9768 & MAX1363. I've created my own image recipe and that is building. Now I need to add a couple of modules to the kernel configuration and I'm not sure what I need to do. Do I create a .scc file and .cfg file in the directory that I've got my image recipe, or is there a better way, or different place to put them? And then I'm assuming that I add the .scc file to KERNEL_FEATURES in my image recipe.
Regards,
Greg Wilson-Lindberg Sakura Finetek 310-783-5075
|
|
Re: do_kernel_checkout() not using the correct directory
Bruce Ashfield <bruce.ashfield@...>
On 2017-11-02 4:16 PM, Bishop, Mark (STRT) wrote:
I changed the code in arm/layers/core/meta/classes/kernel-yocto.bbclassYah, not a great idea to modify the base class. It may be working, but if you actually add a patch to the SRC_URI, it will fail, since the rest of the code also needs a git repository (to apply patches, merge branches, etc, etc). You may or may not have done that, but where you put that sample code *should* let the tgz processing do the right thing and create a simple git repo. I wrote that code (a long time ago now!) to work with git trees or tgz's. Anything that isn't dropping the source into a location that is different than that, won't work (as you found out and worked around). You could add your own task that runs before do_kernel_checkout to put the svn checkout into ${S}, and then do_checkout_checkout will do its work as normal. You can add that task in your kernel recipe, or in a bbappend to a kernel recipe. i.e. addtask kernel_svn_precondition before do_kernel_checkout after do_unpack do_kernel_svn_precondition() { if [ -d "${WORKDIR}/trunk/" ]; then source_workdir="${WORKDIR}/trunk" if [ "${source_dir}" != "${source_workdir}" ]; then rm -rf ${S} mv ${WORKDIR}/trunk ${S} fi fi } Maybe someone else will have a better idea, but that is mine :D Cheers, Bruce From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Bishop, Mark (STRT)
|
|
Re: [ptest-runner] utils.c: Prefer monotonic clock to calculate elapsed time
Joshua Lock <joshua.g.lock@...>
On 31/10/17 19:38, Jeffrey Pautler wrote:
The current implementation uses the system clock to calculate how longThis patch looks good to me, merged & pushed to ptest-runner2 repo. Thanks, Joshua Signed-off-by: Jeffrey Pautler <jeffrey.pautler@...>
|
|
Re: do_kernel_checkout() not using the correct directory
Bishop, Mark (STRT) <MBishop@...>
I changed the code in arm/layers/core/meta/classes/kernel-yocto.bbclass
From: . else # case: we have no git repository at all. # To support low bandwidth options for building the kernel, we'll just # convert the tree to a git repo and let the rest of the process work unchanged # if ${S} hasn't been set to the proper subdirectory a default of "linux" is # used, but we can't initialize that empty directory. So check it and throw a # clear error cd ${S} if [ ! -f "Makefile" ]; then .. To: else # case: we have no git repository at all. # To support low bandwidth options for building the kernel, we'll just # convert the tree to a git repo and let the rest of the process work unchanged # if ${S} hasn't been set to the proper subdirectory a default of "linux" is # used, but we can't initialize that empty directory. So check it and throw a # clear error if [ -d "${WORKDIR}/trunk/" ]; then source_workdir="${WORKDIR}/trunk" if [ "${source_dir}" != "${source_workdir}" ]; then rm -rf ${S} mv ${WORKDIR}/trunk ${S} fi fi cd ${S} if [ ! -f "Makefile" ]; then And everything is working but it seems that this would be the wrong way to do this as this is me editing a base class file. From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Bishop, Mark (STRT) Sent: Thursday, November 02, 2017 1:48 PM To: yocto@... Subject: [yocto] do_kernel_checkout() not using the correct directory I am trying to compile a kernel located in SVN. I get this error message: ERROR: linux-xlnx-4.9-xilinx-v2017.2+git20-r0 do_kernel_checkout: S /tmp/stride/work-shared/plnx_arm/kernel-source is not set to the linux source directory. Check ERROR: linux-xlnx-4.9-xilinx-v2017.2+git20-r0 do_kernel_checkout: the recipe and set S to the proper extracted subdirectory ERROR: linux-xlnx-4.9-xilinx-v2017.2+git20-r0 do_kernel_checkout: Function failed: do_kernel_checkout (log file is located at /tmp/stride/work/plnx_arm-xilinx-linux-gnueabi/linux-xlnx/4.9-xilinx-v2017.2+git20-r0/temp/log.do_kernel_checkout.34928) ERROR: Logfile of failure stored in: /tmp/stride/work/plnx_arm-xilinx-linux-gnueabi/linux-xlnx/4.9-xilinx-v2017.2+git20-r0/temp/log.do_kernel_checkout.34928 ERROR: Task (/opt/pkg/petalinux/2017.2/components/yocto/source/arm/layers/meta-xilinx/recipes-kernel/linux/linux-xlnx_4.9.bb:do_kernel_checkout) failed with exit code '1' And my kernel gets downloaded to: /tmp/stride/work/plnx_arm-xilinx-linux-gnueabi/linux-xlnx/4.9-xilinx-v2017.2+git20-r0/trunk But Yocto is looking for it in /tmp/stride/work-shared/plnx_arm/kernel-source Which is why it is failing in kernel-yocto.bbclass when I try and compile a kernel located in SVN. If it is a git repo it gets copied into /tmp/stride/work-shared/plnx_arm/kernel-source and things work nicely. do_kernel_checkout() { ... if [ -d "${WORKDIR}/git/" ]; then # case: git repository # if S is WORKDIR/git, then we shouldn't be moving or deleting the tree. if [ "${source_dir}" != "${source_workdir}" ]; then if [ -d "${source_workdir}/.git" ]; then # regular git repository with .git rm -rf ${S} mv ${WORKDIR}/git ${S} else # create source for bare cloned git repository git clone ${WORKDIR}/git ${S} rm -rf ${WORKDIR}/git fi fi cd ${S} else # case: we have no git repository at all. # To support low bandwidth options for building the kernel, we'll just # convert the tree to a git repo and let the rest of the process work unchanged # if ${S} hasn't been set to the proper subdirectory a default of "linux" is # used, but we can't initialize that empty directory. So check it and throw a # clear error cd ${S} if [ ! -f "Makefile" ]; then bberror "S ${S} is not set to the linux source directory. Check " bbfatal "the recipe and set S to the proper extracted subdirectory" fi .. ${S} is set to /tmp/stride/work-shared/plnx_arm/kernel-source when I need one of the two things to happen: A) ${S} set to ${WORKDIR}/trunk OR B) ${WORKDIR}/trunk copied to ${S}/ I could modify that file directly on my machine and move on, but is there a way I can create an .bbappend or something that will change ${S} I'm pretty new to Yocto and I'd like to have a solution that resides in my project folder instead of having to modify Yocto files so that when I do tool installs on new development machines I can just checkout my project data and have it work. I'm using Petalinux, so the process would be install that, then checkout the project and then build it, with the correct ${S} directory flowing into kernel-yocto.bbclass:do_kernel_checkout() I'm new Yocto but I've been reading a ton and am looking for some advice. This e-mail contains proprietary information some or all of which may be legally privileged. It is intended for the recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the authority by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. In addition, information contained in or attached to this e-mail may be subject to either 22 C.F.R. Parts 120?130, or 15 C.F.R. Parts 730-774. These regulations prohibit the release or disclosure of certain information contained herein to anyone who is not a U.S. citizen or permanent resident alien, without a license first having been issued. Failure to observe such requirements is a violation of U.S. law that carries serious penalties.
|
|
do_kernel_checkout() not using the correct directory
Bishop, Mark (STRT) <MBishop@...>
I am trying to compile a kernel located in SVN.
I get this error message: ERROR: linux-xlnx-4.9-xilinx-v2017.2+git20-r0 do_kernel_checkout: S /tmp/stride/work-shared/plnx_arm/kernel-source is not set to the linux source directory. Check ERROR: linux-xlnx-4.9-xilinx-v2017.2+git20-r0 do_kernel_checkout: the recipe and set S to the proper extracted subdirectory ERROR: linux-xlnx-4.9-xilinx-v2017.2+git20-r0 do_kernel_checkout: Function failed: do_kernel_checkout (log file is located at /tmp/stride/work/plnx_arm-xilinx-linux-gnueabi/linux-xlnx/4.9-xilinx-v2017.2+git20-r0/temp/log.do_kernel_checkout.34928) ERROR: Logfile of failure stored in: /tmp/stride/work/plnx_arm-xilinx-linux-gnueabi/linux-xlnx/4.9-xilinx-v2017.2+git20-r0/temp/log.do_kernel_checkout.34928 ERROR: Task (/opt/pkg/petalinux/2017.2/components/yocto/source/arm/layers/meta-xilinx/recipes-kernel/linux/linux-xlnx_4.9.bb:do_kernel_checkout) failed with exit code '1'
And my kernel gets downloaded to: /tmp/stride/work/plnx_arm-xilinx-linux-gnueabi/linux-xlnx/4.9-xilinx-v2017.2+git20-r0/trunk But Yocto is looking for it in /tmp/stride/work-shared/plnx_arm/kernel-source Which is why it is failing in kernel-yocto.bbclass when I try and compile a kernel located in SVN.
If it is a git repo it gets copied into /tmp/stride/work-shared/plnx_arm/kernel-source and things work nicely.
do_kernel_checkout() { ……. if [ -d "${WORKDIR}/git/" ]; then # case: git repository # if S is WORKDIR/git, then we shouldn't be moving or deleting the tree. if [ "${source_dir}" != "${source_workdir}" ]; then if [ -d "${source_workdir}/.git" ]; then # regular git repository with .git rm -rf ${S} mv ${WORKDIR}/git ${S} else # create source for bare cloned git repository git clone ${WORKDIR}/git ${S} rm -rf ${WORKDIR}/git fi fi cd ${S} else # case: we have no git repository at all. # To support low bandwidth options for building the kernel, we'll just # convert the tree to a git repo and let the rest of the process work unchanged
# if ${S} hasn't been set to the proper subdirectory a default of "linux" is # used, but we can't initialize that empty directory. So check it and throw a # clear error
cd ${S} if [ ! -f "Makefile" ]; then bberror "S ${S} is not set to the linux source directory. Check " bbfatal "the recipe and set S to the proper extracted subdirectory" fi ……
${S} is set to /tmp/stride/work-shared/plnx_arm/kernel-source when I need one of the two things to happen: A) ${S} set to ${WORKDIR}/trunk OR B) ${WORKDIR}/trunk copied to ${S}/
I could modify that file directly on my machine and move on, but is there a way I can create an .bbappend or something that will change ${S}
I’m pretty new to Yocto and I’d like to have a solution that resides in my project folder instead of having to modify Yocto files so that when I do tool installs on new development machines I can just checkout my project data and have it work. I’m using Petalinux, so the process would be install that, then checkout the project and then build it, with the correct ${S} directory flowing into kernel-yocto.bbclass:do_kernel_checkout()
I’m new Yocto but I’ve been reading a ton and am looking for some advice.
This e-mail contains proprietary information some or all of which may be legally privileged. It is intended for the recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the authority by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. In addition, information contained in or attached to this e-mail may be subject to either 22 C.F.R. Parts 120?130, or 15 C.F.R. Parts 730-774. These regulations prohibit the release or disclosure of certain information contained herein to anyone who is not a U.S. citizen or permanent resident alien, without a license first having been issued. Failure to observe such requirements is a violation of U.S. law that carries serious penalties.
|
|
Re: Slightly varying builds
Colin Helliwell <colin.helliwell@...>
On 02 November 2017 at 16:59 Alexander Kanavin <alexander.kanavin@...> wrote:Thanks Alex, that has indeed resolved the problem of DEP_IMG not changing. Still getting the "trying to install files into a shared area when those files already exist" error on the second [-dvl] bitbake. And a cleanall throws "ERROR: Multiple .bb files are due to be built which each provide u-boot: /home/colin/trunk/fsl-community-bsp/../meta-ln-karo/recipes-bsp/u-boot/u-boot-w2-dvl.bb /home/colin/trunk/fsl-community-bsp/../meta-ln-karo/recipes-bsp/u-boot/u-boot-w2.bb A list of tasks depending on these providers is shown and may help explain where the dependency comes from. /home/colin/trunk/fsl-community-bsp/../meta-ln-karo/recipes-bsp/u-boot/u-boot-w2.bb has unique dependees: /home/colin/trunk/fsl-community-bsp/../meta-ln-karo/recipes-bsp/u-boot/u-boot-w2-dvl.bb has unique dependees: It could be that one recipe provides something the other doesn't and should. The following provider and runtime provider differences may be helpful. /home/colin/trunk/fsl-community-bsp/../meta-ln-karo/recipes-bsp/u-boot/u-boot-w2-dvl.bb has unique provides: u-boot-w2-dvl /home/colin/trunk/fsl-community-bsp/../meta-ln-karo/recipes-bsp/u-boot/u-boot-w2-dvl.bb has unique rprovides: u-boot-w2-dvl-dev u-boot-w2-dvl-doc u-boot-w2-dvl u-boot-w2-dvl-staticdev u-boot-w2-dvl-dbg u-boot-w2-dvl-locale ^u-boot-w2-dvl-locale-.* /home/colin/trunk/fsl-community-bsp/../meta-ln-karo/recipes-bsp/u-boot/u-boot-w2.bb has unique provides: u-boot-w2 /home/colin/trunk/fsl-community-bsp/../meta-ln-karo/recipes-bsp/u-boot/u-boot-w2.bb has unique rprovides: u-boot-w2-doc ^u-boot-w2-locale-.* u-boot-w2-dev u-boot-w2-staticdev u-boot-w2 u-boot-w2-dbg u-boot-w2-locale" That doesn't seem to imply too much conflict, so might be something simple... It's nearly dinnertime - :) - so I could, to make absolutely sure, try a thorough cleanout by deleting tmp/ and see what happens.
|
|
Re: Slightly varying builds
Alexander Kanavin <alexander.kanavin@...>
On 11/02/2017 06:50 PM, Colin Helliwell wrote:
Not sure if this will help, but start by not using the -dev suffix. It will clash with -dev packages produced by (any) recipe. Alex
|
|
Re: Slightly varying builds
Colin Helliwell <colin.helliwell@...>
On 02 November 2017 at 16:29 Alexander Kanavin <alexander.kanavin@...> wrote:Very little! One is: DESCRIPTION = "Das U-Boot for W2 [for development]" DEP_IMG = "u-boot-dev" PROVIDES = "u-boot-w2-dev" require u-boot-w2_1.inc The other is: DESCRIPTION = "Das U-Boot for W2" DEP_IMG = "u-boot-prodn" PROVIDES = "u-boot-w2" require u-boot-w2_1.inc u-boot-w2_1.inc has the standard kind of recipe stuff. For creating env files, and files to be used for later signing, it has some _append steps, so I'm aiming to use 'DEP_IMG' to create the various files with different prefixes for the two variants. Strangely though, an 'echo ${DEP_IMG}' is outputting the same value ("u-boot-prodn") from both recipes, even after a cleanall on both. Possibly some state info being pulled in somewhere? It seems that you do need to have two different build directories thatI *do* realise I'm trying to do something a bit unusual! All I want between the two variants is to disable some functionality - the 'machine' is identical. I was going to patch one build to take the functionality out (for 'production'), but create my own specific environment for the system anyway. So I wonder if a cleaner/easier (aka working...!) approach would be to instead patch my own custom envar into the source, and then I could instead create two different env files for the two variants?
|
|
Customize SDKPATH
Jonathan Poulin <jopoulin@...>
Hello, thanksAs we build different images for the same machine, I would like to customize the SDKPATH to include the image name. This way our application developers can install the different sdk related to each image. To do that I firstly create my custom distro conf where I set the SDKPATH this way: SDKPATH = "/opt/${DISTRO}/${SDK_VERSION}/${IMAGE_BASENAME}" But it doesn't work because the populate_sdk task depend on many other packages that also use the SDKPATH variable. IMAGE_BASENAME is define as ${PN} so all other package install sdk files in a different folder. (the value of PN is different for each package). Is there a way to set IMAGE_BASENAME to the image name used in the command "bitbake -c populate_sdk <image_name>" in a way that all package recipe see it?
|
|
Re: Slightly varying builds
Alexander Kanavin <alexander.kanavin@...>
On 11/02/2017 06:26 PM, Colin Helliwell wrote:
Following on from this, I'm trying to be able to build my two versions of u-boot, in the *same* build directory.Can you share exactly how the two recipes differ? It seems that you do need to have two different build directories that differ in what MACHINE is set to. And that would configure u-boot accordingly. Alex
|
|
Re: Slightly varying builds
Colin Helliwell <colin.helliwell@...>
On 02 November 2017 at 07:10 Colin Helliwell <colin.helliwell@...> wrote:Following on from this, I'm trying to be able to build my two versions of u-boot, in the *same* build directory.On 01 November 2017 at 17:04 Alexander Kanavin <alexander.kanavin@...> wrote:Rootfs changes I can certainly do with different image recipes. I'm not sure if this is possible, but I figured it might be: since u-boot doesn't get put into the rootfs (?), I would ideally be able to build both and just pull down from tmp/deploy/images/.... the image that I want to program into a particular unit. I've pushed common stuff into .inc file(s), and have two recipes which set different 'PROVIDES' values. However, even after a cleanall on both recipes, bitbaking the second one throws an error "The recipe u-boot-mymachine-dev is trying to install files into a shared area when those files already exist". Is it possible to do what I'm trying to do....? Ta
|
|
Re: [meta-mono][PATCH] mono-4.xx: compiling mono 4 with btls requires cmake
On Thu, Nov 2, 2017 at 8:46 AM, Pascal Bach <pascal.bach@...> wrote:
yeah that probably is a case of bundling which is on rise at app level these days, One option would be to disable it with `--disable-btls` but I fear that would disable TLS1.2 support (http://www.mono-project.com/docs/about-mono/releases/4.8.0/#tls-12-support).interesting, do they support any other TLS implementations ? PascalSRC_URI = "http://download.mono-project.com/sources/mono/mono-${PV}.tar.bz2 \
|
|
Re: [meta-raspberrypi][PATCH 1/5] x264: Disable asm for raspberrypi0-wifi
Andrei Gherzan <andrei@...>
Hi all, On Thu, Nov 2, 2017 at 3:51 PM, Andrei Gherzan <andrei@...> wrote: This used to work in the past because this machine was based on raspberrypi Pushed a PR to github too: https://github.com/agherzan/meta-raspberrypi/pull/149 in which I fixed the two typos in this series: "firmware.in" and "zzImage". Andrei
|
|
[meta-raspberrypi][PATCH 5/5] firmware.in: Update to 20170811
Andrei Gherzan <andrei@...>
Signed-off-by: Andrei Gherzan <andrei@...>
--- recipes-bsp/common/firmware.inc | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/recipes-bsp/common/firmware.inc b/recipes-bsp/common/firmware.inc index ac2bd82..67078c1 100644 --- a/recipes-bsp/common/firmware.inc +++ b/recipes-bsp/common/firmware.inc @@ -1,10 +1,9 @@ -RPIFW_DATE ?= "20170811" +RPIFW_DATE ?= "20171029" RPIFW_SRC_URI ?= "https://github.com/raspberrypi/firmware/archive/1.${RPIFW_DATE}.tar.gz" RPIFW_S ?= "${WORKDIR}/firmware-1.${RPIFW_DATE}" SRC_URI = "${RPIFW_SRC_URI}" -SRC_URI[md5sum] = "afd09f9a6df14e32b6d832fd9f51d087" -SRC_URI[sha256sum] = "a25f6281d64732892a2e838cc2346f1a88505b5c77a57a6540755362ea64043a" - +SRC_URI[md5sum] = "4d27c1888a7bab3097471906e7b4a319" +SRC_URI[sha256sum] = "46ce28c8d87ef22bdcc57ac1836ca3f04d1ec6f46580ff5a30bf76b3c0822117" PV = "${RPIFW_DATE}" -- 2.7.4
|
|
[meta-raspberrypi][PATCH 4/5] rpi-base.inc: KERNEL_IMAGETYPE default to zzImage
Andrei Gherzan <andrei@...>
We used to have this as the default but there was a bug at some point in the
firmware which didn't work with compressed kernel images. We switched to Image and never changed it back even though that bug is long history. In this way we will stop carrying 15M of a kernel image. 4M looks much better. Signed-off-by: Andrei Gherzan <andrei@...> --- conf/machine/include/rpi-base.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conf/machine/include/rpi-base.inc b/conf/machine/include/rpi-base.inc index 688227c..71c63cb 100644 --- a/conf/machine/include/rpi-base.inc +++ b/conf/machine/include/rpi-base.inc @@ -51,7 +51,7 @@ KERNEL_DEVICETREE ?= " \ # within u-boot to load the kernel. KERNEL_BOOTCMD ??= "bootm" KERNEL_IMAGETYPE_UBOOT ??= "uImage" -KERNEL_IMAGETYPE ?= "${@bb.utils.contains('RPI_USE_U_BOOT', '1', '${KERNEL_IMAGETYPE_UBOOT}', 'Image', d)}" +KERNEL_IMAGETYPE ?= "${@bb.utils.contains('RPI_USE_U_BOOT', '1', '${KERNEL_IMAGETYPE_UBOOT}', 'zImage', d)}" MACHINE_FEATURES += "apm usbhost keyboard vfat ext2 screen touchscreen alsa bluetooth wifi sdio" -- 2.7.4
|
|
[meta-raspberrypi][PATCH 3/5] pi-blaster: An .inc file looks too much for this small recipe
Andrei Gherzan <andrei@...>
Signed-off-by: Andrei Gherzan <andrei@...>
--- recipes-devtools/pi-blaster/pi-blaster.inc | 21 --------------------- recipes-devtools/pi-blaster/pi-blaster_git.bb | 22 +++++++++++++++++++++- 2 files changed, 21 insertions(+), 22 deletions(-) delete mode 100644 recipes-devtools/pi-blaster/pi-blaster.inc diff --git a/recipes-devtools/pi-blaster/pi-blaster.inc b/recipes-devtools/pi-blaster/pi-blaster.inc deleted file mode 100644 index 3cb79cc..0000000 --- a/recipes-devtools/pi-blaster/pi-blaster.inc +++ /dev/null @@ -1,21 +0,0 @@ -DESCRIPTION = "This project enables PWM on the GPIO pins you request of a Raspberry Pi." -HOMEPAGE = "https://github.com/sarfata/pi-blaster/" -SECTION = "devel/libs" -LICENSE = "MIT" -LIC_FILES_CHKSUM = "file://README.md;beginline=225;endline=252;md5=a012868ef5f83b9f257af253d7cb07a3" - -SRC_URI = "git://github.com/sarfata/pi-blaster \ - file://remove-initscript-lsb-dependency.patch \ -" - -S = "${WORKDIR}/git" - -inherit update-rc.d autotools - -INITSCRIPT_PACKAGES = "${PN}" -INITSCRIPT_NAME_${PN} = "${PN}.boot.sh" -INITSCRIPT_PARAMS_${PN} = "defaults 15 85" - -COMPATIBLE_MACHINE = "^rpi$" - -PACKAGE_ARCH = "${MACHINE_ARCH}" diff --git a/recipes-devtools/pi-blaster/pi-blaster_git.bb b/recipes-devtools/pi-blaster/pi-blaster_git.bb index 730f9d3..2748459 100644 --- a/recipes-devtools/pi-blaster/pi-blaster_git.bb +++ b/recipes-devtools/pi-blaster/pi-blaster_git.bb @@ -1,3 +1,23 @@ -require pi-blaster.inc +DESCRIPTION = "This project enables PWM on the GPIO pins you request of a Raspberry Pi." +HOMEPAGE = "https://github.com/sarfata/pi-blaster/" +SECTION = "devel/libs" +LICENSE = "MIT" +LIC_FILES_CHKSUM = "file://README.md;beginline=225;endline=252;md5=a012868ef5f83b9f257af253d7cb07a3" + +SRC_URI = "git://github.com/sarfata/pi-blaster \ + file://remove-initscript-lsb-dependency.patch \ +" + +S = "${WORKDIR}/git" SRCREV = "1035ad7dffb270c40eec1bb3a654171a755fba98" + +inherit update-rc.d autotools + +INITSCRIPT_PACKAGES = "${PN}" +INITSCRIPT_NAME_${PN} = "${PN}.boot.sh" +INITSCRIPT_PARAMS_${PN} = "defaults 15 85" + +COMPATIBLE_MACHINE = "^rpi$" + +PACKAGE_ARCH = "${MACHINE_ARCH}" -- 2.7.4
|
|