[yocto] [meta-selinux][PATCH] libcap-ng: CVE-2014-3215

[jackie.huang]

From: Shan Hai 

seunshare in policycoreutils 2.2.5 is owned by root with 4755 permissions,
and executes programs in a way that changes the relationship between the
setuid system call and the getresuid saved set-user-ID value, which makes
it easier for local users to gain privileges by leveraging a program that
mistakenly expected that it could permanently drop privileges.

Pick a patch from below link to address the CVE-2014-3215.
https://bugzilla.redhat.com/attachment.cgi?id=829864

Signed-off-by: Shan Hai 
Signed-off-by: Jackie Huang 
---
 .../libcap-ng/libcap-ng/CVE-2014-3215.patch| 79 ++
 recipes-security/libcap-ng/libcap-ng_0.7.3.bb  |  4 +-
 2 files changed, 82 insertions(+), 1 deletion(-)
 create mode 100644 recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch

diff --git a/recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch 
b/recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch
new file mode 100644
index 000..d7a868d
--- /dev/null
+++ b/recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch
@@ -0,0 +1,79 @@
+Upstream-Status: Pending
+
+diff --git a/docs/capng_lock.3 b/docs/capng_lock.3
+index 7683119..a070c1e 100644
+--- a/docs/capng_lock.3
 b/docs/capng_lock.3
+@@ -8,12 +8,13 @@ int capng_lock(void);
+ 
+ .SH "DESCRIPTION"
+ 
+-capng_lock will take steps to prevent children of the current process to 
regain full privileges if the uid is 0. This should be called while possessing 
the CAP_SETPCAP capability in the kernel. This function will do the following 
if permitted by the kernel: Set the NOROOT option on for PR_SET_SECUREBITS, set 
the NOROOT_LOCKED option to on for PR_SET_SECUREBITS, set the 
PR_NO_SETUID_FIXUP option on for PR_SET_SECUREBITS, and set the 
PR_NO_SETUID_FIXUP_LOCKED option on for PR_SET_SECUREBITS.
++capng_lock will take steps to prevent children of the current process from 
gaining privileges by executing setuid programs.  This should be called while 
possessing the CAP_SETPCAP capability in the kernel.
+ 
++This function will do the following if permitted by the kernel:  If the 
kernel supports PR_SET_NO_NEW_PRIVS, it will use it.  Otherwise it will set the 
NOROOT option on for PR_SET_SECUREBITS, set the NOROOT_LOCKED option to on for 
PR_SET_SECUREBITS, set the PR_NO_SETUID_FIXUP option on for PR_SET_SECUREBITS, 
and set the PR_NO_SETUID_FIXUP_LOCKED option on for PR_SET_SECUREBITS.  If both 
fail, it will return an error.
+ 
+ .SH "RETURN VALUE"
+ 
+-This returns 0 on success and a negative number on failure. -1 means a 
failure setting any of the PR_SET_SECUREBITS options.
++This returns 0 on success and a negative number on failure. -1 means a 
failure to use PR_SET_NO_NEW_PRIVS and a failure setting any of the 
PR_SET_SECUREBITS options.
+ 
+ .SH "SEE ALSO"
+ 
+diff --git a/src/cap-ng.c b/src/cap-ng.c
+index bd105ba..422f2bc 100644
+--- a/src/cap-ng.c
 b/src/cap-ng.c
+@@ -45,6 +45,7 @@
+  * 2.6.24 kernel  XATTR_NAME_CAPS
+  * 2.6.25 kernel  PR_CAPBSET_DROP, CAPABILITY_VERSION_2
+  * 2.6.26 kernel  PR_SET_SECUREBITS, SECURE_*_LOCKED, VERSION_3
++ * 3.5kernel  PR_SET_NO_NEW_PRIVS
+  */
+ 
+ /* External syscall prototypes */
+@@ -122,6 +123,14 @@ extern int capget(cap_user_header_t header, const 
cap_user_data_t data);
+ #define SECURE_NO_SETUID_FIXUP_LOCKED   3  /* make bit-2 immutable */
+ #endif
+ 
++/* prctl values that we use */
++#ifndef PR_SET_SECUREBITS
++#define PR_SET_SECUREBITS 28
++#endif
++#ifndef PR_SET_NO_NEW_PRIVS
++#define PR_SET_NO_NEW_PRIVS   38
++#endif
++
+ // States: new, allocated, initted, updated, applied
+ typedef enum { CAPNG_NEW, CAPNG_ERROR, CAPNG_ALLOCATED, CAPNG_INIT,
+   CAPNG_UPDATED, CAPNG_APPLIED } capng_states_t;
+@@ -663,15 +672,22 @@ int capng_change_id(int uid, int gid, capng_flags_t flag)
+ 
+ int capng_lock(void)
+ {
+-#ifdef PR_SET_SECUREBITS
+-  int rc = prctl(PR_SET_SECUREBITS,
+-  1 << SECURE_NOROOT |
+-  1 << SECURE_NOROOT_LOCKED |
+-  1 << SECURE_NO_SETUID_FIXUP |
+-  1 << SECURE_NO_SETUID_FIXUP_LOCKED, 0, 0, 0);
++  int rc;
++
++  // On Linux 3.5 and up, we can directly prevent ourselves and
++  // our descendents from gaining privileges.
++  if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) == 0)
++  return 0;
++
++  // This kernel is too old or otherwise doesn't support
++  // PR_SET_NO_NEW_PRIVS.  Fall back to using securebits.
++  rc = prctl(PR_SET_SECUREBITS,
++ 1 << SECURE_NOROOT |
++ 1 << SECURE_NOROOT_LOCKED |
++ 1 << SECURE_NO_SETUID_FIXUP |
++ 1 << SECURE_NO_SETUID_FIXUP_LOCKED, 0, 0, 0);
+   if (rc)
+   return -1;
+-#endif
+ 
+   return 0;
+ }
diff --git a/recipes-security/libcap-ng/libcap-ng_0.7.3.bb 
b/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
index 3f225ba..e729518 100644
--- a/recipes-security/libcap-ng/li

[yocto] Yocto Bitbake Error - rmp-native task failure

[Anoop]

I gave bitbake for imx6qsabreauto

command used 
bitbake -v tizen-common-core-image-minimal-dev


below is the error section from the log
+ patch -p0

patch:  Can't create file /tmp/tmpT3pUSD/poMZnbmM : No such file or 
directory

+ bb_exit_handler
+ ret=2
+ echo WARNING: exit code 2 from a shell command.
WARNING: exit code 2 from a shell command.
+ exit 2

ERROR: Function failed: do_prep (log file is located at 
/home/sfm/yocto_temp/build/tmp/work/i686-linux/rpm-native/git-
r0/temp/log.do_patch.32228)
/usr/bin/install -c -m 644 ./Lib/test/test_bool.py 
/home/sfm/yocto_temp/build/tmp/sysroots/i686-linux/usr/lib/python2.7/test

ERROR: Logfile of failure stored in: 
/home/sfm/yocto_temp/build/tmp/work/i686-linux/rpm-native/git-
r0/temp/log.do_patch.32228
NOTE: recipe rpm-native-git-r0: task do_patch: Failed
ERROR: Task 85 (virtual:native:/home/sfm/yocto_temp/meta-tizen/recipes-
tizen/rpm/rpm_git.bb, do_patch) failed with exit code '1'

Error log from patch file
+ 
chmod
 -Rf
 a+rX,u+w,g-w,o-w
 /home/sfm/yocto_temp/build/tmp/work/i686-linux/rpm-native/git-r0/git


+ cp /home/sfm/yocto_temp/build/tmp/work/i686-linux/rpm-native/git-
r0/git/packaging/rpm.manifest .

+ rm -rf sqlite

+ tar xjf /home/sfm/yocto_temp/build/tmp/work/i686-linux/rpm-native/git-
r0/git/packaging/db-4.8.30.tar.bz2

+ ln -s db-4.8.30 db

+ chmod -R u+w db/LICENSE db/README db/btree db/build_brew db/build_s60 
db/build_unix db/build_vxworks db/build_wince db/build_windows db/clib 
db/common db/crypto db/csharp db/cxx db/db db/db185 db/db_archive 
db/db_checkpoint db/db_deadlock db/db_dump db/db_dump185 db/db_hotbackup 
db/db_load db/db_printlog db/db_recover db/db_sql db/db_stat db/db_upgrade 
db/db_verify db/dbinc db/dbinc_auto db/dbm db/dbreg db/dist db/docs 
db/docs_src db/env db/examples_c db/examples_csharp db/examples_cxx 
db/examples_java db/examples_stl db/fileops db/hash db/hmac db/hsearch 
db/java db/libdb_csharp db/libdb_java db/lock db/log db/mod_db4 db/mp 
db/mutex db/os db/os_brew db/os_qnx db/os_s60 db/os_vxworks db/os_windows 
db/perl db/php_db4 db/qam db/rep db/repmgr db/sequence db/stl db/tcl db/test 
db/test_micro db/test_stl db/txn

+ rm -f rpmdb/db.h

+ patch -p0

patch:  Can't create file /tmp/tmpT3pUSD/poMZnbmM : No such file or 
directory

+ bb_exit_handler
+ ret=2
+ echo WARNING: exit code 2 from a shell command.
WARNING: exit code 2 from a shell command.
+ exit 2

+ cd /home/sfm/yocto_temp/build/tmp/work/i686-linux/rpm-native/git-r0/git
+ do_prep
+ cd /home/sfm/yocto_temp/build/tmp/work/i686-linux/rpm-native/git-r0/git
+ chmod -Rf a+rX,u+w,g-w,o-w /home/sfm/yocto_temp/build/tmp/work/i686-
linux/rpm-native/git-r0/git
+ cp /home/sfm/yocto_temp/build/tmp/work/i686-linux/rpm-native/git-
r0/git/packaging/rpm.manifest .
+ rm -rf sqlite
+ tar xjf /home/sfm/yocto_temp/build/tmp/work/i686-linux/rpm-native/git-
r0/git/packaging/db-4.8.30.tar.bz2
+ ln -s db-4.8.30 db
+ chmod -R u+w db/LICENSE db/README db/btree db/build_brew db/build_s60 
db/build_unix db/build_vxworks db/build_wince db/build_windows db/clib 
db/common db/crypto db/csharp db/cxx db/db db/db185 db/db_archive 
db/db_checkpoint db/db_deadlock db/db_dump db/db_dump185 db/db_hotbackup 
db/db_load db/db_printlog db/db_recover db/db_sql db/db_stat db/db_upgrade 
db/db_verify db/dbinc db/dbinc_auto db/dbm db/dbreg db/dist db/docs 
db/docs_src db/env db/examples_c db/examples_csharp db/examples_cxx 
db/examples_java db/examples_stl db/fileops db/hash db/hmac db/hsearch 
db/java db/libdb_csharp db/libdb_java db/lock db/log db/mod_db4 db/mp 
db/mutex db/os db/os_brew db/os_qnx db/os_s60 db/os_vxworks db/os_windows 
db/perl db/php_db4 db/qam db/rep db/repmgr db/sequence db/stl db/tcl db/test 
db/test_micro db/test_stl db/txn
+ rm -f rpmdb/db.h
+ patch -p0
patch:  Can't create file /tmp/tmpT3pUSD/poMZnbmM : No such file or 
directory
+ bb_exit_handler
+ ret=2
+ echo WARNING: exit code 2 from a shell command.
WARNING: exit code 2 from a shell command.
+ exit 2
DEBUG: Python function do_patch finished
ERROR: Function failed: do_prep (log file is located at 
/home/sfm/yocto_temp/build/tmp/work/i686-linux/rpm-native/git-
r0/temp/log.do_patch.32228)

can any one help on how to resolve this error


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

[yocto] Weekly build now available

[Flanagan, Elizabeth]

http://autobuilder.yoctoproject.org/pub/nightly/20140722-2 Unknown

bitbake 8fbffd25d42f1f2d9a85ae1d9cc4852e835730d4
eclipse-poky-juno 26bfc407781aa185f244a47ba63120343cee4a37
eclipse-poky-kepler 4a167fd662262ebdaa3cf0d332ac0debb52d7904
meta-fsl-arm d900d935e1f45a79c7116c4fd290baaa447a870d
meta-fsl-ppc 0772054526043a29b73345540174f2c344f9a353
meta-intel c249763d3cb92bd06742b7986f08cf844ddb1d51
meta-minnow ee48eba5895178ec19febee2e0a2d8b0f3ace0e9
meta-qt3 3016129d90b7ac8517a5227d819f10ad417b5b45
oecore 6bc3696d8451a23d743daf03ee98c4ba54ce4551
poky 8b7116d25ed6255a03895d835e5a0560858ab496


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

[yocto] SDK not contianing archive libraries

[Joseph Andrew de la Peña]

Good day,

I have bumped into a problem when compiling from my generated SDK (-c
populate_sdk). I have archive libraries (.a) that were not reflected in my
SDK's lib dir in sysroots. However, my shared objects (.so) are present. I
needed both .a and .so to be present in my SDK. With the former being the
problem, how can archive libraries be included in SDK? I've checked in my
poky and all .a are installed successfully in tmp/sysroots.

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

[yocto] [ANNOUNCEMENT] Yocto Project 1.7 Milestone 1 now available

[Flanagan, Elizabeth]

The first milestone for the upcoming 1.7 release is now available at:

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-1.7_M1

poky a5531a2b8983318b99c119a87b78a92cf84160b8
meta-qt3 3016129d90b7ac8517a5227d819f10ad417b5b45
eclipse-poky-juno 26bfc407781aa185f244a47ba63120343cee4a37
eclipse-poky-kepler 4a167fd662262ebdaa3cf0d332ac0debb52d7904
meta-fsl-arm 31a0928cbbe707548712ec3612cdc727a3775501
meta-fsl-ppc b920491d60752ffc38098266f260dacaa2c35e7a
meta-intel 05dd98cf5c117a8bdd566d36d20a84fff20e8cc3
meta-minnow ee48eba5895178ec19febee2e0a2d8b0f3ace0e9

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

Re: [yocto] SELinux doesn't work on t4240qds

[zhenhua....@freescale.com]

Hi Mark, 

Thanks for your comments. 

> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-
> boun...@yoctoproject.org] On Behalf Of Mark Hatle
> 
> On 7/22/14, 10:11 AM, zhenhua@freescale.com wrote:
> > Hi all,
> 
> Which release are you using. 
[Luo Zhenhua-B19537] I tried poky daisy + meta-fsl-ppc master + meta-selinux 
master

> The last version I used w/ meta-selinux was the 1.5 release.
> 
> We're planning on updating it to master in the 'near' future [patches
> welcome!], and I've been told by a few others of success w/ 1.7.
[Luo Zhenhua-B19537] I will try master and dora. 

> Did you enable the 'selinux' distribution flag? 
> If so, it should have enabled all of the components necessary for this stuff 
> to be enabled.
[Luo Zhenhua-B19537] Yes, selinux is in DISTRO_FEATURES.


Best Regards,

Zhenhua
 
> --Mark
> 
> > I use the meta-selinux layer to build a core-image-selinux rootfs
> > image, and build kernel with following options enabled.
> >
> > CONFIG_AUDIT=y
> >
> > CONFIG_NETWORK_SECMARK=y
> >
> > CONFIG_EXT2_FS_SECURITY=y
> >
> > CONFIG_EXT3_FS_SECURITY=y
> >
> > CONFIG_EXT4_FS_SECURITY=y
> >
> > CONFIG_JFS_SECURITY=y
> >
> > CONFIG_REISERFS_FS_SECURITY=y
> >
> > CONFIG_JFFS2_FS_SECURITY=y
> >
> > CONFIG_SECURITY_NETWORK=y
> >
> > CONFIG_SECURITY_SELINUX=y
> >
> > CONFIG_SECURITY_SELINUX_BOOTPARAM=y
> >
> > CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
> >
> > CONFIG_SECURITY_SELINUX_DISABLE=y
> >
> > CONFIG_SECURITY_SELINUX_DEVELOP=y
> >
> > CONFIG_SECURITY_SELINUX_AVC_STATS=y
> >
> > CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
> >
> > I use the generated images to boot up FSL PPC t4240qds board(tried
> > both NFS boot and RAM boot with ext2.gz.u-boot rootfs), the SELinux is
> > not turned on after kernel boot up.
> >
> > following is some information in rootfs.
> >
> > root@t4240qds:~# sestatus
> >
> > SELinux status: disabled
> >
> > root@t4240qds:~#
> >
> > root@t4240qds:~# cat /etc/selinux/config
> >
> > # This file controls the state of SELinux on the system.
> >
> > # SELINUX= can take one of these three values:
> >
> > # enforcing - SELinux security policy is enforced.
> >
> > # permissive - SELinux prints warnings instead of enforcing.
> >
> > # disabled - No SELinux policy is loaded.
> >
> > SELINUX=enforcing
> >
> > # SELINUXTYPE= can take one of these two values:
> >
> > # standard - Standard Security protection.
> >
> > # mls - Multi Level Security protection.
> >
> > SELINUXTYPE=mls
> >
> > root@t4240qds:~# cat /proc/cmdline
> >
> > root=/dev/ram rw console=ttyS0,115200 selinux=1
> >
> > root@t4240qds:~# setenforce 1
> >
> > setenforce: SELinux is disabled
> >
> > root@t4240qds:~# getenforce
> >
> > Disabled
> >
> > root@t4240qds:~#
> >
> > Can somebody shed some light on the issue?
> >
> > Best Regards,
> >
> > Zhenhua
> >
> >
> >
> 
> --
> ___
> 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] [Yocto 1.6] PAM _pam_load_conf_file: unable to open /etc/pam.d/system-auth

[Kevyn-Alexandre Paré]

Hi,

Just trying to found what's missing for PAM to work so ssh will stop
exiting with Broken pipe? Quick fix to solve ssh broken pipe is to
change in /etc/ssh/sshd_config "UsePAM yes" to "UsePAM no". But this
does not remove my PAM error?

Here the log for PAM:
root@ka:~$  journalctl | grep -i PAM
Jan 01 00:00:11 ka systemd[1]: systemd 211 running in system mode.
(+PAM +LIBWRAP -AUDIT -SELINUX +IMA +SYSVINIT -LIBCRYPTSETUP -GCRYPT
+ACL +XZ -SECCOMP -APPARMOR)
Jan 01 00:00:16 ka kernel[116]: [4.918701] systemd[1]: systemd 211
running in system mode. (+PAM +LIBWRAP -AUDIT -SELINUX +IMA +SYSVINIT
-LIBCRYPTSETUP -GCRYPT +ACL +XZ -SE
CCOMP -APPARMOR)
Jan 01 00:40:22 ka login[132]: pam_unix(login:account): account root
has password changed in future
Jan 01 00:40:22 ka login[132]: pam_lastlog(login:session): file
/var/log/lastlog created
Jan 01 00:40:22 ka login[132]: pam_unix(login:session): session opened
for user root by LOGIN(uid=0)
Jan 01 00:40:22 ka systemd[194]: PAM _pam_load_conf_file: unable to
open /etc/pam.d/system-auth
Jan 01 00:40:22 ka systemd[194]: PAM _pam_load_conf_file: unable to
open /etc/pam.d/system-auth
Jan 01 00:40:22 ka systemd[194]: Failed at step PAM spawning
/lib/systemd/systemd: Operation not permitted

So my image contain pam:
bitbake -e nirs-console-image | grep ^DISTRO_FEATURES=
DISTRO_FEATURES="alsa argp bluetooth ext2 irda largefile pcmcia
usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11 ipv4 ipv6
libc-backtrace libc-big-macros libc-bsd libc-cxx-tests libc-catgets
libc-charsets libc-crypt
libc-crypt-ufc libc-db-aliases libc-envz libc-fcvt libc-fmtmsg
libc-fstab libc-ftraverse
libc-getlogin libc-idn libc-inet-anl libc-libm libc-locales
libc-locale-codelibc-memusage
libc-nis libc-nsswitch libc-rcmd libc-rtld-debug libc-spawn
libc-streams libc-sunrpc libc-utmp libc-utmpx libc-wordexp
libc-posix-clang-wchar libc-posix-regexp libc-posix-regexp-glibc
libc-posix-wchar-io largefile opengl
ptest multiarch wayland pulseaudio systemd pam"

Any clue or advise on how to fix this and why it's not working?

BR,

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

[yocto] why does meta-yocto prepend to BBPATH, while meta-yocto-bsp appends?

[Robert P. J. Day]

  i know i asked this way back when but i forget the answer -- why
does meta-yocto layer.conf prepend to BBPATH:

  BBPATH =. "${LAYERDIR}:"

while meta-yocto-bsp appends:

  BBPATH .= ":${LAYERDIR}"

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [yocto] read only rootfs & systemd

[Maciek Borzecki]

On wto, 2014-07-22 at 08:44 -0700, Christopher Larson wrote:
> 
> On Tue, Jul 22, 2014 at 4:43 AM, Maciek Borzecki
>  wrote:
> Is read-only-rootfs supported on systemd setups?
> 
> The current dev manual is not clear about this. Also in
> image.bbclass
> there are comments that read_only_rootfs_hook supports only
> sysvinit
> setups.
> 
> 
> Not in oe-core, no. https://github.com/MentorEmbedded/meta-ro-rootfs
> is how we're handling it at mentor today, we haven't gotten around to
> pursuing an upstream solution, whether integration of this or
> something else, as of yet. If you follow the instructions at
> https://github.com/MentorEmbedded/meta-ro-rootfs#usage it should work
> fine for you.
> 
Thanks, very useful.


-- 
Maciej Borzęcki
Senior Software Developer at Open-RnD Sp. z o.o., Poland
www.open-rnd.pl
mobile: +48 889 117 365, fax: +48 42 657 9079

Niniejsza wiadomość wraz z załącznikami może zawierać chronione prawem
lub poufne informacje i została wysłana wyłącznie do wiadomości i
użytku osób, do których została zaadresowana. Jeśli wiadomość została
otrzymana przypadkowo zabrania się jej kopiowania lub rozsyłania do
osób trzecich. W takim przypadku uprasza się o natychmiastowe
zniszczenie wiadomości oraz poinformowanie nadawcy o zaistniałej
sytuacji za pomocą wiadomości zwrotnej. Dziękujemy.

This message, including any attachments hereto, may contain privileged
or confidential information and is sent solely for the attention and
use of the intended addressee(s). If you are not an intended addressee,
you may neither use this message nor copy or deliver it to anyone. In
such case, you should immediately destroy this message and kindly notify
the sender by reply email. Thank you.


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

Re: [yocto] [OE-core] Carrier Grade layer proposal

[Bruce Ashfield]

On 14-07-22 01:21 PM, Alexandru Vaduva wrote:

Hello Bruce,

What I understand from your mail you suggest using the already available 
linux-yocto tree.
As an answer to this let me assure that as much as possible the meta-cgl layer 
will try to do that. If that will not be the case I will let the community know 
that.


Sounds good. I'm attempting to push everything I do in the yocto
eco system into that same kernel tree. That's why meta-cloud-services
and meta-virtualization don't carry custom kernels, even though they
have some very specific requirements.


One such case could be grsecurity(which as Joe mentioned changes the kernel 
quite much) I also expect more such examples exist.


grsec is a well known kernel maintenance cost, but it is something that
we can easily deal with (if we want) in the common yocto kernel. Just look
at how preempt-rt is managed. We wouldn't want that for all boards and
builds, yet it is carried and maintained along with the other features.

One someone gets deeper into development, they may find that they want
to consume the patch series differently, and that's fine, but getting it 
along

with the other reference kernel versions and features is a good kickstart
for development.

That means it always patches, and gets CVEs, -stable updates, etc. If
grsec is maintained out of a tree (that may or may not be the plan), you'll
find that even korg -stable updates will break the application and you'll
be in constant refresh mode. Not to mention, repeating the same
standard/boring maintenance tasks across multiple trees, when we could
be developing  new features and fixing bugs.

Just more food for thought and options to consider.




Do you consider this subject needs a new email opened for it?


We could, but I just went and blathered on about it above. So we'll see if
an initial direction isn't too far away.

Cheers,

Bruce


I will think more about this and in the same time gather more information on it.
I will try to come back with an answer.

  
Alex


-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, July 22, 2014 6:59 PM
To: akuster; Alexandru Vaduva; Joe MacDonald
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal

On 14-07-22 11:54 AM, akuster wrote:

Alexandru,

Regarding  a few packages in category C&D.

I have latest samhain building as well as grsecurity (pax patches
applied against 3.14.12) in a branch in my meta-security tree.  I have
a bit more testing to do before I was going to post them.

And on this note, we should consider the kernel parts and see if getting them 
into a common location is a good idea.

We already have the linux-yocto tree, and it tracks LTSI, has CVE and -stable 
tracking, and is maintained to support the set of reference boards.

Creating yet more reference kernel trees doesn't help our goal of fewer trees 
and a discrete set of kernel versions.

Just something to consider.

Cheers,

Bruce


grsecurity and samhain aren't CGL specific and they maybe belong in a
more generalize layer? just a thought.

regards,
Armin


On 07/22/2014 03:52 AM, Alexandru Vaduva wrote:

Hello Joe,

Here at Enea we are preparing the steps needed for publishing the
layer on the open embedded meta layers initiative:
http://layers.openembedded.org/layerindex/branch/master/layers/
For this we started working at a web page that should contain all the
relevant information regarding meta-cgl. It will be available in a
couple of weeks. Until then the layer will be available internally
and the patches should be submitted as the README states: on the
eneali...@lists.enea.com mailing list. We will try to make the switch
to Open Embedded mailing list as quick as possible.

Regarding the other B, C and D packages  that we will try to add into
the meta-cgl layer, I will post this information below, but keep in
mind that this information will also be available on the web page.
 Category B packages:
 - ifenslave
 - evlog
 - crash
 - mipv6-daemon-umip
 - openl2tp
 Category C&D packages:
 - drbd
 - grsecurity
 - logcheck
 - makedumpfile
 - numactl
 - ocfs2-tools
 - pam_passwdqc
 - samhain
 - ltt-usertrace
 - ftrace
The above lists correspond with only the P1 requirements that we try
to fulfill for the moment. If there are any questions and/or
suggestions regarding this CGL initialtive please address them to me
and I will try to offer a response in the shortest time possible.


Thanks,
Alex

-Original Message-
From: Joe MacDonald [mailto:j...@deserted.net]
Sent: Monday, July 21, 2014 10:58 PM
To: Alexandru Vaduva
Cc: Jeff Osier-Mixon; yocto@yoctoproject.org
Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal

Hey Alex,

I've been away from this for a bit but now I'm getting time to look
at it again and I was wondering if you had any deeper level of detail

Re: [yocto] Fwd: How to find the bb file from package name

[Anooj Gopi]

I would like to generalize my last question

A yocto PACKAGE,  generates an rpm package, 
with are different names due to an inherited class setting "PKG
"
variable.

When I try to add such a package to "TOOLCHAIN_HOST_TASK", it throws
following error during populate_sdk

Error:  not found in the base feeds (i686_nativesdk
noarch any all ).

Does anybody have a clue how to fix this?



On Tue, Jul 22, 2014 at 7:14 PM, Anooj Gopi  wrote:

> This package (nativesdk-libqt5core-dev-5.2.1-r1.i686_nativesdk.rpm) is not
> installed in my sdk sysroot. So I need to add it to TOOLCHAIN_HOST_TASK and
> see if it gets installed into my sdk sysroot
>
> But it fails with below error:
> Error: nativesdk-qtbase-tools-dev not found in the base feeds
> (i686_nativesdk noarch any all ).
>
> Any idea what is the problem here?
>
>
>
> On Tue, Jul 22, 2014 at 6:26 PM, Burton, Ross 
> wrote:
>
>> On 22 July 2014 17:19, Anooj Gopi  wrote:
>> > But I'm still not able to find out where in yocto PKG variable is
>> configured
>> > (which changes this rpm file name from the default one).
>>
>> Packages containing libraries get renamed through debian.bbclass.
>>
>> I'm not sure why you need to know the recipe name for adding packages
>> to a SDK though.
>>
>> Ross
>>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SELinux doesn't work on t4240qds

[Mark Hatle]

On 7/22/14, 10:11 AM, zhenhua@freescale.com wrote:

Hi all,


Which release are you using.  The last version I used w/ meta-selinux was the 
1.5 release.


We're planning on updating it to master in the 'near' future [patches welcome!], 
and I've been told by a few others of success w/ 1.7.


Did you enable the 'selinux' distribution flag?  If so, it should have enabled 
all of the components necessary for this stuff to be enabled.


--Mark


I use the meta-selinux layer to build a core-image-selinux rootfs image, and
build kernel with following options enabled.

CONFIG_AUDIT=y

CONFIG_NETWORK_SECMARK=y

CONFIG_EXT2_FS_SECURITY=y

CONFIG_EXT3_FS_SECURITY=y

CONFIG_EXT4_FS_SECURITY=y

CONFIG_JFS_SECURITY=y

CONFIG_REISERFS_FS_SECURITY=y

CONFIG_JFFS2_FS_SECURITY=y

CONFIG_SECURITY_NETWORK=y

CONFIG_SECURITY_SELINUX=y

CONFIG_SECURITY_SELINUX_BOOTPARAM=y

CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1

CONFIG_SECURITY_SELINUX_DISABLE=y

CONFIG_SECURITY_SELINUX_DEVELOP=y

CONFIG_SECURITY_SELINUX_AVC_STATS=y

CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1

I use the generated images to boot up FSL PPC t4240qds board(tried both NFS boot
and RAM boot with ext2.gz.u-boot rootfs), the SELinux is not turned on after
kernel boot up.

following is some information in rootfs.

root@t4240qds:~# sestatus

SELinux status: disabled

root@t4240qds:~#

root@t4240qds:~# cat /etc/selinux/config

# This file controls the state of SELinux on the system.

# SELINUX= can take one of these three values:

# enforcing - SELinux security policy is enforced.

# permissive - SELinux prints warnings instead of enforcing.

# disabled - No SELinux policy is loaded.

SELINUX=enforcing

# SELINUXTYPE= can take one of these two values:

# standard - Standard Security protection.

# mls - Multi Level Security protection.

SELINUXTYPE=mls

root@t4240qds:~# cat /proc/cmdline

root=/dev/ram rw console=ttyS0,115200 selinux=1

root@t4240qds:~# setenforce 1

setenforce: SELinux is disabled

root@t4240qds:~# getenforce

Disabled

root@t4240qds:~#

Can somebody shed some light on the issue?

Best Regards,

Zhenhua





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

Re: [yocto] [OE-core] Carrier Grade layer proposal

[Alexandru Vaduva]

Hello Bruce,

What I understand from your mail you suggest using the already available 
linux-yocto tree.
As an answer to this let me assure that as much as possible the meta-cgl layer 
will try to do that. If that will not be the case I will let the community know 
that.
One such case could be grsecurity(which as Joe mentioned changes the kernel 
quite much) I also expect more such examples exist.

