Re: [yocto] Custom defconfig is not used

[Diego Sueiro]

2013/10/17 Bruce Ashfield 

> On Wed, Oct 16, 2013 at 2:19 PM, Diego Sueiro 
> wrote:
> > Folks,
> >
> > Looking at log.do_unpack it shows:
> >
> > ...
> > NOTE: Unpacking
> >
> <...>/meta-beagleboard/common-bsp/recipes-kernel/linux/linux-mainline-3.8/beaglebone/defconfig
> > to
> >
> <...>/build/tmp-angstrom_v2013_06-eglibc/work/beaglebone-angstrom-linux-gnueabi/linux-mainline/3.8.13-r23a/
> > ...
> >
> > NOTE: Unpacking
> > <...>/meta-mine/recipes-kernel/linux/linux-mainline-3.8/mine.patch to
> >
> <...>/build/tmp-angstrom_v2013_06-eglibc/work/beaglebone-angstrom-linux-gnueabi/linux-mainline/3.8.13-r23a/
> > NOTE: Unpacking
> >
> <...>/meta-beagleboard/common-bsp/recipes-kernel/linux/linux-mainline-3.8/beaglebone/defconfig
> > to
> >
> <...>/build/tmp-angstrom_v2013_06-eglibc/work/beaglebone-angstrom-linux-gnueabi/linux-mainline/3.8.13-r23a/
> >
> >
> > Note that it copies defconfig from meta-beagleboard and in the end,
> instead
> > copying mine, it is copying from meta-beagleboard again.
> >
> > My layer has the priority higher than meta-beagleboard.
>
> I can't get at my machines to test this myself (technically I'm still
> on vacation), but when you
> dump the bitbake environment, how many defconfig's show up in the
> SRC_URI ? It would be
> easy enough in your bbapend to simply call your defconfig something
> else (i.e. defconfig-mine)
> and override/append to kernel_do_configure() to simply copy yours over
> top of the .config,
> regardless of what the fetcher is doing with the SRC_URI.
>
> Bruce
>
>
Bruce,

Putting the following in my recipe did the trick:

do_configure_prepend() {
cp ${WORKDIR}/defconfig-mine ${WORKDIR}/defconfig
}


Now the .config is the same as my custom defconfig.

But, this is a workaround, right?
I expected to get this working "out-of-box".
Why config fragments did not worked too?



--
*dS
Diego Sueiro

/*long live rock 'n roll*/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] default root password

[Diego Sueiro]

2013/10/16 David Andrey 

> Hi,
>
> There are lot of threads floating around, and a FAQ without answer.
> https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_set_or_change_the_root_p
> assword
>
> So what is the official way to set a default root password ?
> Using a sed command on /etc/passwd through ROOTFS_POSTPROCESS_COMMAND or
> is there any other built-in solution ?
>
> regards
> David
>

David,

Did you find another way to achieve this?

--
*dS
Diego Sueiro

/*long live rock 'n roll*/


> ___
> 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] Custom defconfig is not used

[Bruce Ashfield]

On 13-10-17 06:39 AM, Diego Sueiro wrote:




2013/10/17 Bruce Ashfield mailto:bruce.ashfi...@gmail.com>>

On Wed, Oct 16, 2013 at 2:19 PM, Diego Sueiro
mailto:diego.sue...@gmail.com>> wrote:
 > Folks,
 >
 > Looking at log.do_unpack it shows:
 >
 > ...
 > NOTE: Unpacking
 >

<...>/meta-beagleboard/common-bsp/recipes-kernel/linux/linux-mainline-3.8/beaglebone/defconfig
 > to
 >

<...>/build/tmp-angstrom_v2013_06-eglibc/work/beaglebone-angstrom-linux-gnueabi/linux-mainline/3.8.13-r23a/
 > ...
 >
 > NOTE: Unpacking
 > <...>/meta-mine/recipes-kernel/linux/linux-mainline-3.8/mine.patch to
 >

<...>/build/tmp-angstrom_v2013_06-eglibc/work/beaglebone-angstrom-linux-gnueabi/linux-mainline/3.8.13-r23a/
 > NOTE: Unpacking
 >

<...>/meta-beagleboard/common-bsp/recipes-kernel/linux/linux-mainline-3.8/beaglebone/defconfig
 > to
 >

<...>/build/tmp-angstrom_v2013_06-eglibc/work/beaglebone-angstrom-linux-gnueabi/linux-mainline/3.8.13-r23a/
 >
 >
 > Note that it copies defconfig from meta-beagleboard and in the
end, instead
 > copying mine, it is copying from meta-beagleboard again.
 >
 > My layer has the priority higher than meta-beagleboard.

I can't get at my machines to test this myself (technically I'm still
on vacation), but when you
dump the bitbake environment, how many defconfig's show up in the
SRC_URI ? It would be
easy enough in your bbapend to simply call your defconfig something
else (i.e. defconfig-mine)
and override/append to kernel_do_configure() to simply copy yours over
top of the .config,
regardless of what the fetcher is doing with the SRC_URI.

Bruce


Bruce,

Putting the following in my recipe did the trick:

do_configure_prepend() {
 cp ${WORKDIR}/defconfig-mine ${WORKDIR}/defconfig
}


Now the .config is the same as my custom defconfig.

But, this is a workaround, right?


I could be. Until we root cause the issue, I can't say for sure.


I expected to get this working "out-of-box".


Did you do a  "bitbake -e " ? and then look at
the SRC_URI ? That will tell us if for some reason the beagle layer's
defconfig is on there twice.


Why config fragments did not worked too?


recipes must inherit linux-yocto to get that support, since it is
optional and not something we force on all kernel recipes. So if you
want fragment support, creating your own kernel recipe, based on the
one in the layers you are using, which inherits linux-yocto is one
route to take.

Bruce





--
*dS
Diego Sueiro

/*long live rock 'n roll*/


___
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] Custom defconfig is not used

[Diego Sueiro]

2013/10/17 Bruce Ashfield 

>
>
>  I expected to get this working "out-of-box".
>>
>
> Did you do a  "bitbake -e " ? and then look at
> the SRC_URI ? That will tell us if for some reason the beagle layer's
> defconfig is on there twice.


I'll do it after my current build gets finished.


>
>
>  Why config fragments did not worked too?
>>
>
> recipes must inherit linux-yocto to get that support, since it is
> optional and not something we force on all kernel recipes. So if you
> want fragment support, creating your own kernel recipe, based on the
> one in the layers you are using, which inherits linux-yocto is one
> route to take.

Can I do it on bbappend, or do I need to copy the entirely
linux-mainline_3.8.bb from meta-bleagleboard to my layer and add "inherit
linux-yocto"?
Do I need to "inherit linux-yocto", "require
recipes-kernel/linux/linux-yocto.inc" or "inherit kernel-yocto"?
My concern is: if doing this to just have the config fragment feature, I'll
possibly mess up the kernel build.


Regards,

--
*dS
Diego Sueiro

/*long live rock 'n roll*/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Custom defconfig is not used

[Bruce Ashfield]

On 13-10-17 09:15 AM, Diego Sueiro wrote:


2013/10/17 Bruce Ashfield mailto:bruce.ashfi...@windriver.com>>



I expected to get this working "out-of-box".


Did you do a  "bitbake -e " ? and then look at
the SRC_URI ? That will tell us if for some reason the beagle layer's
defconfig is on there twice.

I'll do it after my current build gets finished.



Why config fragments did not worked too?


recipes must inherit linux-yocto to get that support, since it is
optional and not something we force on all kernel recipes. So if you
want fragment support, creating your own kernel recipe, based on the
one in the layers you are using, which inherits linux-yocto is one
route to take.

Can I do it on bbappend, or do I need to copy the entirely
linux-mainline_3.8.bb  from
meta-bleagleboard to my layer and add "inherit linux-yocto"?
Do I need to "inherit linux-yocto", "require
recipes-kernel/linux/linux-yocto.inc" or "inherit kernel-yocto"?


Look at oe-core/meta-skeleton for the custom kernel recipe example.
It has the inherit/include combinations that you need to follow.


My concern is: if doing this to just have the config fragment feature,
I'll possibly mess up the kernel build.


It shouldn't. It only adds to existing phases, and doesn't make
any changes. I've tested it in many combinations and it should
work fine.

If something breaks, I'd like to know, so we can fix it.

Bruce




Regards,

--
*dS
Diego Sueiro

/*long live rock 'n roll*/


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] default root password

[Bryan Evenson]

David,

I've had similar issues, and this is what I've done to get the root password 
set properly in my image.  I am using poky/Dylan-9.0.1 for a starting point.

1. In my case, I want a root password that is longer than 8 characters.  With 
poky/dylan, it is using tinylogin for password management which has an issue 
with passwords longer than 8 characters; it looks like it is using them, but it 
only pays attention to the first 8 characters.  If you want to use a root 
password that is longer than 8 characters, there is a 10 patch series under 
poky/master submitted by Chen Qi on 2013-06-25.  Cherry-pick these 10 patches 
and apply them to your local poky repository.  Rebuild your image with 
"debug-tweaks" set in local.conf.
2. Boot up your newly built image with the default blank password (or some 
other password you know what it is).  Then, change the root password using the 
passwd command.  If you want a root password that is longer than 8 characters, 
use "passwd -m".
3. Look at the contents of /etc/shadow.  Everything between the first two 
colons on root's line is its password.  For example, if it looked like this:
root:$QAGQ$%Y#QTRAG%^J#$#QR$@:15924:0:9:7:::
then $QAGQ$%Y#QTRAG%^J#$#QR$@ would be root's encrypted password.  Copy that 
text.
4. Add the following to the end of your image recipe:

ROOTFS_POSTPROCESS_COMMAND += "\
sed 's%^root:[^:]*:%root::%' \
< ${IMAGE_ROOTFS}/etc/shadow \
> ${IMAGE_ROOTFS}/etc/shadow.new;\
mv ${IMAGE_ROOTFS}/etc/shadow.new ${IMAGE_ROOTFS}/etc/shadow ;"

and that will change root's password in your image.

I know there is the EXTRA_USER_PARAMS feature for adding users and modifying a 
user's password, but I couldn't get it to work for root.  I tried adding:

INHERIT += "extrausers"
EXTRA_USERS_PARAMS = "\
usermod -p '' root; \
"

and I would get errors when building the image.  I can't remember the errors I 
got, but I couldn't get the build to complete when I tried to modify the root 
password in this manner.  The other way worked so I went with that.

Hope that helps.

-Bryan Evenson

> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-
> boun...@yoctoproject.org] On Behalf Of David Andrey
> Sent: Wednesday, October 16, 2013 8:58 AM
> To: yocto@yoctoproject.org
> Subject: [yocto] default root password
> 
> Hi,
> 
> There are lot of threads floating around, and a FAQ without answer.
> https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_set_or_change_the_root_
> p
> assword
> 
> So what is the official way to set a default root password ?
> Using a sed command on /etc/passwd through ROOTFS_POSTPROCESS_COMMAND
> or is there any other built-in solution ?
> 
> regards
> David
> ___
> 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] default root password

[Diego Sueiro]

2013/10/17 Bryan Evenson 

> I know there is the EXTRA_USER_PARAMS feature for adding users and
> modifying a user's password, but I couldn't get it to work for root.  I
> tried adding:
>
> INHERIT += "extrausers"
> EXTRA_USERS_PARAMS = "\
> usermod -p '' root; \
> "
>
> and I would get errors when building the image.  I can't remember the
> errors I got, but I couldn't get the build to complete when I tried to
> modify the root password in this manner.  The other way worked so I went
> with that.
>

Bryan,

I've tried that too.The issue raised for me was related to INHERIT +=
"extrausers", as soon as, it is not present on dylan branch.
So, I solved that with ROOTFS_POSTPROCESS_COMMAND strategy.

Regards,

--
*dS
Diego Sueiro

/*long live rock 'n roll*/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Busybox configuration example?

[Gary Thomas]

I see mention of busybox configuration fragments in the mega
manual (section 5.9.7) but no explanation nor examples.

Can someone explain how I might control my busybox builds?
For example, I routinely add this to busybox*.bbappend:

  #
  # Force 'ifup' to wait longer for really slow links...
  #
  do_prepare_config_append () {
sed -i 's/CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-R 
-n"/CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-R -n -T 1 -t 20"/' ${S}/.config
  }

which is just editing the confguration file to match my preferences.
Is there a way to do this using the "configuration fragments" mentioned
above?

Thanks

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Custom defconfig is not used

[Andrea Adami]

On Thu, Oct 17, 2013 at 3:19 PM, Bruce Ashfield
 wrote:
> On 13-10-17 09:15 AM, Diego Sueiro wrote:
>>
>>
>> 2013/10/17 Bruce Ashfield > >
>>
>>
>>
>>
>> I expected to get this working "out-of-box".
>>
>>
>> Did you do a  "bitbake -e " ? and then look at
>> the SRC_URI ? That will tell us if for some reason the beagle layer's
>> defconfig is on there twice.
>>
>> I'll do it after my current build gets finished.
>>
>>
>>
>> Why config fragments did not worked too?
>>
>>
>> recipes must inherit linux-yocto to get that support, since it is
>> optional and not something we force on all kernel recipes. So if you
>> want fragment support, creating your own kernel recipe, based on the
>> one in the layers you are using, which inherits linux-yocto is one
>> route to take.
>>
>> Can I do it on bbappend, or do I need to copy the entirely
>> linux-mainline_3.8.bb  from
>>
>> meta-bleagleboard to my layer and add "inherit linux-yocto"?
>> Do I need to "inherit linux-yocto", "require
>> recipes-kernel/linux/linux-yocto.inc" or "inherit kernel-yocto"?
>
>
> Look at oe-core/meta-skeleton for the custom kernel recipe example.
> It has the inherit/include combinations that you need to follow.
>
>
>> My concern is: if doing this to just have the config fragment feature,
>> I'll possibly mess up the kernel build.
>
>
> It shouldn't. It only adds to existing phases, and doesn't make
> any changes. I've tested it in many combinations and it should
> work fine.
>
> If something breaks, I'd like to know, so we can fix it.
>
> Bruce
>
>
>>
>>
>> Regards,
>>
>> --
>> *dS
>> Diego Sueiro
>>
>> /*long live rock 'n roll*/
>
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

As a final note, the defconfig is overwritten by the
do_configure_prepend() code in linux.inc.
This is how kernel recipes did work before linux-yocto.

Cheers

Andrea
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-xilinx

[Edward Vidal]

Hello,
I got the following error.
DEBUG: Executing shell function do_compile
NOTE: make -C
/home/vidal/POKY/build101613_zedboard/poky/build/tmp/sysroots/zedboard-zynq7/usr/src/kernel/tools/perf
O=/home/vidal/POKY/build101613_zedboard/poky/build/tmp/work/zedboard_zynq7-poky-linux-gnueabi/perf/1.0-r8/perf-1.0
CROSS_COMPILE=arm-poky-linux-gnueabi- ARCH=arm
CC=arm-poky-linux-gnueabi-gcc  -march=armv7-a -mthumb-interwork
-mfloat-abi=softfp -mfpu=neon
--sysroot=/home/vidal/POKY/build101613_zedboard/poky/build/tmp/sysroots/zedboard-zynq7
AR=arm-poky-linux-gnueabi-ar perfexecdir=/usr/lib/perf NO_GTK2=1 NO_DWARF=1
prefix=/usr bindir=/usr/bin sharedir=/usr/share sysconfdir=/etc
perfexecdir=/usr/lib/perf/perf-core ETC_PERFCONFIG=../etc sharedir=share
mandir=share/man infodir=share/info all
CHK -fstack-protector-all
CHK -Wstack-protector
CHK -Wvolatile-register-var
CHK bionic
CHK libelf
CHK libdw
make: Entering directory
`/home/vidal/POKY/build101613_zedboard/poky/build/tmp/sysroots/zedboard-zynq7/usr/src/kernel/tools/perf'
Makefile:554: No libdw.h found or old libdw.h found or elfutils is older
than 0.138, disables dwarf support. Please install new
elfutils-devel/libdw-dev
CHK libunwind
Makefile:570: No libunwind found, disabling post unwind support. Please
install libunwind-dev[el] >= 0.99
I installed libunwind-devel-1.0.1-5.fc18.x86_64
Is this a zedboard-zynq specific error?  Is this an error in building the
kernel?
 I did not see this when building for the beagleboard. I installed
libunwind-devel-1.0.1-5.fc18.x86_64
I removed the package libunwind-devel-1.0.1-5.fc18.x86_64 since nothing
improved with the package installed.
I am in the process of running a clean build after  all repository were
loaded in clean folder.
I appreciate any and all help.
Regards


On Wed, Oct 16, 2013 at 5:06 PM, Edward Vidal wrote:

> Hello Khem,
> Thanks for the help after modifying my local.conf
> MACHINE ?= "zedboard-zynq7"
> My build "MACHINE=zedboard-zynq7 bitbake core-image-sato" is in the
> process now 295 of 5076 tasks
> should take a short time to complete.
> regards
>
>
>
> On Wed, Oct 16, 2013 at 4:45 PM, Khem Raj  wrote:
>
>>
>> On Oct 16, 2013, at 2:57 PM, Edward Vidal 
>> wrote:
>>
>> > Hello,
>> > I built a zedboard core-image-sato on 09/21/13 with meta-xilinx at that
>> time I had the following folders.
>> >
>> > meta-kc705
>> > meta-zc702
>> > meta-zedboard
>> >
>> > Build Configuration:
>> > BB_VERSION= "1.19.1"
>> > BUILD_SYS = "x86_64-linux"
>> > NATIVELSBSTRING   = "Fedora-18"
>> > TARGET_SYS= "arm-poky-linux-gnueabi"
>> > MACHINE   = "zedboard"
>> > DISTRO= "poky"
>> > DISTRO_VERSION= "1.4+snapshot-20130921"
>> > TUNE_FEATURES = " armv7a vfp neon zynq"
>> > TARGET_FPU= "vfp-neon"
>> > meta
>> > meta-yocto=
>> "(nobranch):3dee534f1e25109e0bdb681de0746c336f4b8840"
>> > meta-xilinx
>> > meta-kc705
>> > meta-zc702
>> > meta-zedboard = "master:46f4c79d6d55b556a90bb0fd89c2c09acf2aebff"
>> > meta-yocto-bsp=
>> "(nobranch):3dee534f1e25109e0bdb681de0746c336f4b8840"
>> >
>> > With the dora release I did a new clone of git://
>> git.yoctoproject.org/meta-xilinx
>> > now I do not see
>> > meta-kc705
>> > meta-zc702
>> > meta-zedboard
>> >
>> > When I execute MACHINE=zedboard bitbake core-image-sato
>> > ERROR:  OE-core's config sanity checker detected a potential
>> misconfiguration.
>> > Either fix the cause of this error or at your own risk disable the
>> checker (see sanity.conf).
>> > Following is the list of potential problems / advisories:
>> >
>> > Please set a valid MACHINE in your local.conf or environment
>> >
>> > ERROR: Execution of event handler 'check_sanity_eventhandler' failed
>> > In my local.conf I have the following.
>> >
>> > MACHINE ?= "zedboard"
>> >
>> > bblayers.conf
>> > # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
>> > # changes incompatibly
>> > LCONF_VERSION = "6"
>> >
>> > BBPATH = "${TOPDIR}"
>> > BBFILES ?= ""
>> >
>> > BBLAYERS ?= " \
>> >   /home/vidal/POKY/build101613_zedboard/poky/meta \
>> >   /home/vidal/POKY/build101613_zedboard/poky/meta-yocto \
>> >   /home/vidal/POKY/build101613_zedboard/poky/meta-xilinx \
>> >   /home/vidal/POKY/build101613_zedboard/poky/meta-yocto-bsp \
>> >   "
>> > BBLAYERS_NON_REMOVABLE ?= " \
>> >   /home/vidal/POKY/build101613_zedboard/poky/meta \
>> >   /home/vidal/POKY/build101613_zedboard/poky/meta-yocto \
>> >   "
>> > Any help will be appreciated.
>> > Regards
>>
>> it seems like layer went thru some restructuring e.g. see
>> commit d9617006376d73e37f1db17857ee06c24e6b7c03
>> Author: Nathan Rossi 
>> Date:   Fri Aug 2 12:41:14 2013 +1000
>>
>> meta-*: Remove deprecated sublayers
>>
>> * The machines supported in the sublayer BSPs are now supported in
>> the base
>>   meta-xilinx layer, these sublayers are no longer required.
>> * Relevant documentation has also been relocated into
>> meta-xilinx/docs/*.
>

Re: [yocto] Busybox configuration example?

[Jack Mitchell]

On 17/10/13 14:50, Gary Thomas wrote:
> I see mention of busybox configuration fragments in the mega
> manual (section 5.9.7) but no explanation nor examples.
> 
> Can someone explain how I might control my busybox builds?
> For example, I routinely add this to busybox*.bbappend:
> 
>   #
>   # Force 'ifup' to wait longer for really slow links...
>   #
>   do_prepare_config_append () {
> sed -i 's/CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-R
> -n"/CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-R -n -T 1 -t 20"/' ${S}/.config
>   }
> 
> which is just editing the confguration file to match my preferences.
> Is there a way to do this using the "configuration fragments" mentioned
> above?
> 
> Thanks
> 

If I remember correctly there is one in meta-skeleton.


-- 
  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  Cambrideshire, UK
  http://www.embed.me.uk
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Custom defconfig is not used

[Diego Sueiro]

2013/10/17 Bruce Ashfield 

> Look at oe-core/meta-skeleton for the custom kernel recipe example.
> It has the inherit/include combinations that you need to follow.
>
>
>  My concern is: if doing this to just have the config fragment feature,
>> I'll possibly mess up the kernel build.
>>
>
> It shouldn't. It only adds to existing phases, and doesn't make
> any changes. I've tested it in many combinations and it should
> work fine.
>
> If something breaks, I'd like to know, so we can fix it.
>

Bruce,

I didn't change linux-mainline_3.8.bb.
My linux-mainline_3.8.bbappend is:

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:"
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
COMPATIBLE_MACHINE_beaglebone = "(beaglebone)"
SRC_URI += " file://mine.patch \
 file://config-addons.cfg \
 "

My config-addons.cfg:

CONFIG_WATCHDOG_NOWAYOUT=y
CONFIG_NTFS_FS=y
CONFIG_NTFS_RW=y

After a cleansstate the build got stucked on do_patch task.
Here is the content of log.do_patch:

DEBUG: Executing shell function do_patch
WARNING: no meta data branch found ...
Switched to branch 'linux-3.8.y'


Running with bitbake -v I got the following:

...
+ configme --reconfig --output
<...>/build/tmp-angstrom_v2013_06-eglibc/work/beaglebone-angstrom-linux-gnueabi/linux-mainline/3.8.13-r23a/linux-beaglebone-standard-build
standard beaglebone
[INFO] Configuring target/machine combo: "standard/beaglebone"

[INFO] Configuring target/machine combo: "standard/beaglebone"
[INFO] collecting configs in ./meta/meta-series

[INFO] collecting configs in ./meta/meta-series
cat: meta/cfg/standard/beaglebone/config_frag.txt: No such file or directory

cat: meta/cfg/standard/beaglebone/config_frag.txt: No such file or directory
cat: meta/cfg/standard/beaglebone/config_frag.txt: No such file or directory

cat: meta/cfg/standard/beaglebone/config_frag.txt: No such file or directory
mv: target `3.8.13' is not a directory

mv: target `3.8.13' is not a directory
creation of pre-processed config data failed
config of "standard/beaglebone" failed

creation of pre-processed config data failed
config of "standard/beaglebone" failed
ERROR: Function failed: do_kernel_configme (see
<...>/build/tmp-angstrom_v2013_06-eglibc/work/beaglebone-angstrom-linux-gnueabi/linux-mainline/3.8.13-r23a/temp/log.do_kernel_configme15450.
for further information)
ERROR: Task 7
(<...>/setup-scripts/sources/meta-beagleboard/common-bsp/recipes-kernel/linux/
linux-mainline_3.8.bb, do_kernel_configme) failed with exit code '1'





Regards,

--
*dS
Diego Sueiro

/*long live rock 'n roll*/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-xilinx

[Philip Balister]

This is may be better asked on the meta-xilinx list:

https://lists.yoctoproject.org/listinfo/meta-xilinx

Philip

On 10/17/2013 11:05 AM, Edward Vidal wrote:
> Hello,
> I got the following error.
> DEBUG: Executing shell function do_compile
> NOTE: make -C
> /home/vidal/POKY/build101613_zedboard/poky/build/tmp/sysroots/zedboard-zynq7/usr/src/kernel/tools/perf
> O=/home/vidal/POKY/build101613_zedboard/poky/build/tmp/work/zedboard_zynq7-poky-linux-gnueabi/perf/1.0-r8/perf-1.0
> CROSS_COMPILE=arm-poky-linux-gnueabi- ARCH=arm
> CC=arm-poky-linux-gnueabi-gcc  -march=armv7-a -mthumb-interwork
> -mfloat-abi=softfp -mfpu=neon
> --sysroot=/home/vidal/POKY/build101613_zedboard/poky/build/tmp/sysroots/zedboard-zynq7
> AR=arm-poky-linux-gnueabi-ar perfexecdir=/usr/lib/perf NO_GTK2=1 NO_DWARF=1
> prefix=/usr bindir=/usr/bin sharedir=/usr/share sysconfdir=/etc
> perfexecdir=/usr/lib/perf/perf-core ETC_PERFCONFIG=../etc sharedir=share
> mandir=share/man infodir=share/info all
> CHK -fstack-protector-all
> CHK -Wstack-protector
> CHK -Wvolatile-register-var
> CHK bionic
> CHK libelf
> CHK libdw
> make: Entering directory
> `/home/vidal/POKY/build101613_zedboard/poky/build/tmp/sysroots/zedboard-zynq7/usr/src/kernel/tools/perf'
> Makefile:554: No libdw.h found or old libdw.h found or elfutils is older
> than 0.138, disables dwarf support. Please install new
> elfutils-devel/libdw-dev
> CHK libunwind
> Makefile:570: No libunwind found, disabling post unwind support. Please
> install libunwind-dev[el] >= 0.99
> I installed libunwind-devel-1.0.1-5.fc18.x86_64
> Is this a zedboard-zynq specific error?  Is this an error in building the
> kernel?
>  I did not see this when building for the beagleboard. I installed
> libunwind-devel-1.0.1-5.fc18.x86_64
> I removed the package libunwind-devel-1.0.1-5.fc18.x86_64 since nothing
> improved with the package installed.
> I am in the process of running a clean build after  all repository were
> loaded in clean folder.
> I appreciate any and all help.
> Regards
> 
> 
> On Wed, Oct 16, 2013 at 5:06 PM, Edward Vidal wrote:
> 
>> Hello Khem,
>> Thanks for the help after modifying my local.conf
>> MACHINE ?= "zedboard-zynq7"
>> My build "MACHINE=zedboard-zynq7 bitbake core-image-sato" is in the
>> process now 295 of 5076 tasks
>> should take a short time to complete.
>> regards
>>
>>
>>
>> On Wed, Oct 16, 2013 at 4:45 PM, Khem Raj  wrote:
>>
>>>
>>> On Oct 16, 2013, at 2:57 PM, Edward Vidal 
>>> wrote:
>>>
 Hello,
 I built a zedboard core-image-sato on 09/21/13 with meta-xilinx at that
>>> time I had the following folders.

 meta-kc705
 meta-zc702
 meta-zedboard

 Build Configuration:
 BB_VERSION= "1.19.1"
 BUILD_SYS = "x86_64-linux"
 NATIVELSBSTRING   = "Fedora-18"
 TARGET_SYS= "arm-poky-linux-gnueabi"
 MACHINE   = "zedboard"
 DISTRO= "poky"
 DISTRO_VERSION= "1.4+snapshot-20130921"
 TUNE_FEATURES = " armv7a vfp neon zynq"
 TARGET_FPU= "vfp-neon"
 meta
 meta-yocto=
>>> "(nobranch):3dee534f1e25109e0bdb681de0746c336f4b8840"
 meta-xilinx
 meta-kc705
 meta-zc702
 meta-zedboard = "master:46f4c79d6d55b556a90bb0fd89c2c09acf2aebff"
 meta-yocto-bsp=
>>> "(nobranch):3dee534f1e25109e0bdb681de0746c336f4b8840"

 With the dora release I did a new clone of git://
>>> git.yoctoproject.org/meta-xilinx
 now I do not see
 meta-kc705
 meta-zc702
 meta-zedboard

 When I execute MACHINE=zedboard bitbake core-image-sato
 ERROR:  OE-core's config sanity checker detected a potential
>>> misconfiguration.
 Either fix the cause of this error or at your own risk disable the
>>> checker (see sanity.conf).
 Following is the list of potential problems / advisories:

 Please set a valid MACHINE in your local.conf or environment

 ERROR: Execution of event handler 'check_sanity_eventhandler' failed
 In my local.conf I have the following.

 MACHINE ?= "zedboard"

 bblayers.conf
 # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
 # changes incompatibly
 LCONF_VERSION = "6"

 BBPATH = "${TOPDIR}"
 BBFILES ?= ""

 BBLAYERS ?= " \
   /home/vidal/POKY/build101613_zedboard/poky/meta \
   /home/vidal/POKY/build101613_zedboard/poky/meta-yocto \
   /home/vidal/POKY/build101613_zedboard/poky/meta-xilinx \
   /home/vidal/POKY/build101613_zedboard/poky/meta-yocto-bsp \
   "
 BBLAYERS_NON_REMOVABLE ?= " \
   /home/vidal/POKY/build101613_zedboard/poky/meta \
   /home/vidal/POKY/build101613_zedboard/poky/meta-yocto \
   "
 Any help will be appreciated.
 Regards
>>>
>>> it seems like layer went thru some restructuring e.g. see
>>> commit d9617006376d73e37f1db17857ee06c24e6b7c03
>>> Author: Nathan Rossi 
>>> Date:   Fri Aug 2 12:41:14 2013 +1000
>>>
>>> meta

Re: [yocto] meta-xilinx

[Khem Raj]

On Oct 17, 2013, at 8:05 AM, Edward Vidal  wrote:

> Hello,
> I got the following error.
> DEBUG: Executing shell function do_compile
> NOTE: make -C 
> /home/vidal/POKY/build101613_zedboard/poky/build/tmp/sysroots/zedboard-zynq7/usr/src/kernel/tools/perf
>  
> O=/home/vidal/POKY/build101613_zedboard/poky/build/tmp/work/zedboard_zynq7-poky-linux-gnueabi/perf/1.0-r8/perf-1.0
>  CROSS_COMPILE=arm-poky-linux-gnueabi- ARCH=arm CC=arm-poky-linux-gnueabi-gcc 
>  -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon 
> --sysroot=/home/vidal/POKY/build101613_zedboard/poky/build/tmp/sysroots/zedboard-zynq7
>  AR=arm-poky-linux-gnueabi-ar perfexecdir=/usr/lib/perf NO_GTK2=1 NO_DWARF=1 
> prefix=/usr bindir=/usr/bin sharedir=/usr/share sysconfdir=/etc 
> perfexecdir=/usr/lib/perf/perf-core ETC_PERFCONFIG=../etc sharedir=share 
> mandir=share/man infodir=share/info all
> CHK -fstack-protector-all
> CHK -Wstack-protector
> CHK -Wvolatile-register-var
> CHK bionic
> CHK libelf
> CHK libdw
> make: Entering directory 
> `/home/vidal/POKY/build101613_zedboard/poky/build/tmp/sysroots/zedboard-zynq7/usr/src/kernel/tools/perf'
> Makefile:554: No libdw.h found or old libdw.h found or elfutils is older than 
> 0.138, disables dwarf support. Please install new elfutils-devel/libdw-dev
> CHK libunwind
> Makefile:570: No libunwind found, disabling post unwind support. Please 
> install libunwind-dev[el] >= 0.99
> I installed libunwind-devel-1.0.1-5.fc18.x86_64
> Is this a zedboard-zynq specific error?  Is this an error in building the 
> kernel?
>  I did not see this when building for the beagleboard. I installed 
> libunwind-devel-1.0.1-5.fc18.x86_64
> I removed the package libunwind-devel-1.0.1-5.fc18.x86_64 since nothing 
> improved with the package installed.

You were barking up the wrong tree :) The problem is missing dependency for 
target package not for host package.
whichever package is failing, add elfutils to DEPENDS section of the recipe and 
it should fix it.

> I am in the process of running a clean build after  all repository were 
> loaded in clean folder.
> I appreciate any and all help.
> Regards
> 
> 
> On Wed, Oct 16, 2013 at 5:06 PM, Edward Vidal  
> wrote:
> Hello Khem,
> Thanks for the help after modifying my local.conf 
> MACHINE ?= "zedboard-zynq7"
> My build "MACHINE=zedboard-zynq7 bitbake core-image-sato" is in the process 
> now 295 of 5076 tasks
> should take a short time to complete.
> regards 
> 
> 
> 
> On Wed, Oct 16, 2013 at 4:45 PM, Khem Raj  wrote:
> 
> On Oct 16, 2013, at 2:57 PM, Edward Vidal  wrote:
> 
> > Hello,
> > I built a zedboard core-image-sato on 09/21/13 with meta-xilinx at that 
> > time I had the following folders.
> >
> > meta-kc705
> > meta-zc702
> > meta-zedboard
> >
> > Build Configuration:
> > BB_VERSION= "1.19.1"
> > BUILD_SYS = "x86_64-linux"
> > NATIVELSBSTRING   = "Fedora-18"
> > TARGET_SYS= "arm-poky-linux-gnueabi"
> > MACHINE   = "zedboard"
> > DISTRO= "poky"
> > DISTRO_VERSION= "1.4+snapshot-20130921"
> > TUNE_FEATURES = " armv7a vfp neon zynq"
> > TARGET_FPU= "vfp-neon"
> > meta
> > meta-yocto= "(nobranch):3dee534f1e25109e0bdb681de0746c336f4b8840"
> > meta-xilinx
> > meta-kc705
> > meta-zc702
> > meta-zedboard = "master:46f4c79d6d55b556a90bb0fd89c2c09acf2aebff"
> > meta-yocto-bsp= "(nobranch):3dee534f1e25109e0bdb681de0746c336f4b8840"
> >
> > With the dora release I did a new clone of 
> > git://git.yoctoproject.org/meta-xilinx
> > now I do not see
> > meta-kc705
> > meta-zc702
> > meta-zedboard
> >
> > When I execute MACHINE=zedboard bitbake core-image-sato
> > ERROR:  OE-core's config sanity checker detected a potential 
> > misconfiguration.
> > Either fix the cause of this error or at your own risk disable the 
> > checker (see sanity.conf).
> > Following is the list of potential problems / advisories:
> >
> > Please set a valid MACHINE in your local.conf or environment
> >
> > ERROR: Execution of event handler 'check_sanity_eventhandler' failed
> > In my local.conf I have the following.
> >
> > MACHINE ?= "zedboard"
> >
> > bblayers.conf
> > # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
> > # changes incompatibly
> > LCONF_VERSION = "6"
> >
> > BBPATH = "${TOPDIR}"
> > BBFILES ?= ""
> >
> > BBLAYERS ?= " \
> >   /home/vidal/POKY/build101613_zedboard/poky/meta \
> >   /home/vidal/POKY/build101613_zedboard/poky/meta-yocto \
> >   /home/vidal/POKY/build101613_zedboard/poky/meta-xilinx \
> >   /home/vidal/POKY/build101613_zedboard/poky/meta-yocto-bsp \
> >   "
> > BBLAYERS_NON_REMOVABLE ?= " \
> >   /home/vidal/POKY/build101613_zedboard/poky/meta \
> >   /home/vidal/POKY/build101613_zedboard/poky/meta-yocto \
> >   "
> > Any help will be appreciated.
> > Regards
> 
> it seems like layer went thru some restructuring e.g. see
> commit d9617006376d73e37f1db17857ee06c24e6b7c03
> Author: Nathan Rossi 
> Date:   Fri Aug 2 12:41

[yocto] [meta-selinux][PATCH 2/5] Remove unnecessary RDEPENDS_${BPN}.

[Philip Tricca]

Now that the policycoreutuils package is empty no need for RDEPENDS.
Doing this in the commit that broke up the policycoreutuils package
made the diff hard to read. Figured it best to break it out for
readability.
---
 recipes-security/selinux/policycoreutils.inc |   16 
 1 file changed, 16 deletions(-)

diff --git a/recipes-security/selinux/policycoreutils.inc 
b/recipes-security/selinux/policycoreutils.inc
index e6ff4ed..05de7ac 100644
--- a/recipes-security/selinux/policycoreutils.inc
+++ b/recipes-security/selinux/policycoreutils.inc
@@ -22,22 +22,6 @@ DEPENDS += "${@['', '${EXTRA_DEPENDS}']['${PN}' != 
'${BPN}-native']}"
 inherit selinux
 DEPENDS += "${@target_selinux(d, 'libpam audit')}"
 
-RDEPENDS_${BPN} += "\
-   libselinux-python \
-   libsemanage-python \
-   sepolgen \
-   "
-RDEPENDS_${BPN} += "\
-   python \
-   python-unixadmin \
-   python-shell \
-   python-crypt \
-   python-subprocess \
-   python-syslog \
-   python-textutils \
-   python-ipy \
-   "
-
 RDEPENDS_${BPN}-audit2allow = " \
python-textutils \
libselinux-python \
-- 
1.7.10.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH 0/5] Resend: Remove python dependency from refpol.

[Philip Tricca]

This is a resend of an earlier patch set that never made it to the list
AFAIK.

The reference policy package currently pulls in a lot of python stuff
that isn't strictly necessary to boot an SELinux system and load a
policy. AFAIK this is caused by the mix of python and C utilities in
policycoreutils.

This patch set breaks the policycoreutils recipe up into multiple
packages, one for each utility. In this way we can have the refpol etc
pull in only the utilities necessary for normal operation. This happens
to be only the utilities written in C and thus we can remove python
completely in a minimal image.

I've attempted to localize these changes as much as possible so this
patch set should have minimal impact on recipes outside of the
policycoreutils. An example image reicpe is added to demonstrate a
minimal image with only the utilities required to load a policy and
manipulate the policy store (add / remove policy modules) at runtime.

Regards,
- Philip

Philip Tricca (5):
 Break policycoreutils out into separate
 Remove unnecessary RDEPENDS_${BPN}.
 Remove runtime dependency on
 Add packagegroup and image recipe for
 Add packagegroup for policycoreutils

 .../images/core-image-selinux-minimal.bb   |   15 ++
 .../packagegroups/packagegroup-core-selinux.bb |4 +-
 .../packagegroups/packagegroup-selinux-minimal.bb  |   26 +++
 .../packagegroup-selinux-policycoreutils.bb|   36 
 recipes-security/refpolicy/refpolicy_common.inc|2 +-
 recipes-security/selinux/policycoreutils.inc   |  179 +--
 6 files changed, 245 insertions(+), 17 deletions(-)

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH 3/5] Remove runtime dependency on policycoreutils from the reference policy.

[Philip Tricca]

The only thing refpol needs to depend on at runtime are the things
necessary to load the policy.  If sysvinit is patched to load the
policy (which it is) then we only need the config.
---
 recipes-security/refpolicy/refpolicy_common.inc |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-security/refpolicy/refpolicy_common.inc 
b/recipes-security/refpolicy/refpolicy_common.inc
index 3eaf16d..873d887 100644
--- a/recipes-security/refpolicy/refpolicy_common.inc
+++ b/recipes-security/refpolicy/refpolicy_common.inc
@@ -16,7 +16,7 @@ FILES_${PN} = "${sysconfdir}/selinux/${POLICY_NAME}/ \
 FILES_${PN}-dev =+ "${datadir}/selinux/${POLICY_NAME}/include/"
 
 DEPENDS += "checkpolicy-native policycoreutils-native m4-native"
-RDEPENDS_${PN} += "policycoreutils selinux-config"
+RDEPENDS_${PN} += "selinux-config"
 
 PACKAGE_ARCH = "${MACHINE_ARCH}"
 
-- 
1.7.10.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH 1/5] Break policycoreutils out into separate packages for the various utilities.

[Philip Tricca]

The driver beind this is to allow images to be built with the minimal
tools necessary to load a policy.  Breaking all of the stuff that's
dependent on python out from the core utils allows us to make much
smaller images.
---
 recipes-security/selinux/policycoreutils.inc |  181 +-
 1 file changed, 175 insertions(+), 6 deletions(-)

diff --git a/recipes-security/selinux/policycoreutils.inc 
b/recipes-security/selinux/policycoreutils.inc
index dfd65e3..e6ff4ed 100644
--- a/recipes-security/selinux/policycoreutils.inc
+++ b/recipes-security/selinux/policycoreutils.inc
@@ -38,6 +38,92 @@ RDEPENDS_${BPN} += "\
python-ipy \
"
 
+RDEPENDS_${BPN}-audit2allow = " \
+   python-textutils \
+   libselinux-python \
+   sepolgen \
+   "
+RDEPENDS_${BPN}-chcat = " \
+   python-codecs \
+   python-shell \
+   python-stringold \
+   python-unixadmin \
+   ${BPN}-python \
+   libselinux-python \
+   "
+RDEPENDS_${BPN}-fixfiles += "\
+   ${BPN}-setfiles \
+   "
+RDEPENDS_${BPN}-genhomedircon += "\
+   ${BPN}-genhomedircon \
+   ${BPN}-semodule \
+   "
+RDEPENDS_${BPN}-loadpolicy += "\
+   libselinux \
+   libsepol \
+   "
+RDEPENDS_${BPN}-newrole += "\
+   libcap-ng \
+   libselinux \
+   "
+RDEPENDS_${BPN}-python += "\
+   python-codecs \
+   python-io \
+   python-ipy \
+   python-re \
+   python-stringold \
+   python-syslog \
+   python-unixadmin \
+   libselinux-python \
+   libsemanage-python \
+   "
+RDEPENDS_${BPN}-runinit += "libselinux"
+RDEPENDS_${BPN}-sandbox += "\
+   python-math \
+   python-shell \
+   python-subprocess \
+   python-textutils \
+   python-unixadmin \
+   libselinux-python \
+   ${BPN}-python \
+   "
+RDEPENDS_${BPN}-secon += "libselinux"
+RDEPENDS_${BPN}-semanage = " \
+   python-core \
+   python-ipy \
+   ${BPN}-python \
+   libselinux-python \
+   "
+RDEPENDS_${BPN}-semodule += "\
+   libsepol \
+   libselinux \
+   libsemanage \
+   "
+# static link to libsepol
+DEPENDS_${BPN}-semodule-deps += "libsepol"
+RDEPENDS_${BPN}-semodule-expand += "libsepol libselinux"
+RDEPENDS_${BPN}-semodule-link += "libsepol libselinux"
+RDEPENDS_${BPN}-semodule-package += "libsepol libselinux"
+RDEPENDS_${BPN}-sepolicy += "\
+   python-argparse \
+   python-codecs \
+   python-core \
+   python-syslog \
+   ${BPN}-python \
+   "
+# static link to libsepol
+DEPENDS_${BPN}-sepolgen-ifgen += "libsepol"
+RDEPENDS_${BPN}-sepolgen-ifgen += "libselinux-python"
+RDEPENDS_${BPN}-sestatus += "libselinux"
+RDEPENDS_${BPN}-setfiles += "\
+   libselinux \
+   libsepol \
+   "
+RDEPENDS_${BPN}-setsebool += "\
+   libsepol \
+   libselinux \
+   libsemanage \
+   "
 RDEPENDS_${BPN} += "setools setools-libs ${BPN}-python"
 
 WARN_QA := "${@oe_filter_out('unsafe-references-in-scripts', '${WARN_QA}', d)}"
@@ -45,14 +131,97 @@ ERROR_QA := 
"${@oe_filter_out('unsafe-references-in-scripts', '${ERROR_QA}', d)}
 
 inherit pythonnative
 
-PACKAGES =+ "${PN}-python ${PN}-sandbox system-config-selinux"
-FILES_${PN}-python = 
"${libdir}/python${PYTHON_BASEVERSION}/site-packages/seobject.py* \
+PACKAGES =+ "\
+   ${PN}-audit2allow \
+   ${PN}-chcat \
+   ${PN}-fixfiles \
+   ${PN}-genhomedircon \
+   ${PN}-loadpolicy \
+   ${PN}-newrole \
+   ${PN}-python \
+   ${PN}-runinit \
+   ${PN}-sandbox \
+   ${PN}-secon \
+   ${PN}-semanage \
+   ${PN}-semodule \
+   ${PN}-semodule-deps \
+   ${PN}-semodule-expand \
+   ${PN}-semodule-link \
+   ${PN}-semodule-package \
+   ${PN}-sepolgen-ifgen \
+   ${PN}-sepolicy \
+   ${PN}-sestatus \
+   ${PN}-setfiles \
+   ${PN}-setsebool \
+   system-config-selinux \
+   "
+FILES_${PN}-audit2allow = " \
+   ${bindir}/audit2allow \
+   ${bindir}/audit2why \
+   "
+FILES_${PN}-chcat = " \
+   ${bindir}/chcat \
+   "
+FILES_${PN}-fixfiles += "${base_sbindir}/fixfiles"
+FILES_${PN}-genhomedircon += "${sbindir}/genhomedircon"
+FILES_${PN}-loadpolicy += "\
+   ${base_sbindir}/load_policy \
+   ${sbindir}/load_policy \
+   "
+FILES_${PN}-newrole += "\
+   ${bindir}/newrole \
+   ${@base_contains('DISTRO_FEATURES', 'pam', 
'${sysconfdir}/pam.d/newrole', '', d)} \
+   "
+FILES_${PN}-python = " \
+   ${libdir}/python${PYTHON_BASEVERSION}/site-packages/seobject.py* \
${libdir}/python${PYTHON_BASEVERSION}/site-packages/sepolicy*.egg-info \
-   ${libdir}/python${PYTHON_BASEVERSION}/site-packages/sepolicy/*"
+   ${libdir}/python${PYTHON_BASEVERSION}/site-packages/sepolicy/* \
+"
+FILES_${PN}-runinit += "\
+   ${sbindir}/run_init \
+   ${sbindir}/open_init_pty \
+   ${@base_contains('DISTRO_FEATURES', 'pam', 
'${sysconfdir}/pam.d/run_init', '', d)} \
+   "
 FIL

[yocto] [meta-selinux][PATCH 5/5] Add packagegroup for policycoreutils packages.

[Philip Tricca]

The policycoreutils package previously included most everything in
the base package. This packagegroup is intended to fill the role
of the old policycoreutils package and pull in all packages from the
policycoreutils recipe.
---
 .../packagegroups/packagegroup-core-selinux.bb |4 +--
 .../packagegroup-selinux-policycoreutils.bb|   36 
 2 files changed, 37 insertions(+), 3 deletions(-)
 create mode 100644 
recipes-security/packagegroups/packagegroup-selinux-policycoreutils.bb

diff --git a/recipes-security/packagegroups/packagegroup-core-selinux.bb 
b/recipes-security/packagegroups/packagegroup-core-selinux.bb
index 7cd7409..76863b0 100644
--- a/recipes-security/packagegroups/packagegroup-core-selinux.bb
+++ b/recipes-security/packagegroups/packagegroup-core-selinux.bb
@@ -19,9 +19,7 @@ RDEPENDS_${PN} = " \
libsemanage \
checkpolicy \
sepolgen \
-   policycoreutils \
-   policycoreutils-sandbox \
-   policycoreutils-python \
+   packagegroup-selinux-policycoreutils \
setools \
setools-console \
selinux-config \
diff --git 
a/recipes-security/packagegroups/packagegroup-selinux-policycoreutils.bb 
b/recipes-security/packagegroups/packagegroup-selinux-policycoreutils.bb
new file mode 100644
index 000..296a7e3
--- /dev/null
+++ b/recipes-security/packagegroups/packagegroup-selinux-policycoreutils.bb
@@ -0,0 +1,36 @@
+DESCRIPTION = "SELinux policycoreutils packagegroup"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = 
"file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
+
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+PR = "r0"
+
+PACKAGES = "\
+${PN} \
+"
+
+ALLOW_EMPTY_${PN} = "1"
+
+RDEPENDS_${PN} = " \
+   policycoreutils-audit2allow \
+   policycoreutils-chcat \
+   policycoreutils-fixfiles \
+   policycoreutils-genhomedircon \
+   policycoreutils-loadpolicy \
+   policycoreutils-newrole \
+   policycoreutils-python \
+   policycoreutils-runinit \
+   policycoreutils-sandbox \
+   policycoreutils-secon \
+   policycoreutils-semanage \
+   policycoreutils-semodule \
+   policycoreutils-semodule-deps \
+   policycoreutils-semodule-expand \
+   policycoreutils-semodule-link \
+   policycoreutils-semodule-package \
+   policycoreutils-sepolgen-ifgen \
+   policycoreutils-sepolicy \
+   policycoreutils-sestatus \
+   policycoreutils-setfiles \
+   policycoreutils-setsebool \
+   system-config-selinux \
+   "
-- 
1.7.10.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH 4/5] Add packagegroup and image recipe for minimal SELinux image.

[Philip Tricca]

This is intended to demonstrate the minimal set packages necessary
to boot and load a system with SELinux enabled. Specifically we
don't need any of the packages that depend on python.
---
 .../images/core-image-selinux-minimal.bb   |   15 +++
 .../packagegroups/packagegroup-selinux-minimal.bb  |   26 
 2 files changed, 41 insertions(+)
 create mode 100644 recipes-security/images/core-image-selinux-minimal.bb
 create mode 100644 
recipes-security/packagegroups/packagegroup-selinux-minimal.bb

diff --git a/recipes-security/images/core-image-selinux-minimal.bb 
b/recipes-security/images/core-image-selinux-minimal.bb
new file mode 100644
index 000..45cd847
--- /dev/null
+++ b/recipes-security/images/core-image-selinux-minimal.bb
@@ -0,0 +1,15 @@
+DESCRIPTION = "Minimal image with SELinux support (no python)"
+
+IMAGE_FEATURES += "splash ssh-server-openssh"
+
+LICENSE = "MIT"
+
+IMAGE_INSTALL = "\
+   ${CORE_IMAGE_BASE_INSTALL} \
+   bash \
+   util-linux-agetty \
+   packagegroup-core-boot \
+   packagegroup-selinux-minimal \
+"
+
+inherit core-image
diff --git a/recipes-security/packagegroups/packagegroup-selinux-minimal.bb 
b/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
new file mode 100644
index 000..16f6bae
--- /dev/null
+++ b/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
@@ -0,0 +1,26 @@
+DESCRIPTION = "SELinux packagegroup with only packages required for basic 
operations"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = 
"file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
+
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+PR = "r0"
+
+PACKAGES = "\
+   ${PN} \
+   "
+
+ALLOW_EMPTY_${PN} = "1"
+
+RDEPENDS_${PN} = " \
+   coreutils \
+   libsepol \
+   libselinux \
+   libselinux-bin \
+   libsemanage \
+   policycoreutils-fixfiles \
+   policycoreutils-secon \
+   policycoreutils-semodule \
+   policycoreutils-sestatus \
+   policycoreutils-setfiles \
+   selinux-config \
+   refpolicy-mls \
+   "
-- 
1.7.10.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Busybox configuration example?

[Nicolas Dechesne]

On Thu, Oct 17, 2013 at 3:50 PM, Gary Thomas  wrote:
> Can someone explain how I might control my busybox builds?
> For example, I routinely add this to busybox*.bbappend:
>
>   #
>   # Force 'ifup' to wait longer for really slow links...
>   #
>   do_prepare_config_append () {
> sed -i 's/CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-R
> -n"/CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-R -n -T 1 -t 20"/' ${S}/.config
>   }
>
> which is just editing the confguration file to match my preferences.
> Is there a way to do this using the "configuration fragments" mentioned
> above?

here is an example of busybox config fragment, that we use

https://git.linaro.org/gitweb?p=openembedded/meta-linaro.git;a=tree;f=meta-linaro/recipes-core/busybox;h=2c4a6b6b8b542b2eef04561d95a802d855ae7573;hb=master

i don't know if the config fragment would work for what you are
doing.. let us know ;-)
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-autobuilder][PATCH] buildsteps/CheckOutLayers: use a commit object for git rev-parse

[Flanagan, Elizabeth]

Stefan,

I'm pulling this patch, as this is part of our override of
parseGotRevision in buildbot/steps/source/git.py, but I'd also suggest
that this get suggested to the buildbot project for the original
parseGotRevision.

-b

On Thu, Oct 10, 2013 at 6:18 AM, Stefan Stanacar
 wrote:
> When the object passed to git rev-parse is a tag, we need to dereference
> the tag until a commit id is found or the object cannot be dereferenced
> anymore hence add ^0. (^0 is a short-hand for ^{commit})
>
> This avoids confusing tarballs like
> http://autobuilder.yoctoproject.org/pub/releases/dora-10.0.0/poky-319e24a8b1e100e950b07bbcad5fc81c42396845.tar.bz2
> which have the SHA-1 hash of the tag instead of the commit.
> It was first mentioned here
> https://lists.yoctoproject.org/pipermail/yocto/2013-October/018607.html
>
> Signed-off-by: Stefan Stanacar 
> ---
>  lib/python2.7/site-packages/autobuilder/buildsteps/CheckOutLayers.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git 
> a/lib/python2.7/site-packages/autobuilder/buildsteps/CheckOutLayers.py 
> b/lib/python2.7/site-packages/autobuilder/buildsteps/CheckOutLayers.py
> index f7b7d6e..46f9b25 100644
> --- a/lib/python2.7/site-packages/autobuilder/buildsteps/CheckOutLayers.py
> +++ b/lib/python2.7/site-packages/autobuilder/buildsteps/CheckOutLayers.py
> @@ -128,7 +128,7 @@ class CheckOutLayers(Git):
>
>  @defer.inlineCallbacks
>  def parseGotRevision(self, _=None):
> -stdout = yield self._dovccmd(['rev-parse', self.commit], 
> collectStdout=True)
> +stdout = yield self._dovccmd(['rev-parse', self.commit + "^0"], 
> collectStdout=True)
>  revision = stdout.strip()
>  if len(revision) != 40:
>  raise buildstep.BuildStepFailed()
> --
> 1.8.3.1
>



-- 
Elizabeth Flanagan
Yocto Project
Build and Release
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-autobuilder] [PATCH 1/1] README-NEW-AUTOBUILDER: Add to scheduler documentation

[Flanagan, Elizabeth]

Pulled into master. Thanks!

-b

On Mon, Oct 14, 2013 at 11:11 AM, Bryan Evenson  wrote:
> Adds detail on the Nightly scheduler properties that are
> available.  Notes default settings where appropriate and
> notes which values must be set by the user.
>
> Signed-off-by: Bryan Evenson 
> ---
>  README-NEW-AUTOBUILDER |   12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/README-NEW-AUTOBUILDER b/README-NEW-AUTOBUILDER
> index 27f892f..430e2a3 100644
> --- a/README-NEW-AUTOBUILDER
> +++ b/README-NEW-AUTOBUILDER
> @@ -145,10 +145,14 @@ scheduler: A list of dicts. Each item defines a 
> scheduler associated with this
> are type-specific:
>
>Nightly scheduler properties:
> -   month
> -   dayOfWeek
> -  hour
> -  minute
> +   month: The month in which to start the build, with January = 
> 1.
> +This defaults to '*', meaning every month.
> +   dayOfWeek: The day of the week in which to start the build, 
> with
> +Monday = 1.  This defaults to '*', meaning every day.
> +  hour: The hour of the day in which to start the build, with
> +12:00 AM = 0.  This must be set by the user.
> +  minute: The minute of the hour in which to start the build, 
> with
> +0 to 59 as valid values.  This must be set by the user.
>
>   SingleBranchScheduler properties:
> repository: the repository to attach the scheduler to; this
> --
> 1.7.9.5
>



-- 
Elizabeth Flanagan
Yocto Project
Build and Release
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] lxc/namespace: Clean up kernel configs

[Yang Shi]

Remove namespaces-experimental.cfg since USER_NS is not experimental anymore.

Add CONFIG_USER_NS into namespaces.cfg.

Add CONFIG_MACVLAN into lxc to avoid the below missing report from
lxc-checkconfig:
---
 meta/cfg/kernel-cache/features/lxc/lxc.cfg | 3 ++-
 .../kernel-cache/features/namespaces/namespaces-experimental.cfg   | 1 -
 meta/cfg/kernel-cache/features/namespaces/namespaces.cfg   | 2 +-
 meta/cfg/kernel-cache/features/namespaces/namespaces.scc   | 7 +--
 4 files changed, 4 insertions(+), 9 deletions(-)
 delete mode 100644 
meta/cfg/kernel-cache/features/namespaces/namespaces-experimental.cfg

diff --git a/meta/cfg/kernel-cache/features/lxc/lxc.cfg 
b/meta/cfg/kernel-cache/features/lxc/lxc.cfg
index dfd7847..740b800 100644
--- a/meta/cfg/kernel-cache/features/lxc/lxc.cfg
+++ b/meta/cfg/kernel-cache/features/lxc/lxc.cfg
@@ -1,4 +1,5 @@
 # Misc configs
 CONFIG_VETH=y
 CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
-CONFIG_MM_OWNER=y
\ No newline at end of file
+CONFIG_MM_OWNER=y
+CONFIG_MACVLAN=y
diff --git 
a/meta/cfg/kernel-cache/features/namespaces/namespaces-experimental.cfg 
b/meta/cfg/kernel-cache/features/namespaces/namespaces-experimental.cfg
deleted file mode 100644
index 416bd53..000
--- a/meta/cfg/kernel-cache/features/namespaces/namespaces-experimental.cfg
+++ /dev/null
@@ -1 +0,0 @@
-CONFIG_USER_NS=y
diff --git a/meta/cfg/kernel-cache/features/namespaces/namespaces.cfg 
b/meta/cfg/kernel-cache/features/namespaces/namespaces.cfg
index 6e850fe..6254019 100644
--- a/meta/cfg/kernel-cache/features/namespaces/namespaces.cfg
+++ b/meta/cfg/kernel-cache/features/namespaces/namespaces.cfg
@@ -1,6 +1,6 @@
 CONFIG_NAMESPACES=y
 CONFIG_UTS_NS=y
 CONFIG_IPC_NS=y
-
+CONFIG_USER_NS=y
 CONFIG_PID_NS=y
 CONFIG_NET_NS=y
diff --git a/meta/cfg/kernel-cache/features/namespaces/namespaces.scc 
b/meta/cfg/kernel-cache/features/namespaces/namespaces.scc
index 1328400..ea23151 100644
--- a/meta/cfg/kernel-cache/features/namespaces/namespaces.scc
+++ b/meta/cfg/kernel-cache/features/namespaces/namespaces.scc
@@ -1,9 +1,4 @@
-define KFEATURE_DESCRIPTION "Enable namespace support + experimental 
namespaces"
+define KFEATURE_DESCRIPTION "Enable namespace support"
 define KFEATURE_COMPATIBILITY all
 
-define EXPERIMENTAL 1
-
 kconf non-hardware namespaces.cfg
-if [ -n "EXPERIMENTAL" ]; then
-kconf non-hardware namespaces-experimental.cfg
-fi
-- 
1.8.3.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] perf: fix bench numa compilation

[Yang Shi]

From: Riccardo Magliocchetti 

Taken from: https://lkml.org/lkml/2013/6/20/80

Fix the following errors on gcc 4.8.1 / x86:

bench/numa.c: In function worker_thread:
bench/numa.c:1113:20: error: comparison between signed and unsigned integer 
expressions [-Werror=sign-compare]
if (diff.tv_sec >= g->p.nr_secs) {
^
bench/numa.c:1161:6: error: format %lx expects argument of type long unsigned 
int, but argument 5 has type u64 [-Werror=format=]
  process_nr, thread_nr, runtime_ns_max / bytes_done, val);
  ^
Signed-off-by: Riccardo Magliocchetti 
Signed-off-by: Yang Shi 
---
 tools/perf/bench/numa.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/perf/bench/numa.c b/tools/perf/bench/numa.c
index 30d1c32..f5c0834 100644
--- a/tools/perf/bench/numa.c
+++ b/tools/perf/bench/numa.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1110,7 +,7 @@ static void *worker_thread(void *__tdata)
/* Check whether our max runtime timed out: */
if (g->p.nr_secs) {
timersub(&stop, &start0, &diff);
-   if (diff.tv_sec >= g->p.nr_secs) {
+   if (diff.tv_sec >= (long int)g->p.nr_secs) {
g->stop_work = true;
break;
}
@@ -1157,7 +1158,7 @@ static void *worker_thread(void *__tdata)
runtime_ns_max += diff.tv_usec * 1000;
 
if (details >= 0) {
-   printf(" #%2d / %2d: %14.2lf nsecs/op [val: 
%016lx]\n",
+   printf(" #%2d / %2d: %14.2lf nsecs/op [val: 
%016"PRIu64"x]\n",
process_nr, thread_nr, runtime_ns_max / 
bytes_done, val);
}
fflush(stdout);
-- 
1.8.3.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] how to enable the LTP in core-image-basic

[Amit Kumar]

Hi,
   I wants to use the LTP test suite provided by yocto project. But I 
don't know how to enable it for "core-image-basic".
Can anyone help me to enable the LTP in "core-image-basic"?


Thanks & Regards
Amit K


The contents of this e-mail and any attachment(s) may contain confidential or 
privileged information for the intended recipient(s). Unintended recipients are 
prohibited from taking action on the basis of information in this e-mail and 
using or disseminating the information, and must notify the sender and delete 
it from their system. L&T Infotech will not accept responsibility or liability 
for the accuracy or completeness of, or the presence of any virus or disabling 
code in this e-mail"
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Custom defconfig is not used

[Bruce Ashfield]

On 13-10-17 11:47 AM, Diego Sueiro wrote:


2013/10/17 Bruce Ashfield mailto:bruce.ashfi...@windriver.com>>

Look at oe-core/meta-skeleton for the custom kernel recipe example.
It has the inherit/include combinations that you need to follow.


My concern is: if doing this to just have the config fragment
feature,
I'll possibly mess up the kernel build.


It shouldn't. It only adds to existing phases, and doesn't make
any changes. I've tested it in many combinations and it should
work fine.

If something breaks, I'd like to know, so we can fix it.


Bruce,

I didn't change linux-mainline_3.8.bb .
My linux-mainline_3.8.bbappend is:

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:"
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
COMPATIBLE_MACHINE_beaglebone = "(beaglebone)"
SRC_URI += " file://mine.patch \
  file://config-addons.cfg \
  "

My config-addons.cfg:

CONFIG_WATCHDOG_NOWAYOUT=y
CONFIG_NTFS_FS=y
CONFIG_NTFS_RW=y

After a cleansstate the build got stucked on do_patch task.
Here is the content of log.do_patch:

DEBUG: Executing shell function do_patch
WARNING: no meta data branch found ...
Switched to branch 'linux-3.8.y'


I fell behind today .. i had 2300 unread email to start this morning :)
Is there a way that I can get a copy of your recipes and layers ? If
I can do a build myself, I can easily debug and fix this .. otherwise, we'll
go back and forth many times debugging.

Cheers,

Bruce




Running with bitbake -v I got the following:

...
+ configme --reconfig --output

<...>/build/tmp-angstrom_v2013_06-eglibc/work/beaglebone-angstrom-linux-gnueabi/linux-mainline/3.8.13-r23a/linux-beaglebone-standard-build
standard beaglebone
[INFO] Configuring target/machine combo: "standard/beaglebone"

[INFO] Configuring target/machine combo: "standard/beaglebone"
[INFO] collecting configs in ./meta/meta-series

[INFO] collecting configs in ./meta/meta-series
cat: meta/cfg/standard/beaglebone/config_frag.txt: No such file or
directory

cat: meta/cfg/standard/beaglebone/config_frag.txt: No such file or
directory
cat: meta/cfg/standard/beaglebone/config_frag.txt: No such file or
directory

cat: meta/cfg/standard/beaglebone/config_frag.txt: No such file or
directory
mv: target `3.8.13' is not a directory

mv: target `3.8.13' is not a directory
creation of pre-processed config data failed
config of "standard/beaglebone" failed

creation of pre-processed config data failed
config of "standard/beaglebone" failed
ERROR: Function failed: do_kernel_configme (see

<...>/build/tmp-angstrom_v2013_06-eglibc/work/beaglebone-angstrom-linux-gnueabi/linux-mainline/3.8.13-r23a/temp/log.do_kernel_configme15450.
for further information)
ERROR: Task 7

(<...>/setup-scripts/sources/meta-beagleboard/common-bsp/recipes-kernel/linux/linux-mainline_3.8.bb
, do_kernel_configme) failed with exit
code '1'





Regards,

--
*dS
Diego Sueiro

/*long live rock 'n roll*/


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Add kernel path in *.bb file and Arm based board BSP

[DineshKumar Varadarajan]

Hi  All,


I want to create a New BSP for ARM CorteXA9 based board . I have 
downloaded the poky 9.0.2 and create the new BSP with the following commands as 
mentioned in the Manual.


   "yocto-bsp create myarm arm" command and selected the 
"linux-Yocto_3.4" as my kernel.I have modified the bblayeres

LCONF_VERSION = "6"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
/home/murali/src/dinesh/yocto/poky/meta \

/home/murali/src/dinesh/yocto/poky/meta-yocto \

/home/murali/src/dinesh/yocto/poky/meta-yocto-bsp \

/home/murali/src/dinesh/yocto/poky/meta-myarm \
"
BBLAYERS_NON_REMOVABLE ?= " \

/home/murali/src/dinesh/yocto/poky/meta \

/home/murali/src/dinesh/yocto/poky/meta-yocto \
"


   1. my question is where i hAve to add the kernel PATH (git path) in 
SRC_URI.

Whether i have add inside the  
mete-myarm/kernel_recipes/linux/linux-yocto_3.4.bbappend. or some where else.


  2. when i entered the "bitbake core-image-minimal" command its start 
executing tasks , but after some time ,its try to "do_fetch" the 
linux-yocto_3.8.git kernel as per the *.bb in the below path

"/home/murali/src/dinesh/yocto/poky/meta/recipes-kernel/linux_3.8.bb"


  My question is why 3.8 kernel is doing "do_fetch" , my aim is build 
the 3.4 kernel for my board.


  can some one help me out ?? or point some examples


Regards,
Dinesh kumar.v














The contents of this e-mail and any attachment(s) may contain confidential or 
privileged information for the intended recipient(s). Unintended recipients are 
prohibited from taking action on the basis of information in this e-mail and 
using or disseminating the information, and must notify the sender and delete 
it from their system. L&T Infotech will not accept responsibility or liability 
for the accuracy or completeness of, or the presence of any virus or disabling 
code in this e-mail"
*
 This email and attachments have been scanned for
 potential proprietary or sensitive information leakage.
 Websense Data Security, Protecting Your Information from the Inside Out.
 www.websense.com
 *
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto