Re: [yocto] Multiple conncetion to svn (svn+ssh)
Hi Brian, Paul,
Thanks for response.
W dniu 06.07.2015 o 17:11, Paul Eggleton pisze:
On Monday 06 July 2015 15:04:57 Bryan Evenson wrote:
Paul,
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: Monday, July 06, 2015 10:08 AM
To: Marcin Krzemiński
Cc: Bryan Evenson; yocto@yoctoproject.org
Subject: Re: [yocto] Multiple conncetion to svn (svn+ssh)
On Monday 06 July 2015 12:57:39 Bryan Evenson wrote:
Marcin,
From: yocto-boun...@yoctoproject.org
[mailto:yocto-boun...@yoctoproject.org] On Behalf Of Marcin
Krzeminski
Sent: Friday, July 03, 2015 7:55 AM
To: yocto@yoctoproject.org
Subject: [yocto] Multiple conncetion to svn (svn+ssh)
Hello again,
I have 12 recipes that download code from same svn repository (using
svn+ssh)protocol. Recipes are grouped in packagegroup.
When I want to bitbake packagegroup fetcher fail, but when I run
recipe alone all is ok. I think it is because I want to open 8
connection to one svn repository.How can I fix this, for example by
allowing only eg. 2 recipes from packagegroup to be executed in
paralell.
There is no fetcher-specific variable that I know of, but I think you
can set PARALLEL_MAKE=2 in your recipes to reduce the number of
fetches on your repository at a time. The downside is your build will
go slower when it is building your recipes as it won't be doing as
many things in parallel.
That's not going to help. The parallelism we are talking about here is
across recipes - PARALLEL_MAKE is just passed through to make within one
task in one recipe, and make isn't even involved at the fetch stage.
Sorry, I grabbed the wrong variable. I meant BB_NUMBER_THREADS, not
PARALLEL_MAKE.
Sure, but that's not going to work either from within a recipe. It would work
at the configuration level but that'll quite severely impact build performance.
This was my first idea.
Something that might work would be to set a lockfile on the do_fetch task
such that only one of the recipes could fetch at once. That could not
allow
two executing at once, but at least it would solve the problem. e.g. you
could add this to all of the recipes:
do_fetch[lockfiles] += ${TMPDIR}/mysvnlock.lock
(The file name isn't critical, it just needs to be the same for all of the
recipes you wish to participate in the exclusive fetching.)
This works as you wrote, it is not a perfect solution for my problem,
but at least builds doesn't fail. Thanks!
I had no idea that we could do this. I don't see any documentation on
lockfiles anywhere. If you use a lockfile, do the all recipes with the same
lockfile wait until the lockfile is available before continuing on with
that step? Is there a timeout for waiting for the lockfile or does the
recipe wait indefinitely?
Yes, it's just a lock on the specified file - whoever gets there first can
continue, everyone else blocks, and it's an indefinite wait as far as
I'm aware.
It's a little obscure perhaps, but it is in the BitBake manual:
http://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#variable-flags
Cheers,
Paul
Regards,
Marcin
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] installing kernel modules in root filesystem
On Tue, Jul 7, 2015 at 5:55 AM, Philip Balister phi...@balister.org wrote: On 07/06/2015 09:16 PM, Richard Cagley wrote: I have a kernel module that shows up in my build work directory after I configure the kernel accordingly build/tmp-glibc/work/zedboard_zynq7-oe-linux-gnueabi/linux-xlnx/3.14-xilinx+gitAUTOINC+2b48a8aeea-r0/image/lib/modules/3.14.2-xilinx/kernel/drivers/dma/xilinx/vdmatest.ko But, when I add kernel-modules to my IMAGE_INSTALL in local.conf I don't see vdmatest.ko show up in the resultant root filesystem after I run bitbake core-image-minimal-dev and untar the image Is there a way to tell yocto to install all kernel modules or a step I've missed? I have: MACHINE_EXTRA_RRECOMMENDS = kernel-modules in my machine conf, Wow, thanks. I spent a lot of time trying to figure out that one. I stuck it in local.conf for now but I guess the machine.conf would eventually make more sense. Make sure you have buildhistory in your user classes. That creates files that are very helpful for working out what is actually in the generated packages. thanks for the tip. I just turned this on and will try to leverage it in the future. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCH] cross-localedef-native_2.20.bb: fix for gcc5
Burton, Ross ross.bur...@intel.com writes: On 7 July 2015 at 03:54, Richard Tollerton rich.toller...@ni.com wrote: The build of cross-localedef-native is observed to fail under gcc5 hosts with multiple definition errors, e.g.: Is this patch intended for fido? Master doesn't have 2.20 anymore (2.21) and I believe that works with gcc5 hosts. It was nominally written for dizzy. It looks like Khem already added -fgnu89-inline in his initial commit of cross-localedef-native_2.21.bb, so that's why this works in fido (and master). -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] External toolchains
Hi, For various reasons, we have a need to work with pre-compiled external toolchains, in this case, the 2014-09 Linaro aarch64 release. A key difference between this specific toolchain vs. the Fido/1.8 out of the box toolchain (4.9.2 + patches?), is that the Linaro version is built with --enable-multiarch. We end up with applications built with search paths such as /lib/aarch64, /usr/lib/aarch64, etc, but libraries installed in the normal /lib, /usr/lib paths. Obviously if we use the built-in toolchain recipes in 1.8, life is good, search paths match install paths. I wanted to understand a couple points. 1) What are the long term goals/roadmap are in this area specific to Yocto/OE? 2) Where is the right place to deal with this? a. Configure (based on detected toolchain capability) b. Install (override library destination?) c. Other? 3) Any other examples that can be used as a reference? I've seen a few emails in the archives that seem to touch on this, but none that really seemed to come to any conclusion. Thanks, Luke Starrett -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Creating image with genericx86 machine and RT-Preempt Patch
On 2015-07-07 7:56 AM, Gorny Krystian wrote: Hi, I try to build an image for a x86 architecture with RT-Preemtp Patch. So I use the genericx86 machine and try to build the core-image-rt recipe. This fails with the following errors: / ERROR: Nothing PROVIDES 'linux-yocto-rt' (but /media/disk/myYocto/poky/meta/recipes-rt/images/core-image-rt.bb DEPENDS on or otherwise requires it)/ / ERROR: linux-yocto-rt was skipped: incompatible with machine genericx86 (not in COMPATIBLE_MACHINE)/ / ERROR: Required build target 'core-image-rt' has no buildable providers./ / Missing or unbuildable dependency chain was: ['core-image-rt', 'linux-yocto-rt']/ So I add the following parameter to my local.conf file: / COMPATIBLE_MACHINE_genericx86 = genericx86/ / COMPATIBLE_MACHINE_quilt-native = genericx86/ / PREFERRED_PROVIDER_virtual/kernel = linux-yocto-rt/ But I get this error: / ERROR: Task 80 (/media/disk/myYocto/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb, do_compile) failed with exit code '1'/ In the log.do_compile file I see: / NOTE: make -j 4 bzImage CC=i686-poky-linux-gcc LD=i686-poky-linux-ld.bfd/ / make[3]: Nothing to be done for `all'./ / CHK include/config/kernel.release/ / GEN /media/disk/myYocto/poky/build/tmp/work/genericx86-poky-linux/linux-yocto-rt/3.14.36+gitAUTOINC+a996d95104_3428de7103-r0/linux-genericx86preempt-$/ / CHK include/generated/uapi/linux/version.h/ / CHK include/generated/utsrelease.h/ / HOSTCC scripts/conmakehash/ / HOSTCC scripts/sortextable/ / CC scripts/mod/empty.o/ / /media/disk/myYocto/poky/build/tmp/work-shared/genericx86/kernel-source/scripts/mod/empty.c:1:0: error: code model 'kernel' not supported in the 32 bit mode/ / /* empty file to figure out endianness / word size *// / ^/ / /media/disk/myYocto/poky/build/tmp/work-shared/genericx86/kernel-source/scripts/mod/empty.c:1:0: sorry, unimplemented: 64-bit mode not compiled in/ / make[4]: *** [scripts/mod/empty.o] Error 1/ / make[4]: *** Waiting for unfinished jobs/ / HOSTCC scripts/mod/mk_elfconfig/ / make[3]: *** [scripts/mod] Error 2/ / make[3]: *** Waiting for unfinished jobs/ / make[2]: *** [scripts] Error 2/ / make[1]: *** [sub-make] Error 2/ / make: *** [all] Error 2/ / ERROR: oe_runmake failed/ / WARNING: exit code 1 from a shell command./ I already tried genericx86_64 machine and it’s still not working. Are the genericx86 machine incompatible with the core-image-rt recipy? If yes how can I build a x86 image with the RT patch? What you did should have worked, since we do map the genericx86 BSP onto one of the configurations that supports preempt-rt. It looks like a compile error has crept in .. I'll start a build and see if it is indeed broken at the moment (and then I can fix it). Bruce Many Thanks _ *Krystian Gorny* Research Development Wipotec GmbH Adam-Hoffmann-Str. 26 67657 Kaiserslautern T +49.631.34146-0 F +49.631.34146-8640 http://www.wipotec.com http://www.wipotec.com Legal information: Wipotec Wiege- und Positioniersysteme GmbH HRB 2317 Kaiserslautern, Management: T. Düppre, U. Wagner This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCH] cross-localedef-native_2.20.bb: fix for gcc5
On 7 July 2015 at 03:54, Richard Tollerton rich.toller...@ni.com wrote: The build of cross-localedef-native is observed to fail under gcc5 hosts with multiple definition errors, e.g.: Is this patch intended for fido? Master doesn't have 2.20 anymore (2.21) and I believe that works with gcc5 hosts. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Recipe runs before network is established on target, causes problems.
Hey! I have a recipe where I in the pkg_postinst_mypackage () function runs apt-get update on first boot only. This doesn't work. I've seen the logfile which says: Cannot initiate the connection to xxx.xxx.xxx.xxx - connect (101: Network is unreachable). If I manually go to the terminal after it has booted and type apt-get update it works perfectly fine. Guess that means that my code tries to run before the network settings are established. Is there some way I could manage this? Eirik -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-mono: Issue building 4.0.2.4
Chris Morgan chmor...@gmail.com writes: /home/cmorgan/projects/yocto-cybex/build/tmp/work/x86_64-linux/mono-native/4.0.1.34-r0/image/home/cmorgan/projects/yocto-cybex/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild/Microsoft/VisualStudio/v11.0/WebApplications | /usr/bin/install: cannot create regular file '/home/cmorgan/projects/yocto-cybex/build/tmp/work/x86_64-linux/mono-native/4.0.1.34-r0/image/home/cmorgan/projects/yocto-cybex/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild/Microsoft/VisualStudio/v11.0/WebApplications/Microsoft.WebApplication.targets': File exists Did you try disabling PARALLEL_MAKE? I found a flat-out race at -j6: /usr/bin/install: cannot change permissions of build/tmp-glibc/work/x86_64-linux/mono-native/4.0.2.4-r0/image/build/tmp-glibc/sysroots/x86_64-linux/usr/lib/mono/xbuild-frameworks/.NETFramework/v4.5/RedistList/FrameworkList.xml: No such file or directory ... and FrameworkList.xml nevertheless existed once the failed build completed. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] mono-4.xx.inc: disable parallel make
A race was observed during `make install` of mono-native under
PARALLEL_MAKE=-j6:
/usr/bin/install: cannot change permissions of
build/tmp-glibc/work/x86_64-linux/mono-native/4.0.2.4-r0/image/
build/tmp-glibc/sysroots/x86_64-linux/usr/lib/mono/xbuild-frameworks/
.NETFramework/v4.5/RedistList/FrameworkList.xml: No such file or
directory
This is definitely a race, because FrameworkList.xml was present once
the failed build completed.
The present mono build doesn't appear to build much of anything in
parallel in the first place, and I would guess that this issue applies
equally to the mono and mono-native builds. So the correct place for the
workaround ought to be in the shared .inc file.
Signed-off-by: Richard Tollerton rich.toller...@ni.com
---
recipes-mono/mono/mono-4.xx.inc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/recipes-mono/mono/mono-4.xx.inc b/recipes-mono/mono/mono-4.xx.inc
index 2d7f65d..973593a 100644
--- a/recipes-mono/mono/mono-4.xx.inc
+++ b/recipes-mono/mono/mono-4.xx.inc
@@ -68,3 +68,6 @@ FILES_${PN}-dbg +=
${datadir}/mono-2.0/mono/cil/cil-opcodes.xml ${libdir}/m
FILES_${PN}-staticdev += ${libdir}/*.a
RDEPENDS_${PN} =+ bash
+
+# Workaround for observed race in `make install`
+PARALLEL_MAKE=
--
2.4.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] software upgrade - minimal amount of packages
Hi, Say I build a release with the YP and load this software onto some target. Then I keep on developing, make changes and make another release. At this point I would like to figure out the minimal amount of packages required to install on the target in order to update it to the new release. Could this be done with build history somehow? Did someone do something like this before? Regards, Robert...If the code and the comments disagree, both are probably wrong. My public pgp key is available,at: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x90320BF1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] External toolchains
Hi Luke, On 07/07/2015 08:35 PM, Luke (Lucas) Starrett wrote: Hi, For various reasons, we have a need to work with pre-compiled external toolchains, in this case, the 2014-09 Linaro aarch64 release. A key difference between this specific toolchain vs. the Fido/1.8 out of the box toolchain (4.9.2 + patches?), is that the Linaro version is built with --enable-multiarch. We end up with applications built with search paths such as /lib/aarch64, /usr/lib/aarch64, etc, but libraries installed in the normal /lib, /usr/lib paths. Obviously if we use the built-in toolchain recipes in 1.8, life is good, search paths match install paths. I wanted to understand a couple points. 1)What are the long term goals/roadmap are in this area specific to Yocto/OE? 2)Where is the “right” place to deal with this? a.Configure (based on detected toolchain capability) b.Install (override library destination?) c.Other? Is it possible for you to use ld.so.conf to point to the proper library paths? 3)Any other examples that can be used as a reference? I’ve seen a few emails in the archives that seem to touch on this, but none that really seemed to come to any conclusion. Thanks, Luke Starrett Regards, Nikolay -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-mono: Issue building 4.0.2.4
On Tue, Jul 7, 2015 at 4:01 PM, Richard Tollerton rich.toller...@ni.com wrote: Chris Morgan chmor...@gmail.com writes: /home/cmorgan/projects/yocto-cybex/build/tmp/work/x86_64-linux/mono-native/4.0.1.34-r0/image/home/cmorgan/projects/yocto-cybex/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild/Microsoft/VisualStudio/v11.0/WebApplications | /usr/bin/install: cannot create regular file '/home/cmorgan/projects/yocto-cybex/build/tmp/work/x86_64-linux/mono-native/4.0.1.34-r0/image/home/cmorgan/projects/yocto-cybex/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild/Microsoft/VisualStudio/v11.0/WebApplications/Microsoft.WebApplication.targets': File exists Did you try disabling PARALLEL_MAKE? I found a flat-out race at -j6: /usr/bin/install: cannot change permissions of build/tmp-glibc/work/x86_64-linux/mono-native/4.0.2.4-r0/image/build/tmp-glibc/sysroots/x86_64-linux/usr/lib/mono/xbuild-frameworks/.NETFramework/v4.5/RedistList/FrameworkList.xml: No such file or directory ... and FrameworkList.xml nevertheless existed once the failed build completed. I haven't tried that. Is that something that would go into the recipe, if it were necessary? If so, how do you do that? Chris -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] using shared state cache from other machine
Hi Kurt, On Tue, Jul 7, 2015 at 6:07 AM, Kurt Van Dijck dev.k...@vandijck-laurijssen.be wrote: Hey, I started to re-use the shared state cache from a build machine. If I clean everything locally, I still spend time building. So, can everything be re-used, or only the target packages. How different may the build machine may host be. The build machine is a (recent) ubuntu. My machine is debian squeeze+sid mixed version. Is that a problem? You can try it, but no guarantees. I have a build machine running Ubuntu 14.04 and a laptop running Linux Mint 17.1 and I regularly rsync sstate from the build server to the laptop without any issues (as expected, since Linux Mint uses Ubuntu packages). The trick to avoid rebuilding all native packages is to rename sstate-cache/Ubuntu-14.04 - sstate-cache/LinuxMint-17.1 after each rsync. Digging around a little in oe-core, it looks like the directory under sstate-cache for native packages is controlled by NATIVELSBSTRING, which is set by lsb_distro_identifier(), which accepts an option adjustment hook via LSB_DISTRO_ADJUST. You can find an example lsb_distro_adjust hook here: http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/meta-mel/conf/distro/include/sstate.inc Kind regards, Kurt -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Creating image with genericx86 machine and RT-Preempt Patch
On 2015-07-07 12:30 PM, Bruce Ashfield wrote: On 2015-07-07 7:56 AM, Gorny Krystian wrote: Hi, I try to build an image for a x86 architecture with RT-Preemtp Patch. So I use the genericx86 machine and try to build the core-image-rt recipe. This fails with the following errors: / ERROR: Nothing PROVIDES 'linux-yocto-rt' (but /media/disk/myYocto/poky/meta/recipes-rt/images/core-image-rt.bb DEPENDS on or otherwise requires it)/ / ERROR: linux-yocto-rt was skipped: incompatible with machine genericx86 (not in COMPATIBLE_MACHINE)/ / ERROR: Required build target 'core-image-rt' has no buildable providers./ / Missing or unbuildable dependency chain was: ['core-image-rt', 'linux-yocto-rt']/ So I add the following parameter to my local.conf file: / COMPATIBLE_MACHINE_genericx86 = genericx86/ / COMPATIBLE_MACHINE_quilt-native = genericx86/ / PREFERRED_PROVIDER_virtual/kernel = linux-yocto-rt/ But I get this error: / ERROR: Task 80 (/media/disk/myYocto/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb, do_compile) failed with exit code '1'/ In the log.do_compile file I see: / NOTE: make -j 4 bzImage CC=i686-poky-linux-gcc LD=i686-poky-linux-ld.bfd/ / make[3]: Nothing to be done for `all'./ / CHK include/config/kernel.release/ / GEN /media/disk/myYocto/poky/build/tmp/work/genericx86-poky-linux/linux-yocto-rt/3.14.36+gitAUTOINC+a996d95104_3428de7103-r0/linux-genericx86preempt-$/ / CHK include/generated/uapi/linux/version.h/ / CHK include/generated/utsrelease.h/ / HOSTCC scripts/conmakehash/ / HOSTCC scripts/sortextable/ / CC scripts/mod/empty.o/ / /media/disk/myYocto/poky/build/tmp/work-shared/genericx86/kernel-source/scripts/mod/empty.c:1:0: error: code model 'kernel' not supported in the 32 bit mode/ / /* empty file to figure out endianness / word size *// / ^/ / /media/disk/myYocto/poky/build/tmp/work-shared/genericx86/kernel-source/scripts/mod/empty.c:1:0: sorry, unimplemented: 64-bit mode not compiled in/ / make[4]: *** [scripts/mod/empty.o] Error 1/ / make[4]: *** Waiting for unfinished jobs/ / HOSTCC scripts/mod/mk_elfconfig/ / make[3]: *** [scripts/mod] Error 2/ / make[3]: *** Waiting for unfinished jobs/ / make[2]: *** [scripts] Error 2/ / make[1]: *** [sub-make] Error 2/ / make: *** [all] Error 2/ / ERROR: oe_runmake failed/ / WARNING: exit code 1 from a shell command./ I already tried genericx86_64 machine and it’s still not working. Are the genericx86 machine incompatible with the core-image-rt recipy? If yes how can I build a x86 image with the RT patch? What you did should have worked, since we do map the genericx86 BSP onto one of the configurations that supports preempt-rt. It looks like a compile error has crept in .. I'll start a build and see if it is indeed broken at the moment (and then I can fix it). Assuming you are building with yocto/poky, you need the following patch. (note: this is configure tested only). Since without this bbappend, we don't have genericx86 mapped to a valid linux-yocto BSP and commit hash. I'll be sending this change for merging into the project shortly. Cheers, Bruce Bruce Many Thanks _ *Krystian Gorny* Research Development Wipotec GmbH Adam-Hoffmann-Str. 26 67657 Kaiserslautern T +49.631.34146-0 F +49.631.34146-8640 http://www.wipotec.com http://www.wipotec.com Legal information: Wipotec Wiege- und Positioniersysteme GmbH HRB 2317 Kaiserslautern, Management: T. Düppre, U. Wagner This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. 0001-yocto-bsps-add-3.14-rt-configuration.patch Description: application/mbox -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, July 7, 2015 8:00 AM US Pacific Time
Attendees: Stephen, Michael, Randy, Cristian, Belen, Bruce, Alex V., Ross, * Opens collection - 5 min (Stephen) * Yocto Project status - 5 min (Stephen/team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.9_Status https://wiki.yoctoproject.org/wiki/Yocto_1.9_Schedule https://wiki.yoctoproject.org/wiki/Yocto_1.9_Features YP 1.9 M1 rc1 completed QA but we are debating to release or do an rc2. A lot of issues have been found with autobuilder and we are working them at the highest possible priority. * Opens - 10 min Belen - Toaster - Toaster his broken in master, but is being improved. Issues are being worked but please let the team know if there are other issues found. * Team Sharing - 10 min Michael - Will attend the O'Reilly Open Source convention in Portland this month. You can meet him F2F and have a discussion. Randy - WRS now has a cluster of over 100 nodes for building Yocto images. Discussed their usage and the YP teams usage of its build environment. Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 * Work Telephone: (503) 712-0534 *Cell:(208) 244-4460 * Email: stephen.k.jol...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [PATCH v2 06/11] stmicro: Add support for the STMMAC Ethernet controller family
On 7/6/15, 9:42 AM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 2015-07-06 12:16 PM, Saul Wold wrote: On 07/06/2015 07:18 AM, Bruce Ashfield wrote: On 2015-07-06 9:55 AM, Paul Gortmaker wrote: [Re: [PATCH v2 06/11] stmicro: Add support for the STMMAC Ethernet controller family] On 05/07/2015 (Sun 22:30) Saul Wold wrote: On 07/05/2015 08:52 PM, Bruce Ashfield wrote: On 2015-07-01 7:15 PM, Darren Hart wrote: On 7/1/15 4:06 PM, Saul Wold wrote: This is needed for the meta-quark BSP which is used by the Galileo Board. Still would like to see this in features/net - or some discussion as to why not. Agreed. We can start a cleanup of the net* fragments with a small bit of effort here. A good example for any following SOCs. I have updated my branch linux-yocto-contrib/sgw/refactor-wip with this change along with the rest of the refactoring of the x86/x86_64 and x86_base changes. One of the key differences is the way we handle MTRR_SANITIZER, by removing the not set as Darren recommended we get the following difference: # CONFIG_MTRR_SANITIZER is not set --- CONFIG_MTRR_SANITIZER=y CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0 CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1 Paul G was the person that added the not set to have it match the kernel.org defconfig for x86/x86_64. Since the default is disabled is there any reason to continue explicitly saying not set? There are a couple reasons I typically do sth. like that. One is that it makes it explicitly clear that it was a choice and not just a lets go with the default, even if in this case the underlying reason was to get better alignment with the defconfig (which is _not_ the same as taking the defaults for everything). Another reason, is that if the default changes, you won't just get swept along for the ride without knowing what happened. You will stay where you were until you decide whether you consciously want to align with the new default. I'm also a fan of not relying on defaults for configs we care about (as we all know, we don't set them all) for the same reasons paul highlights. And finally, (assuming that this is set at a higher level) you will get a warning from the config audit about the divergence from the more global value if a later level (in config prio) BSP decides to change it. Yep, and even if something selects it (to change our default), we'll get a log in the configuration audit. Of course none of these are critical, and if we have a lot of BSPs that want it on, then the explicit not set may not make sense anymore and hence rolling back to accepting the default to make BSP life easier may be the right thing to do; I don't have enough context to know, given that I just got dragged into this discussion now. :) Agreed as well. We all got dragged into this as I started the refactor and Darren asked the questions. I looked at the Kconfig description for MTRR_SANITIZER and related and it seems safe to enable it as default. Bruce, do you want me include or exclude the MTRR_SANITIZER in a v4? Let's try it as a default to 'on' for the x86 platforms. I thought Paul made a strong case for leaving it is not set. It wasn't that I objected to it being is not set, I just wanted to know the reasoning for it. Keeping close to defconfig unless there is a specific reason not to makes a lot of sense to me. For one thing, we'll be testing and using what has seen the broadest usage in industry. I suggest leaving it as is not set, but include a comment as to why. Thanks for the context Paul. -- Darren Hart Intel Open Source Technology Center -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[yocto] populate_sdk and kernel headers
Hello, I want my kernel headers to be included in the SDK output when I run bitbake myimage -c populate_sdk. I expect to see the headers in my installed SDK folder such as sdk/sysroot/target_mach/usr/src/kernel; however, I don't see anything there. Also, I don't want the headers appearing on the target. In my recipe I have added IMAGE_INSTALL += kernel-modules, and SDKIMAGE_FEATURES += kernel-devsrc. The kernel I'm using is linux-altera-ltsi-rt from https://github.com/kraj/meta-altera/blob/master/recipes-kernel/linux/linux-altera-ltsi-rt_3.10.bb What am I missing? Thanks, Ben -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] using shared state cache from other machine
On Tuesday 07 July 2015 14:59:37 Andre McCurdy wrote: On Tue, Jul 7, 2015 at 6:07 AM, Kurt Van Dijck dev.k...@vandijck-laurijssen.be wrote: I started to re-use the shared state cache from a build machine. If I clean everything locally, I still spend time building. So, can everything be re-used, or only the target packages. How different may the build machine may host be. The build machine is a (recent) ubuntu. My machine is debian squeeze+sid mixed version. Is that a problem? You can try it, but no guarantees. I have a build machine running Ubuntu 14.04 and a laptop running Linux Mint 17.1 and I regularly rsync sstate from the build server to the laptop without any issues (as expected, since Linux Mint uses Ubuntu packages). The theory is this should work provided the distro you use the native sstate artifacts on has the same or newer glibc version as the one on which they were originally built. The trick to avoid rebuilding all native packages is to rename sstate-cache/Ubuntu-14.04 - sstate-cache/LinuxMint-17.1 after each rsync. Rather than renaming, you can simply create a symlink from the other distribution to the one which was used to do the build. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCH] cross-localedef-native_2.20.bb: fix for gcc5
On Tue, Jul 7, 2015 at 5:29 AM, Burton, Ross ross.bur...@intel.com wrote: On 7 July 2015 at 03:54, Richard Tollerton rich.toller...@ni.com wrote: The build of cross-localedef-native is observed to fail under gcc5 hosts with multiple definition errors, e.g.: Is this patch intended for fido? Master doesn't have 2.20 anymore (2.21) and I believe that works with gcc5 hosts. I would prefer to upgrade to 2.21, if this is tthe case. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] installing kernel modules in root filesystem
On 07/06/2015 09:16 PM, Richard Cagley wrote: I have a kernel module that shows up in my build work directory after I configure the kernel accordingly build/tmp-glibc/work/zedboard_zynq7-oe-linux-gnueabi/linux-xlnx/3.14-xilinx+gitAUTOINC+2b48a8aeea-r0/image/lib/modules/3.14.2-xilinx/kernel/drivers/dma/xilinx/vdmatest.ko But, when I add kernel-modules to my IMAGE_INSTALL in local.conf I don't see vdmatest.ko show up in the resultant root filesystem after I run bitbake core-image-minimal-dev and untar the image Is there a way to tell yocto to install all kernel modules or a step I've missed? I have: MACHINE_EXTRA_RRECOMMENDS = kernel-modules in my machine conf, Make sure you have buildhistory in your user classes. That creates files that are very helpful for working out what is actually in the generated packages. Philip -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Creating image with genericx86 machine and RT-Preempt Patch
Hi, I try to build an image for a x86 architecture with RT-Preemtp Patch. So I use the genericx86 machine and try to build the core-image-rt recipe. This fails with the following errors: ERROR: Nothing PROVIDES 'linux-yocto-rt' (but /media/disk/myYocto/poky/meta/recipes-rt/images/core-image-rt.bb DEPENDS on or otherwise requires it) ERROR: linux-yocto-rt was skipped: incompatible with machine genericx86 (not in COMPATIBLE_MACHINE) ERROR: Required build target 'core-image-rt' has no buildable providers. Missing or unbuildable dependency chain was: ['core-image-rt', 'linux-yocto-rt'] So I add the following parameter to my local.conf file: COMPATIBLE_MACHINE_genericx86 = genericx86 COMPATIBLE_MACHINE_quilt-native = genericx86 PREFERRED_PROVIDER_virtual/kernel = linux-yocto-rt But I get this error: ERROR: Task 80 (/media/disk/myYocto/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb, do_compile) failed with exit code '1' In the log.do_compile file I see: NOTE: make -j 4 bzImage CC=i686-poky-linux-gcc LD=i686-poky-linux-ld.bfd make[3]: Nothing to be done for `all'. CHK include/config/kernel.release GEN /media/disk/myYocto/poky/build/tmp/work/genericx86-poky-linux/linux-yocto-rt/3.14.36+gitAUTOINC+a996d95104_3428de7103-r0/linux-genericx86preempt-$ CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h HOSTCC scripts/conmakehash HOSTCC scripts/sortextable CC scripts/mod/empty.o /media/disk/myYocto/poky/build/tmp/work-shared/genericx86/kernel-source/scripts/mod/empty.c:1:0: error: code model 'kernel' not supported in the 32 bit mode /* empty file to figure out endianness / word size */ ^ /media/disk/myYocto/poky/build/tmp/work-shared/genericx86/kernel-source/scripts/mod/empty.c:1:0: sorry, unimplemented: 64-bit mode not compiled in make[4]: *** [scripts/mod/empty.o] Error 1 make[4]: *** Waiting for unfinished jobs HOSTCC scripts/mod/mk_elfconfig make[3]: *** [scripts/mod] Error 2 make[3]: *** Waiting for unfinished jobs make[2]: *** [scripts] Error 2 make[1]: *** [sub-make] Error 2 make: *** [all] Error 2 ERROR: oe_runmake failed WARNING: exit code 1 from a shell command. I already tried genericx86_64 machine and it's still not working. Are the genericx86 machine incompatible with the core-image-rt recipy? If yes how can I build a x86 image with the RT patch? Many Thanks _ Krystian Gorny Research Development Wipotec GmbH Adam-Hoffmann-Str. 26 67657 Kaiserslautern T +49.631.34146-0 F +49.631.34146-8640 http://www.wipotec.com [http://www.wipotec.com/fileadmin/user_upload/Signatur/W_Standard.jpg]http://www.wipotec.com Legal information: Wipotec Wiege- und Positioniersysteme GmbH HRB 2317 Kaiserslautern, Management: T. D?ppre, U. Wagner This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] populate_sdk and kernel headers
On Tue, Jul 7, 2015 at 4:16 PM, Benjamin Fleming bflem...@meteorcomm.com wrote: Hello, I want my kernel headers to be included in the SDK output when I run bitbake myimage -c populate_sdk. I expect to see the headers in my installed SDK folder such as sdk/sysroot/target_mach/usr/src/kernel; however, I don't see anything there. Also, I don't want the headers appearing on the target. In my recipe I have added IMAGE_INSTALL += kernel-modules, and SDKIMAGE_FEATURES += kernel-devsrc. The kernel I'm using is linux-altera-ltsi-rt from https://github.com/kraj/meta-altera/blob/master/recipes-kernel/linux/linux-altera-ltsi-rt_3.10.bb What am I missing? Try adding kernel-devsrc to IMAGE_INSTALL rather than SDKIMAGE_FEATURES. Thanks, Ben -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH][meta-selinux] findutils/gnulib:drop the error output of 'ls' command
Ping...
On 04/02/2015 10:26 AM, rongqing...@windriver.com wrote:
From: Roy Li rongqing...@windriver.com
The ls command is used to check if the file exists, and it is normal that
the checked file does not exist, so drop the ls error ouput:
ls: cannot access ./doc/fdl.texi: No such file or directory
Signed-off-by: Roy Li rongqing...@windriver.com
---
.../drop-the-error-output-of-ls-command.patch | 29 ++
.../findutils/findutils_4.4.2.bbappend | 1 +
2 files changed, 30 insertions(+)
create mode 100644
recipes-extended/findutils/findutils-4.4.2/drop-the-error-output-of-ls-command.patch
diff --git
a/recipes-extended/findutils/findutils-4.4.2/drop-the-error-output-of-ls-command.patch
b/recipes-extended/findutils/findutils-4.4.2/drop-the-error-output-of-ls-command.patch
new file mode 100644
index 000..069be41
--- /dev/null
+++
b/recipes-extended/findutils/findutils-4.4.2/drop-the-error-output-of-ls-command.patch
@@ -0,0 +1,29 @@
+[PATCH] drop the error output of 'ls' command
+
+Upstream-Status: pending
+
+ls is used to check if the file exists, and it is normal that
+the checked file does not exist, so drop the ls error
+ls: cannot access ./doc/fdl.texi: No such file or directory
+
+Signed-off-by: Roy Li rongqing...@windriver.com
+---
+ gnulib-tool | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/gnulib-tool b/gnulib-tool
+index 354b1f0..beb81ba 100755
+--- a/gnulib-tool
b/gnulib-tool
+@@ -602,7 +602,7 @@ else
+ {
+ # Use two sed invocations. A single sed -n -e 's,^.* - \(.*\)$,\1,p'
+ # would do the wrong thing if the link target contains - .
+-LC_ALL=C ls -l $1 | sed -e 's, - ,#%%#,' | sed -n -e
's,^.*#%%#\(.*\)$,\1,p'
++LC_ALL=C ls -l $1 2/dev/null | sed -e 's, - ,#%%#,' | sed -n -e
's,^.*#%%#\(.*\)$,\1,p'
+ }
+ fi
+
+--
+1.9.1
+
diff --git a/recipes-extended/findutils/findutils_4.4.2.bbappend
b/recipes-extended/findutils/findutils_4.4.2.bbappend
index 3245e5c..e174888 100644
--- a/recipes-extended/findutils/findutils_4.4.2.bbappend
+++ b/recipes-extended/findutils/findutils_4.4.2.bbappend
@@ -5,6 +5,7 @@ FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}-${PV}:
SRC_URI +=
git://git.savannah.gnu.org/gnulib.git;protocol=git;rev=0e0635af0b23826911dc456bd0da40dcb19247de
SRC_URI += file://findutils-with-selinux.patch
SRC_URI += file://findutils-with-selinux-gnulib.patch
+SRC_URI += file://drop-the-error-output-of-ls-command.patch;patchdir=../git/
inherit with-selinux
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] using shared state cache from other machine
Hey, I started to re-use the shared state cache from a build machine. If I clean everything locally, I still spend time building. So, can everything be re-used, or only the target packages. How different may the build machine may host be. The build machine is a (recent) ubuntu. My machine is debian squeeze+sid mixed version. Is that a problem? Kind regards, Kurt -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [PATCH v4 00/14] Introduce new Quark BSP with refactor of x86 and associted features
On 2015-07-06 1:42 PM, Saul Wold wrote: Bruce: This patch set introduces several new feautres and refactors the the x86 cfg files to have a common base. The series looks good to me. We can adjust it more once it is in the tree. I assume this is for 3.14, -dev and the soon to be created 4.1 linux-yocto ? Bruce This also introduces the Quark/X1000 BSP with basic drivers enabled. Updates in v4 - Use new x86_base and pci for the x86 based BSP - Moved stmicro to features/net heirarchy Updates in v3: - Fixed a couple of stupid typos Updates in v2: - addressed issues raised by Darren - Moved PCI related to features/pci - removed PCI_MSI and MTRR_SANITIZER not set from x86_base - renamed serial-vendor - erial-all - Added misc/bosch-pressure-sensor-i2c - updated Quark/X1000 soc and bsp configs Sau! Saul Wold (14): cfg/amd: Add AMD Vendor Specific enabler cfg/intel: Add Intel Vendor Specific enabler cfg/x86_base: Create new base config for x86 Architectures cfg/x86*: refactor to use x86_base features/debug: Create a new feature for early printk debug features/net: Add a features/net heirarchy features/net/stmicro: Add the STMICRO networking drivers features/pwm: Create new feature for PWM features/usb/serial-all: Add new set of configs for USB_SERIAL devices features/pci/pci.cfg: Extend to be more complete features/misc/bosch-pressure-sensor: Add config fragment Quark/X1000: Add new SOC and BSP pci: use the new pci config fragment in common-pc and intel-common x86* BSPs: Add AMD and Intel vendor .SCC .../kernel-cache/bsp/common-pc-64/common-pc-64.scc | 3 ++ .../bsp/common-pc/common-pc-drivers.cfg| 3 -- meta/cfg/kernel-cache/bsp/common-pc/common-pc.scc | 3 ++ .../bsp/intel-common/intel-common-drivers.scc | 3 ++ .../kernel-cache/bsp/intel-common/intel-common.scc | 2 +- .../bsp/intel-common/intel-quark-standard.scc | 14 + .../kernel-cache/bsp/intel-common/intel-quark.cfg | 7 + .../kernel-cache/bsp/intel-common/intel-quark.scc | 21 + meta/cfg/kernel-cache/cfg/amd.cfg | 11 +++ meta/cfg/kernel-cache/cfg/amd.scc | 1 + meta/cfg/kernel-cache/cfg/intel.cfg| 16 ++ meta/cfg/kernel-cache/cfg/intel.scc| 1 + meta/cfg/kernel-cache/cfg/x86.cfg | 14 - meta/cfg/kernel-cache/cfg/x86.scc | 4 +-- meta/cfg/kernel-cache/cfg/x86_64.cfg | 13 meta/cfg/kernel-cache/cfg/x86_64.scc | 4 +-- meta/cfg/kernel-cache/cfg/x86_base.cfg | 7 + meta/cfg/kernel-cache/cfg/x86_base.scc | 4 +++ meta/cfg/kernel-cache/features/debug/printk.cfg| 11 +++ meta/cfg/kernel-cache/features/debug/printk.scc| 10 ++ .../features/misc/bosch-pressure-sensor-i2c.cfg| 2 ++ .../features/misc/bosch-pressure-sensor-i2c.scc| 5 +++ meta/cfg/kernel-cache/features/net/net-all.scc | 3 ++ meta/cfg/kernel-cache/features/net/net.cfg | 3 ++ meta/cfg/kernel-cache/features/net/net.scc | 2 ++ .../kernel-cache/features/net/stmicro/stmmac.cfg | 4 +++ .../kernel-cache/features/net/stmicro/stmmac.scc | 4 +++ meta/cfg/kernel-cache/features/pci/pci.cfg | 10 ++ meta/cfg/kernel-cache/features/pwm/intel_pwm.cfg | 6 meta/cfg/kernel-cache/features/pwm/intel_pwm.scc | 5 +++ meta/cfg/kernel-cache/features/pwm/pwm.cfg | 3 ++ meta/cfg/kernel-cache/features/pwm/pwm.scc | 4 +++ meta/cfg/kernel-cache/features/soc/x1000/x1000.cfg | 23 ++ meta/cfg/kernel-cache/features/soc/x1000/x1000.scc | 36 ++ meta/cfg/kernel-cache/features/usb/serial-all.cfg | 17 ++ meta/cfg/kernel-cache/features/usb/serial-all.scc | 4 +++ 36 files changed, 246 insertions(+), 37 deletions(-) create mode 100644 meta/cfg/kernel-cache/bsp/intel-common/intel-quark-standard.scc create mode 100644 meta/cfg/kernel-cache/bsp/intel-common/intel-quark.cfg create mode 100644 meta/cfg/kernel-cache/bsp/intel-common/intel-quark.scc create mode 100644 meta/cfg/kernel-cache/cfg/amd.cfg create mode 100644 meta/cfg/kernel-cache/cfg/amd.scc create mode 100644 meta/cfg/kernel-cache/cfg/intel.cfg create mode 100644 meta/cfg/kernel-cache/cfg/intel.scc create mode 100644 meta/cfg/kernel-cache/cfg/x86_base.cfg create mode 100644 meta/cfg/kernel-cache/cfg/x86_base.scc create mode 100644 meta/cfg/kernel-cache/features/debug/printk.cfg create mode 100644 meta/cfg/kernel-cache/features/debug/printk.scc create mode 100644 meta/cfg/kernel-cache/features/misc/bosch-pressure-sensor-i2c.cfg create mode 100644 meta/cfg/kernel-cache/features/misc/bosch-pressure-sensor-i2c.scc create mode 100644 meta/cfg/kernel-cache/features/net/net-all.scc create mode 100644 meta/cfg/kernel-cache/features/net/net.cfg create
Re: [linux-yocto] [PATCH v4 00/14] Introduce new Quark BSP with refactor of x86 and associted features
On 07/07/2015 09:00 PM, Bruce Ashfield wrote: On 2015-07-07 11:58 PM, Bruce Ashfield wrote: On 2015-07-06 1:42 PM, Saul Wold wrote: Bruce: This patch set introduces several new feautres and refactors the the x86 cfg files to have a common base. The series looks good to me. We can adjust it more once it is in the tree. I assume this is for 3.14, -dev and the soon to be created 4.1 4.1 only, I don't know that the QUARK Configs are part of 3.19 so we can just focus on -dev and 4.1. Sau! And by 3.14 .. I meant 3.19. Bruce linux-yocto ? Bruce This also introduces the Quark/X1000 BSP with basic drivers enabled. Updates in v4 - Use new x86_base and pci for the x86 based BSP - Moved stmicro to features/net heirarchy Updates in v3: - Fixed a couple of stupid typos Updates in v2: - addressed issues raised by Darren - Moved PCI related to features/pci - removed PCI_MSI and MTRR_SANITIZER not set from x86_base - renamed serial-vendor - erial-all - Added misc/bosch-pressure-sensor-i2c - updated Quark/X1000 soc and bsp configs Sau! Saul Wold (14): cfg/amd: Add AMD Vendor Specific enabler cfg/intel: Add Intel Vendor Specific enabler cfg/x86_base: Create new base config for x86 Architectures cfg/x86*: refactor to use x86_base features/debug: Create a new feature for early printk debug features/net: Add a features/net heirarchy features/net/stmicro: Add the STMICRO networking drivers features/pwm: Create new feature for PWM features/usb/serial-all: Add new set of configs for USB_SERIAL devices features/pci/pci.cfg: Extend to be more complete features/misc/bosch-pressure-sensor: Add config fragment Quark/X1000: Add new SOC and BSP pci: use the new pci config fragment in common-pc and intel-common x86* BSPs: Add AMD and Intel vendor .SCC .../kernel-cache/bsp/common-pc-64/common-pc-64.scc | 3 ++ .../bsp/common-pc/common-pc-drivers.cfg| 3 -- meta/cfg/kernel-cache/bsp/common-pc/common-pc.scc | 3 ++ .../bsp/intel-common/intel-common-drivers.scc | 3 ++ .../kernel-cache/bsp/intel-common/intel-common.scc | 2 +- .../bsp/intel-common/intel-quark-standard.scc | 14 + .../kernel-cache/bsp/intel-common/intel-quark.cfg | 7 + .../kernel-cache/bsp/intel-common/intel-quark.scc | 21 + meta/cfg/kernel-cache/cfg/amd.cfg | 11 +++ meta/cfg/kernel-cache/cfg/amd.scc | 1 + meta/cfg/kernel-cache/cfg/intel.cfg| 16 ++ meta/cfg/kernel-cache/cfg/intel.scc| 1 + meta/cfg/kernel-cache/cfg/x86.cfg | 14 - meta/cfg/kernel-cache/cfg/x86.scc | 4 +-- meta/cfg/kernel-cache/cfg/x86_64.cfg | 13 meta/cfg/kernel-cache/cfg/x86_64.scc | 4 +-- meta/cfg/kernel-cache/cfg/x86_base.cfg | 7 + meta/cfg/kernel-cache/cfg/x86_base.scc | 4 +++ meta/cfg/kernel-cache/features/debug/printk.cfg| 11 +++ meta/cfg/kernel-cache/features/debug/printk.scc| 10 ++ .../features/misc/bosch-pressure-sensor-i2c.cfg| 2 ++ .../features/misc/bosch-pressure-sensor-i2c.scc| 5 +++ meta/cfg/kernel-cache/features/net/net-all.scc | 3 ++ meta/cfg/kernel-cache/features/net/net.cfg | 3 ++ meta/cfg/kernel-cache/features/net/net.scc | 2 ++ .../kernel-cache/features/net/stmicro/stmmac.cfg | 4 +++ .../kernel-cache/features/net/stmicro/stmmac.scc | 4 +++ meta/cfg/kernel-cache/features/pci/pci.cfg | 10 ++ meta/cfg/kernel-cache/features/pwm/intel_pwm.cfg | 6 meta/cfg/kernel-cache/features/pwm/intel_pwm.scc | 5 +++ meta/cfg/kernel-cache/features/pwm/pwm.cfg | 3 ++ meta/cfg/kernel-cache/features/pwm/pwm.scc | 4 +++ meta/cfg/kernel-cache/features/soc/x1000/x1000.cfg | 23 ++ meta/cfg/kernel-cache/features/soc/x1000/x1000.scc | 36 ++ meta/cfg/kernel-cache/features/usb/serial-all.cfg | 17 ++ meta/cfg/kernel-cache/features/usb/serial-all.scc | 4 +++ 36 files changed, 246 insertions(+), 37 deletions(-) create mode 100644 meta/cfg/kernel-cache/bsp/intel-common/intel-quark-standard.scc create mode 100644 meta/cfg/kernel-cache/bsp/intel-common/intel-quark.cfg create mode 100644 meta/cfg/kernel-cache/bsp/intel-common/intel-quark.scc create mode 100644 meta/cfg/kernel-cache/cfg/amd.cfg create mode 100644 meta/cfg/kernel-cache/cfg/amd.scc create mode 100644 meta/cfg/kernel-cache/cfg/intel.cfg create mode 100644 meta/cfg/kernel-cache/cfg/intel.scc create mode 100644 meta/cfg/kernel-cache/cfg/x86_base.cfg create mode 100644 meta/cfg/kernel-cache/cfg/x86_base.scc create mode 100644 meta/cfg/kernel-cache/features/debug/printk.cfg create mode 100644 meta/cfg/kernel-cache/features/debug/printk.scc create mode 100644
[yocto] bash getcwd errors when running under OverlayFS
I am using an OverlayFS patch for kernel 3.14.x obtained from OpenWRT. Once I started using OverlayFS, I found that bash shell scripts would give a lot of errors, something like: shell-init: error retrieving current directory: getcwd: cannot access parent directories: Success job-working-directory: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory chdir: error retrieving current directory: getcwd: cannot access parent directories: Bad file descriptor It seems that this can be traced to an internal implementation of getcwd() in bash. When cross-compiled, it can't check for getcwd() use of malloc, so it is cautious and sets GETCWD_BROKEN and uses an internal implementation of getcwd(). This internal implementation doesn't seem to work well with OverlayFS. A simple fix in Yocto is to put the following in a recipes-extended/bash/bash_4.3.bbappend in your own layer: EXTRA_OECONF += bash_cv_getcwd_malloc=yes -- Craig McQueen -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH v2][meta-selinux] udev: restorecon /run to allow mdadm creating /run/mdadm
Ping ...
On 03/23/2015 03:40 PM, wenzong@windriver.com wrote:
From: Wenzong Fan wenzong@windriver.com
This change bases on the factors during bootup:
a. the default type for /run is var_run_t;
b. the type for /run will be changed to tmpfs_t after tmpfs mounted;
c. the type for /run will be fixed after populate-volatile.sh run.
udev service is started in b-c period, fix the type for /run from
udev init script to remove:
avc: denied { write } for pid=294 comm=mdadm \
name=/ dev=tmpfs ino=10581 \
scontext=system_u:system_r:mdadm_t:s0-s15:c0.c1023 \
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
Signed-off-by: Wenzong Fan wenzong@windriver.com
---
recipes-core/udev/udev/init | 3 +++
1 file changed, 3 insertions(+)
diff --git a/recipes-core/udev/udev/init b/recipes-core/udev/udev/init
index 66359f2..bb8b95b 100644
--- a/recipes-core/udev/udev/init
+++ b/recipes-core/udev/udev/init
@@ -61,6 +61,9 @@ case $1 in
# /var/volatile/tmp directory to be available.
mkdir -p /var/volatile/tmp
+# restorecon /run early to allow mdadm creating dir /run/mdadm
+test ! -x /sbin/restorecon || /sbin/restorecon -F /run
+
# Cache handling.
# A list of files which are used as a criteria to judge whether the udev
cache could be reused.
CMP_FILE_LIST=/proc/version /proc/cmdline /proc/devices /proc/atags
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH][meta-selinux] policycoreutils: enable mcstransd
Ping ...
On 01/26/2015 03:38 PM, rongqing...@windriver.com wrote:
From: Roy Li rongqing...@windriver.com
mcstransd is a daemon to translate SELinux MCS/MLS sensitivity labels,
policycoreutils includes mcstransd whose version is newer than that
from http://mcstrans.sourcearchive.com/
Signed-off-by: Roy Li rongqing...@windriver.com
---
recipes-security/selinux/policycoreutils.inc | 82 --
.../0001-mcstrans-fix-the-init-script.patch| 27 +++
.../selinux/policycoreutils/enable-mcstrans.patch | 17 +
recipes-security/selinux/policycoreutils_2.3.bb| 2 +
recipes-security/selinux/policycoreutils_git.bb| 2 +
5 files changed, 126 insertions(+), 4 deletions(-)
create mode 100644
recipes-security/selinux/policycoreutils/0001-mcstrans-fix-the-init-script.patch
create mode 100644
recipes-security/selinux/policycoreutils/enable-mcstrans.patch
diff --git a/recipes-security/selinux/policycoreutils.inc
b/recipes-security/selinux/policycoreutils.inc
index 44a5861..fa0b601 100644
--- a/recipes-security/selinux/policycoreutils.inc
+++ b/recipes-security/selinux/policycoreutils.inc
@@ -13,11 +13,14 @@ PAM_SRC_URI = file://pam.d/newrole \
file://pam.d/run_init \
-DEPENDS += libsepol libselinux libsemanage
+DEPENDS += libsepol libselinux libsemanage libcap
EXTRA_DEPENDS = libcap-ng libcgroup setools
DEPENDS += ${@['', '${EXTRA_DEPENDS}']['${PN}' != '${BPN}-native']}
-inherit selinux
+inherit selinux systemd pythonnative update-rc.d
+
+PROVIDES += mcstrans
+
DEPENDS += ${@target_selinux(d, 'libpam audit')}
RDEPENDS_${BPN}-audit2allow = \
@@ -113,7 +116,6 @@ RDEPENDS_${BPN} += setools setools-libs ${BPN}-python
WARN_QA := ${@oe_filter_out('unsafe-references-in-scripts', '${WARN_QA}',
d)}
ERROR_QA := ${@oe_filter_out('unsafe-references-in-scripts', '${ERROR_QA}',
d)}
-inherit pythonnative
PACKAGES =+ \
${PN}-audit2allow \
@@ -137,8 +139,31 @@ PACKAGES =+ \
${PN}-sestatus \
${PN}-setfiles \
${PN}-setsebool \
+ mcstrans \
+ mcstrans-doc \
system-config-selinux \
+PKGV_mcstrans = 0.3.2
+PKGV_mcstrans-doc = 0.3.2
+SUMMARY_mcstrans = Daemon to translate SELinux MCS/MLS sensitivity labels
+DESCRIPTION_mcstrans = \
+Security-enhanced Linux is a feature of the Linux kernel and a number \
+of utilities with enhanced security functionality designed to add \
+mandatory access controls to Linux. The Security-enhanced Linux \
+kernel contains new architectural components originally developed to \
+improve the security of the Flask operating system. These \
+architectural components provide general support for the enforcement \
+of many kinds of mandatory access control policies, including those \
+based on the concepts of Type Enforcement®, Role-based Access \
+Control, and Multi-level Security. \
+ \
+mcstrans provides an translation daemon to translate SELinux
categories \
+from internal representations to user defined representation. \
+
+SUMMARY_mcstrans-doc = ${SUMMARY_mcstrans} man pages and examples
+DESCRIPTION_mcstrans-doc = ${DESCRIPTION_mcstrans} \
+This package contains man pages and examples. \
+
FILES_${PN}-audit2allow = \
${bindir}/audit2allow \
${bindir}/audit2why \
@@ -208,6 +233,23 @@ FILES_${PN}-setsebool += \
${sbindir}/setsebool \
${datadir}/bash-completion/completions/setsebool \
+FILES_mcstrans = \
+ ${base_sbindir}/mcstransd \
+ ${sbindir}/untranscon \
+ ${sbindir}/transcon \
+ ${sysconfdir}/init.d/mcstrans \
+ ${systemd_unitdir}/system/mcstrans.service \
+ ${sysconfdir}/default/volatiles/volatiles.80_mcstrans \
+ ${sysconfdir}/tmpfiles.d/setrans.conf \
+
+
+FILES_mcstrans-doc = \
+/usr/share/man/man8/mcstransd.8 \
+/usr/share/man/man8/mcs.8 \
+/usr/share/man/man8/setrans.conf.8 \
+${datadir}/mcstrans \
+
+
FILES_system-config-selinux = \
${bindir}/sepolgen \
${datadir}/system-config-selinux/* \
@@ -248,7 +290,24 @@ do_compile_prepend() {
do_install_prepend() {
export PYTHON=python
- export SEMODULE_PATH=${sbindir}
+ export SEMODULE_PATH=${sbindir} SYSTEMDDIR=${D}/${systemd_unitdir}
+}
+
+do_install_append_class-target() {
+ install -m 755 mcstrans/utils/untranscon ${D}${sbindir}/
+ install -m 755 mcstrans/utils/transcon ${D}${sbindir}/
+
+ if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false',
d)}; then
+ install -d ${D}${sysconfdir}/tmpfiles.d
+ echo d ${localstatedir}/run/setrans - - - - \
+${D}${sysconfdir}/tmpfiles.d/setrans.conf
+ else
+ install -d ${D}${sysconfdir}/default/volatiles
+ echo d root root 0755 /var/run/setrans none \
+
