date:20170110

Re: [yocto] [bitbake] OECORE_TARGET_SYSROOT and OECORE_NATIVE_SYSROOT variables not availables ?

2017-01-10 Thread Karim ATIKI

Khem,


Ok.

How are they specified using Yocto build system ?

Is there any doc link ?



K.


De : Khem Raj 
Envoyé : mardi 10 janvier 2017 20:39
À : Karim ATIKI; yocto
Objet : Re: [yocto] [bitbake] OECORE_TARGET_SYSROOT and OECORE_NATIVE_SYSROOT 
variables not availables ?

These are specified differently when using the Yocto build system you should 
not be using these variables in your makefiles
On Tue, Jan 10, 2017 at 8:11 AM Karim ATIKI 
> wrote:















Hi,








I'm using generated Poky SDK to cross-compile our program source-codes, which 
works fine.








Now I wish to integrate the build of the project into Yocto recipes using our 
makefiles.








However, some custom parameters in the makefiles are using the variables 
OECORE_TARGET_SYSROOT  and OECORE_NATIVE_SYSROOT to manage paths.




But it appears that these 2 variables do not exists when the makefiles are 
called in a do_compile() function of a recipe.








Is it normal ? Did I did something wrong ?



Should my recipe inherit something specific?








Or should I "source" my 
"environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi" from the SDK into my 
recipe file ? (=> not portable)








Thanks.








Z.



























--

___

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] [meta-selinux][PATCH 0/2] uprev refpolicy to 2.20161023

2017-01-10 Thread wenzong fan


On 01/10/2017 10:25 PM, Joe MacDonald wrote:

[[yocto] [meta-selinux][PATCH 0/2] uprev refpolicy to 2.20161023] On 17.01.10 
(Tue 00:54) wenzong@windriver.com wrote:


From: Wenzong Fan 

Uprev refpolicy to 2.20161023 and fix build errors for refpolicy-minimum.

The following changes since commit bae51859f0dbcdde9fd563d15128a6dbbb816801:

  audit: upgrade 2.6.6 -> 2.7 (2017-01-09 08:59:55 -0500)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib wenzong/refpolicy-2.20161023
  
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/refpolicy-2.20161023


As poky-contrib is full of unrelated stuff, it's not the right place to
be doing meta-selinux work AFAICT.  I'd rather you actually just
fork meta-selinux somewhere like github if you plan to send pull
requests.  Patches are fine, of course, they're even easier for me to
work with.


Oko< I didn't notice that before, I'll fork it on github for my pull 
requests later.


Thanks
Wenzong



-J.



Wenzong Fan (2):
  refpolicy: uprev 2.20151208 -> 2.20161023
  refpolicy-minimum: update patch file

 .../ftp-add-ftpd_t-to-mlsfilewrite.patch | 0
 .../poky-fc-clock.patch  | 0
 .../poky-fc-corecommands.patch   | 0
 .../poky-fc-dmesg.patch  | 0
 .../poky-fc-fix-bind.patch   | 0
 .../poky-fc-fix-real-path_login.patch| 0
 .../poky-fc-fix-real-path_resolv.conf.patch  | 0
 .../poky-fc-fix-real-path_shadow.patch   | 0
 .../poky-fc-fix-real-path_su.patch   | 0
 .../poky-fc-fstools.patch| 0
 .../poky-fc-ftpwho-dir.patch | 0
 .../poky-fc-iptables.patch   | 0
 .../poky-fc-mta.patch| 0
 .../poky-fc-netutils.patch   | 0
 .../poky-fc-nscd.patch   | 0
 .../poky-fc-rpm.patch| 0
 .../poky-fc-screen.patch | 0
 .../poky-fc-ssh.patch| 0
 .../poky-fc-su.patch | 0
 .../poky-fc-subs_dist.patch  | 0
 .../poky-fc-sysnetwork.patch | 0
 .../poky-fc-udevd.patch  | 0
 .../poky-fc-update-alternatives_hostname.patch   | 0
 .../poky-fc-update-alternatives_sysklogd.patch   | 0
 .../poky-fc-update-alternatives_sysvinit.patch   | 0
 .../poky-policy-add-rules-for-bsdpty_device_t.patch  | 0
 .../poky-policy-add-rules-for-syslogd_t-symlink.patch| 0
 .../poky-policy-add-rules-for-tmp-symlink.patch  | 0
 .../poky-policy-add-rules-for-var-cache-symlink.patch| 0
 .../poky-policy-add-rules-for-var-log-symlink-apache.patch   | 0
 ...ky-policy-add-rules-for-var-log-symlink-audisp_remote_t.patch | 0
 .../poky-policy-add-rules-for-var-log-symlink.patch  | 0
 .../poky-policy-add-syslogd_t-to-trusted-object.patch| 0
 .../poky-policy-allow-nfsd-to-exec-shell-commands.patch  | 0
 .../poky-policy-allow-setfiles_t-to-read-symlinks.patch  | 0
 .../poky-policy-allow-sysadm-to-run-rpcinfo.patch| 0
 .../poky-policy-don-t-audit-tty_device_t.patch   | 0
 .../poky-policy-fix-dmesg-to-use-dev-kmsg.patch  | 0
 .../poky-policy-fix-new-SELINUXMNT-in-sys.patch  | 0
 .../poky-policy-fix-nfsd_t-to-mount_nfsd_fs_t.patch  | 0
 .../poky-policy-fix-setfiles-statvfs-get-file-count.patch| 0
 .../poky-policy-fix-seutils-manage-config-files.patch| 0
 .../refpolicy-update-for_systemd.patch   | 0
 .../{refpolicy-mcs_2.20151208.bb => refpolicy-mcs_2.20161023.bb} | 0
 ...07-refpolicy-minimum-systemd-fix-for-login-journal-serv.patch | 9 ++---
 ...icy-minimum_2.20151208.bb => refpolicy-minimum_2.20161023.bb} | 0
 .../{refpolicy-mls_2.20151208.bb => refpolicy-mls_2.20161023.bb} | 0
 ...y-standard_2.20151208.bb => refpolicy-standard_2.20161023.bb} | 0
 ...y-targeted_2.20151208.bb => refpolicy-targeted_2.20161023.bb} | 0
 .../{refpolicy_2.20151208.inc => refpolicy_2.20161023.inc}   | 8 
 50 files changed, 10 insertions(+), 7 deletions(-)
 rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
refpolicy-2.20161023}/ftp-add-ftpd_t-to-mlsfilewrite.patch (100%)
 rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
refpolicy-2.20161023}/poky-fc-clock.patch (100%)
 rename recipes-security/refpolicy/{refpolicy-2.20151208 =>

Re: [yocto] kernel config fragments not applied

2017-01-10 Thread Bruce Ashfield


On 2017-01-10 4:27 PM, Bruce Ashfield wrote:

On 2017-01-10 4:20 PM, Bruce Ashfield wrote:

On 2017-01-10 4:13 PM, Schmitt, Richard wrote:



-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, January 10, 2017 2:58 PM
To: Schmitt, Richard ;
yocto@yoctoproject.org
Subject: Re: [yocto] kernel config fragments not applied

On 2017-01-10 1:05 PM, Schmitt, Richard wrote:

I am having a heck of a hard time getting a minor kernel config
fragment applied.



In order to minimize all variables, I am simply trying to build
linux-yocto for a qemux86 MACHINE target.





What release ? Everything is working here, but I can switch to
whatever release you are using and run the test there (I'm using
master).


I'm using krogoth.  I'll try a build based on master and see if it's
release specific.


Thanks. I'm also spinning up a krogoth build .. you never know if
something crept in. krogoth is before my audit code was visible, so
hints as to why it failed likely aren't visible.


Well I'll be  different behaviour with krogoth. I just updated it
and some patches came in from what I had been using before. It could
be something that merged recently.

Anyway, leave this with me. I'll debug it tonight and spin a fix.


I take that back.

My first build was tainted with old sstate and didn't actually do
anything. Now that I'm building with a clean slate on krogoth, I
can create a local layer, add a linux-yocto_4.4.bbappend and add a
overlay.cfg to enable CONFIG_OVERLAYFS.

Is it possible that you could tar up your test layer and send it with
me, so I can try it directly ?

Bruce



Bruce




Bruce




Bruce



There had been some discussion on the mailing list previously that
suggested making sure linux-yocto.inc was included within the recipes.
The ones being used are standard poky recipes and they do include the
linux-yocto.inc file.

My configuration is very simple.  I have my own layer and linux-yocto
bbappend:

meta-mylayer/recipes-kernel/linux/linux-yocto_4.4.bbappend

Whose contents are:


FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"


SRC_URI += " \
file://overlayfs.cfg \
"

With the config fragment in:

meta-mylayer/recipes-kernel/linux/linux-yocto/overlayfs.cfg

whose contents is:

CONFIG_OVERLAY_FS=y

If I do a "bitbake linux-yocto" I would expect it to generate a config
file that includes CONFIG_OVERLAY_FS=y and a kernel that includes this
filesystem.  I don't.

My layer is parsed correctly and the bbappend is found and parsed.  I
know this because in the tmp directory:

tmp/work/qemux86-poky-linux/linux-yocto/4.4.26+gitAUTOINC+3030330b06_c
a6a08bd7f-r0/

the file overlayfs.cfg exists.

Searching the log files, the only one that references this file though
is log.do_unpack.  I do not see any reference to it in
log.do_kernel_configme or log.do_configure.I'm not sure how kernel
fragments are applied, but looking through the classes and recipes for
linux-yocto in poky/meta, I do not see any code that would apply
kernel fragments.  So I'm not sure if I'm missing some piece.

Searching through the files in poky/meta, I find meta-config.sh only
in recipes-core/uclibc and recipes-core/busybox.  That's why I think
I'm missing something.

I'm using the krogoth branch of poky.

What am I missing?

Thanks,
Rich








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

Re: [yocto] kernel config fragments not applied

2017-01-10 Thread Bruce Ashfield


On 2017-01-10 4:20 PM, Bruce Ashfield wrote:

On 2017-01-10 4:13 PM, Schmitt, Richard wrote:



-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, January 10, 2017 2:58 PM
To: Schmitt, Richard ;
yocto@yoctoproject.org
Subject: Re: [yocto] kernel config fragments not applied

On 2017-01-10 1:05 PM, Schmitt, Richard wrote:

I am having a heck of a hard time getting a minor kernel config
fragment applied.



In order to minimize all variables, I am simply trying to build
linux-yocto for a qemux86 MACHINE target.





What release ? Everything is working here, but I can switch to
whatever release you are using and run the test there (I'm using
master).


I'm using krogoth.  I'll try a build based on master and see if it's
release specific.


Thanks. I'm also spinning up a krogoth build .. you never know if
something crept in. krogoth is before my audit code was visible, so
hints as to why it failed likely aren't visible.


Well I'll be  different behaviour with krogoth. I just updated it
and some patches came in from what I had been using before. It could
be something that merged recently.

Anyway, leave this with me. I'll debug it tonight and spin a fix.

Bruce




Bruce




Bruce



There had been some discussion on the mailing list previously that
suggested making sure linux-yocto.inc was included within the recipes.
The ones being used are standard poky recipes and they do include the
linux-yocto.inc file.

My configuration is very simple.  I have my own layer and linux-yocto
bbappend:

meta-mylayer/recipes-kernel/linux/linux-yocto_4.4.bbappend

Whose contents are:


FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"


SRC_URI += " \
file://overlayfs.cfg \
"

With the config fragment in:

meta-mylayer/recipes-kernel/linux/linux-yocto/overlayfs.cfg

whose contents is:

CONFIG_OVERLAY_FS=y

If I do a "bitbake linux-yocto" I would expect it to generate a config
file that includes CONFIG_OVERLAY_FS=y and a kernel that includes this
filesystem.  I don't.

My layer is parsed correctly and the bbappend is found and parsed.  I
know this because in the tmp directory:

tmp/work/qemux86-poky-linux/linux-yocto/4.4.26+gitAUTOINC+3030330b06_c
a6a08bd7f-r0/

the file overlayfs.cfg exists.

Searching the log files, the only one that references this file though
is log.do_unpack.  I do not see any reference to it in
log.do_kernel_configme or log.do_configure.I'm not sure how kernel
fragments are applied, but looking through the classes and recipes for
linux-yocto in poky/meta, I do not see any code that would apply
kernel fragments.  So I'm not sure if I'm missing some piece.

Searching through the files in poky/meta, I find meta-config.sh only
in recipes-core/uclibc and recipes-core/busybox.  That's why I think
I'm missing something.

I'm using the krogoth branch of poky.

What am I missing?

Thanks,
Rich






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

Re: [yocto] kernel config fragments not applied

2017-01-10 Thread Bruce Ashfield

On 2017-01-10 4:13 PM, Schmitt, Richard wrote:

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, January 10, 2017 2:58 PM
To: Schmitt, Richard ; yocto@yoctoproject.org
Subject: Re: [yocto] kernel config fragments not applied

On 2017-01-10 1:05 PM, Schmitt, Richard wrote:

I am having a heck of a hard time getting a minor kernel config
fragment applied.

In order to minimize all variables, I am simply trying to build
linux-yocto for a qemux86 MACHINE target.

What release ? Everything is working here, but I can switch to whatever release 
you are using and run the test there (I'm using master).

I'm using krogoth.  I'll try a build based on master and see if it's release 
specific.

Thanks. I'm also spinning up a krogoth build .. you never know if
something crept in. krogoth is before my audit code was visible, so
hints as to why it failed likely aren't visible.

Bruce

Bruce

There had been some discussion on the mailing list previously that
suggested making sure linux-yocto.inc was included within the recipes.
The ones being used are standard poky recipes and they do include the
linux-yocto.inc file.

My configuration is very simple.  I have my own layer and linux-yocto
bbappend:

meta-mylayer/recipes-kernel/linux/linux-yocto_4.4.bbappend

Whose contents are:

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI += " \
file://overlayfs.cfg \
"

With the config fragment in:

meta-mylayer/recipes-kernel/linux/linux-yocto/overlayfs.cfg

whose contents is:

CONFIG_OVERLAY_FS=y

If I do a "bitbake linux-yocto" I would expect it to generate a config
file that includes CONFIG_OVERLAY_FS=y and a kernel that includes this
filesystem.  I don't.

My layer is parsed correctly and the bbappend is found and parsed.  I
know this because in the tmp directory:

tmp/work/qemux86-poky-linux/linux-yocto/4.4.26+gitAUTOINC+3030330b06_c
a6a08bd7f-r0/

the file overlayfs.cfg exists.

Searching the log files, the only one that references this file though
is log.do_unpack.  I do not see any reference to it in
log.do_kernel_configme or log.do_configure.I'm not sure how kernel
fragments are applied, but looking through the classes and recipes for
linux-yocto in poky/meta, I do not see any code that would apply
kernel fragments.  So I'm not sure if I'm missing some piece.

Searching through the files in poky/meta, I find meta-config.sh only
in recipes-core/uclibc and recipes-core/busybox.  That's why I think
I'm missing something.

I'm using the krogoth branch of poky.

What am I missing?

Thanks,
Rich

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

Re: [yocto] kernel config fragments not applied

2017-01-10 Thread Schmitt, Richard



-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] 
Sent: Tuesday, January 10, 2017 2:58 PM
To: Schmitt, Richard ; yocto@yoctoproject.org
Subject: Re: [yocto] kernel config fragments not applied

On 2017-01-10 1:05 PM, Schmitt, Richard wrote:
>> I am having a heck of a hard time getting a minor kernel config 
>> fragment applied.
>>
>>
>>
>> In order to minimize all variables, I am simply trying to build 
>> linux-yocto for a qemux86 MACHINE target.
>>
>>
>>
>
> What release ? Everything is working here, but I can switch to whatever 
> release you are using and run the test there (I'm using master).

I'm using krogoth.  I'll try a build based on master and see if it's release 
specific.

> Bruce

>> There had been some discussion on the mailing list previously that 
>> suggested making sure linux-yocto.inc was included within the recipes.
>> The ones being used are standard poky recipes and they do include the 
>> linux-yocto.inc file.
>>
>> My configuration is very simple.  I have my own layer and linux-yocto
>> bbappend:
>>
>> meta-mylayer/recipes-kernel/linux/linux-yocto_4.4.bbappend
>>
>> Whose contents are:
>>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>
>> SRC_URI += " \
>> file://overlayfs.cfg \
>> "
>>
>> With the config fragment in:
>>
>>meta-mylayer/recipes-kernel/linux/linux-yocto/overlayfs.cfg
>>
>> whose contents is:
>>
>> CONFIG_OVERLAY_FS=y
>>
>> If I do a "bitbake linux-yocto" I would expect it to generate a config 
>> file that includes CONFIG_OVERLAY_FS=y and a kernel that includes this 
>> filesystem.  I don't.
>>
>> My layer is parsed correctly and the bbappend is found and parsed.  I 
>> know this because in the tmp directory:
>>
>> tmp/work/qemux86-poky-linux/linux-yocto/4.4.26+gitAUTOINC+3030330b06_c
>> a6a08bd7f-r0/
>>
>> the file overlayfs.cfg exists.
>>
>> Searching the log files, the only one that references this file though 
>> is log.do_unpack.  I do not see any reference to it in
>> log.do_kernel_configme or log.do_configure.I'm not sure how kernel
>> fragments are applied, but looking through the classes and recipes for 
>> linux-yocto in poky/meta, I do not see any code that would apply 
>> kernel fragments.  So I'm not sure if I'm missing some piece.
>>
>> Searching through the files in poky/meta, I find meta-config.sh only 
>> in recipes-core/uclibc and recipes-core/busybox.  That's why I think 
>> I'm missing something.
>>
>> I'm using the krogoth branch of poky.
>>
>> What am I missing?
>>
>> Thanks,
>> Rich

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

Re: [yocto] kernel config fragments not applied

2017-01-10 Thread Bruce Ashfield


On 2017-01-10 1:05 PM, Schmitt, Richard wrote:

I am having a heck of a hard time getting a minor kernel config fragment
applied.



In order to minimize all variables, I am simply trying to build
linux-yocto for a qemux86 MACHINE target.





What release ? Everything is working here, but I can switch to
whatever release you are using and run the test there (I'm using
master).

Bruce


There had been some discussion on the mailing list previously that
suggested making sure linux-yocto.inc was included within the recipes.
The ones being used are standard poky recipes and they do include the
linux-yocto.inc file.



My configuration is very simple.  I have my own layer and linux-yocto
bbappend:



meta-mylayer/recipes-kernel/linux/linux-yocto_4.4.bbappend



Whose contents are:



FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"



SRC_URI += " \

file://overlayfs.cfg \

"



With the config fragment in:



meta-mylayer/recipes-kernel/linux/linux-yocto/overlayfs.cfg



whose contents is:



CONFIG_OVERLAY_FS=y



If I do a “bitbake linux-yocto” I would expect it to generate a config
file that includes CONFIG_OVERLAY_FS=y and a kernel that includes this
filesystem.  I don’t.



My layer is parsed correctly and the bbappend is found and parsed.  I
know this because in the tmp directory:



tmp/work/qemux86-poky-linux/linux-yocto/4.4.26+gitAUTOINC+3030330b06_ca6a08bd7f-r0/



the file overlayfs.cfg exists.



Searching the log files, the only one that references this file though
is log.do_unpack.  I do not see any reference to it in
log.do_kernel_configme or log.do_configure.I’m not sure how kernel
fragments are applied, but looking through the classes and recipes for
linux-yocto in poky/meta, I do not see any code that would apply kernel
fragments.  So I’m not sure if I’m missing some piece.



Searching through the files in poky/meta, I find meta-config.sh only in
recipes-core/uclibc and recipes-core/busybox.  That’s why I think I’m
missing something.



I’m using the krogoth branch of poky.



What am I missing?



Thanks,

Rich









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

Re: [yocto] how does one stay on top of YP security alerts?

2017-01-10 Thread Paul Eggleton

On Tue, 10 Jan 2017 10:37:48 Bent Bisballe Nyeng wrote:
> I found the list initially through this page:
> https://wiki.yoctoproject.org/wiki/Security where it is described as the
> security [at] yoctoprojct [dot] org being the discussion list and the yocto
> [dash] security [at] yoctoproject[dot] org being the security announcement
> list.

That's not what it says. What it does say is that yocto-security@ list is for 
discussions about security patches, and security@ is for private notification 
about security issues *to* several nominated individuals. There isn't an 
announcement list I'm afraid.

> If the yocto [dash] security [at] yoctoproject[dot] org is in fact no longer
> active I think it is important that the wiki page is changed to reflect
> that to prevent potential dangerous misunderstandings in the future.

I'm not sure how you came to the conclusions you did - do you have any 
suggestions on rewording?

I will say that the yocto-security@ list has been pretty quiet since it was 
set up. Adding a few people on CC - are there any plans to make better use of 
this list?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [bitbake] OECORE_TARGET_SYSROOT and OECORE_NATIVE_SYSROOT variables not availables ?

2017-01-10 Thread Khem Raj

These are specified differently when using the Yocto build system you
should not be using these variables in your makefiles
On Tue, Jan 10, 2017 at 8:11 AM Karim ATIKI  wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi,
>
>
>
>
>
>
>
> I'm using generated Poky SDK to cross-compile our program source-codes,
> which works fine.
>
>
>
>
>
>
>
> Now I wish to integrate the build of the project into Yocto recipes using
> our makefiles.
>
>
>
>
>
>
>
> However, some custom parameters in the makefiles are using the variables 
> OECORE_TARGET_SYSROOT
>  and OECORE_NATIVE_SYSROOT to manage paths.
>
>
>
> But it appears that these 2 variables do not exists when the makefiles are
> called in a do_compile() function of a recipe.
>
>
>
>
>
>
>
> Is it normal ? Did I did something wrong ?
>
>
> Should my recipe inherit something specific?
>
>
>
>
>
>
>
> Or should I "source" my 
> "environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi"
> from the SDK into my recipe file ? (=> not portable)
>
>
>
>
>
>
>
> Thanks.
>
>
>
>
>
>
>
> Z.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
> ___
>
> yocto mailing list
>
> yocto@yoctoproject.org
>
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] kernel config fragments not applied

2017-01-10 Thread Schmitt, Richard

I am having a heck of a hard time getting a minor kernel config fragment 
applied.

In order to minimize all variables, I am simply trying to build linux-yocto for 
a qemux86 MACHINE target.

There had been some discussion on the mailing list previously that suggested 
making sure linux-yocto.inc was included within the recipes.   The ones being 
used are standard poky recipes and they do include the linux-yocto.inc file.

My configuration is very simple.  I have my own layer and linux-yocto bbappend:

meta-mylayer/recipes-kernel/linux/linux-yocto_4.4.bbappend

Whose contents are:

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI += " \
file://overlayfs.cfg \
"

With the config fragment in:

meta-mylayer/recipes-kernel/linux/linux-yocto/overlayfs.cfg

whose contents is:

CONFIG_OVERLAY_FS=y

If I do a "bitbake linux-yocto" I would expect it to generate a config file 
that includes CONFIG_OVERLAY_FS=y and a kernel that includes this filesystem.  
I don't.

My layer is parsed correctly and the bbappend is found and parsed.  I know this 
because in the tmp directory:

tmp/work/qemux86-poky-linux/linux-yocto/4.4.26+gitAUTOINC+3030330b06_ca6a08bd7f-r0/

the file overlayfs.cfg exists.

Searching the log files, the only one that references this file though is 
log.do_unpack.  I do not see any reference to it in log.do_kernel_configme or 
log.do_configure.I'm not sure how kernel fragments are applied, but looking 
through the classes and recipes for linux-yocto in poky/meta, I do not see any 
code that would apply kernel fragments.  So I'm not sure if I'm missing some 
piece.

Searching through the files in poky/meta, I find meta-config.sh only in 
recipes-core/uclibc and recipes-core/busybox.  That's why I think I'm missing 
something.

I'm using the krogoth branch of poky.

What am I missing?

Thanks,
Rich


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

[yocto] [PATCH][opkg 2/2] conffile: gracefully handle deleted conffiles in conffile_has_been_modified

2017-01-10 Thread Ross Burton

Handle conffiles that don't exist gracefully so that instead of showing an error
message from file_md5sum_alloc() a notice that the file has been deleted is
shown instead.

Signed-off-by: Ross Burton 
---
 libopkg/conffile.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libopkg/conffile.c b/libopkg/conffile.c
index b2f2469..7b4b87b 100644
--- a/libopkg/conffile.c
+++ b/libopkg/conffile.c
@@ -51,6 +51,11 @@ int conffile_has_been_modified(conffile_t * conffile)
 }
 
 root_filename = root_filename_alloc(filename);
+if (!file_exists(root_filename)) {
+opkg_msg(INFO, "Conffile %s deleted\n", conffile->name);
+free(root_filename);
+return 1;
+}
 
 md5sum = file_md5sum_alloc(root_filename);
 
-- 
2.8.1

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

[yocto] [PATCH][opkg 1/2] opkg_cmd: only look at conffile status if we're going to output it

2017-01-10 Thread Ross Burton

The loop to compare the recorded conffile hash with their hash on disk is
outputted at level INFO but the loop was executed at level NOTICE and higher.

This means that if a conffile had been deleted the status operation would
produce error messages for output it isn't displaying.

Signed-off-by: Ross Burton 
---
 libopkg/opkg_cmd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libopkg/opkg_cmd.c b/libopkg/opkg_cmd.c
index ba57c6a..37416fd 100644
--- a/libopkg/opkg_cmd.c
+++ b/libopkg/opkg_cmd.c
@@ -638,7 +638,7 @@ static int opkg_info_status_cmd(int argc, char **argv, int 
installed_only)
 
 pkg_formatted_info(stdout, pkg);
 
-if (opkg_config->verbosity >= NOTICE) {
+if (opkg_config->verbosity >= INFO) {
 conffile_list_elt_t *iter;
 for (iter = nv_pair_list_first(>conffiles); iter;
  iter = nv_pair_list_next(>conffiles, iter)) {
-- 
2.8.1

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

[yocto] [bitbake] OECORE_TARGET_SYSROOT and OECORE_NATIVE_SYSROOT variables not availables ?

2017-01-10 Thread Karim ATIKI

Hi,


I'm using generated Poky SDK to cross-compile our program source-codes, which 
works fine.


Now I wish to integrate the build of the project into Yocto recipes using our 
makefiles.


However, some custom parameters in the makefiles are using the variables 
OECORE_TARGET_SYSROOT  and OECORE_NATIVE_SYSROOT to manage paths.

But it appears that these 2 variables do not exists when the makefiles are 
called in a do_compile() function of a recipe.


Is it normal ? Did I did something wrong ?

Should my recipe inherit something specific?


Or should I "source" my 
"environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi" from the SDK into my 
recipe file ? (=> not portable)


Thanks.


Z.



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

Re: [yocto] [meta-selinux] What's the point of refpolicy-minimum?

2017-01-10 Thread Shrikant Bobade

Hi Joe,


On Tue, Jan 10, 2017 at 8:18 PM, Joe MacDonald 
wrote:
>
> Wenzong / Shrikant,
>
> I thought I knew the answer to the above question, and maybe my
> understanding is still correct, but I think I need to ask it now anyway.
>
> I don't use refpolicy-minimum for anything, so when I did the updates to
> refpolicy*_git I didn't even glance at refpolicy-minimum_git.  Wenzong's
> change to refpolicy-minimum_2.20161023 (in the same thread as the uprev
> of the recipe) piqued my curiosity, so I had a look.  Of course,
> refpolicy-minimum_git.bb also needs to be updated (or thrown out), but
> now that I'm looking at the recipe I see what seems like conflicting
> statements in the recipe:
>
>recipes-security/refpolicy/refpolicy-minimum_2.20161023.bb:
>
>  1 include refpolicy-targeted_${PV}.bb
>  2
>  3 SUMMARY = "SELinux minimum policy"
>  4 DESCRIPTION = "\
>  5 This is a minimum reference policy with just core policy modules,
and \
>  6 could be used as a base for customizing targeted policy. \
>  7 Pretty much everything runs as initrc_t or unconfined_t so all of
the \
>  8 domains are unconfined. \
>  9 "
>
> and:
>
>recipes-security/refpolicy/refpolicy-targeted_2.20161023.bb:
>
>  1 SUMMARY = "SELinux targeted policy"
>  2 DESCRIPTION = "\
>  3 This is the targeted variant of the SELinux reference policy.
Most service \
>  4 domains are locked down. Users and admins will login in with
unconfined_t \
>  5 domain, so they have the same access to the system as if SELinux
was not \
>  6 enabled. \
>  7 "
>
> So now I'm trying to understand what the point of refpolicy-minimum
> really is here.  Those of you who are using it, what are you using it
> for and what do you expect would be the correct behaviour of a system
> running that policy?

recently used refpolicy-minimum, as it provides protection/security for
minimum modules
and reaming things with unconfined, the minimum coverage(modules) of policy
easy to start on
& cross check the prepared infrastructure against the expected selinux
behavior.

Also it is easy to patch for systemd compared to other policies. Till
refpolicy v20151208 release
we have refpolicy-minimum working with systemd as init manager.
regarding the latest release need to check.

But moving ahead similar policy with minimum modules can be used..

>
> At the very least, I'm going to remove the 'include [...].bb' from both
> 'minimum' recipes, as that's completely incorrect, but when I do that I
> want to know what anyone using this recipe wants to see from it, so
> whatever the 'include' gets replaced with is doing the right thing
> (which isn't necessarily what it's doing today).

agree..
>
> --
> -Joe MacDonald.
> :wq
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

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

[yocto] [meta-selinux] What's the point of refpolicy-minimum?

2017-01-10 Thread Joe MacDonald

Wenzong / Shrikant,

I thought I knew the answer to the above question, and maybe my
understanding is still correct, but I think I need to ask it now anyway.

I don't use refpolicy-minimum for anything, so when I did the updates to
refpolicy*_git I didn't even glance at refpolicy-minimum_git.  Wenzong's
change to refpolicy-minimum_2.20161023 (in the same thread as the uprev
of the recipe) piqued my curiosity, so I had a look.  Of course,
refpolicy-minimum_git.bb also needs to be updated (or thrown out), but
now that I'm looking at the recipe I see what seems like conflicting
statements in the recipe:

   recipes-security/refpolicy/refpolicy-minimum_2.20161023.bb:

 1 include refpolicy-targeted_${PV}.bb
 2 
 3 SUMMARY = "SELinux minimum policy"
 4 DESCRIPTION = "\
 5 This is a minimum reference policy with just core policy modules, and \
 6 could be used as a base for customizing targeted policy. \
 7 Pretty much everything runs as initrc_t or unconfined_t so all of the \
 8 domains are unconfined. \
 9 "

and:

   recipes-security/refpolicy/refpolicy-targeted_2.20161023.bb:

 1 SUMMARY = "SELinux targeted policy"
 2 DESCRIPTION = "\
 3 This is the targeted variant of the SELinux reference policy.  Most 
service \
 4 domains are locked down. Users and admins will login in with 
unconfined_t \
 5 domain, so they have the same access to the system as if SELinux was not 
\
 6 enabled. \
 7 "

So now I'm trying to understand what the point of refpolicy-minimum
really is here.  Those of you who are using it, what are you using it
for and what do you expect would be the correct behaviour of a system
running that policy?

At the very least, I'm going to remove the 'include [...].bb' from both
'minimum' recipes, as that's completely incorrect, but when I do that I
want to know what anyone using this recipe wants to see from it, so
whatever the 'include' gets replaced with is doing the right thing
(which isn't necessarily what it's doing today).

-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH 0/2] uprev refpolicy to 2.20161023

2017-01-10 Thread Joe MacDonald

[[yocto] [meta-selinux][PATCH 0/2] uprev refpolicy to 2.20161023] On 17.01.10 
(Tue 00:54) wenzong@windriver.com wrote:

> From: Wenzong Fan 
> 
> Uprev refpolicy to 2.20161023 and fix build errors for refpolicy-minimum.
> 
> The following changes since commit bae51859f0dbcdde9fd563d15128a6dbbb816801:
> 
>   audit: upgrade 2.6.6 -> 2.7 (2017-01-09 08:59:55 -0500)
> 
> are available in the git repository at:
> 
>   git://git.pokylinux.org/poky-contrib wenzong/refpolicy-2.20161023
>   
> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/refpolicy-2.20161023

As poky-contrib is full of unrelated stuff, it's not the right place to
be doing meta-selinux work AFAICT.  I'd rather you actually just
fork meta-selinux somewhere like github if you plan to send pull
requests.  Patches are fine, of course, they're even easier for me to
work with.

-J.

> 
> Wenzong Fan (2):
>   refpolicy: uprev 2.20151208 -> 2.20161023
>   refpolicy-minimum: update patch file
> 
>  .../ftp-add-ftpd_t-to-mlsfilewrite.patch | 0
>  .../poky-fc-clock.patch  | 0
>  .../poky-fc-corecommands.patch   | 0
>  .../poky-fc-dmesg.patch  | 0
>  .../poky-fc-fix-bind.patch   | 0
>  .../poky-fc-fix-real-path_login.patch| 0
>  .../poky-fc-fix-real-path_resolv.conf.patch  | 0
>  .../poky-fc-fix-real-path_shadow.patch   | 0
>  .../poky-fc-fix-real-path_su.patch   | 0
>  .../poky-fc-fstools.patch| 0
>  .../poky-fc-ftpwho-dir.patch | 0
>  .../poky-fc-iptables.patch   | 0
>  .../poky-fc-mta.patch| 0
>  .../poky-fc-netutils.patch   | 0
>  .../poky-fc-nscd.patch   | 0
>  .../poky-fc-rpm.patch| 0
>  .../poky-fc-screen.patch | 0
>  .../poky-fc-ssh.patch| 0
>  .../poky-fc-su.patch | 0
>  .../poky-fc-subs_dist.patch  | 0
>  .../poky-fc-sysnetwork.patch | 0
>  .../poky-fc-udevd.patch  | 0
>  .../poky-fc-update-alternatives_hostname.patch   | 0
>  .../poky-fc-update-alternatives_sysklogd.patch   | 0
>  .../poky-fc-update-alternatives_sysvinit.patch   | 0
>  .../poky-policy-add-rules-for-bsdpty_device_t.patch  | 0
>  .../poky-policy-add-rules-for-syslogd_t-symlink.patch| 0
>  .../poky-policy-add-rules-for-tmp-symlink.patch  | 0
>  .../poky-policy-add-rules-for-var-cache-symlink.patch| 0
>  .../poky-policy-add-rules-for-var-log-symlink-apache.patch   | 0
>  ...ky-policy-add-rules-for-var-log-symlink-audisp_remote_t.patch | 0
>  .../poky-policy-add-rules-for-var-log-symlink.patch  | 0
>  .../poky-policy-add-syslogd_t-to-trusted-object.patch| 0
>  .../poky-policy-allow-nfsd-to-exec-shell-commands.patch  | 0
>  .../poky-policy-allow-setfiles_t-to-read-symlinks.patch  | 0
>  .../poky-policy-allow-sysadm-to-run-rpcinfo.patch| 0
>  .../poky-policy-don-t-audit-tty_device_t.patch   | 0
>  .../poky-policy-fix-dmesg-to-use-dev-kmsg.patch  | 0
>  .../poky-policy-fix-new-SELINUXMNT-in-sys.patch  | 0
>  .../poky-policy-fix-nfsd_t-to-mount_nfsd_fs_t.patch  | 0
>  .../poky-policy-fix-setfiles-statvfs-get-file-count.patch| 0
>  .../poky-policy-fix-seutils-manage-config-files.patch| 0
>  .../refpolicy-update-for_systemd.patch   | 0
>  .../{refpolicy-mcs_2.20151208.bb => refpolicy-mcs_2.20161023.bb} | 0
>  ...07-refpolicy-minimum-systemd-fix-for-login-journal-serv.patch | 9 
> ++---
>  ...icy-minimum_2.20151208.bb => refpolicy-minimum_2.20161023.bb} | 0
>  .../{refpolicy-mls_2.20151208.bb => refpolicy-mls_2.20161023.bb} | 0
>  ...y-standard_2.20151208.bb => refpolicy-standard_2.20161023.bb} | 0
>  ...y-targeted_2.20151208.bb => refpolicy-targeted_2.20161023.bb} | 0
>  .../{refpolicy_2.20151208.inc => refpolicy_2.20161023.inc}   | 8 
>  50 files changed, 10 insertions(+), 7 deletions(-)
>  rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
> refpolicy-2.20161023}/ftp-add-ftpd_t-to-mlsfilewrite.patch (100%)
>  rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
> refpolicy-2.20161023}/poky-fc-clock.patch (100%)
>  rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
>

Re: [yocto] how does one stay on top of YP security alerts?

2017-01-10 Thread Bent Bisballe Nyeng

On 01/10/2017 11:29 AM, Burton, Ross wrote:

On 10 January 2017 at 10:01, Bent Bisballe Nyeng 
> wrote:
So /is/ the yocto-security mailinglist considered "dead"? Or has there
simply not been any security issues for a while?

IIRC, yocto-security was more to discuss security issues, not an announcement 
of security related fixes.  If you care about security then you'll want notice 
for more than just what is in oe-core, so I suggest monitoring the CVE 
announcements directly.

Ross

I found the list initially through this page: 
https://wiki.yoctoproject.org/wiki/Security where it is described as the 
security [at] yoctoprojct [dot] org being the discussion list and the yocto 
[dash] security [at] yoctoproject[dot] org being the security announcement list.

If the yocto [dash] security [at] yoctoproject[dot] org is in fact no longer 
active I think it is important that the wiki page is changed to reflect that to 
prevent potential dangerous misunderstandings in the future.

Kind regards
Bent Bisballe Nyeng
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] how does one stay on top of YP security alerts?

2017-01-10 Thread Burton, Ross

On 10 January 2017 at 10:01, Bent Bisballe Nyeng  wrote:

> So /is/ the yocto-security mailinglist considered "dead"? Or has there
> simply not been any security issues for a while?
>

IIRC, yocto-security was more to discuss security issues, not an
announcement of security related fixes.  If you care about security then
you'll want notice for more than just what is in oe-core, so I suggest
monitoring the CVE announcements directly.

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

Re: [yocto] how does one stay on top of YP security alerts?

2017-01-10 Thread Bent Bisballe Nyeng

On 01/09/2017 02:12 PM, Alexander Kanavin wrote:
> On 01/07/2017 05:29 PM, Robert P. J. Day wrote:
>>   colleague wants to know how one stays up to date with security
>> alerts related to YP releases, i checked out the yocto-security
>> mailing list:
>>
>> https://lists.yoctoproject.org/pipermail/yocto-security/
>>
>> but that looks like a very dead mailing list. are there other options?
> You can subscribe to yocto-announce list and follow the announcements 
> for stable point releases, or simply pull from release branches as often 
> as possible, and make some form of 'git log' your personal security alert.
>
> Alex
>
So /is/ the yocto-security mailinglist considered "dead"? Or has there
simply not been any security issues for a while?

Kind regards
Bent Bisballe Nyeng

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

[yocto] [meta-selinux][PATCH 2/2] refpolicy-minimum: update patch file

2017-01-10 Thread wenzong.fan

From: Wenzong Fan 

Fix build errors:
| policy/modules/system/init.te:1120:ERROR 'class dbus is not within scope' at 
token ';' on line 40246:
| allow initrc_t init_t:dbus send_msg;
| allow init_t initrc_t:dbus { send_msg acquire_svc };

Signed-off-by: Wenzong Fan 
---
 ...07-refpolicy-minimum-systemd-fix-for-login-journal-serv.patch | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git 
a/recipes-security/refpolicy/refpolicy-minimum/0007-refpolicy-minimum-systemd-fix-for-login-journal-serv.patch
 
b/recipes-security/refpolicy/refpolicy-minimum/0007-refpolicy-minimum-systemd-fix-for-login-journal-serv.patch
index 50e3c64..a4084d7 100644
--- 
a/recipes-security/refpolicy/refpolicy-minimum/0007-refpolicy-minimum-systemd-fix-for-login-journal-serv.patch
+++ 
b/recipes-security/refpolicy/refpolicy-minimum/0007-refpolicy-minimum-systemd-fix-for-login-journal-serv.patch
@@ -49,15 +49,18 @@ diff --git a/policy/modules/system/init.te 
b/policy/modules/system/init.te
 index 19a7a20..cefa59d 100644
 --- a/policy/modules/system/init.te
 +++ b/policy/modules/system/init.te
-@@ -1105,3 +1105,8 @@ allow init_t self:capability2 audit_read;
+@@ -1105,3 +1105,11 @@ allow init_t self:capability2 audit_read;
  
  allow initrc_t init_t:system { start status reboot };
  allow initrc_t init_var_run_t:service { start status };
 +
 +allow initrc_t init_var_run_t:service stop;
-+allow initrc_t init_t:dbus send_msg;
++init_dbus_chat(initrc_t)
 +
-+allow init_t initrc_t:dbus { send_msg acquire_svc };
++gen_require(`
++  class dbus acquire_svc;
++')
++allow init_t initrc_t:dbus { acquire_svc };
 diff --git a/policy/modules/system/locallogin.te 
b/policy/modules/system/locallogin.te
 index 09ec33f..be25c82 100644
 --- a/policy/modules/system/locallogin.te
-- 
2.11.0

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

[yocto] [meta-selinux][PATCH 1/2] refpolicy: uprev 2.20151208 -> 2.20161023

2017-01-10 Thread wenzong.fan

From: Wenzong Fan 

Signed-off-by: Wenzong Fan 
---
 .../ftp-add-ftpd_t-to-mlsfilewrite.patch  | 0
 .../poky-fc-clock.patch   | 0
 .../poky-fc-corecommands.patch| 0
 .../poky-fc-dmesg.patch   | 0
 .../poky-fc-fix-bind.patch| 0
 .../poky-fc-fix-real-path_login.patch | 0
 .../poky-fc-fix-real-path_resolv.conf.patch   | 0
 .../poky-fc-fix-real-path_shadow.patch| 0
 .../poky-fc-fix-real-path_su.patch| 0
 .../poky-fc-fstools.patch | 0
 .../poky-fc-ftpwho-dir.patch  | 0
 .../poky-fc-iptables.patch| 0
 .../poky-fc-mta.patch | 0
 .../poky-fc-netutils.patch| 0
 .../poky-fc-nscd.patch| 0
 .../poky-fc-rpm.patch | 0
 .../poky-fc-screen.patch  | 0
 .../poky-fc-ssh.patch | 0
 .../poky-fc-su.patch  | 0
 .../poky-fc-subs_dist.patch   | 0
 .../poky-fc-sysnetwork.patch  | 0
 .../poky-fc-udevd.patch   | 0
 .../poky-fc-update-alternatives_hostname.patch| 0
 .../poky-fc-update-alternatives_sysklogd.patch| 0
 .../poky-fc-update-alternatives_sysvinit.patch| 0
 .../poky-policy-add-rules-for-bsdpty_device_t.patch   | 0
 .../poky-policy-add-rules-for-syslogd_t-symlink.patch | 0
 .../poky-policy-add-rules-for-tmp-symlink.patch   | 0
 .../poky-policy-add-rules-for-var-cache-symlink.patch | 0
 .../poky-policy-add-rules-for-var-log-symlink-apache.patch| 0
 ...oky-policy-add-rules-for-var-log-symlink-audisp_remote_t.patch | 0
 .../poky-policy-add-rules-for-var-log-symlink.patch   | 0
 .../poky-policy-add-syslogd_t-to-trusted-object.patch | 0
 .../poky-policy-allow-nfsd-to-exec-shell-commands.patch   | 0
 .../poky-policy-allow-setfiles_t-to-read-symlinks.patch   | 0
 .../poky-policy-allow-sysadm-to-run-rpcinfo.patch | 0
 .../poky-policy-don-t-audit-tty_device_t.patch| 0
 .../poky-policy-fix-dmesg-to-use-dev-kmsg.patch   | 0
 .../poky-policy-fix-new-SELINUXMNT-in-sys.patch   | 0
 .../poky-policy-fix-nfsd_t-to-mount_nfsd_fs_t.patch   | 0
 .../poky-policy-fix-setfiles-statvfs-get-file-count.patch | 0
 .../poky-policy-fix-seutils-manage-config-files.patch | 0
 .../refpolicy-update-for_systemd.patch| 0
 .../{refpolicy-mcs_2.20151208.bb => refpolicy-mcs_2.20161023.bb}  | 0
 ...licy-minimum_2.20151208.bb => refpolicy-minimum_2.20161023.bb} | 0
 .../{refpolicy-mls_2.20151208.bb => refpolicy-mls_2.20161023.bb}  | 0
 ...cy-standard_2.20151208.bb => refpolicy-standard_2.20161023.bb} | 0
 ...cy-targeted_2.20151208.bb => refpolicy-targeted_2.20161023.bb} | 0
 .../{refpolicy_2.20151208.inc => refpolicy_2.20161023.inc}| 8 
 49 files changed, 4 insertions(+), 4 deletions(-)
 rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
refpolicy-2.20161023}/ftp-add-ftpd_t-to-mlsfilewrite.patch (100%)
 rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
refpolicy-2.20161023}/poky-fc-clock.patch (100%)
 rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
refpolicy-2.20161023}/poky-fc-corecommands.patch (100%)
 rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
refpolicy-2.20161023}/poky-fc-dmesg.patch (100%)
 rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
refpolicy-2.20161023}/poky-fc-fix-bind.patch (100%)
 rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
refpolicy-2.20161023}/poky-fc-fix-real-path_login.patch (100%)
 rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
refpolicy-2.20161023}/poky-fc-fix-real-path_resolv.conf.patch (100%)
 rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
refpolicy-2.20161023}/poky-fc-fix-real-path_shadow.patch (100%)
 rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
refpolicy-2.20161023}/poky-fc-fix-real-path_su.patch (100%)
 rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
refpolicy-2.20161023}/poky-fc-fstools.patch (100%)
 rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
refpolicy-2.20161023}/poky-fc-ftpwho-dir.patch (100%)
 rename

[yocto] [meta-selinux][PATCH 0/2] uprev refpolicy to 2.20161023

2017-01-10 Thread wenzong.fan

From: Wenzong Fan 

Uprev refpolicy to 2.20161023 and fix build errors for refpolicy-minimum.

The following changes since commit bae51859f0dbcdde9fd563d15128a6dbbb816801:

  audit: upgrade 2.6.6 -> 2.7 (2017-01-09 08:59:55 -0500)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib wenzong/refpolicy-2.20161023
  
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/refpolicy-2.20161023

Wenzong Fan (2):
  refpolicy: uprev 2.20151208 -> 2.20161023
  refpolicy-minimum: update patch file

 .../ftp-add-ftpd_t-to-mlsfilewrite.patch | 0
 .../poky-fc-clock.patch  | 0
 .../poky-fc-corecommands.patch   | 0
 .../poky-fc-dmesg.patch  | 0
 .../poky-fc-fix-bind.patch   | 0
 .../poky-fc-fix-real-path_login.patch| 0
 .../poky-fc-fix-real-path_resolv.conf.patch  | 0
 .../poky-fc-fix-real-path_shadow.patch   | 0
 .../poky-fc-fix-real-path_su.patch   | 0
 .../poky-fc-fstools.patch| 0
 .../poky-fc-ftpwho-dir.patch | 0
 .../poky-fc-iptables.patch   | 0
 .../poky-fc-mta.patch| 0
 .../poky-fc-netutils.patch   | 0
 .../poky-fc-nscd.patch   | 0
 .../poky-fc-rpm.patch| 0
 .../poky-fc-screen.patch | 0
 .../poky-fc-ssh.patch| 0
 .../poky-fc-su.patch | 0
 .../poky-fc-subs_dist.patch  | 0
 .../poky-fc-sysnetwork.patch | 0
 .../poky-fc-udevd.patch  | 0
 .../poky-fc-update-alternatives_hostname.patch   | 0
 .../poky-fc-update-alternatives_sysklogd.patch   | 0
 .../poky-fc-update-alternatives_sysvinit.patch   | 0
 .../poky-policy-add-rules-for-bsdpty_device_t.patch  | 0
 .../poky-policy-add-rules-for-syslogd_t-symlink.patch| 0
 .../poky-policy-add-rules-for-tmp-symlink.patch  | 0
 .../poky-policy-add-rules-for-var-cache-symlink.patch| 0
 .../poky-policy-add-rules-for-var-log-symlink-apache.patch   | 0
 ...ky-policy-add-rules-for-var-log-symlink-audisp_remote_t.patch | 0
 .../poky-policy-add-rules-for-var-log-symlink.patch  | 0
 .../poky-policy-add-syslogd_t-to-trusted-object.patch| 0
 .../poky-policy-allow-nfsd-to-exec-shell-commands.patch  | 0
 .../poky-policy-allow-setfiles_t-to-read-symlinks.patch  | 0
 .../poky-policy-allow-sysadm-to-run-rpcinfo.patch| 0
 .../poky-policy-don-t-audit-tty_device_t.patch   | 0
 .../poky-policy-fix-dmesg-to-use-dev-kmsg.patch  | 0
 .../poky-policy-fix-new-SELINUXMNT-in-sys.patch  | 0
 .../poky-policy-fix-nfsd_t-to-mount_nfsd_fs_t.patch  | 0
 .../poky-policy-fix-setfiles-statvfs-get-file-count.patch| 0
 .../poky-policy-fix-seutils-manage-config-files.patch| 0
 .../refpolicy-update-for_systemd.patch   | 0
 .../{refpolicy-mcs_2.20151208.bb => refpolicy-mcs_2.20161023.bb} | 0
 ...07-refpolicy-minimum-systemd-fix-for-login-journal-serv.patch | 9 ++---
 ...icy-minimum_2.20151208.bb => refpolicy-minimum_2.20161023.bb} | 0
 .../{refpolicy-mls_2.20151208.bb => refpolicy-mls_2.20161023.bb} | 0
 ...y-standard_2.20151208.bb => refpolicy-standard_2.20161023.bb} | 0
 ...y-targeted_2.20151208.bb => refpolicy-targeted_2.20161023.bb} | 0
 .../{refpolicy_2.20151208.inc => refpolicy_2.20161023.inc}   | 8 
 50 files changed, 10 insertions(+), 7 deletions(-)
 rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
refpolicy-2.20161023}/ftp-add-ftpd_t-to-mlsfilewrite.patch (100%)
 rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
refpolicy-2.20161023}/poky-fc-clock.patch (100%)
 rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
refpolicy-2.20161023}/poky-fc-corecommands.patch (100%)
 rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
refpolicy-2.20161023}/poky-fc-dmesg.patch (100%)
 rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
refpolicy-2.20161023}/poky-fc-fix-bind.patch (100%)
 rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
refpolicy-2.20161023}/poky-fc-fix-real-path_login.patch (100%)
 rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
refpolicy-2.20161023}/poky-fc-fix-real-path_resolv.conf.patch (100%)
 rename

[yocto] openjdk 8 support compile for arm with jit support

2017-01-10 Thread Rohit Jindal

Sorry i am new to this forum, actually my target is as follows:

I want to compile openjdk 8 for arm processor due to one of my requirement .
I have used meta-java layer with openjre 102b14 version.
Its compiling good with arm compiler.
But i want to add any available JIT ie just in time compiler to be added in
my working arm based java binaries to increase the performance of my java
applications to be used.
Steps followed are :
Downloaded poky and meta-java layer.
Set machine to be qemuarm .
Toolchain get downloaded as required along with required tools.
Openjre 8_102b14 is compiled for arm successfully.
I twisted the recipe and added enable-jamvm as config param. Now jamvm is
compiled as dependency.
After successful compilations of recipes i tried to run java binaries using
chroot replacing libjvm.so default with created using jamvm .
Java -jamvm -version
Getting segmentation fault core dumped.

Please suggest the solution for the same.

I tried with diffrrent VMs also but all in vein.

Even i tried diiferent variants of openjdk that says that Jit works fine
with it. Like openjdk8u-111-b14 works fine for debian but same source gives
compilation errors. Please suggest openjdk8 version for arm to add jit
support that will work fine for me.

Thanks
Rohit jindal
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [bitbake] OECORE_TARGET_SYSROOT and OECORE_NATIVE_SYSROOT variables not availables ?

Re: [yocto] [meta-selinux][PATCH 0/2] uprev refpolicy to 2.20161023

Re: [yocto] kernel config fragments not applied

Re: [yocto] kernel config fragments not applied

Re: [yocto] kernel config fragments not applied

Re: [yocto] kernel config fragments not applied

Re: [yocto] kernel config fragments not applied

Re: [yocto] how does one stay on top of YP security alerts?

Re: [yocto] [bitbake] OECORE_TARGET_SYSROOT and OECORE_NATIVE_SYSROOT variables not availables ?

[yocto] kernel config fragments not applied

[yocto] [PATCH][opkg 2/2] conffile: gracefully handle deleted conffiles in conffile_has_been_modified

[yocto] [PATCH][opkg 1/2] opkg_cmd: only look at conffile status if we're going to output it

[yocto] [bitbake] OECORE_TARGET_SYSROOT and OECORE_NATIVE_SYSROOT variables not availables ?

Re: [yocto] [meta-selinux] What's the point of refpolicy-minimum?

[yocto] [meta-selinux] What's the point of refpolicy-minimum?

Re: [yocto] [meta-selinux][PATCH 0/2] uprev refpolicy to 2.20161023

Re: [yocto] how does one stay on top of YP security alerts?

Re: [yocto] how does one stay on top of YP security alerts?

Re: [yocto] how does one stay on top of YP security alerts?

[yocto] [meta-selinux][PATCH 2/2] refpolicy-minimum: update patch file

[yocto] [meta-selinux][PATCH 1/2] refpolicy: uprev 2.20151208 -> 2.20161023

[yocto] [meta-selinux][PATCH 0/2] uprev refpolicy to 2.20161023

[yocto] openjdk 8 support compile for arm with jit support

23 matches

Site Navigation

Mail list logo

Footer information