Do you consider this subject needs a new email opened for it?
I will think more about this and in the same time gather more information on it.
I will try to come back with an answer.

 
Alex

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] 
Sent: Tuesday, July 22, 2014 6:59 PM
To: akuster; Alexandru Vaduva; Joe MacDonald
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal

On 14-07-22 11:54 AM, akuster wrote:
> Alexandru,
>
> Regarding  a few packages in category C&D.
>
> I have latest samhain building as well as grsecurity (pax patches 
> applied against 3.14.12) in a branch in my meta-security tree.  I have 
> a bit more testing to do before I was going to post them.

And on this note, we should consider the kernel parts and see if getting them 
into a common location is a good idea.

We already have the linux-yocto tree, and it tracks LTSI, has CVE and -stable 
tracking, and is maintained to support the set of reference boards.

Creating yet more reference kernel trees doesn't help our goal of fewer trees 
and a discrete set of kernel versions.

Just something to consider.

Cheers,

Bruce

>
> grsecurity and samhain aren't CGL specific and they maybe belong in a 
> more generalize layer? just a thought.
>
> regards,
> Armin
>
>
> On 07/22/2014 03:52 AM, Alexandru Vaduva wrote:
>> Hello Joe,
>>
>> Here at Enea we are preparing the steps needed for publishing the 
>> layer on the open embedded meta layers initiative:
>> http://layers.openembedded.org/layerindex/branch/master/layers/
>> For this we started working at a web page that should contain all the 
>> relevant information regarding meta-cgl. It will be available in a 
>> couple of weeks. Until then the layer will be available internally 
>> and the patches should be submitted as the README states: on the 
>> eneali...@lists.enea.com mailing list. We will try to make the switch 
>> to Open Embedded mailing list as quick as possible.
>>
>> Regarding the other B, C and D packages  that we will try to add into 
>> the meta-cgl layer, I will post this information below, but keep in 
>> mind that this information will also be available on the web page.
>> Category B packages:
>> - ifenslave
>> - evlog
>> - crash
>> - mipv6-daemon-umip
>> - openl2tp
>> Category C&D packages:
>> - drbd
>> - grsecurity
>> - logcheck
>> - makedumpfile
>> - numactl
>> - ocfs2-tools
>> - pam_passwdqc
>> - samhain
>> - ltt-usertrace
>> - ftrace
>> The above lists correspond with only the P1 requirements that we try 
>> to fulfill for the moment. If there are any questions and/or 
>> suggestions regarding this CGL initialtive please address them to me 
>> and I will try to offer a response in the shortest time possible.
>>
>>
>> Thanks,
>> Alex
>>
>> -Original Message-
>> From: Joe MacDonald [mailto:j...@deserted.net]
>> Sent: Monday, July 21, 2014 10:58 PM
>> To: Alexandru Vaduva
>> Cc: Jeff Osier-Mixon; yocto@yoctoproject.org
>> Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal
>>
>> Hey Alex,
>>
>> I've been away from this for a bit but now I'm getting time to look 
>> at it again and I was wondering if you had any deeper level of detail 
>> you could share about the work going on in meta-cgl.  Obviously since 
>> this is a new registration and one that will look rather different 
>> from all of the other CGL registrations currently, those of us in the 
>> CGL workgroup were quite interested to see this happen.  Personally 
>> I'm also interested in this since it's the kind of thing I've been 
>> doing for a long time now and if I can, I'd like to help out.  In 
>> particular, if you've got a list of, say, the category B+ items, that 
>> might be something I can do that will be independent of your work on 
>> the more active cat-A stuff.  OTOH, cat-A is easy to work on since 
>> those are the items I saw when I was working with meta-cgl a month or 
>> so back.  I know you guys are focused on your part of it, but if you 
>> had sort of a "here's how to help us" guide, that'd be awesome.
>>
>> Also, I probably missed it, but is the intent to use either the yocto 
>> list or the oe list for all meta-cgl discussions, or do you have a 
>> dedicated list we can sign up for?  I see you have guidance for 
>> sending submissions to meta-cgl, but is that a list that's open to 
>> the community, or is it an internal alias / distribution list for Enea?
>>
>> Thanks,
>> -J.
>>
>

Re: [yocto] Fwd: How to find the bb file from package name

[Anooj Gopi]

This package (nativesdk-libqt5core-dev-5.2.1-r1.i686_nativesdk.rpm) is not
installed in my sdk sysroot. So I need to add it to TOOLCHAIN_HOST_TASK and
see if it gets installed into my sdk sysroot

But it fails with below error:
Error: nativesdk-qtbase-tools-dev not found in the base feeds
(i686_nativesdk noarch any all ).

Any idea what is the problem here?



On Tue, Jul 22, 2014 at 6:26 PM, Burton, Ross  wrote:

> On 22 July 2014 17:19, Anooj Gopi  wrote:
> > But I'm still not able to find out where in yocto PKG variable is
> configured
> > (which changes this rpm file name from the default one).
>
> Packages containing libraries get renamed through debian.bbclass.
>
> I'm not sure why you need to know the recipe name for adding packages
> to a SDK though.
>
> Ross
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Fwd: How to find the bb file from package name

[Anooj Gopi]

Hello Bharath,

This is already known to me. The confusion mainly here was because of the
name of the rpm package. From the recipe expected name was
"nativesdk-qtbase-tools-dev-5.2.1-r1.i686_nativesdk.rpm" but generated
package name is "nativesdk-libqt5core-dev-5.2.1-r1.i686_nativesdk.rpm"
which confused me.

As Mr. Burton mentioned in his last mail, this was done by
"debian.bbclass", which makes our life more difficult. So I feel a tool to
track this relations is really necessary, and I guess yocto has done this
in Yocto 1.6 with "toaster
" (I still have
to use it and see).

Regards,
Anooj


On Tue, Jul 22, 2014 at 6:37 PM, Bharath Chandra 
wrote:

> Hi,
>
> you can find it under .inc file here
>
> https://github.com/meta-qt5/meta-qt5/blob/daisy/recipes-qt/qt5/nativesdk-qtbase.inc
>
> PACKAGES = "${PN}-tools-dbg *${PN}-tools-dev* ${PN}-tools-staticdev 
> ${PN}-tools"
>
> Thanks,
>
> Bharath
>
>
>
> On Tue, Jul 22, 2014 at 11:19 AM, Anooj Gopi  wrote:
>
>>
>> Oh sorry the link I sent was wrong. The correct one is
>> https://github.com/meta-qt5/meta-qt5/blob/daisy/recipes-qt/qt5/nativesdk-qtbase_5.2.1.bb
>>
>> Manually searching the bb/inc file did not help until this point.
>>
>> Now I enabled the build history (INHERIT += "buildhistory"
>> BUILDHISTORY_FEATURES = "image package sdk") and built the packages once
>> again. Then searched for the package name as shown below
>>
>> cd build/buildhistory/packages
>> grep -nri nativesdk-libqt5core-dev .
>> ./i686-nativesdk-oesdk-linux/nativesdk-qtbase/nativesdk-qtbase-tools-dev/latest:3:PKG
>> = nativesdk-libqt5core-dev
>>
>> which shows that the yocto package is "nativesdk-qtbase-tools-dev", which
>> is provided by "nativesdk-qtbase_5.2.1.bb".
>>
>> But I'm still not able to find out where in yocto PKG variable is
>> configured (which changes this rpm file name from the default one).
>>
>>
>>
>> On Tue, Jul 22, 2014 at 5:50 PM, Bharath Chandra <
>> ellurubharat...@gmail.com> wrote:
>>
>>> Hi Anooj,
>>>
>>> I guess you are looking at a wrong version of the recipe file, you have
>>> to look into version number 5.2.1 and revision r1 as your package name is
>>> suggesting but the link which you have mentioned is for 5.3.1 . Kindly,
>>> have a look into correct version number of recipe file and if you do not
>>> find any package name in the recipe file then you can search in *.inc*
>>> files which are included in that recipe file.
>>> for eg :
>>>
>>> require qt5-${PV}.inc
>>>
>>>
>>>
>>> You have to check in qt5-5.2.1.inc file and see if any package is included 
>>> with the name which you are searching for.
>>>
>>>
>>>
>>> Thanks & Regards,
>>> Bharath Chandra Elluru
>>>
>>>
>>>
>>> On Tue, Jul 22, 2014 at 6:52 AM, Anooj Gopi  wrote:
>>>

 Yes I am trying to track down the recipe from the rpm file. In my
 project yocto builds the rpm package
 "nativesdk-libqt5core-dev-5.2.1-r1.i686_nativesdk.rpm" (by
 https://github.com/meta-qt5/meta-qt5) but it is not included in my sdk
 sysroot image. So I would like to see how I could include this into my sdk.
 For that I am tracing back the recipe which generated the rpm.

 I tried as you said:
 From the source package name I can see it is from "Source RPM  :
 nativesdk-qtbase-5.2.1-r1.src.rpm", which means bb file is
 https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/qt5/nativesdk-qtbase_5.3.1.bb
 Now this from the bb file content I can see this file provides multiple
 packages, (for eg. nativesdk-qtbase-tools-dbg nativesdk-qtbase-tools-dev
 nativesdk-qtbase-tools-staticdev nativesdk-qtbase-tool) but I still could
 not find where it is configured to generate the package
 "nativesdk-libqt5core-dev-5.2.1-r1.i686_nativesdk.rpm".

 As Belen in his last mail, the tools like "Toaster" could confirm this
 (by listing the packages generated from a bb file), but is there any way I
 can do it in Yocto Project 1.5?

 Regards,
 Anooj


 On Tue, Jul 22, 2014 at 11:15 AM, Burton, Ross 
 wrote:

> On 21 July 2014 16:39, Anooj Gopi  wrote:
> > Could some one help me to understand how we could find the bb file
> which
> > generated particular package (rpm package for eg.)?
> > (In some cases the name of the package and recipe name differ
> drastically)
> >
> > Also is there any way to list packages (rpm) generated by particular
> recipe
> > (yocto package) easily. (without looking into the PACKAGES variable).
>
> It's probably best if you explain exactly what you want to do.
>
> If you want to work backwards from a RPM to the recipe, then binary
> RPMs have a Source RPM metadata field and the srpm is named after the
> recipe:
>
> $ rpm -qpi connman-tests-1.24-r0.15.corei7_64.rpm | grep Source
> Source RPM  : connman-1.24-r0.15.src.rpm
>
> Ross
>



 --
 __

Re: [yocto] Fwd: How to find the bb file from package name

[Bharath Chandra]

Hi,

you can find it under .inc file here
https://github.com/meta-qt5/meta-qt5/blob/daisy/recipes-qt/qt5/nativesdk-qtbase.inc

PACKAGES = "${PN}-tools-dbg *${PN}-tools-dev* ${PN}-tools-staticdev ${PN}-tools"

Thanks,

Bharath



On Tue, Jul 22, 2014 at 11:19 AM, Anooj Gopi  wrote:

>
> Oh sorry the link I sent was wrong. The correct one is
> https://github.com/meta-qt5/meta-qt5/blob/daisy/recipes-qt/qt5/nativesdk-qtbase_5.2.1.bb
>
> Manually searching the bb/inc file did not help until this point.
>
> Now I enabled the build history (INHERIT += "buildhistory"
> BUILDHISTORY_FEATURES = "image package sdk") and built the packages once
> again. Then searched for the package name as shown below
>
> cd build/buildhistory/packages
> grep -nri nativesdk-libqt5core-dev .
> ./i686-nativesdk-oesdk-linux/nativesdk-qtbase/nativesdk-qtbase-tools-dev/latest:3:PKG
> = nativesdk-libqt5core-dev
>
> which shows that the yocto package is "nativesdk-qtbase-tools-dev", which
> is provided by "nativesdk-qtbase_5.2.1.bb".
>
> But I'm still not able to find out where in yocto PKG variable is
> configured (which changes this rpm file name from the default one).
>
>
>
> On Tue, Jul 22, 2014 at 5:50 PM, Bharath Chandra <
> ellurubharat...@gmail.com> wrote:
>
>> Hi Anooj,
>>
>> I guess you are looking at a wrong version of the recipe file, you have
>> to look into version number 5.2.1 and revision r1 as your package name is
>> suggesting but the link which you have mentioned is for 5.3.1 . Kindly,
>> have a look into correct version number of recipe file and if you do not
>> find any package name in the recipe file then you can search in *.inc*
>> files which are included in that recipe file.
>> for eg :
>>
>> require qt5-${PV}.inc
>>
>>
>> You have to check in qt5-5.2.1.inc file and see if any package is included 
>> with the name which you are searching for.
>>
>>
>> Thanks & Regards,
>> Bharath Chandra Elluru
>>
>>
>>
>> On Tue, Jul 22, 2014 at 6:52 AM, Anooj Gopi  wrote:
>>
>>>
>>> Yes I am trying to track down the recipe from the rpm file. In my
>>> project yocto builds the rpm package
>>> "nativesdk-libqt5core-dev-5.2.1-r1.i686_nativesdk.rpm" (by
>>> https://github.com/meta-qt5/meta-qt5) but it is not included in my sdk
>>> sysroot image. So I would like to see how I could include this into my sdk.
>>> For that I am tracing back the recipe which generated the rpm.
>>>
>>> I tried as you said:
>>> From the source package name I can see it is from "Source RPM  :
>>> nativesdk-qtbase-5.2.1-r1.src.rpm", which means bb file is
>>> https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/qt5/nativesdk-qtbase_5.3.1.bb
>>> Now this from the bb file content I can see this file provides multiple
>>> packages, (for eg. nativesdk-qtbase-tools-dbg nativesdk-qtbase-tools-dev
>>> nativesdk-qtbase-tools-staticdev nativesdk-qtbase-tool) but I still could
>>> not find where it is configured to generate the package
>>> "nativesdk-libqt5core-dev-5.2.1-r1.i686_nativesdk.rpm".
>>>
>>> As Belen in his last mail, the tools like "Toaster" could confirm this
>>> (by listing the packages generated from a bb file), but is there any way I
>>> can do it in Yocto Project 1.5?
>>>
>>> Regards,
>>> Anooj
>>>
>>>
>>> On Tue, Jul 22, 2014 at 11:15 AM, Burton, Ross 
>>> wrote:
>>>
 On 21 July 2014 16:39, Anooj Gopi  wrote:
 > Could some one help me to understand how we could find the bb file
 which
 > generated particular package (rpm package for eg.)?
 > (In some cases the name of the package and recipe name differ
 drastically)
 >
 > Also is there any way to list packages (rpm) generated by particular
 recipe
 > (yocto package) easily. (without looking into the PACKAGES variable).

 It's probably best if you explain exactly what you want to do.

 If you want to work backwards from a RPM to the recipe, then binary
 RPMs have a Source RPM metadata field and the srpm is named after the
 recipe:

 $ rpm -qpi connman-tests-1.24-r0.15.corei7_64.rpm | grep Source
 Source RPM  : connman-1.24-r0.15.src.rpm

 Ross

>>>
>>>
>>>
>>> --
>>> ___
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>>
>>
>>
>> --
>> Thanks & Regards,
>> Bharath Chandra Elluru.
>> Contact Number:785-979-4875.
>>
>
>


-- 
Thanks & Regards,
Bharath Chandra Elluru.
Contact Number:785-979-4875.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Fwd: How to find the bb file from package name

[Burton, Ross]

On 22 July 2014 17:19, Anooj Gopi  wrote:
> But I'm still not able to find out where in yocto PKG variable is configured
> (which changes this rpm file name from the default one).

Packages containing libraries get renamed through debian.bbclass.

I'm not sure why you need to know the recipe name for adding packages
to a SDK though.

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

Re: [yocto] [OE-core] Carrier Grade layer proposal

[Alexandru Vaduva]

Glad to hear that Bruce.



On Tuesday, July 22, 2014 7:09 PM, Bruce Ashfield 
 wrote:
 


On 14-07-22 12:02 PM, akuster wrote:
>
> On 07/22/2014 08:58 AM, Bruce Ashfield wrote:
>> On 14-07-22 11:54 AM, akuster wrote:
>>> Alexandru,
>>>
>>> Regarding  a few packages in category C&D.
>>>
>>> I have latest samhain building as well as grsecurity (pax patches
>>> applied against 3.14.12) in a branch in my meta-security tree. I have a
>>> bit more testing to do before I was going to post them.
>>
>> And on this note, we should consider the kernel parts and see if getting
>> them into a common location is a good idea.
>>
> yep.
>
>> We already have the linux-yocto tree, and it tracks LTSI, has CVE and
>> -stable tracking, and is maintained to support the set of reference
>> boards.
>>
>> Creating yet more reference kernel trees doesn't help our goal of
>> fewer trees and a discrete set of kernel versions.
>
> Agreed.

Great, glad to hear.

I wasn't trying to divert the discussion, just seeing if there
was anywhere I could help.

I know for certain that Joe has a LOT of experience with grsec, and
I've been helping maintain its 'tentacles' for a long time, so I'm
sure we can come up with something workable when the time is right.

Cheers,


Bruce

>
> thanks,
> Armin
>>
>> Just something to consider.
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>> grsecurity and samhain aren't CGL specific and they maybe belong in a
>>> more generalize layer? just a thought.
>>>
>>> regards,
>>> Armin
>>>
>>>
>>> On 07/22/2014 03:52 AM, Alexandru Vaduva wrote:
 Hello Joe,

 Here at Enea we are preparing the steps needed for publishing the
 layer on the open embedded meta layers initiative:
 http://layers.openembedded.org/layerindex/branch/master/layers/
 For this we started working at a web page that should contain all the
 relevant information regarding meta-cgl. It will be available in a
 couple of weeks. Until then the layer will be available internally and
 the patches should
 be submitted as the README states: on the eneali...@lists.enea.com
 mailing list. We will try to make the switch to Open Embedded mailing
 list as quick as possible.

 Regarding the other B, C and D packages  that we will try to add into
 the meta-cgl layer, I will post this information below, but keep in
 mind that this information will also be available on the web page.
     Category B packages:
         - ifenslave
         - evlog
         - crash
         - mipv6-daemon-umip
         - openl2tp
     Category C&D packages:
         - drbd
         - grsecurity
         - logcheck
         - makedumpfile
         - numactl
         - ocfs2-tools
         - pam_passwdqc
         - samhain
         - ltt-usertrace
         - ftrace
 The above lists correspond with only the P1 requirements that we try
 to fulfill for the moment. If there are any questions and/or
 suggestions regarding this CGL initialtive please address them to me
 and I will try to offer a response in the
 shortest time possible.


 Thanks,
 Alex

 -Original Message-
 From: Joe MacDonald [mailto:j...@deserted.net]
 Sent: Monday, July 21, 2014 10:58 PM
 To: Alexandru Vaduva
 Cc: Jeff Osier-Mixon; yocto@yoctoproject.org
 Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal

 Hey Alex,

 I've been away from this for a bit but now I'm getting time to look at
 it again and I was wondering if you had any deeper level of detail you
 could share about the work going on in meta-cgl.  Obviously since this
 is a new registration and one that will look rather different from all
 of the other CGL registrations currently, those of us in the CGL
 workgroup were quite interested to see this happen. Personally I'm
 also interested in this since it's the kind of thing I've been doing
 for a long time now and if I can, I'd like to help out.  In
 particular, if you've got a list of, say, the category B+ items, that
 might be something I can do that will be independent of your work on
 the more active cat-A stuff.  OTOH, cat-A is easy to work on since
 those are the items I saw when I was working with meta-cgl a month or
 so back.  I know you guys are focused on your part of it, but if you
 had sort of a "here's how to help us" guide, that'd be awesome.

 Also, I probably missed it, but is the intent to use either the yocto
 list or the oe list for all meta-cgl discussions, or do you have a
 dedicated list we can sign up for?  I see you have guidance for
 sending submissions to meta-cgl, but is that a list that's open to the
 community, or is it an internal alias / distribution list for Enea?

 Thanks,
 -J.


 On Mon, Jul 7, 2014 at 2:43 PM, Alexandru Vaduva
  wrote:
> Hello Jeff,
>
>>

Re: [yocto] [OE-core] Carrier Grade layer proposal

[Alexandru Vaduva]

OK, thanks for the information and your contribution.
I am not opposing to your suggestion but in the same time I believe that this 
recipe should appear in a properly maintained layer, in the case your layer 
disappears tomorrow. As you mentioned this information should appear in the 
mainline meta-security layer. In that case I will use the recipe without adding 
it into meta-cgl because we do not plan to have duplicate recipes available in 
meta-cgl layer if this is not applicable.

Alex



On Tuesday, July 22, 2014 6:54 PM, akuster  wrote:
 


Alexandru,

Regarding  a few packages in category C&D.

I have latest samhain building as well as grsecurity (pax patches 
applied against 3.14.12) in a branch in my meta-security tree.  I have a 
bit more testing to do before I was going to post them.

grsecurity and samhain aren't CGL specific and they maybe belong in a 
more generalize layer? just a thought.

regards,
Armin



On 07/22/2014 03:52 AM, Alexandru Vaduva wrote:
> Hello Joe,
>
> Here at Enea we are preparing the steps needed for publishing the layer on 
> the open embedded meta layers initiative: 
> http://layers.openembedded.org/layerindex/branch/master/layers/
> For this we started working at a web page that should contain all the 
> relevant information regarding meta-cgl. It will be available in a couple of 
> weeks. Until then the layer will be available internally and the patches 
> should
> be submitted as the README states: on the eneali...@lists.enea.com mailing 
> list. We will try to make the switch to Open Embedded mailing list as quick 
> as possible.
>
> Regarding the other B, C and D packages  that we will try to add into the 
> meta-cgl layer, I will post this information below, but keep in mind that 
> this information will also be available on the web page.
>     Category B packages:
>         - ifenslave
>         - evlog
>         - crash
>         - mipv6-daemon-umip
>         - openl2tp
>     Category C&D packages:
>         - drbd
>         - grsecurity
>         -
 logcheck
>         - makedumpfile
>         - numactl
>         - ocfs2-tools
>         - pam_passwdqc
>         - samhain
>         - ltt-usertrace
>         - ftrace
> The above lists correspond with only the P1 requirements that we try to 
> fulfill for the moment. If there are any questions and/or suggestions 
> regarding this CGL initialtive please address them to me and I will try to 
> offer a response in the
> shortest time possible.
>
>
> Thanks,
> Alex
>
>
 -Original Message-
> From: Joe MacDonald [mailto:j...@deserted.net]
> Sent: Monday, July 21, 2014 10:58 PM
> To: Alexandru Vaduva
> Cc: Jeff Osier-Mixon; yocto@yoctoproject.org
> Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal
>
> Hey Alex,
>
> I've been away from this for a bit but now I'm getting time to look at it 
> again and I was wondering if you had any deeper level of detail you could 
> share about the work going on in meta-cgl.  Obviously since this is a new 
> registration and one that will look rather different from all of the other 
> CGL registrations currently, those of us in the
 CGL workgroup were quite interested to see this happen.  Personally I'm also 
interested in this since it's the kind of thing I've been doing for a long time 
now and if I can, I'd like to help out.  In particular, if you've got a list 
of, say, the category B+ items, that might be something I can do that will be 
independent of your work on the more active cat-A stuff.  OTOH, cat-A is easy 
to work on since those are the items I saw when I was working with meta-cgl a 
month or so back.  I know you guys are focused on your part of it, but if you 
had sort of a "here's how to help us" guide, that'd be awesome.
>
> Also, I probably missed it, but is the intent to use either the yocto list or 
> the oe list for all meta-cgl discussions, or do you have a dedicated list we 
> can sign up for?  I see you have guidance for sending submissions to 
> meta-cgl, but is that a list that's open to the community, or is
 it an internal alias / distribution list for Enea?
>
> Thanks,
> -J.
>
>
> On Mon, Jul 7, 2014 at 2:43 PM, Alexandru Vaduva  
> wrote:
>> Hello Jeff,
>>
>> The errors are package related.
>> Meta-cgl can be seen as a non BSP specific layer (it can be viewed as the 
>> LSB from poky).
>> I already started fixing a number, of the already existing errors and the 
>> patches will be added upstream after proper testing.
>> I will continue the bug fixing and package integration (into the
>> core-image-cgl image) process and after that is finished I will continue 
>> with the
 Category B packages.
>>
>> I will also try to keep you guys informed about the latest updates,
>> mainly on the YPTM, but for those who cannot wait that much, there is
>> the Git repository with which they can interact:
>> http://git.enea.com/git/?p=linux/meta-cgl.git;a=summary
>>
>>
>> Have a good day,
>> Alex
>>
>>
>> -Original Message-
>> From: jefro@gmail.c

Re: [yocto] Fwd: How to find the bb file from package name

[Anooj Gopi]

Oh sorry the link I sent was wrong. The correct one is
https://github.com/meta-qt5/meta-qt5/blob/daisy/recipes-qt/qt5/nativesdk-qtbase_5.2.1.bb

Manually searching the bb/inc file did not help until this point.

Now I enabled the build history (INHERIT += "buildhistory"
BUILDHISTORY_FEATURES = "image package sdk") and built the packages once
again. Then searched for the package name as shown below

cd build/buildhistory/packages
grep -nri nativesdk-libqt5core-dev .
./i686-nativesdk-oesdk-linux/nativesdk-qtbase/nativesdk-qtbase-tools-dev/latest:3:PKG
= nativesdk-libqt5core-dev

which shows that the yocto package is "nativesdk-qtbase-tools-dev", which
is provided by "nativesdk-qtbase_5.2.1.bb".

But I'm still not able to find out where in yocto PKG variable is
configured (which changes this rpm file name from the default one).



On Tue, Jul 22, 2014 at 5:50 PM, Bharath Chandra 
wrote:

> Hi Anooj,
>
> I guess you are looking at a wrong version of the recipe file, you have to
> look into version number 5.2.1 and revision r1 as your package name is
> suggesting but the link which you have mentioned is for 5.3.1 . Kindly,
> have a look into correct version number of recipe file and if you do not
> find any package name in the recipe file then you can search in *.inc*
> files which are included in that recipe file.
> for eg :
>
> require qt5-${PV}.inc
>
> You have to check in qt5-5.2.1.inc file and see if any package is included 
> with the name which you are searching for.
>
> Thanks & Regards,
> Bharath Chandra Elluru
>
>
>
> On Tue, Jul 22, 2014 at 6:52 AM, Anooj Gopi  wrote:
>
>>
>> Yes I am trying to track down the recipe from the rpm file. In my project
>> yocto builds the rpm package
>> "nativesdk-libqt5core-dev-5.2.1-r1.i686_nativesdk.rpm" (by
>> https://github.com/meta-qt5/meta-qt5) but it is not included in my sdk
>> sysroot image. So I would like to see how I could include this into my sdk.
>> For that I am tracing back the recipe which generated the rpm.
>>
>> I tried as you said:
>> From the source package name I can see it is from "Source RPM  :
>> nativesdk-qtbase-5.2.1-r1.src.rpm", which means bb file is
>> https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/qt5/nativesdk-qtbase_5.3.1.bb
>> Now this from the bb file content I can see this file provides multiple
>> packages, (for eg. nativesdk-qtbase-tools-dbg nativesdk-qtbase-tools-dev
>> nativesdk-qtbase-tools-staticdev nativesdk-qtbase-tool) but I still could
>> not find where it is configured to generate the package
>> "nativesdk-libqt5core-dev-5.2.1-r1.i686_nativesdk.rpm".
>>
>> As Belen in his last mail, the tools like "Toaster" could confirm this
>> (by listing the packages generated from a bb file), but is there any way I
>> can do it in Yocto Project 1.5?
>>
>> Regards,
>> Anooj
>>
>>
>> On Tue, Jul 22, 2014 at 11:15 AM, Burton, Ross 
>> wrote:
>>
>>> On 21 July 2014 16:39, Anooj Gopi  wrote:
>>> > Could some one help me to understand how we could find the bb file
>>> which
>>> > generated particular package (rpm package for eg.)?
>>> > (In some cases the name of the package and recipe name differ
>>> drastically)
>>> >
>>> > Also is there any way to list packages (rpm) generated by particular
>>> recipe
>>> > (yocto package) easily. (without looking into the PACKAGES variable).
>>>
>>> It's probably best if you explain exactly what you want to do.
>>>
>>> If you want to work backwards from a RPM to the recipe, then binary
>>> RPMs have a Source RPM metadata field and the srpm is named after the
>>> recipe:
>>>
>>> $ rpm -qpi connman-tests-1.24-r0.15.corei7_64.rpm | grep Source
>>> Source RPM  : connman-1.24-r0.15.src.rpm
>>>
>>> Ross
>>>
>>
>>
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>
>
> --
> Thanks & Regards,
> Bharath Chandra Elluru.
> Contact Number:785-979-4875.
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] Carrier Grade layer proposal

[akuster]

On 07/22/2014 08:58 AM, Bruce Ashfield wrote:

On 14-07-22 11:54 AM, akuster wrote:

Alexandru,

Regarding  a few packages in category C&D.

I have latest samhain building as well as grsecurity (pax patches
applied against 3.14.12) in a branch in my meta-security tree. I have a
bit more testing to do before I was going to post them.


And on this note, we should consider the kernel parts and see if getting
them into a common location is a good idea.


yep.


We already have the linux-yocto tree, and it tracks LTSI, has CVE and
-stable tracking, and is maintained to support the set of reference
boards.

Creating yet more reference kernel trees doesn't help our goal of
fewer trees and a discrete set of kernel versions.


Agreed.

thanks,
Armin


Just something to consider.

Cheers,

Bruce



grsecurity and samhain aren't CGL specific and they maybe belong in a
more generalize layer? just a thought.

regards,
Armin


On 07/22/2014 03:52 AM, Alexandru Vaduva wrote:

Hello Joe,

Here at Enea we are preparing the steps needed for publishing the
layer on the open embedded meta layers initiative:
http://layers.openembedded.org/layerindex/branch/master/layers/
For this we started working at a web page that should contain all the
relevant information regarding meta-cgl. It will be available in a
couple of weeks. Until then the layer will be available internally and
the patches should
be submitted as the README states: on the eneali...@lists.enea.com
mailing list. We will try to make the switch to Open Embedded mailing
list as quick as possible.

Regarding the other B, C and D packages  that we will try to add into
the meta-cgl layer, I will post this information below, but keep in
mind that this information will also be available on the web page.
Category B packages:
- ifenslave
- evlog
- crash
- mipv6-daemon-umip
- openl2tp
Category C&D packages:
- drbd
- grsecurity
- logcheck
- makedumpfile
- numactl
- ocfs2-tools
- pam_passwdqc
- samhain
- ltt-usertrace
- ftrace
The above lists correspond with only the P1 requirements that we try
to fulfill for the moment. If there are any questions and/or
suggestions regarding this CGL initialtive please address them to me
and I will try to offer a response in the
shortest time possible.


Thanks,
Alex

-Original Message-
From: Joe MacDonald [mailto:j...@deserted.net]
Sent: Monday, July 21, 2014 10:58 PM
To: Alexandru Vaduva
Cc: Jeff Osier-Mixon; yocto@yoctoproject.org
Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal

Hey Alex,

I've been away from this for a bit but now I'm getting time to look at
it again and I was wondering if you had any deeper level of detail you
could share about the work going on in meta-cgl.  Obviously since this
is a new registration and one that will look rather different from all
of the other CGL registrations currently, those of us in the CGL
workgroup were quite interested to see this happen. Personally I'm
also interested in this since it's the kind of thing I've been doing
for a long time now and if I can, I'd like to help out.  In
particular, if you've got a list of, say, the category B+ items, that
might be something I can do that will be independent of your work on
the more active cat-A stuff.  OTOH, cat-A is easy to work on since
those are the items I saw when I was working with meta-cgl a month or
so back.  I know you guys are focused on your part of it, but if you
had sort of a "here's how to help us" guide, that'd be awesome.

Also, I probably missed it, but is the intent to use either the yocto
list or the oe list for all meta-cgl discussions, or do you have a
dedicated list we can sign up for?  I see you have guidance for
sending submissions to meta-cgl, but is that a list that's open to the
community, or is it an internal alias / distribution list for Enea?

Thanks,
-J.


On Mon, Jul 7, 2014 at 2:43 PM, Alexandru Vaduva
 wrote:

Hello Jeff,

The errors are package related.
Meta-cgl can be seen as a non BSP specific layer (it can be viewed as
the LSB from poky).
I already started fixing a number, of the already existing errors and
the patches will be added upstream after proper testing.
I will continue the bug fixing and package integration (into the
core-image-cgl image) process and after that is finished I will
continue with the Category B packages.

I will also try to keep you guys informed about the latest updates,
mainly on the YPTM, but for those who cannot wait that much, there is
the Git repository with which they can interact:
http://git.enea.com/git/?p=linux/meta-cgl.git;a=summary


Have a good day,
Alex


-Original Message-
From: jefro@gmail.com [mailto:jefro@gmail.com] On Behalf Of
Jeff Osier-Mixon
Sent: Monday, July 07, 2014 9:22 PM
To: Alexandru Vaduva
Subject: Re: [OE-core] Carrier Grade layer proposal

Thanks, Alex.

Others on the mailing lists, if you have any

Re: [yocto] [OE-core] Carrier Grade layer proposal

[Bruce Ashfield]

On 14-07-22 12:02 PM, akuster wrote:


On 07/22/2014 08:58 AM, Bruce Ashfield wrote:

On 14-07-22 11:54 AM, akuster wrote:

Alexandru,

Regarding  a few packages in category C&D.

I have latest samhain building as well as grsecurity (pax patches
applied against 3.14.12) in a branch in my meta-security tree. I have a
bit more testing to do before I was going to post them.


And on this note, we should consider the kernel parts and see if getting
them into a common location is a good idea.


yep.


We already have the linux-yocto tree, and it tracks LTSI, has CVE and
-stable tracking, and is maintained to support the set of reference
boards.

Creating yet more reference kernel trees doesn't help our goal of
fewer trees and a discrete set of kernel versions.


Agreed.


Great, glad to hear.

I wasn't trying to divert the discussion, just seeing if there
was anywhere I could help.

I know for certain that Joe has a LOT of experience with grsec, and
I've been helping maintain its 'tentacles' for a long time, so I'm
sure we can come up with something workable when the time is right.

Cheers,

Bruce



thanks,
Armin


Just something to consider.

Cheers,

Bruce



grsecurity and samhain aren't CGL specific and they maybe belong in a
more generalize layer? just a thought.

regards,
Armin


On 07/22/2014 03:52 AM, Alexandru Vaduva wrote:

Hello Joe,

Here at Enea we are preparing the steps needed for publishing the
layer on the open embedded meta layers initiative:
http://layers.openembedded.org/layerindex/branch/master/layers/
For this we started working at a web page that should contain all the
relevant information regarding meta-cgl. It will be available in a
couple of weeks. Until then the layer will be available internally and
the patches should
be submitted as the README states: on the eneali...@lists.enea.com
mailing list. We will try to make the switch to Open Embedded mailing
list as quick as possible.

Regarding the other B, C and D packages  that we will try to add into
the meta-cgl layer, I will post this information below, but keep in
mind that this information will also be available on the web page.
Category B packages:
- ifenslave
- evlog
- crash
- mipv6-daemon-umip
- openl2tp
Category C&D packages:
- drbd
- grsecurity
- logcheck
- makedumpfile
- numactl
- ocfs2-tools
- pam_passwdqc
- samhain
- ltt-usertrace
- ftrace
The above lists correspond with only the P1 requirements that we try
to fulfill for the moment. If there are any questions and/or
suggestions regarding this CGL initialtive please address them to me
and I will try to offer a response in the
shortest time possible.


Thanks,
Alex

-Original Message-
From: Joe MacDonald [mailto:j...@deserted.net]
Sent: Monday, July 21, 2014 10:58 PM
To: Alexandru Vaduva
Cc: Jeff Osier-Mixon; yocto@yoctoproject.org
Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal

Hey Alex,

I've been away from this for a bit but now I'm getting time to look at
it again and I was wondering if you had any deeper level of detail you
could share about the work going on in meta-cgl.  Obviously since this
is a new registration and one that will look rather different from all
of the other CGL registrations currently, those of us in the CGL
workgroup were quite interested to see this happen. Personally I'm
also interested in this since it's the kind of thing I've been doing
for a long time now and if I can, I'd like to help out.  In
particular, if you've got a list of, say, the category B+ items, that
might be something I can do that will be independent of your work on
the more active cat-A stuff.  OTOH, cat-A is easy to work on since
those are the items I saw when I was working with meta-cgl a month or
so back.  I know you guys are focused on your part of it, but if you
had sort of a "here's how to help us" guide, that'd be awesome.

Also, I probably missed it, but is the intent to use either the yocto
list or the oe list for all meta-cgl discussions, or do you have a
dedicated list we can sign up for?  I see you have guidance for
sending submissions to meta-cgl, but is that a list that's open to the
community, or is it an internal alias / distribution list for Enea?

Thanks,
-J.


On Mon, Jul 7, 2014 at 2:43 PM, Alexandru Vaduva
 wrote:

Hello Jeff,

The errors are package related.
Meta-cgl can be seen as a non BSP specific layer (it can be viewed as
the LSB from poky).
I already started fixing a number, of the already existing errors and
the patches will be added upstream after proper testing.
I will continue the bug fixing and package integration (into the
core-image-cgl image) process and after that is finished I will
continue with the Category B packages.

I will also try to keep you guys informed about the latest updates,
mainly on the YPTM, but for those who cannot wait that much, there is
the Git repository with which they can

Re: [yocto] [prelink-cross][PATCH] Always create a conflict for R_ARM_TLS_DESC relocs

[Mark Hatle]

Thanks for the patch, I'll get it integrated later today.

(What a nasty problem for such a simple fix.)

--Mark

On 7/22/14, 9:50 AM, Maciej W. Rozycki wrote:

Hi,

  This is a bit obscure.  In my testing, for the purpose of upstreaming, of
the glibc change to support ARM TLS descriptors in prelinked binaries (cf
upstream BZ #17078, https://sourceware.org/bugzilla/show_bug.cgi?id=17078)
I have come across a problem where all programs prelinked against glibc
binaries using ARM TLS descriptors themselves segfaulted in the normal
exit path, where libc.so's own TLS destructors are called.  I have tracked
it down to the GOT entry (pointed to by the DT_TLSDESC_GOT dynamic tag)
meant to point to the lazy TLS descriptor resolver (pointed to by the
DT_TLSDESC_PLT dynamic tag) being left uninitialised and therefore NULL.
An attempt to call that resolver caused therefore a segfault.

  The cause of this lack of initialisation turned out to be an omission in
the original fix (dated 2011-04-13 in ChangeLog.cross), that didn't ensure
that a conflict entry is created even for these R_ARM_TLS_DESC relocations
that refer to a local symbol.  Somehow it didn't trigger in testing back
when implemented, perhaps glibc didn't require or access the missing entry
in code handling TLS destructors then.  Such an entry is needed, because
for prelinked binaries the DT_TLSDESC_GOT GOT entry is only initialised by
the dynamic linker when a conflict is resolved.  The change below enforces
this conflict entry creation.

  This fix removes 33 failures in prelink testing with glibc built using
ARM TLS descriptors, that is with the `-mtls-dialect=gnu2' GCC option in
effect (that is not the default unless explicitly requested at GCC build
time):

FAIL -> PASS: default/prelink.sum:cxx1.sh
FAIL -> PASS: default/prelink.sum:cxx2.sh
FAIL -> PASS: default/prelink.sum:cxx3.sh
FAIL -> PASS: default/prelink.sum:layout1.sh
FAIL -> PASS: default/prelink.sum:layout2.sh
FAIL -> PASS: default/prelink.sum:reloc1.sh
FAIL -> PASS: default/prelink.sum:reloc10.sh
FAIL -> PASS: default/prelink.sum:reloc11.sh
FAIL -> PASS: default/prelink.sum:reloc2.sh
FAIL -> PASS: default/prelink.sum:reloc3.sh
FAIL -> PASS: default/prelink.sum:reloc4.sh
FAIL -> PASS: default/prelink.sum:reloc5.sh
FAIL -> PASS: default/prelink.sum:reloc6.sh
FAIL -> PASS: default/prelink.sum:reloc7.sh
FAIL -> PASS: default/prelink.sum:reloc8.sh
FAIL -> PASS: default/prelink.sum:reloc9.sh
FAIL -> PASS: default/prelink.sum:shuffle1.sh
FAIL -> PASS: default/prelink.sum:shuffle2.sh
FAIL -> PASS: default/prelink.sum:shuffle3.sh
FAIL -> PASS: default/prelink.sum:shuffle4.sh
FAIL -> PASS: default/prelink.sum:shuffle5.sh
FAIL -> PASS: default/prelink.sum:shuffle6.sh
FAIL -> PASS: default/prelink.sum:shuffle7.sh
FAIL -> PASS: default/prelink.sum:shuffle8.sh
FAIL -> PASS: default/prelink.sum:shuffle9.sh
FAIL -> PASS: default/prelink.sum:tls1.sh
FAIL -> PASS: default/prelink.sum:tls2.sh
FAIL -> PASS: default/prelink.sum:tls3.sh
FAIL -> PASS: default/prelink.sum:tls4.sh
FAIL -> PASS: default/prelink.sum:tls5.sh
FAIL -> PASS: default/prelink.sum:tls6.sh
FAIL -> PASS: default/prelink.sum:tls7.sh
FAIL -> PASS: default/prelink.sum:undo1.sh

  Please apply.

2014-07-22  Maciej W. Rozycki  

* src/arch-arm.c (arm_prelink_conflict_rel): Always create a
conflict for R_ARM_TLS_DESC relocs.
(arm_prelink_conflict_rela): Likewise.

   Maciej

prelink-arm-tlsdesc-conflict-always.diff
Index: trunk/src/arch-arm.c
===
--- trunk.orig/src/arch-arm.c   2014-07-17 23:26:08.0 +0100
+++ trunk/src/arch-arm.c2014-07-18 04:18:53.790564615 +0100
@@ -416,7 +416,9 @@ arm_prelink_conflict_rel (DSO *dso, stru
case R_ARM_TLS_DTPMOD32:
case R_ARM_TLS_TPOFF32:
  break;
-
+   /* Likewise TLS_DESC.  */
+   case R_ARM_TLS_DESC:
+ break;
default:
  return 0;
}
@@ -526,7 +528,9 @@ arm_prelink_conflict_rela (DSO *dso, str
case R_ARM_TLS_DTPMOD32:
case R_ARM_TLS_TPOFF32:
  break;
-
+   /* Likewise TLS_DESC.  */
+   case R_ARM_TLS_DESC:
+ break;
default:
  return 0;
}



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

Re: [yocto] [OE-core] Carrier Grade layer proposal

[Bruce Ashfield]

On 14-07-22 11:54 AM, akuster wrote:

Alexandru,

Regarding  a few packages in category C&D.

I have latest samhain building as well as grsecurity (pax patches
applied against 3.14.12) in a branch in my meta-security tree.  I have a
bit more testing to do before I was going to post them.


And on this note, we should consider the kernel parts and see if getting
them into a common location is a good idea.

We already have the linux-yocto tree, and it tracks LTSI, has CVE and
-stable tracking, and is maintained to support the set of reference
boards.

Creating yet more reference kernel trees doesn't help our goal of
fewer trees and a discrete set of kernel versions.

Just something to consider.

Cheers,

Bruce



grsecurity and samhain aren't CGL specific and they maybe belong in a
more generalize layer? just a thought.

regards,
Armin


On 07/22/2014 03:52 AM, Alexandru Vaduva wrote:

Hello Joe,

Here at Enea we are preparing the steps needed for publishing the
layer on the open embedded meta layers initiative:
http://layers.openembedded.org/layerindex/branch/master/layers/
For this we started working at a web page that should contain all the
relevant information regarding meta-cgl. It will be available in a
couple of weeks. Until then the layer will be available internally and
the patches should
be submitted as the README states: on the eneali...@lists.enea.com
mailing list. We will try to make the switch to Open Embedded mailing
list as quick as possible.

Regarding the other B, C and D packages  that we will try to add into
the meta-cgl layer, I will post this information below, but keep in
mind that this information will also be available on the web page.
Category B packages:
- ifenslave
- evlog
- crash
- mipv6-daemon-umip
- openl2tp
Category C&D packages:
- drbd
- grsecurity
- logcheck
- makedumpfile
- numactl
- ocfs2-tools
- pam_passwdqc
- samhain
- ltt-usertrace
- ftrace
The above lists correspond with only the P1 requirements that we try
to fulfill for the moment. If there are any questions and/or
suggestions regarding this CGL initialtive please address them to me
and I will try to offer a response in the
shortest time possible.


Thanks,
Alex

-Original Message-
From: Joe MacDonald [mailto:j...@deserted.net]
Sent: Monday, July 21, 2014 10:58 PM
To: Alexandru Vaduva
Cc: Jeff Osier-Mixon; yocto@yoctoproject.org
Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal

Hey Alex,

I've been away from this for a bit but now I'm getting time to look at
it again and I was wondering if you had any deeper level of detail you
could share about the work going on in meta-cgl.  Obviously since this
is a new registration and one that will look rather different from all
of the other CGL registrations currently, those of us in the CGL
workgroup were quite interested to see this happen.  Personally I'm
also interested in this since it's the kind of thing I've been doing
for a long time now and if I can, I'd like to help out.  In
particular, if you've got a list of, say, the category B+ items, that
might be something I can do that will be independent of your work on
the more active cat-A stuff.  OTOH, cat-A is easy to work on since
those are the items I saw when I was working with meta-cgl a month or
so back.  I know you guys are focused on your part of it, but if you
had sort of a "here's how to help us" guide, that'd be awesome.

Also, I probably missed it, but is the intent to use either the yocto
list or the oe list for all meta-cgl discussions, or do you have a
dedicated list we can sign up for?  I see you have guidance for
sending submissions to meta-cgl, but is that a list that's open to the
community, or is it an internal alias / distribution list for Enea?

Thanks,
-J.


On Mon, Jul 7, 2014 at 2:43 PM, Alexandru Vaduva
 wrote:

Hello Jeff,

The errors are package related.
Meta-cgl can be seen as a non BSP specific layer (it can be viewed as
the LSB from poky).
I already started fixing a number, of the already existing errors and
the patches will be added upstream after proper testing.
I will continue the bug fixing and package integration (into the
core-image-cgl image) process and after that is finished I will
continue with the Category B packages.

I will also try to keep you guys informed about the latest updates,
mainly on the YPTM, but for those who cannot wait that much, there is
the Git repository with which they can interact:
http://git.enea.com/git/?p=linux/meta-cgl.git;a=summary


Have a good day,
Alex


-Original Message-
From: jefro@gmail.com [mailto:jefro@gmail.com] On Behalf Of
Jeff Osier-Mixon
Sent: Monday, July 07, 2014 9:22 PM
To: Alexandru Vaduva
Subject: Re: [OE-core] Carrier Grade layer proposal

Thanks, Alex.

Others on the mailing lists, if you have any comments on the contents
of this new layer, please mention them on this thread.

Re: [yocto] [OE-core] Carrier Grade layer proposal

[akuster]

Alexandru,

Regarding  a few packages in category C&D.

I have latest samhain building as well as grsecurity (pax patches 
applied against 3.14.12) in a branch in my meta-security tree.  I have a 
bit more testing to do before I was going to post them.


grsecurity and samhain aren't CGL specific and they maybe belong in a 
more generalize layer? just a thought.


regards,
Armin


On 07/22/2014 03:52 AM, Alexandru Vaduva wrote:

Hello Joe,

Here at Enea we are preparing the steps needed for publishing the layer on the 
open embedded meta layers initiative: 
http://layers.openembedded.org/layerindex/branch/master/layers/
For this we started working at a web page that should contain all the relevant 
information regarding meta-cgl. It will be available in a couple of weeks. 
Until then the layer will be available internally and the patches should
be submitted as the README states: on the eneali...@lists.enea.com mailing 
list. We will try to make the switch to Open Embedded mailing list as quick as 
possible.

Regarding the other B, C and D packages  that we will try to add into the 
meta-cgl layer, I will post this information below, but keep in mind that this 
information will also be available on the web page.
Category B packages:
- ifenslave
- evlog
- crash
- mipv6-daemon-umip
- openl2tp
Category C&D packages:
- drbd
- grsecurity
- logcheck
- makedumpfile
- numactl
- ocfs2-tools
- pam_passwdqc
- samhain
- ltt-usertrace
- ftrace
The above lists correspond with only the P1 requirements that we try to fulfill 
for the moment. If there are any questions and/or suggestions regarding this 
CGL initialtive please address them to me and I will try to offer a response in 
the
shortest time possible.


Thanks,
Alex

-Original Message-
From: Joe MacDonald [mailto:j...@deserted.net]
Sent: Monday, July 21, 2014 10:58 PM
To: Alexandru Vaduva
Cc: Jeff Osier-Mixon; yocto@yoctoproject.org
Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal

Hey Alex,

I've been away from this for a bit but now I'm getting time to look at it again and I was 
wondering if you had any deeper level of detail you could share about the work going on 
in meta-cgl.  Obviously since this is a new registration and one that will look rather 
different from all of the other CGL registrations currently, those of us in the CGL 
workgroup were quite interested to see this happen.  Personally I'm also interested in 
this since it's the kind of thing I've been doing for a long time now and if I can, I'd 
like to help out.  In particular, if you've got a list of, say, the category B+ items, 
that might be something I can do that will be independent of your work on the more active 
cat-A stuff.  OTOH, cat-A is easy to work on since those are the items I saw when I was 
working with meta-cgl a month or so back.  I know you guys are focused on your part of 
it, but if you had sort of a "here's how to help us" guide, that'd be awesome.

Also, I probably missed it, but is the intent to use either the yocto list or 
the oe list for all meta-cgl discussions, or do you have a dedicated list we 
can sign up for?  I see you have guidance for sending submissions to meta-cgl, 
but is that a list that's open to the community, or is it an internal alias / 
distribution list for Enea?

Thanks,
-J.


On Mon, Jul 7, 2014 at 2:43 PM, Alexandru Vaduva  
wrote:

Hello Jeff,

The errors are package related.
Meta-cgl can be seen as a non BSP specific layer (it can be viewed as the LSB 
from poky).
I already started fixing a number, of the already existing errors and the 
patches will be added upstream after proper testing.
I will continue the bug fixing and package integration (into the
core-image-cgl image) process and after that is finished I will continue with 
the Category B packages.

I will also try to keep you guys informed about the latest updates,
mainly on the YPTM, but for those who cannot wait that much, there is
the Git repository with which they can interact:
http://git.enea.com/git/?p=linux/meta-cgl.git;a=summary


Have a good day,
Alex


-Original Message-
From: jefro@gmail.com [mailto:jefro@gmail.com] On Behalf Of
Jeff Osier-Mixon
Sent: Monday, July 07, 2014 9:22 PM
To: Alexandru Vaduva
Subject: Re: [OE-core] Carrier Grade layer proposal

Thanks, Alex.

Others on the mailing lists, if you have any comments on the contents of this 
new layer, please mention them on this thread.

Re compilation errors, were they specific to a BSP or were they general errors 
in the packages?

thanks

On Mon, Jun 30, 2014 at 8:01 AM, Alexandru Vaduva  
wrote:

Hello Jeff,



The available layer is a work in progress.

For the moment we have done an internal mapping of the packages
needed inside m

Re: [yocto] read only rootfs & systemd

[Allen Kennedy Jr.]

Christopher,
  Thanks for the information.  I too have been looking for this.

It seems odd to me that this build system that is designed for an embedded
device, doesn't have this feature by default.


On Tue, Jul 22, 2014 at 10:44 AM, Christopher Larson 
wrote:

>
> On Tue, Jul 22, 2014 at 4:43 AM, Maciek Borzecki <
> maciej.borze...@open-rnd.pl> wrote:
>
>> Is read-only-rootfs supported on systemd setups?
>>
>> The current dev manual is not clear about this. Also in image.bbclass
>> there are comments that read_only_rootfs_hook supports only sysvinit
>> setups.
>>
>
> Not in oe-core, no. https://github.com/MentorEmbedded/meta-ro-rootfs is
> how we're handling it at mentor today, we haven't gotten around to pursuing
> an upstream solution, whether integration of this or something else, as of
> yet. If you follow the instructions at
> https://github.com/MentorEmbedded/meta-ro-rootfs#usage it should work
> fine for you.
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
>
> --
> ___
> 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] Fwd: How to find the bb file from package name

[Bharath Chandra]

Hi Anooj,

I guess you are looking at a wrong version of the recipe file, you have to
look into version number 5.2.1 and revision r1 as your package name is
suggesting but the link which you have mentioned is for 5.3.1 . Kindly,
have a look into correct version number of recipe file and if you do not
find any package name in the recipe file then you can search in *.inc*
files which are included in that recipe file.
for eg :

require qt5-${PV}.inc

You have to check in qt5-5.2.1.inc file and see if any package is
included with the name which you are searching for.

Thanks & Regards,
Bharath Chandra Elluru



On Tue, Jul 22, 2014 at 6:52 AM, Anooj Gopi  wrote:

>
> Yes I am trying to track down the recipe from the rpm file. In my project
> yocto builds the rpm package
> "nativesdk-libqt5core-dev-5.2.1-r1.i686_nativesdk.rpm" (by
> https://github.com/meta-qt5/meta-qt5) but it is not included in my sdk
> sysroot image. So I would like to see how I could include this into my sdk.
> For that I am tracing back the recipe which generated the rpm.
>
> I tried as you said:
> From the source package name I can see it is from "Source RPM  :
> nativesdk-qtbase-5.2.1-r1.src.rpm", which means bb file is
> https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/qt5/nativesdk-qtbase_5.3.1.bb
> Now this from the bb file content I can see this file provides multiple
> packages, (for eg. nativesdk-qtbase-tools-dbg nativesdk-qtbase-tools-dev
> nativesdk-qtbase-tools-staticdev nativesdk-qtbase-tool) but I still could
> not find where it is configured to generate the package
> "nativesdk-libqt5core-dev-5.2.1-r1.i686_nativesdk.rpm".
>
> As Belen in his last mail, the tools like "Toaster" could confirm this (by
> listing the packages generated from a bb file), but is there any way I can
> do it in Yocto Project 1.5?
>
> Regards,
> Anooj
>
>
> On Tue, Jul 22, 2014 at 11:15 AM, Burton, Ross 
> wrote:
>
>> On 21 July 2014 16:39, Anooj Gopi  wrote:
>> > Could some one help me to understand how we could find the bb file which
>> > generated particular package (rpm package for eg.)?
>> > (In some cases the name of the package and recipe name differ
>> drastically)
>> >
>> > Also is there any way to list packages (rpm) generated by particular
>> recipe
>> > (yocto package) easily. (without looking into the PACKAGES variable).
>>
>> It's probably best if you explain exactly what you want to do.
>>
>> If you want to work backwards from a RPM to the recipe, then binary
>> RPMs have a Source RPM metadata field and the srpm is named after the
>> recipe:
>>
>> $ rpm -qpi connman-tests-1.24-r0.15.corei7_64.rpm | grep Source
>> Source RPM  : connman-1.24-r0.15.src.rpm
>>
>> Ross
>>
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>


-- 
Thanks & Regards,
Bharath Chandra Elluru.
Contact Number:785-979-4875.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] read only rootfs & systemd

[Christopher Larson]

On Tue, Jul 22, 2014 at 4:43 AM, Maciek Borzecki <
maciej.borze...@open-rnd.pl> wrote:

> Is read-only-rootfs supported on systemd setups?
>
> The current dev manual is not clear about this. Also in image.bbclass
> there are comments that read_only_rootfs_hook supports only sysvinit
> setups.
>

Not in oe-core, no. https://github.com/MentorEmbedded/meta-ro-rootfs is how
we're handling it at mentor today, we haven't gotten around to pursuing an
upstream solution, whether integration of this or something else, as of
yet. If you follow the instructions at
https://github.com/MentorEmbedded/meta-ro-rootfs#usage it should work fine
for you.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [prelink-cross][PATCH] Always create a conflict for R_ARM_TLS_DESC relocs

[Maciej W. Rozycki]

Hi,

 This is a bit obscure.  In my testing, for the purpose of upstreaming, of 
the glibc change to support ARM TLS descriptors in prelinked binaries (cf 
upstream BZ #17078, https://sourceware.org/bugzilla/show_bug.cgi?id=17078) 
I have come across a problem where all programs prelinked against glibc 
binaries using ARM TLS descriptors themselves segfaulted in the normal 
exit path, where libc.so's own TLS destructors are called.  I have tracked 
it down to the GOT entry (pointed to by the DT_TLSDESC_GOT dynamic tag) 
meant to point to the lazy TLS descriptor resolver (pointed to by the 
DT_TLSDESC_PLT dynamic tag) being left uninitialised and therefore NULL.  
An attempt to call that resolver caused therefore a segfault.

 The cause of this lack of initialisation turned out to be an omission in 
the original fix (dated 2011-04-13 in ChangeLog.cross), that didn't ensure 
that a conflict entry is created even for these R_ARM_TLS_DESC relocations 
that refer to a local symbol.  Somehow it didn't trigger in testing back 
when implemented, perhaps glibc didn't require or access the missing entry 
in code handling TLS destructors then.  Such an entry is needed, because 
for prelinked binaries the DT_TLSDESC_GOT GOT entry is only initialised by 
the dynamic linker when a conflict is resolved.  The change below enforces 
this conflict entry creation.

 This fix removes 33 failures in prelink testing with glibc built using 
ARM TLS descriptors, that is with the `-mtls-dialect=gnu2' GCC option in 
effect (that is not the default unless explicitly requested at GCC build 
time):

FAIL -> PASS: default/prelink.sum:cxx1.sh
FAIL -> PASS: default/prelink.sum:cxx2.sh
FAIL -> PASS: default/prelink.sum:cxx3.sh
FAIL -> PASS: default/prelink.sum:layout1.sh
FAIL -> PASS: default/prelink.sum:layout2.sh
FAIL -> PASS: default/prelink.sum:reloc1.sh
FAIL -> PASS: default/prelink.sum:reloc10.sh
FAIL -> PASS: default/prelink.sum:reloc11.sh
FAIL -> PASS: default/prelink.sum:reloc2.sh
FAIL -> PASS: default/prelink.sum:reloc3.sh
FAIL -> PASS: default/prelink.sum:reloc4.sh
FAIL -> PASS: default/prelink.sum:reloc5.sh
FAIL -> PASS: default/prelink.sum:reloc6.sh
FAIL -> PASS: default/prelink.sum:reloc7.sh
FAIL -> PASS: default/prelink.sum:reloc8.sh
FAIL -> PASS: default/prelink.sum:reloc9.sh
FAIL -> PASS: default/prelink.sum:shuffle1.sh
FAIL -> PASS: default/prelink.sum:shuffle2.sh
FAIL -> PASS: default/prelink.sum:shuffle3.sh
FAIL -> PASS: default/prelink.sum:shuffle4.sh
FAIL -> PASS: default/prelink.sum:shuffle5.sh
FAIL -> PASS: default/prelink.sum:shuffle6.sh
FAIL -> PASS: default/prelink.sum:shuffle7.sh
FAIL -> PASS: default/prelink.sum:shuffle8.sh
FAIL -> PASS: default/prelink.sum:shuffle9.sh
FAIL -> PASS: default/prelink.sum:tls1.sh
FAIL -> PASS: default/prelink.sum:tls2.sh
FAIL -> PASS: default/prelink.sum:tls3.sh
FAIL -> PASS: default/prelink.sum:tls4.sh
FAIL -> PASS: default/prelink.sum:tls5.sh
FAIL -> PASS: default/prelink.sum:tls6.sh
FAIL -> PASS: default/prelink.sum:tls7.sh
FAIL -> PASS: default/prelink.sum:undo1.sh

 Please apply.

2014-07-22  Maciej W. Rozycki  

* src/arch-arm.c (arm_prelink_conflict_rel): Always create a 
conflict for R_ARM_TLS_DESC relocs.
(arm_prelink_conflict_rela): Likewise.

  Maciej

prelink-arm-tlsdesc-conflict-always.diff
Index: trunk/src/arch-arm.c
===
--- trunk.orig/src/arch-arm.c   2014-07-17 23:26:08.0 +0100
+++ trunk/src/arch-arm.c2014-07-18 04:18:53.790564615 +0100
@@ -416,7 +416,9 @@ arm_prelink_conflict_rel (DSO *dso, stru
case R_ARM_TLS_DTPMOD32:
case R_ARM_TLS_TPOFF32:
  break;
-
+   /* Likewise TLS_DESC.  */
+   case R_ARM_TLS_DESC:
+ break;
default:
  return 0;
}
@@ -526,7 +528,9 @@ arm_prelink_conflict_rela (DSO *dso, str
case R_ARM_TLS_DTPMOD32:
case R_ARM_TLS_TPOFF32:
  break;
-
+   /* Likewise TLS_DESC.  */
+   case R_ARM_TLS_DESC:
+ break;
default:
  return 0;
}
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] SELinux doesn't work on t4240qds

[zhenhua....@freescale.com]

Hi all,

I use the meta-selinux layer to build a core-image-selinux rootfs image, and 
build kernel with following options enabled.
CONFIG_AUDIT=y
CONFIG_NETWORK_SECMARK=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_EXT4_FS_SECURITY=y
CONFIG_JFS_SECURITY=y
CONFIG_REISERFS_FS_SECURITY=y
CONFIG_JFFS2_FS_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1

I use the generated images to boot up FSL PPC t4240qds board(tried both NFS 
boot and RAM boot with ext2.gz.u-boot rootfs), the SELinux is not turned on 
after kernel boot up.

following is some information in rootfs.
root@t4240qds:~# sestatus
SELinux status: disabled
root@t4240qds:~#
root@t4240qds:~# cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these two values:
# standard - Standard Security protection.
# mls - Multi Level Security protection.
SELINUXTYPE=mls

root@t4240qds:~# cat /proc/cmdline
root=/dev/ram rw console=ttyS0,115200 selinux=1
root@t4240qds:~# setenforce 1
setenforce: SELinux is disabled
root@t4240qds:~# getenforce
Disabled
root@t4240qds:~#

Can somebody shed some light on the issue?


Best Regards,

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

Re: [yocto] [OE-core] Carrier Grade layer proposal

[Alexandru Vaduva]

A quick follow up to the previous e-mail:
I only mention that P1 compliance is until November is a best effort approach. 
This is very much influenced by the community, the available recipes, bugs etc.
The CGL compliance is tested against the qemuppc machine, being the fact that a 
real target is a bit hard to use by everyone.
There is also an idea about a CGL calculator that could offer information about 
the number of cgl requirements that are met and offer a compliance percentage 
(similar to LSB), but as I said this is just at the idea level.

I believe more info about the milestones and the activities that we commit on 
doing until those milestones will be available on the web page. 
Please let me know if any information would be needed in the case I may have 
overlooked some useful parts of information. In that way I can also make sure 
this information will be also available when the web page will be up. 


Alex

-Original Message-
From: Alexandru Vaduva 
Sent: Tuesday, July 22, 2014 5:21 PM
To: 'Joe MacDonald'
Cc: Jeff Osier-Mixon; yocto@yoctoproject.org
Subject: RE: [yocto] [OE-core] Carrier Grade layer proposal

Hello again,

The P1 compliance until in November is a best effort approach.
Regarding the move to the openembedded.org location, we intend to do that as 
soon as possible after the web page will be put on place, as to make it simple 
for the community to interact with the layer and have all the needed 
information available in one place.


Alex



-Original Message-
From: Joe MacDonald [mailto:j...@deserted.net] 
Sent: Tuesday, July 22, 2014 4:53 PM
To: Alexandru Vaduva
Cc: Jeff Osier-Mixon; yocto@yoctoproject.org
Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal

Hi Alex

[RE: [yocto] [OE-core] Carrier Grade layer proposal] On 14.07.22 (Tue 10:52) 
Alexandru Vaduva wrote:

> Hello Joe,
> 
> Here at Enea we are preparing the steps needed for publishing the 
> layer on the open embedded meta layers initiative: 
> http://layers.openembedded.org/layerindex/branch/master/layers/
> For this we started working at a web page that should contain all the 
> relevant information regarding meta-cgl. It will be available in a couple of 
> weeks. Until then the layer will be available internally and the patches 
> should be submitted as the README states: on the eneali...@lists.enea.com 
> mailing list. We will try to make the switch to Open Embedded mailing list as 
> quick as possible.
> 
> Regarding the other B, C and D packages  that we will try to add into the 
> meta-cgl layer, I will post this information below, but keep in mind that 
> this information will also be available on the web page.
>   Category B packages: 
>   - ifenslave
>   - evlog
>   - crash
>   - mipv6-daemon-umip
>   - openl2tp
>   Category C&D packages:
>   - drbd
>   - grsecurity
>   - logcheck
>   - makedumpfile
>   - numactl
>   - ocfs2-tools
>   - pam_passwdqc
>   - samhain
>   - ltt-usertrace
>   - ftrace
> The above lists correspond with only the P1 requirements that we try 
> to fulfill for the moment. If there are any questions and/or suggestions 
> regarding this CGL initialtive please address them to me and I will try to 
> offer a response in the shortest time possible.

Thanks, that is really helpful, actually.  So a couple of other things, though. 
 I think I remember that early on you were intending to take your yocto-based 
system with meta-cgl (and, I imagine based on the contents of the README, the 
additional dependent layers) through a CGL registration.  Really, that's great 
if you still are, but it sounds like maybe now you're planning a staged 
approach and are only targeting a subset of the CGL P1s for the end of the year 
/ start of next year.  Is that accurate, or are you looking at full P1 
compliance by that date?

I ask mostly because I know doing a CGL distribution is a big effort (I've been 
down this road before) and it may be that you don't need to have the system 
complete before you can move it to the openembedded.org location and "get into 
the system" so to speak.  Your team is pretty active, though, so I'm sure 
you'll also notice if things are going into other layers that can save you some 
time (e.g. the submission of a numactl recipe to meta-oe last week).

That, and if I've got an idea of where you're going, I'll be happy to take an 
early look at what you've got in terms of it's CGL-ness and hopefully make the 
eventual registration (if you go that route) move along quickly.

-J.

> 
> 
> Thanks,
> Alex
> 
> -Original Message-
> From: Joe MacDonald [mailto:j...@deserted.net]
> Sent: Monday, July 21, 2014 10:58 PM
> To: Alexandru Vaduva
> Cc: Jeff Osier-Mixon; yocto@yoctoproject.org
> Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal
> 
> Hey Alex,
> 
> I'v

Re: [yocto] [OE-core] Carrier Grade layer proposal

[Alexandru Vaduva]

Hello again,

The P1 compliance until in November is a best effort approach.
Regarding the move to the openembedded.org location, we intend to do that as 
soon as possible after
the web page will be put on place, as to make it simple for the community to 
interact with the layer and 
have all the needed information available in one place.


Alex



-Original Message-
From: Joe MacDonald [mailto:j...@deserted.net] 
Sent: Tuesday, July 22, 2014 4:53 PM
To: Alexandru Vaduva
Cc: Jeff Osier-Mixon; yocto@yoctoproject.org
Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal

Hi Alex

[RE: [yocto] [OE-core] Carrier Grade layer proposal] On 14.07.22 (Tue 10:52) 
Alexandru Vaduva wrote:

> Hello Joe,
> 
> Here at Enea we are preparing the steps needed for publishing the 
> layer on the open embedded meta layers initiative: 
> http://layers.openembedded.org/layerindex/branch/master/layers/
> For this we started working at a web page that should contain all the 
> relevant information regarding meta-cgl. It will be available in a couple of 
> weeks. Until then the layer will be available internally and the patches 
> should be submitted as the README states: on the eneali...@lists.enea.com 
> mailing list. We will try to make the switch to Open Embedded mailing list as 
> quick as possible.
> 
> Regarding the other B, C and D packages  that we will try to add into the 
> meta-cgl layer, I will post this information below, but keep in mind that 
> this information will also be available on the web page.
>   Category B packages: 
>   - ifenslave
>   - evlog
>   - crash
>   - mipv6-daemon-umip
>   - openl2tp
>   Category C&D packages:
>   - drbd
>   - grsecurity
>   - logcheck
>   - makedumpfile
>   - numactl
>   - ocfs2-tools
>   - pam_passwdqc
>   - samhain
>   - ltt-usertrace
>   - ftrace
> The above lists correspond with only the P1 requirements that we try 
> to fulfill for the moment. If there are any questions and/or suggestions 
> regarding this CGL initialtive please address them to me and I will try to 
> offer a response in the shortest time possible.

Thanks, that is really helpful, actually.  So a couple of other things, though. 
 I think I remember that early on you were intending to take your yocto-based 
system with meta-cgl (and, I imagine based on the contents of the README, the 
additional dependent layers) through a CGL registration.  Really, that's great 
if you still are, but it sounds like maybe now you're planning a staged 
approach and are only targeting a subset of the CGL P1s for the end of the year 
/ start of next year.  Is that accurate, or are you looking at full P1 
compliance by that date?

I ask mostly because I know doing a CGL distribution is a big effort (I've been 
down this road before) and it may be that you don't need to have the system 
complete before you can move it to the openembedded.org location and "get into 
the system" so to speak.  Your team is pretty active, though, so I'm sure 
you'll also notice if things are going into other layers that can save you some 
time (e.g. the submission of a numactl recipe to meta-oe last week).

That, and if I've got an idea of where you're going, I'll be happy to take an 
early look at what you've got in terms of it's CGL-ness and hopefully make the 
eventual registration (if you go that route) move along quickly.

-J.

> 
> 
> Thanks,
> Alex
> 
> -Original Message-
> From: Joe MacDonald [mailto:j...@deserted.net]
> Sent: Monday, July 21, 2014 10:58 PM
> To: Alexandru Vaduva
> Cc: Jeff Osier-Mixon; yocto@yoctoproject.org
> Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal
> 
> Hey Alex,
> 
> I've been away from this for a bit but now I'm getting time to look at it 
> again and I was wondering if you had any deeper level of detail you could 
> share about the work going on in meta-cgl.  Obviously since this is a new 
> registration and one that will look rather different from all of the other 
> CGL registrations currently, those of us in the CGL workgroup were quite 
> interested to see this happen.  Personally I'm also interested in this since 
> it's the kind of thing I've been doing for a long time now and if I can, I'd 
> like to help out.  In particular, if you've got a list of, say, the category 
> B+ items, that might be something I can do that will be independent of your 
> work on the more active cat-A stuff.  OTOH, cat-A is easy to work on since 
> those are the items I saw when I was working with meta-cgl a month or so 
> back.  I know you guys are focused on your part of it, but if you had sort of 
> a "here's how to help us" guide, that'd be awesome.
> 
> Also, I probably missed it, but is the intent to use either the yocto list or 
> the oe list for all meta-cgl discussions, or do you have a dedicated list 

Re: [yocto] [OE-core] Carrier Grade layer proposal

[Joe MacDonald]

Hi Alex

[RE: [yocto] [OE-core] Carrier Grade layer proposal] On 14.07.22 (Tue 10:52) 
Alexandru Vaduva wrote:

> Hello Joe,
> 
> Here at Enea we are preparing the steps needed for publishing the layer on 
> the open embedded meta layers initiative: 
> http://layers.openembedded.org/layerindex/branch/master/layers/
> For this we started working at a web page that should contain all the 
> relevant information regarding meta-cgl. It will be available in a couple of 
> weeks. Until then the layer will be available internally and the patches 
> should 
> be submitted as the README states: on the eneali...@lists.enea.com mailing 
> list. We will try to make the switch to Open Embedded mailing list as quick 
> as possible.
> 
> Regarding the other B, C and D packages  that we will try to add into the 
> meta-cgl layer, I will post this information below, but keep in mind that 
> this information will also be available on the web page.
>   Category B packages: 
>   - ifenslave
>   - evlog
>   - crash
>   - mipv6-daemon-umip
>   - openl2tp
>   Category C&D packages:
>   - drbd
>   - grsecurity
>   - logcheck
>   - makedumpfile
>   - numactl
>   - ocfs2-tools
>   - pam_passwdqc
>   - samhain
>   - ltt-usertrace
>   - ftrace
> The above lists correspond with only the P1 requirements that we try to 
> fulfill for the moment. If there are any questions and/or suggestions 
> regarding this CGL initialtive please address them to me and I will try to 
> offer a response in the
> shortest time possible.

Thanks, that is really helpful, actually.  So a couple of other things,
though.  I think I remember that early on you were intending to take
your yocto-based system with meta-cgl (and, I imagine based on the
contents of the README, the additional dependent layers) through a CGL
registration.  Really, that's great if you still are, but it sounds like
maybe now you're planning a staged approach and are only targeting a
subset of the CGL P1s for the end of the year / start of next year.  Is
that accurate, or are you looking at full P1 compliance by that date?

I ask mostly because I know doing a CGL distribution is a big
effort (I've been down this road before) and it may be that you don't
need to have the system complete before you can move it to the
openembedded.org location and "get into the system" so to speak.  Your
team is pretty active, though, so I'm sure you'll also notice if things
are going into other layers that can save you some time (e.g. the
submission of a numactl recipe to meta-oe last week).

That, and if I've got an idea of where you're going, I'll be happy to
take an early look at what you've got in terms of it's CGL-ness and
hopefully make the eventual registration (if you go that route) move
along quickly.

-J.

> 
> 
> Thanks,
> Alex 
> 
> -Original Message-
> From: Joe MacDonald [mailto:j...@deserted.net] 
> Sent: Monday, July 21, 2014 10:58 PM
> To: Alexandru Vaduva
> Cc: Jeff Osier-Mixon; yocto@yoctoproject.org
> Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal
> 
> Hey Alex,
> 
> I've been away from this for a bit but now I'm getting time to look at it 
> again and I was wondering if you had any deeper level of detail you could 
> share about the work going on in meta-cgl.  Obviously since this is a new 
> registration and one that will look rather different from all of the other 
> CGL registrations currently, those of us in the CGL workgroup were quite 
> interested to see this happen.  Personally I'm also interested in this since 
> it's the kind of thing I've been doing for a long time now and if I can, I'd 
> like to help out.  In particular, if you've got a list of, say, the category 
> B+ items, that might be something I can do that will be independent of your 
> work on the more active cat-A stuff.  OTOH, cat-A is easy to work on since 
> those are the items I saw when I was working with meta-cgl a month or so 
> back.  I know you guys are focused on your part of it, but if you had sort of 
> a "here's how to help us" guide, that'd be awesome.
> 
> Also, I probably missed it, but is the intent to use either the yocto list or 
> the oe list for all meta-cgl discussions, or do you have a dedicated list we 
> can sign up for?  I see you have guidance for sending submissions to 
> meta-cgl, but is that a list that's open to the community, or is it an 
> internal alias / distribution list for Enea?
> 
> Thanks,
> -J.
> 
> 
> On Mon, Jul 7, 2014 at 2:43 PM, Alexandru Vaduva  
> wrote:
> > Hello Jeff,
> >
> > The errors are package related.
> > Meta-cgl can be seen as a non BSP specific layer (it can be viewed as the 
> > LSB from poky).
> > I already started fixing a number, of the already existing errors and the 
> > patches will be added upstream after proper testing.
> > I will continue th

Re: [yocto] rationale for including checkouts in both layers and yocto git repos?

[Robert P. J. Day]

On Tue, 22 Jul 2014, Burton, Ross wrote:

> On 22 July 2014 14:15, Robert P. J. Day  wrote:
> >   i just noticed that, across the two major repos for yocto:
> >
> > http://layers.openembedded.org/layerindex/branch/master/layers/
> > http://git.yoctoproject.org/
> >
> > there's a wee bit of duplication in that the second repo above
> > duplicates a lot of the meta- layers found in the first location. is
> > that deliberate? or can things be more properly placed in a single
> > location?
>
> The former - the layer index - is a curated index of every known
> layer.  It doesn't contain any layers, and is merely a (searchable,
> human-readable, tagged) index.
>
> The later is the list of all git repositories on the official Yocto
> Project git server.  It contains layers, kernel forks, applications
> and more.
>
> There is no duplication here.

  ah, got it.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [yocto] rationale for including checkouts in both layers and yocto git repos?

[Burton, Ross]

On 22 July 2014 14:15, Robert P. J. Day  wrote:
>   i just noticed that, across the two major repos for yocto:
>
> http://layers.openembedded.org/layerindex/branch/master/layers/
> http://git.yoctoproject.org/
>
> there's a wee bit of duplication in that the second repo above
> duplicates a lot of the meta- layers found in the first location. is
> that deliberate? or can things be more properly placed in a single
> location?

The former - the layer index - is a curated index of every known
layer.  It doesn't contain any layers, and is merely a (searchable,
human-readable, tagged) index.

The later is the list of all git repositories on the official Yocto
Project git server.  It contains layers, kernel forks, applications
and more.

There is no duplication here.

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

[yocto] rationale for including checkouts in both layers and yocto git repos?

[Robert P. J. Day]

  i just noticed that, across the two major repos for yocto:

http://layers.openembedded.org/layerindex/branch/master/layers/
http://git.yoctoproject.org/

there's a wee bit of duplication in that the second repo above
duplicates a lot of the meta- layers found in the first location. is
that deliberate? or can things be more properly placed in a single
location?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] [PATCH][autobuilder] buildsteps/RunOeSelftest.py: change the way oe-selftest is called

[Corneliu Stoicescu]

A recent patch went in poky master that added command line parsing and options 
to the oe-selftest script.
Changing the way oe-selftest is called by the autobuilder to account for these 
changes.

Signed-off-by: Corneliu Stoicescu 
---
 lib/python2.7/site-packages/autobuilder/buildsteps/RunOeSelftest.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/RunOeSelftest.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/RunOeSelftest.py
index 0efddd7..3d95583 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/RunOeSelftest.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/RunOeSelftest.py
@@ -22,5 +22,5 @@ class RunOeSelftest(ShellCommand):
 self.description = "Running oe-selftest"
 self.timeout = 10
 kwargs['timeout']=self.timeout
-self.command = "if [ -d meta-selftest ]; then . ./oe-init-build-env; 
oe-selftest; else echo 'Skipping step - no meta-selftest layer here'; fi"
+self.command = "if [ -d meta-selftest ]; then . ./oe-init-build-env; 
oe-selftest --run-all-tests; else echo 'Skipping step - no meta-selftest layer 
here'; fi"
 ShellCommand.__init__(self, **kwargs)
-- 
1.8.3.2

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

[yocto] Fwd: How to find the bb file from package name

[Anooj Gopi]

Yes I am trying to track down the recipe from the rpm file. In my project
yocto builds the rpm package
"nativesdk-libqt5core-dev-5.2.1-r1.i686_nativesdk.rpm" (by
https://github.com/meta-qt5/meta-qt5) but it is not included in my sdk
sysroot image. So I would like to see how I could include this into my sdk.
For that I am tracing back the recipe which generated the rpm.

I tried as you said:
>From the source package name I can see it is from "Source RPM  :
nativesdk-qtbase-5.2.1-r1.src.rpm", which means bb file is
https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/qt5/nativesdk-qtbase_5.3.1.bb
Now this from the bb file content I can see this file provides multiple
packages, (for eg. nativesdk-qtbase-tools-dbg nativesdk-qtbase-tools-dev
nativesdk-qtbase-tools-staticdev nativesdk-qtbase-tool) but I still could
not find where it is configured to generate the package
"nativesdk-libqt5core-dev-5.2.1-r1.i686_nativesdk.rpm".

As Belen in his last mail, the tools like "Toaster" could confirm this (by
listing the packages generated from a bb file), but is there any way I can
do it in Yocto Project 1.5?

Regards,
Anooj


On Tue, Jul 22, 2014 at 11:15 AM, Burton, Ross 
wrote:

> On 21 July 2014 16:39, Anooj Gopi  wrote:
> > Could some one help me to understand how we could find the bb file which
> > generated particular package (rpm package for eg.)?
> > (In some cases the name of the package and recipe name differ
> drastically)
> >
> > Also is there any way to list packages (rpm) generated by particular
> recipe
> > (yocto package) easily. (without looking into the PACKAGES variable).
>
> It's probably best if you explain exactly what you want to do.
>
> If you want to work backwards from a RPM to the recipe, then binary
> RPMs have a Source RPM metadata field and the srpm is named after the
> recipe:
>
> $ rpm -qpi connman-tests-1.24-r0.15.corei7_64.rpm | grep Source
> Source RPM  : connman-1.24-r0.15.src.rpm
>
> Ross
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] read only rootfs & systemd

[Maciek Borzecki]

Hi,

Is read-only-rootfs supported on systemd setups?

The current dev manual is not clear about this. Also in image.bbclass
there are comments that read_only_rootfs_hook supports only sysvinit
setups.

Thanks,
-- 
Maciej Borzęcki
Senior Software Developer at Open-RnD Sp. z o.o., Poland
www.open-rnd.pl
mobile: +48 889 117 365, fax: +48 42 657 9079

Niniejsza wiadomość wraz z załącznikami może zawierać chronione prawem
lub poufne informacje i została wysłana wyłącznie do wiadomości i
użytku osób, do których została zaadresowana. Jeśli wiadomość została
otrzymana przypadkowo zabrania się jej kopiowania lub rozsyłania do
osób trzecich. W takim przypadku uprasza się o natychmiastowe
zniszczenie wiadomości oraz poinformowanie nadawcy o zaistniałej
sytuacji za pomocą wiadomości zwrotnej. Dziękujemy.

This message, including any attachments hereto, may contain privileged
or confidential information and is sent solely for the attention and
use of the intended addressee(s). If you are not an intended addressee,
you may neither use this message nor copy or deliver it to anyone. In
such case, you should immediately destroy this message and kindly notify
the sender by reply email. Thank you.


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

Re: [yocto] How to find the bb file from package name

[Anooj Gopi]

Hello Belen,

"Toaster" seems promising. But unfortunately I am currently with Yocto
Project 1.5
Do you see any other possibility in 1.5?

Best Regards,
Anooj


On Tue, Jul 22, 2014 at 11:07 AM, Barros Pena, Belen <
belen.barros.p...@intel.com> wrote:

> On 21/07/2014 16:39, "Anooj Gopi"  wrote:
>
> >Hello All,
> >
> >
> >Could some one help me to understand how we could find the bb file which
> >generated particular package (rpm package for eg.)?
> >
> >(In some cases the name of the package and recipe name differ drastically)
> >
> >
> >Also is there any way to list packages (rpm) generated by particular
> >recipe (yocto package) easily. (without looking into the PACKAGES
> >variable).
>
> Hi Anooj,
>
> One of the ways to get this information is Toaster, a web application that
> collects data about your builds and presents it in a web interface. More
> information here
>
> https://www.yoctoproject.org/documentation/toaster-manual
>
> It's only compatible with Yocto Project 1.6 though.
>
> Cheers
>
> Belén
>
> >
> >
> >
> >Best Regards,
> >Anooj Gopi
> >
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] Carrier Grade layer proposal

[Alexandru Vaduva]

Hello Joe,

Here at Enea we are preparing the steps needed for publishing the layer on the 
open embedded meta layers initiative: 
http://layers.openembedded.org/layerindex/branch/master/layers/
For this we started working at a web page that should contain all the relevant 
information regarding meta-cgl. It will be available in a couple of weeks. 
Until then the layer will be available internally and the patches should 
be submitted as the README states: on the eneali...@lists.enea.com mailing 
list. We will try to make the switch to Open Embedded mailing list as quick as 
possible.

Regarding the other B, C and D packages  that we will try to add into the 
meta-cgl layer, I will post this information below, but keep in mind that this 
information will also be available on the web page.
Category B packages: 
- ifenslave
- evlog
- crash
- mipv6-daemon-umip
- openl2tp
Category C&D packages:
- drbd
- grsecurity
- logcheck
- makedumpfile
- numactl
- ocfs2-tools
- pam_passwdqc
- samhain
- ltt-usertrace
- ftrace
The above lists correspond with only the P1 requirements that we try to fulfill 
for the moment. If there are any questions and/or suggestions regarding this 
CGL initialtive please address them to me and I will try to offer a response in 
the
shortest time possible.


Thanks,
Alex 

-Original Message-
From: Joe MacDonald [mailto:j...@deserted.net] 
Sent: Monday, July 21, 2014 10:58 PM
To: Alexandru Vaduva
Cc: Jeff Osier-Mixon; yocto@yoctoproject.org
Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal

Hey Alex,

I've been away from this for a bit but now I'm getting time to look at it again 
and I was wondering if you had any deeper level of detail you could share about 
the work going on in meta-cgl.  Obviously since this is a new registration and 
one that will look rather different from all of the other CGL registrations 
currently, those of us in the CGL workgroup were quite interested to see this 
happen.  Personally I'm also interested in this since it's the kind of thing 
I've been doing for a long time now and if I can, I'd like to help out.  In 
particular, if you've got a list of, say, the category B+ items, that might be 
something I can do that will be independent of your work on the more active 
cat-A stuff.  OTOH, cat-A is easy to work on since those are the items I saw 
when I was working with meta-cgl a month or so back.  I know you guys are 
focused on your part of it, but if you had sort of a "here's how to help us" 
guide, that'd be awesome.

Also, I probably missed it, but is the intent to use either the yocto list or 
the oe list for all meta-cgl discussions, or do you have a dedicated list we 
can sign up for?  I see you have guidance for sending submissions to meta-cgl, 
but is that a list that's open to the community, or is it an internal alias / 
distribution list for Enea?

Thanks,
-J.


On Mon, Jul 7, 2014 at 2:43 PM, Alexandru Vaduva  
wrote:
> Hello Jeff,
>
> The errors are package related.
> Meta-cgl can be seen as a non BSP specific layer (it can be viewed as the LSB 
> from poky).
> I already started fixing a number, of the already existing errors and the 
> patches will be added upstream after proper testing.
> I will continue the bug fixing and package integration (into the 
> core-image-cgl image) process and after that is finished I will continue with 
> the Category B packages.
>
> I will also try to keep you guys informed about the latest updates, 
> mainly on the YPTM, but for those who cannot wait that much, there is 
> the Git repository with which they can interact: 
> http://git.enea.com/git/?p=linux/meta-cgl.git;a=summary
>
>
> Have a good day,
> Alex
>
>
> -Original Message-
> From: jefro@gmail.com [mailto:jefro@gmail.com] On Behalf Of 
> Jeff Osier-Mixon
> Sent: Monday, July 07, 2014 9:22 PM
> To: Alexandru Vaduva
> Subject: Re: [OE-core] Carrier Grade layer proposal
>
> Thanks, Alex.
>
> Others on the mailing lists, if you have any comments on the contents of this 
> new layer, please mention them on this thread.
>
> Re compilation errors, were they specific to a BSP or were they general 
> errors in the packages?
>
> thanks
>
> On Mon, Jun 30, 2014 at 8:01 AM, Alexandru Vaduva  
> wrote:
>> Hello Jeff,
>>
>>
>>
>> The available layer is a work in progress.
>>
>> For the moment we have done an internal mapping of the packages 
>> needed inside meta-cgl layer. The mapping is done as following:
>> A. Requirement that map against package/packages with recipes that 
>> already exists in Yocto
>>   A1. Requirement that map against package/packages with recipes 
>> already existing in meta-enea
>>   A2. Requirement that map against package/packages with recipes that 
>> exists in

Re: [yocto] How to find the bb file from package name

[Burton, Ross]

On 21 July 2014 16:39, Anooj Gopi  wrote:
> Could some one help me to understand how we could find the bb file which
> generated particular package (rpm package for eg.)?
> (In some cases the name of the package and recipe name differ drastically)
>
> Also is there any way to list packages (rpm) generated by particular recipe
> (yocto package) easily. (without looking into the PACKAGES variable).

It's probably best if you explain exactly what you want to do.

If you want to work backwards from a RPM to the recipe, then binary
RPMs have a Source RPM metadata field and the srpm is named after the
recipe:

$ rpm -qpi connman-tests-1.24-r0.15.corei7_64.rpm | grep Source
Source RPM  : connman-1.24-r0.15.src.rpm

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

Re: [yocto] How to find the bb file from package name

[Barros Pena, Belen]

On 21/07/2014 16:39, "Anooj Gopi"  wrote:

>Hello All,
>
>
>Could some one help me to understand how we could find the bb file which
>generated particular package (rpm package for eg.)?
>
>(In some cases the name of the package and recipe name differ drastically)
>
>
>Also is there any way to list packages (rpm) generated by particular
>recipe (yocto package) easily. (without looking into the PACKAGES
>variable).

Hi Anooj,

One of the ways to get this information is Toaster, a web application that
collects data about your builds and presents it in a web interface. More
information here

https://www.yoctoproject.org/documentation/toaster-manual

It's only compatible with Yocto Project 1.6 though.

Cheers

Belén

>
>
>
>Best Regards,
>Anooj Gopi
>

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

Re: [yocto] [PATCH] Documentation: Ref Manual should use newer "packagegroup-* names.

[Rifenbark, Scott M]

Applied.

Thanks,
Scott

>-Original Message-
>From: yocto-boun...@yoctoproject.org [mailto:yocto-
>boun...@yoctoproject.org] On Behalf Of Robert P. J. Day
>Sent: Thursday, July 10, 2014 8:36 AM
>To: Yocto discussion list
>Subject: [yocto] [PATCH] Documentation: Ref Manual should use newer
>"packagegroup-* names.
>
>
>Replace a couple old references to "task-*" packagegroup names with newer
>form.
>
>Signed-off-by: Robert P. J. Day 
>
>---
>
>diff --git a/documentation/ref-manual/usingpoky.xml b/documentation/ref-
>manual/usingpoky.xml
>index 164e82e..e1db9d8 100644
>--- a/documentation/ref-manual/usingpoky.xml
>+++ b/documentation/ref-manual/usingpoky.xml
>@@ -721,7 +721,7 @@
>  IMAGE_FEATURES = debug-tweaks x11-base apps-x11-core \
> package-management ssh-server-dropbear package-management
>  IMAGE_LINGUAS = en-us en-gb
>- IMAGE_INSTALL = task-core-boot task-base-extended
>+ IMAGE_INSTALL = packagegroup-core-boot packagegroup-base-
>extended
>  BAD_RECOMMENDATIONS =
>  ROOTFS_POSTPROCESS_COMMAND = buildhistory_get_image_installed ;
>rootfs_update_timestamp ;
>  IMAGE_POSTPROCESS_COMMAND = buildhistory_get_imageinfo ;
>
>--
>
>===
>=
>Robert P. J. Day Ottawa, Ontario, CANADA
>http://crashcourse.ca
>
>Twitter:   http://twitter.com/rpjday
>LinkedIn:   http://ca.linkedin.com/in/rpjday
>===
>=
>--
>___
>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] [yocto-docs][PATCH] Grammar fix to kernel-dev manual.

[Rifenbark, Scott M]

Applied.

Thanks,
Scott

>-Original Message-
>From: yocto-boun...@yoctoproject.org [mailto:yocto-
>boun...@yoctoproject.org] On Behalf Of Robert P. J. Day
>Sent: Friday, July 18, 2014 12:31 PM
>To: Yocto discussion list
>Subject: [yocto] [yocto-docs][PATCH] Grammar fix to kernel-dev manual.
>
>
>Signed-off-by: Robert P. J. Day 
>
>---
>
>diff --git a/documentation/kernel-dev/kernel-dev-common.xml
>b/documentation/kernel-dev/kernel-dev-common.xml
>index 5f28b82..5d14a15 100644
>--- a/documentation/kernel-dev/kernel-dev-common.xml
>+++ b/documentation/kernel-dev/kernel-dev-common.xml
>@@ -502,7 +502,7 @@
> you can make them permanent by generating patches and
> applying them to the
> SRC_URI
>-statement as described in section
>+statement as described in the
> "Applying Patches" 
> section.
> If you are not familiar with generating patches, refer to the
> "Creating
>the Patch"
>
>--
>
>===
>=
>Robert P. J. Day Ottawa, Ontario, CANADA
>http://crashcourse.ca
>
>Twitter:   http://twitter.com/rpjday
>LinkedIn:   http://ca.linkedin.com/in/rpjday
>===
>=
>
>--
>___
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto