Date   

Re: ROOTFS_POSTPROCESS_COMMAND warning

Erik Bot?
 

Hi,

On Fri, Apr 18, 2014 at 1:48 AM, Mahyar Yaghmaee
<mahyar@boundarydevices.com> wrote:
Hi,

I'm trying to run a post processing shell command using
ROOTFS_POSTPROCESS_COMMAND by adding ROOTFS_POSTPROCESS_COMMAND +=
"shell_command;" at the end of an image recipe.
I get:
WARNING: Function shell_command doesn't exist

Any ideas what's the problem here?
Nope, but I do see the same issue since a while back. I'm also curious
on how to solve this. I tried moving the commands into a separate
function in the image recipe and to call that from
ROOTFS_POSTPROCESS_COMMAND but still see the issues.

Cheers,
Erik


Regards,
Mahyar

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


Re: [ANNOUNCEMENT] Yocto Project 1.6 (daisy 11.0.0) Released

David Stewart
 

Congratulations to everyone who contributed to 1.6 !!

On 4/24/14, 2:59 PM, "Flanagan, Elizabeth" <elizabeth.flanagan@intel.com>
wrote:

Hello,

The latest release of the Yocto Project 1.6 (daisy-11.0.0) is now
available
for download at:

http://downloads.yoctoproject.org/releases/yocto/yocto-1.6/poky-daisy-11.0
.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-1.6/poky-daisy-11.0.0.tar.bz2

A gpg signed version of these release notes is available at:

http://downloads.yoctoproject.org/releases/yocto/yocto-1.6/RELEASENOTES

Full pass test report is available at:

https://wiki.yoctoproject.org/wiki/WW15_-_2014-04-11_-_Full_Pass_Release_1
.6_M5.rc4

Thanks go out to everyone for all their hard work during this release!

Sincerely,

Elizabeth Flanagan
Yocto Build and Release
<elizabeth.flanagan@intel.com>

--------------------
yocto-1.6 Errata
--------------------

Release Name: poky-daisy-11.0.0
Branch: daisy
Tag: daisy-11.0.0
Hash: 68ef727cdcef439e9bfc57996f3cebfc0e07789e
md5: 45b8e8126161375e3fa127bc101cfa5d
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-1.6/poky-daisy-11.0
.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-1.6/poky-daisy-11.0.0.tar.bz2

Release Name: eclipse-poky-juno-daisy-11.0.0
Branch: daisy
Tag: daisy-11.0.0
Hash: 26bfc407781aa185f244a47ba63120343cee4a37
md5: a72cb37334fbe3a3ba8994711544102a
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-1.6/eclipse-poky-ju
no-daisy-11.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-1.6/eclipse-poky-juno-daisy-11
.0.0.tar.bz2

Release Name: eclipse-poky-kepler-daisy-11.0.0
Branch: daisy
Tag: daisy-11.0.0
Hash: 1dfe1d2f1322b5fda8e1a7637c447b0e060efb3e
md5: d1fa75bedde2e59c24ce89a751d7de27
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-1.6/eclipse-poky-ke
pler-daisy-11.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-1.6/eclipse-poky-kepler-daisy-
11.0.0.tar.bz2

Release Name: meta-qt3-daisy-11.0.0
Branch: daisy
Tag: daisy-11.0.0
Hash: 3016129d90b7ac8517a5227d819f10ad417b5b45
md5: ee9f4ae56c1a3af53aa560b692996efa
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-1.6/meta-qt3-daisy-
11.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-1.6/meta-qt3-daisy-11.0.0.tar.
bz2

--------------------
Features
--------------------
* Linux kernel 3.14 and 3.10 LTSI
* eglibc 2.19
* gcc 4.8.2
* Add support for building Python 3
* Toaster web UI for exploring build output
* Documentation: refreshed and extended BitBake User Manual
* Documentation: Added "Writing a New Recipe" section to Development
Manual
* Add support for using % as a wildcard in bbappend filename
* Introduce client for reporting errors to a central web interface
* New beaglebone reference BSP (replaces beagleboard)
* New edgerouter reference BSP for Edgerouter Lite (replaces
routerstationpro)
* New support for cute embedded nonsense hacks
* Add automatic defaults for BB_NUMBER_THREADS and PARALLEL_MAKE in
local.conf.sample
* Add ability to set user passwords easily (including root password)
* Change to use SHA512 password encryption with shadow by default
* Add ability to specify static uid/gid values for reproducible
numbering between builds
* Introduce more hard-linking instead of copying to improve
performance and reduce disk usage (where possible)
* Recipe cleanup - remove redundant PR = "r0" from all recipes
* Add support for booting UEFI systems with gummiboot
* Split the functions script out of main initscripts package into a
separate package
* Image / SDK creation code rewritten in Python (previously shell scripts)
* Replace populate-extfs.sh usage for building images with native
e2fsprogs support
* Write manifest file next to every image listing the packages
contained in the image
* Add ability to set the default target for systemd images on a per-image
basis
* Add proper dependency mechanism for image output types
* wic: improve error reporting and checks for system requirements
* wic: add extension mechanism for custom partition contents
* New release naming convention for future releases based upon common
english language homonyms. (e.g. where-12.0.0, wear-13.0.0,
ware-14.0.0)
* Add Git Annex fetcher support
* bitbake: add addtask/deltask Python functions
* Tune file support for consolidated x86 BSPs
* Add an NFSv3 user mode server for use with runqemu (unfs3)
* Add support for lz4 compression in SRC_URI, output kernel binaries
and image files
* Add check for unrecognised configure options during do_configure
* Add ability to build rpm/deb/ipk packages concurrently
* Default to out-of-tree builds when using cmake
* Add autotools-brokensep class for use by recipes which do not
support using separate source and build directories
* More robust stop/restart of NFS services with sysvinit
* BitBake now writes errors to stderr
* bitbake -c listtasks now shows descriptions for each task
* Various sstate / task hash improvements to trigger task re-execution
where needed (and avoid it where not needed)
* Add a -c diffconfig option to the kernel (and other menuconfig
users) enabling easy creation of config fragments
* Show a warning when package is providing an already provided shared
library
* Added / improved systemd support in at, distcc, dpkg, dropbear,
openssh, run-postinsts
* oe-pkgdata-util: add ability to find a recipe from a target package,
look up runtime package names and search for target paths
* Add ability to set template location with .templateconf file at top of
layer
* Add basic ability to run automated runtime tests on real hardware via
known IP
* Add ability to deploy image and run runtime tests on EFI-based
hardware using gummiboot (extensible to other systems)
* Add ability to export automated runtime tests to be run independent
of the build system
* Add oe-selftest script for build system tests
* Enable building ptest packages by default
* Add ptest support to acl, apr, apr-util, attr, beecrypt, diffstat,
diffutils, flex, gawk, gdk-pixbuf, libpcre, parted, quilt, tcl, udev,
valgrind, zlib
* Add piglit for OpenGL testing
* Additional recipes to support testing: waffle, expect,
gnome-desktop-testing, python-mako, python-numpy, python-nose
* sanity.bbclass: support wildcards in SANITY_TESTED_DISTROS

--------------------
Security Fixes
--------------------
* acpid: CVE-2011-1159
* gnupg: CVE-2013-4576
* gnupg: CVE-2013-4351
* gnutls: CVE-2014-0092
* gnutls: CVE-2014-1959
* gst-ffmpeg: CVE-2013-3674
* icu: CVE-2013-2924
* libarchive: CVE-2013-0211
* libtiff: CVE-2013-4244
* libtiff: CVE-2013-4243
* libtiff: CVE-2013-4232
* libtiff: CVE-2013-1960
* libxfont: CVE-2013-6462
* linux-yocto: CVE-2014-0038
* nss: CVE-2013-5605
* nss: CVE-2013-1741
* openssl: CVE-2014-0160
* openssl: CVE-2014-0076
* openssl: CVE-2013-6449
* openssl: CVE-2013-6450
* openssl: CVE-2013-4353
* python: CVE-2014-1912
* python: CVE-2013-1752
* xinetd: CVE-2013-4342
* xorg: CVE-2013-6424

--------------------
Upgrades
--------------------
* acl: Update to 2.2.52
* alsa-tools: update to version 1.0.27
* atk: upgrade to 2.10.0.
* at-spi2-core: upgrade to 2.10.2
* at-spi2-gtk: upgrade to 2.10.0
* attr: upgrade to 2.4.47
* at: upgrade to 3.1.14
* augeas: upgrade to 1.2.0
* autogen-native: upgrade to 5.18.2
* automake: upgrade to 1.14
* base-passwd: upgrade to 3.5.29
* bash: upgrade to 4.3
* bind: Update to 9.9.5
* binutils: Upgrade to 2.24
* bluez5: upgrade to 5.15
* boost: updating to 1.55.0
* btrfs-tools: Update to git HEAD
* busybox: add busybox_git.bb recipe
* busybox: upgrade to stable 1.22.1
* byacc: upgrade to 20140101
* cairo: upgrade to upstream version 1.12.16
* cdrtools-native: upgrade to 3.01a20
* chrpath: upgrade to 0.16
* clutter-1.0: upgrade to 1.16.2
* clutter-gtk-1.0: upgrade to 1.4.4
* cmake: upgrade to 2.8.12.2
* cogl-1.0 : Update to 1.16.2 release
* cogl: upgrade to 1.16.0
* connman: upgrade to 1.22
* coreutils: upgrade to 8.22
* cracklib: upgrade to 2.9.1
* cups: upgrade to 1.7.1
* curl: upgrade to 7.35.0
* dbus: upgrade to 1.6.18
* desktop-file-utils-native: upgrade to 0.22
* dhcp: Update to 4.3.0
* diffstat: upgrade to 1.58
* directfb-examples: update to 1.7.0
* directfb: update to 1.7.1
* dpkg: upgrade to 1.17.4
* dropbear: upgrade to 2014.63
* e2fsprogs: upgrade to 1.42.9
* eglibc: Upgrade from 2.18 -> 2.19
* ethtool: upgrade to 3.13
* file: Update to 5.16
* flac: upgrade to 1.3.0
* flex: upgrade to 2.5.38
* fontconfig: upgrade to 2.11.0
* freetype: upgrade to 2.5.2
* fstests: update to git master
* gcc: Upgrade to 4.8.2
* gdbm: upgrade to 1.11
* gdb: upgrade to 7.6.2
* gdk-pixbuf: upgrade to 2.30.3
* gettext: upgrade to 0.18.3.2
* git: update to 1.9.0 release
* glib-2.0: upgrade to 2.38.2
* glib-networking: upgrade to 2.38.0
* glproto: upgrade to 1.4.17
* gnome-desktop-testing: upgrade to 2014.1
* gnupg: upgrade to 2.0.22
* grep: upgrade to 2.18
* grub git: update to latest git
* gsettings-desktop-schemas: Updated to 3.10.1.bb
* gstreamer1.0-libav: upgrade to 1.2.3
* gstreamer1.0-plugins-bad: upgrade to 1.2.3
* gstreamer1.0-plugins-base: upgrade to 1.2.3
* gstreamer1.0-plugins-good: upgrade to 1.2.3
* gstreamer1.0-plugins-ugly: upgrade to 1.2.3
* gstreamer1.0: upgrade to 1.2.3
* gtk+3: upgrade to 3.10.7
* gtk+: upgrade gtk+ to upstream version 2.24.22
* harfbuzz: upgrade to 0.9.26
* help2man: Update to 1.44.1
* iproute2: upgrade to 3.12.0
* iptables: upgrade to 1.4.21
* json-glib: upgrade to 0.16.2
* kbd: upgrade to 2.0.1
* kconfig-frontends: upgrade to 3.12.0.0
* kmod: Update to Rev 16 via git
* libarchive: Upgrade to v3.1.2
* libav: Add v9.10
* libav: Update to v0.8.9
* libbsd: upgrade to 0.6.0
* libcgroup: Update to 0.41
* libcheck: Update to 0.9.12
* libdrm: upgrade to 2.4.52
* libfm: upgrade to upstream version 1.1.2.2
* libjson: update to 0.11 and rename to json-c
* libmpc: upgrade to 1.0.2
* libpcap: upgrade to 1.5.3
* libpcre: upgrade to 8.34
* libpng: upgrade to 1.6.8
* libproxy: Update to 0.4.11
* librsvg: upgrade to 2.40.1
* libsdl2: upgrade to 2.0.1
* libsm: upgrade to 1.2.2
* libsoup-2.4: upgrade to 2.45.3
* libtasn1: upgrade to 3.4
* libtirpc: upgrade to 0.2.4
* liburcu: upgrade to 0.8.1
* libuser: upgrade to 0.60
* libvorbis: upgrade to 1.3.4
* libx11: upgrade to 1.6.2
* libxcb: upgrade to 1.10
* libxcb: upgrade to 1.9.3
* libxfont: upgrade to 1.4.7
* libxkbcommon: Update to 0.4.0
* libxmu: upgrade to 1.1.2
* libxpm: upgrade to 3.5.11
* libxrandr: upgrade to 1.4.1
* libxv: upgrade to 1.0.10
* lighttpd: upgrade to 1.4.33
* linux-yocto/3.14: add 3.14
* linux-yocto/3.10: update to v3.10.34
* linux-yocto/3.4: update to v3.4.85
* logrotate: upgrade to 3.8.7
* lsbinitscripts: Update to 9.52
* ltp: update to 20140115
* lttng-modules: Add version 2.4.0
* lttng-tools: Add version 2.4.0
* lttng-ust: Add version 2.4.0
* m4: upgrade to 1.4.17
* make: upgrade to 4.0
* man-pages: Update to 3.60
* matcbox-keyboard: bump SRCREV
* mdadm: upgrade to 3.3
* mesa: upgrade to 9.2.5
* minicom: upgrade to 2.7
* mtdev: upgrade to 1.1.5
* mtd-utils: Update version to include fixes after 1.5.0
* nasm: upgrade to 2.11
* neard: upgrade to 0.14
* netbase: upgrade to 5.2
* nfs-utils: upgrade to 1.2.9
* nspr: Update to 4.10.3
* ofono: upgrade to 1.14
* openssh: upgrade to 6.5p1
* openssl: Upgrade to v1.0.1g
* opkg: Upgrade to v0.2.1
* opkg-utils: Upgrade to latest git HEAD
* pango: upgrade to 1.36.2
* pciutils: upgrade to 3.2.1
* pcmanfm: upgraded to 1.1.2
* pigz: bump to 2.3.1
* pixman: upgrade to 0.32.4
* powertop: upgrade to 2.5
* ppp: upgrade to 2.4.6
* psmisc: Update to 22.21
* pulseaudio: Upgrade 4.0 -> 5.0
* puzzles: upgrade to r10116
* python-pycurl: upgrade to 7.19.3
* python-setuptools: upgrade to 1.4
* qemu: upgrade to 1.7.0
* qmmp: update to 0.7.5
* quilt: upgrade to 0.61
* readline: upgrade to 6.3
* rpcbind: upgrade to 0.2.1
* rsync: upgrade to 3.1.0
* rt-tests: version bump to 0.87
* rxvt-unicode: upgrade to 9.19
* sbc: upgrade to 1.2
* screen: update debian patchset to version 4.0.3-14
* shared-mime-info: upgrade to 1.2
* socat: upgrade to 1.7.2.3
* sqlite3: update to 3.8.3.1
* sudo: upgrade to 1.8.9p5
* sysstat: upgrade to 10.2.1
* systemd: upgrade to 211+
* systemtap_git: Move to current HEAD
* systemtap: upgrade to 2.4
* tar: upgrade to 1.27.1
* tcl: upgrade to 8.6.1
* telepathy-glib: upgrade to 0.23.2
* telepathy-idle: upgrade to 0.2.0
* telepathy-mission-control: upgrade to 5.16.1
* texinfo: Update to 5.2
* tzcode & tzdata: update to 2013h
* uclibc: Update to git tip
* util-linux: Update to 2.24.1
* util-macros: upgrade to 1.18.0
* valgrind: upgrade to 3.9.0
* wayland: upgrade to 1.4.0
* weston: upgrade to 1.4.0
* wireless-tools: Upgrade 29 -> 30.pre9
* wpa-supplicant: upgrade to 2.1
* xauth: upgrade to 1.0.8
* xcb-proto: upgrade to 1.10
* xcb-proto: upgrade to 1.9
* xcb-util-wm: upgrade to 0.4.0
* xextproto: upgrade to 7.3.0
* xf86-input-evdev: upgrade to 2.8.2
* xf86-input-keyboard: upgrade to 1.8.0
* xf86-input-synaptics: upgrade to 1.7.3
* xf86-video-fbdev: upgrade to 0.4.4
* xf86-video-intel: upgrade to 2.21.15
* xf86-video-intel: add recipe for 2.99.910, remove the git one
* xf86-video-modesetting: update to 0.8.1
* xf86-video-vesa: upgrade to 2.3.3
* xinit: upgrade to 1.3.3
* xinput: upgrade to 1.6.1
* xkeyboard-config: upgrade to 2.11
* xmodmap: upgrade to 1.0.8
* xprop: upgrade to 1.2.2
* xproto: upgrade to 7.0.25
* xserver-xorg: upgrade to 1.15.0
* xset: upgrade to 1.2.3
* xtrans: upgrade to 1.3.3
* xz: upgrade to 5.1.3alpha
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [meta-selinux][PATCH 0/1] refpolicy: add setrans.conf for mcs/mls policy

Joe MacDonald
 

Merged, thanks.
-J.

[[yocto] [meta-selinux][PATCH 0/1] refpolicy: add setrans.conf for mcs/mls policy] On 14.04.24 (Thu 03:02) wenzong.fan@windriver.com wrote:

From: Wenzong Fan <wenzong.fan@windriver.com>

Add initial version for setrans.conf:
- setrans-mls.conf: copied from \
policycoreutils/mcstrans/share/examples/default/setrans.conf
- setrans-mcs.conf: copied from radhat policy.

This fixes below issue:
$ chcat -L
IOError: No such file or directory: \
'/etc/selinux/$POLICY_NAME/setrans.conf'

The following changes since commit 0362287928bc0a58b755488ebd74441c28eeeee2:

audit: Fix lack of a default audit.rules (2014-04-07 09:55:49 -0400)

are available in the git repository at:

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

Wenzong Fan (1):
refpolicy: add setrans.conf for mcs/mls policy

recipes-security/refpolicy/files/setrans-mcs.conf | 17 +++++++
recipes-security/refpolicy/files/setrans-mls.conf | 52 +++++++++++++++++++++
recipes-security/refpolicy/refpolicy_common.inc | 8 ++++
3 files changed, 77 insertions(+)
create mode 100644 recipes-security/refpolicy/files/setrans-mcs.conf
create mode 100644 recipes-security/refpolicy/files/setrans-mls.conf

--
1.7.9.5
--
-Joe MacDonald.
:wq


Re: [meta-selinux][PATCH] audit: Enable ARM System Call Audit in user space.

Joe MacDonald
 

Merged, thanks.
-J.

[[yocto] [meta-selinux][PATCH] audit: Enable ARM System Call Audit in user space.] On 14.04.24 (Thu 16:34) Kai Kang wrote:

From: Han Chao <chan@windriver.com>

Audit System Call needs kernel and user space support.

In user space it needs system call table for ARM. It also needs a
configure option --with-armeb for build audit. Audit system call also
needs enable kernel config CONFIG_AUDITSYSCALL.

Signed-off-by: Han Chao <chan@windriver.com>
Signed-off-by: Kai Kang <kai.kang@windriver.com>
---
.../audit/add-system-call-table-for-ARM.patch | 46 ++++++++++++++++++++++
recipes-security/audit/audit_2.3.2.bb | 2 +
2 files changed, 48 insertions(+)
create mode 100644 recipes-security/audit/audit/add-system-call-table-for-ARM.patch

diff --git a/recipes-security/audit/audit/add-system-call-table-for-ARM.patch b/recipes-security/audit/audit/add-system-call-table-for-ARM.patch
new file mode 100644
index 0000000..ad94d11
--- /dev/null
+++ b/recipes-security/audit/audit/add-system-call-table-for-ARM.patch
@@ -0,0 +1,46 @@
+From 52ff74be2f01182ed9d4fcc3da059512fad63d72 Mon Sep 17 00:00:00 2001
+From: Han Chao <chan@windriver.com>
+Date: Thu, 27 Feb 2014 14:58:57 +0800
+Subject: [PATCH] add system call table for ARM.
+
+This change enable audit system call on ARM.
+Add arm System call table on machinetabs.h.
+Audit system call need enable kernel config CONFIG_AUDITSYSCALL.
+
+Signed-off-by: Han Chao <chan@windriver.com>
+---
+ lib/machinetabs.h | 11 ++++++-----
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+diff --git a/lib/machinetabs.h b/lib/machinetabs.h
+index ec2d033..1c2e284 100644
+--- a/lib/machinetabs.h
++++ b/lib/machinetabs.h
+@@ -1,10 +1,11 @@
+-/* This is a generated file, see Makefile.am for its inputs. */
+-static const char machine_strings[] = "i386\0i486\0i586\0i686\0ia64\0ppc\0ppc64\0s390\0s390x\0x86_64";
++/* Such is aways generated file, see Makefile.am for its inputs.
++ * But this version is not generated file, which is for ARM. */
++static const char machine_strings[] = "armeb\0armv5tejl\0armv5tel\0armv6l\0armv7l";
+ static const unsigned machine_s2i_s[] = {
+- 0,5,10,15,20,25,29,35,40,46,
++ 0,6,16,25,32,
+ };
+ static const int machine_s2i_i[] = {
+- 0,0,0,0,2,4,3,6,5,1,
++ 8,8,8,8,8,
+ };
+ static int machine_s2i(const char *s, int *value) {
+ size_t len, i;
+@@ -19,7 +20,7 @@ static int machine_s2i(const char *s, int *value) {
+ }
+ }
+ static const unsigned machine_i2s_direct[] = {
+- 0,46,20,29,25,40,35,
++ 39,85,59,68,64,
+ };
+ static const char *machine_i2s(int v) {
+ return i2s_direct__(machine_strings, machine_i2s_direct, 0, 6, v);
+--
+1.7.9.5
+
diff --git a/recipes-security/audit/audit_2.3.2.bb b/recipes-security/audit/audit_2.3.2.bb
index ae6556f..4baf7a0 100644
--- a/recipes-security/audit/audit_2.3.2.bb
+++ b/recipes-security/audit/audit_2.3.2.bb
@@ -18,6 +18,7 @@ SRC_URI = "http://people.redhat.com/sgrubb/audit/audit-${PV}.tar.gz \
file://auditd.service \
file://audit-volatile.conf \
"
+SRC_URI_append_arm = "file://add-system-call-table-for-ARM.patch"

inherit autotools pythonnative update-rc.d systemd

@@ -41,6 +42,7 @@ EXTRA_OECONF += "--without-prelude \
--libdir=${base_libdir} \
--sbindir=${base_sbindir} \
"
+EXTRA_OECONF_append_arm = " --with-armeb=yes"

EXTRA_OEMAKE += "PYLIBVER='python${PYTHON_BASEVERSION}' \
PYINC='${STAGING_INCDIR}/$(PYLIBVER)' \
--
1.8.4
--
-Joe MacDonald.
:wq


Re: [meta-selinux][PATCH 0/4] some minor fixes to udevd, initscripts, policycoreutils

Joe MacDonald
 

Merged, thanks.
-J.

[[yocto] [meta-selinux][PATCH 0/4] some minor fixes to udevd, initscripts, policycoreutils] On 14.04.23 (Wed 03:42) wenzong.fan@windriver.com wrote:

From: Wenzong Fan <wenzong.fan@windriver.com>

* udevd: it creates /dev/shm, /dev/pts, restorecon for them as well;
* initscripts: always force to restore file contexts for /var/lib
* policycoreutils:
get semanage process the ValueError from sepolicy, seobject;
fix TypeError from seobject.py

The following changes since commit 0362287928bc0a58b755488ebd74441c28eeeee2:
policycoreutils
audit: Fix lack of a default audit.rules (2014-04-07 09:55:49 -0400)

are available in the git repository at:

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

Wenzong Fan (4):
udev init: restorecon for /dev/shm, /dev/pts
always force to restore file contexts for /var/lib
semanage: process ValueError for sepolicy, seobject
policycoreutils: fix TypeError for seobject.py

recipes-core/initscripts/initscripts_1.0.bbappend | 2 +-
recipes-core/udev/udev/init | 2 +-
...cycoreutils-fix-TypeError-for-seobject.py.patch | 32 +++++++++++++
...-process-ValueError-for-sepolicy-seobject.patch | 48 ++++++++++++++++++++
recipes-security/selinux/policycoreutils_2.2.5.bb | 2 +
5 files changed, 84 insertions(+), 2 deletions(-)
create mode 100644 recipes-security/selinux/policycoreutils/policycoreutils-fix-TypeError-for-seobject.py.patch
create mode 100644 recipes-security/selinux/policycoreutils/policycoreutils-process-ValueError-for-sepolicy-seobject.patch

--
1.7.9.5
--
-Joe MacDonald.
:wq


[ANNOUNCEMENT] Yocto Project 1.6 (daisy 11.0.0) Released

Flanagan, Elizabeth <elizabeth.flanagan@...>
 

Hello,

The latest release of the Yocto Project 1.6 (daisy-11.0.0) is now available
for download at:

http://downloads.yoctoproject.org/releases/yocto/yocto-1.6/poky-daisy-11.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-1.6/poky-daisy-11.0.0.tar.bz2

A gpg signed version of these release notes is available at:

http://downloads.yoctoproject.org/releases/yocto/yocto-1.6/RELEASENOTES

Full pass test report is available at:

https://wiki.yoctoproject.org/wiki/WW15_-_2014-04-11_-_Full_Pass_Release_1.6_M5.rc4

Thanks go out to everyone for all their hard work during this release!

Sincerely,

Elizabeth Flanagan
Yocto Build and Release
<elizabeth.flanagan@intel.com>

--------------------
yocto-1.6 Errata
--------------------

Release Name: poky-daisy-11.0.0
Branch: daisy
Tag: daisy-11.0.0
Hash: 68ef727cdcef439e9bfc57996f3cebfc0e07789e
md5: 45b8e8126161375e3fa127bc101cfa5d
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-1.6/poky-daisy-11.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-1.6/poky-daisy-11.0.0.tar.bz2

Release Name: eclipse-poky-juno-daisy-11.0.0
Branch: daisy
Tag: daisy-11.0.0
Hash: 26bfc407781aa185f244a47ba63120343cee4a37
md5: a72cb37334fbe3a3ba8994711544102a
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-1.6/eclipse-poky-juno-daisy-11.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-1.6/eclipse-poky-juno-daisy-11.0.0.tar.bz2

Release Name: eclipse-poky-kepler-daisy-11.0.0
Branch: daisy
Tag: daisy-11.0.0
Hash: 1dfe1d2f1322b5fda8e1a7637c447b0e060efb3e
md5: d1fa75bedde2e59c24ce89a751d7de27
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-1.6/eclipse-poky-kepler-daisy-11.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-1.6/eclipse-poky-kepler-daisy-11.0.0.tar.bz2

Release Name: meta-qt3-daisy-11.0.0
Branch: daisy
Tag: daisy-11.0.0
Hash: 3016129d90b7ac8517a5227d819f10ad417b5b45
md5: ee9f4ae56c1a3af53aa560b692996efa
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-1.6/meta-qt3-daisy-11.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-1.6/meta-qt3-daisy-11.0.0.tar.bz2

--------------------
Features
--------------------
* Linux kernel 3.14 and 3.10 LTSI
* eglibc 2.19
* gcc 4.8.2
* Add support for building Python 3
* Toaster web UI for exploring build output
* Documentation: refreshed and extended BitBake User Manual
* Documentation: Added "Writing a New Recipe" section to Development Manual
* Add support for using % as a wildcard in bbappend filename
* Introduce client for reporting errors to a central web interface
* New beaglebone reference BSP (replaces beagleboard)
* New edgerouter reference BSP for Edgerouter Lite (replaces routerstationpro)
* New support for cute embedded nonsense hacks
* Add automatic defaults for BB_NUMBER_THREADS and PARALLEL_MAKE in
local.conf.sample
* Add ability to set user passwords easily (including root password)
* Change to use SHA512 password encryption with shadow by default
* Add ability to specify static uid/gid values for reproducible
numbering between builds
* Introduce more hard-linking instead of copying to improve
performance and reduce disk usage (where possible)
* Recipe cleanup - remove redundant PR = "r0" from all recipes
* Add support for booting UEFI systems with gummiboot
* Split the functions script out of main initscripts package into a
separate package
* Image / SDK creation code rewritten in Python (previously shell scripts)
* Replace populate-extfs.sh usage for building images with native
e2fsprogs support
* Write manifest file next to every image listing the packages
contained in the image
* Add ability to set the default target for systemd images on a per-image basis
* Add proper dependency mechanism for image output types
* wic: improve error reporting and checks for system requirements
* wic: add extension mechanism for custom partition contents
* New release naming convention for future releases based upon common
english language homonyms. (e.g. where-12.0.0, wear-13.0.0,
ware-14.0.0)
* Add Git Annex fetcher support
* bitbake: add addtask/deltask Python functions
* Tune file support for consolidated x86 BSPs
* Add an NFSv3 user mode server for use with runqemu (unfs3)
* Add support for lz4 compression in SRC_URI, output kernel binaries
and image files
* Add check for unrecognised configure options during do_configure
* Add ability to build rpm/deb/ipk packages concurrently
* Default to out-of-tree builds when using cmake
* Add autotools-brokensep class for use by recipes which do not
support using separate source and build directories
* More robust stop/restart of NFS services with sysvinit
* BitBake now writes errors to stderr
* bitbake -c listtasks now shows descriptions for each task
* Various sstate / task hash improvements to trigger task re-execution
where needed (and avoid it where not needed)
* Add a -c diffconfig option to the kernel (and other menuconfig
users) enabling easy creation of config fragments
* Show a warning when package is providing an already provided shared library
* Added / improved systemd support in at, distcc, dpkg, dropbear,
openssh, run-postinsts
* oe-pkgdata-util: add ability to find a recipe from a target package,
look up runtime package names and search for target paths
* Add ability to set template location with .templateconf file at top of layer
* Add basic ability to run automated runtime tests on real hardware via known IP
* Add ability to deploy image and run runtime tests on EFI-based
hardware using gummiboot (extensible to other systems)
* Add ability to export automated runtime tests to be run independent
of the build system
* Add oe-selftest script for build system tests
* Enable building ptest packages by default
* Add ptest support to acl, apr, apr-util, attr, beecrypt, diffstat,
diffutils, flex, gawk, gdk-pixbuf, libpcre, parted, quilt, tcl, udev,
valgrind, zlib
* Add piglit for OpenGL testing
* Additional recipes to support testing: waffle, expect,
gnome-desktop-testing, python-mako, python-numpy, python-nose
* sanity.bbclass: support wildcards in SANITY_TESTED_DISTROS

--------------------
Security Fixes
--------------------
* acpid: CVE-2011-1159
* gnupg: CVE-2013-4576
* gnupg: CVE-2013-4351
* gnutls: CVE-2014-0092
* gnutls: CVE-2014-1959
* gst-ffmpeg: CVE-2013-3674
* icu: CVE-2013-2924
* libarchive: CVE-2013-0211
* libtiff: CVE-2013-4244
* libtiff: CVE-2013-4243
* libtiff: CVE-2013-4232
* libtiff: CVE-2013-1960
* libxfont: CVE-2013-6462
* linux-yocto: CVE-2014-0038
* nss: CVE-2013-5605
* nss: CVE-2013-1741
* openssl: CVE-2014-0160
* openssl: CVE-2014-0076
* openssl: CVE-2013-6449
* openssl: CVE-2013-6450
* openssl: CVE-2013-4353
* python: CVE-2014-1912
* python: CVE-2013-1752
* xinetd: CVE-2013-4342
* xorg: CVE-2013-6424

--------------------
Upgrades
--------------------
* acl: Update to 2.2.52
* alsa-tools: update to version 1.0.27
* atk: upgrade to 2.10.0.
* at-spi2-core: upgrade to 2.10.2
* at-spi2-gtk: upgrade to 2.10.0
* attr: upgrade to 2.4.47
* at: upgrade to 3.1.14
* augeas: upgrade to 1.2.0
* autogen-native: upgrade to 5.18.2
* automake: upgrade to 1.14
* base-passwd: upgrade to 3.5.29
* bash: upgrade to 4.3
* bind: Update to 9.9.5
* binutils: Upgrade to 2.24
* bluez5: upgrade to 5.15
* boost: updating to 1.55.0
* btrfs-tools: Update to git HEAD
* busybox: add busybox_git.bb recipe
* busybox: upgrade to stable 1.22.1
* byacc: upgrade to 20140101
* cairo: upgrade to upstream version 1.12.16
* cdrtools-native: upgrade to 3.01a20
* chrpath: upgrade to 0.16
* clutter-1.0: upgrade to 1.16.2
* clutter-gtk-1.0: upgrade to 1.4.4
* cmake: upgrade to 2.8.12.2
* cogl-1.0 : Update to 1.16.2 release
* cogl: upgrade to 1.16.0
* connman: upgrade to 1.22
* coreutils: upgrade to 8.22
* cracklib: upgrade to 2.9.1
* cups: upgrade to 1.7.1
* curl: upgrade to 7.35.0
* dbus: upgrade to 1.6.18
* desktop-file-utils-native: upgrade to 0.22
* dhcp: Update to 4.3.0
* diffstat: upgrade to 1.58
* directfb-examples: update to 1.7.0
* directfb: update to 1.7.1
* dpkg: upgrade to 1.17.4
* dropbear: upgrade to 2014.63
* e2fsprogs: upgrade to 1.42.9
* eglibc: Upgrade from 2.18 -> 2.19
* ethtool: upgrade to 3.13
* file: Update to 5.16
* flac: upgrade to 1.3.0
* flex: upgrade to 2.5.38
* fontconfig: upgrade to 2.11.0
* freetype: upgrade to 2.5.2
* fstests: update to git master
* gcc: Upgrade to 4.8.2
* gdbm: upgrade to 1.11
* gdb: upgrade to 7.6.2
* gdk-pixbuf: upgrade to 2.30.3
* gettext: upgrade to 0.18.3.2
* git: update to 1.9.0 release
* glib-2.0: upgrade to 2.38.2
* glib-networking: upgrade to 2.38.0
* glproto: upgrade to 1.4.17
* gnome-desktop-testing: upgrade to 2014.1
* gnupg: upgrade to 2.0.22
* grep: upgrade to 2.18
* grub git: update to latest git
* gsettings-desktop-schemas: Updated to 3.10.1.bb
* gstreamer1.0-libav: upgrade to 1.2.3
* gstreamer1.0-plugins-bad: upgrade to 1.2.3
* gstreamer1.0-plugins-base: upgrade to 1.2.3
* gstreamer1.0-plugins-good: upgrade to 1.2.3
* gstreamer1.0-plugins-ugly: upgrade to 1.2.3
* gstreamer1.0: upgrade to 1.2.3
* gtk+3: upgrade to 3.10.7
* gtk+: upgrade gtk+ to upstream version 2.24.22
* harfbuzz: upgrade to 0.9.26
* help2man: Update to 1.44.1
* iproute2: upgrade to 3.12.0
* iptables: upgrade to 1.4.21
* json-glib: upgrade to 0.16.2
* kbd: upgrade to 2.0.1
* kconfig-frontends: upgrade to 3.12.0.0
* kmod: Update to Rev 16 via git
* libarchive: Upgrade to v3.1.2
* libav: Add v9.10
* libav: Update to v0.8.9
* libbsd: upgrade to 0.6.0
* libcgroup: Update to 0.41
* libcheck: Update to 0.9.12
* libdrm: upgrade to 2.4.52
* libfm: upgrade to upstream version 1.1.2.2
* libjson: update to 0.11 and rename to json-c
* libmpc: upgrade to 1.0.2
* libpcap: upgrade to 1.5.3
* libpcre: upgrade to 8.34
* libpng: upgrade to 1.6.8
* libproxy: Update to 0.4.11
* librsvg: upgrade to 2.40.1
* libsdl2: upgrade to 2.0.1
* libsm: upgrade to 1.2.2
* libsoup-2.4: upgrade to 2.45.3
* libtasn1: upgrade to 3.4
* libtirpc: upgrade to 0.2.4
* liburcu: upgrade to 0.8.1
* libuser: upgrade to 0.60
* libvorbis: upgrade to 1.3.4
* libx11: upgrade to 1.6.2
* libxcb: upgrade to 1.10
* libxcb: upgrade to 1.9.3
* libxfont: upgrade to 1.4.7
* libxkbcommon: Update to 0.4.0
* libxmu: upgrade to 1.1.2
* libxpm: upgrade to 3.5.11
* libxrandr: upgrade to 1.4.1
* libxv: upgrade to 1.0.10
* lighttpd: upgrade to 1.4.33
* linux-yocto/3.14: add 3.14
* linux-yocto/3.10: update to v3.10.34
* linux-yocto/3.4: update to v3.4.85
* logrotate: upgrade to 3.8.7
* lsbinitscripts: Update to 9.52
* ltp: update to 20140115
* lttng-modules: Add version 2.4.0
* lttng-tools: Add version 2.4.0
* lttng-ust: Add version 2.4.0
* m4: upgrade to 1.4.17
* make: upgrade to 4.0
* man-pages: Update to 3.60
* matcbox-keyboard: bump SRCREV
* mdadm: upgrade to 3.3
* mesa: upgrade to 9.2.5
* minicom: upgrade to 2.7
* mtdev: upgrade to 1.1.5
* mtd-utils: Update version to include fixes after 1.5.0
* nasm: upgrade to 2.11
* neard: upgrade to 0.14
* netbase: upgrade to 5.2
* nfs-utils: upgrade to 1.2.9
* nspr: Update to 4.10.3
* ofono: upgrade to 1.14
* openssh: upgrade to 6.5p1
* openssl: Upgrade to v1.0.1g
* opkg: Upgrade to v0.2.1
* opkg-utils: Upgrade to latest git HEAD
* pango: upgrade to 1.36.2
* pciutils: upgrade to 3.2.1
* pcmanfm: upgraded to 1.1.2
* pigz: bump to 2.3.1
* pixman: upgrade to 0.32.4
* powertop: upgrade to 2.5
* ppp: upgrade to 2.4.6
* psmisc: Update to 22.21
* pulseaudio: Upgrade 4.0 -> 5.0
* puzzles: upgrade to r10116
* python-pycurl: upgrade to 7.19.3
* python-setuptools: upgrade to 1.4
* qemu: upgrade to 1.7.0
* qmmp: update to 0.7.5
* quilt: upgrade to 0.61
* readline: upgrade to 6.3
* rpcbind: upgrade to 0.2.1
* rsync: upgrade to 3.1.0
* rt-tests: version bump to 0.87
* rxvt-unicode: upgrade to 9.19
* sbc: upgrade to 1.2
* screen: update debian patchset to version 4.0.3-14
* shared-mime-info: upgrade to 1.2
* socat: upgrade to 1.7.2.3
* sqlite3: update to 3.8.3.1
* sudo: upgrade to 1.8.9p5
* sysstat: upgrade to 10.2.1
* systemd: upgrade to 211+
* systemtap_git: Move to current HEAD
* systemtap: upgrade to 2.4
* tar: upgrade to 1.27.1
* tcl: upgrade to 8.6.1
* telepathy-glib: upgrade to 0.23.2
* telepathy-idle: upgrade to 0.2.0
* telepathy-mission-control: upgrade to 5.16.1
* texinfo: Update to 5.2
* tzcode & tzdata: update to 2013h
* uclibc: Update to git tip
* util-linux: Update to 2.24.1
* util-macros: upgrade to 1.18.0
* valgrind: upgrade to 3.9.0
* wayland: upgrade to 1.4.0
* weston: upgrade to 1.4.0
* wireless-tools: Upgrade 29 -> 30.pre9
* wpa-supplicant: upgrade to 2.1
* xauth: upgrade to 1.0.8
* xcb-proto: upgrade to 1.10
* xcb-proto: upgrade to 1.9
* xcb-util-wm: upgrade to 0.4.0
* xextproto: upgrade to 7.3.0
* xf86-input-evdev: upgrade to 2.8.2
* xf86-input-keyboard: upgrade to 1.8.0
* xf86-input-synaptics: upgrade to 1.7.3
* xf86-video-fbdev: upgrade to 0.4.4
* xf86-video-intel: upgrade to 2.21.15
* xf86-video-intel: add recipe for 2.99.910, remove the git one
* xf86-video-modesetting: update to 0.8.1
* xf86-video-vesa: upgrade to 2.3.3
* xinit: upgrade to 1.3.3
* xinput: upgrade to 1.6.1
* xkeyboard-config: upgrade to 2.11
* xmodmap: upgrade to 1.0.8
* xprop: upgrade to 1.2.2
* xproto: upgrade to 7.0.25
* xserver-xorg: upgrade to 1.15.0
* xset: upgrade to 1.2.3
* xtrans: upgrade to 1.3.3
* xz: upgrade to 5.1.3alpha


Re: patching issue

Khem Raj
 

On Thu, Apr 24, 2014 at 8:27 AM, Rohit2 Jindal
<rohit2.jindal@aricent.com> wrote:
I have two patches and two different source as shown with fetching controlled using SRC_URI_newlib and SRC_URI and I want to apply patches conditionally on SRC_URI and SRC_URI_newlib . But fails to do so.
Can u help how to apply newlib.patch in SRC_URI_newlib and glibc.patch in SRC_URI.

If I keep newlib.patch in SRC_URI_newlib it is not considered and ignored.

Please help me out
is new lib an override that you have defined ? if not then yes its not
going to change anything when you say SRC_URI_newlib


Re: Exporting kernel header from patch

Vuille, Martin (Martin) <vmartin@...>
 

From: Bruce Ashfield
Sent: April 24, 2014 4:06 PM
To: Vuille, Martin (Martin); yocto@yoctoproject.org
Subject: Re: [yocto] Exporting kernel header from patch

On 14-04-24 03:54 PM, Vuille, Martin (Martin) wrote:
From: Bruce Ashfield
Sent: April 24, 2014 2:01 PM
To: Vuille, Martin (Martin); yocto@yoctoproject.org
Subject: Re: [yocto] Exporting kernel header from patch

On 14-04-24 01:52 PM, Vuille, Martin (Martin) wrote:
From: Bruce Ashfield
Sent: April 24, 2014 1:32 PM

On 14-04-24 11:57 AM, Vuille, Martin (Martin) wrote:
I have a custom layer to add patches to my vendor's BSP layer

(based on Linux 3.4, if it matters) and a .bbappend to list the

patches.

One of the patches adds a header, and this header needs to

be exported to the sysroot.

I added the following to my .bbappend, based on a discussion

I found:

do_install_append() {

install -d ${D}${includedir}/linux

install -m 644 ${S}/include/linux/uc1698u.h
${D}${includedir}/linux/uc1698u.h

}

It "works" (i.e., the header is installed in the sysroot) but
there must

be more to it than that because I also get a warning about the
header

being "installed but not shipped in any package".

What's the correct way to do this?
Not answering the question directly, but I can say that kernel's
shouldn't be exporting their header files over the sysroot's
include/linux/* directory structure, since that is where
linux-libc-headers installs and manages the userspace safe headers
for
the c-library.

Sure you are probably installing a new file, and one that doesn't
conflict with the existing libc-headers, but as soon as you start
working in that directory structure .. you will eventually clobber
an
existing file.

There have been quite a few discussions on this topic over time on
the oe- core and yocto lists. Look at the comment in the
linux-libc-headers.inc file, and you'll see a note from Richard
explaining why this shouldn't be done (searches on the mailing list
archives will also find more hits).

When you install into the sysroot, the header file should also be
in a FILES_<package> as part of your recipe .. and that is why you
are seeing the warning. packaging it would remove the warning, but
you'll still have the problem I mention above.

The right way is for your application to look at the
STAGING_KERNEL_DIR, which will have a copy of that same header file.

Alternatively, you can stage your header file at a different
sysroot location than include/linux/* and have your application look
there.

I have an open enhancement that I'm doing for yocto 1.7 which
automates the alternate header file structure, but doing it
explicitly in your recipes will work for now.
Hi Bruce,

Thanks for your response. But I'm afraid I'm not entirely following
you. I am quite new to Yocto/OE, so I may be missing something
fundamental/obvious.

Leaving aside the patch and .bbappend for the moment, presumably it
is normal for the kernel in the BSP layer to export headers for
userland's consumption. How is that specified? Where is the
FILES_<package> that lists those headers?
Actually, in the yocto world, it isn't. At least not in the sense
that you are looking for.

The kernel's source tree is staged for consumption by other packages
in the sysroot, accessible via the variable STAGING_KERNEL_DIR.
That's the first choice for an application to look for kernel header files.

The sysroots /usr/include/linux/* is strictly for the
linux-libc-headers package, and nothing else should be installing into
that structure.

If you do need to export something to the sysroot, that isn't already
in the libc-headers, and you can't use the STAGING_KERNEL_DIR, then
you should be installing it to another directory structure like:
/usr-alt/include/linux/*
and have your applications look there. You'd export and install them
similarly to what you are doing, and you'd need to package them
similarly.

i.e. in the recipe:

PACKAGES += " kernel-extra-headers"
FILES_kernel-extra-headers = "/usr-alt/linux/*'

And you'd get the header in the sysroot, and avoid the QA warning
about it not being packaged.
I probably should've mentioned earlier that this header contains some
ioctl definitions that I need to import into some userland code.

If I include the header from STAGING_KERNEL_DIR, isn't that the "raw"
header, unprepared for inclusion from userland? (Of course, that was
also a problem with my original way of doing it, which I omitted from my
OP).

Yep, it is the kernel header without having been run through the uapi
export. But that doesn't mean it is immediately wrong, applications that
know what they are doing can look at headers directly.


What is special about the headers added to sysroot by linux-libc-headers?
If this driver were part of upstream instead of added by me, wouldn't
its header file be included in the sysroot by linux-libc-headers?
Yes it would be, and then it forms part of the released kernel's ABI, and is
what the libc interface is based on. It also means that the definitions are
consistent across kernels of that same version. If you are patching the
kernel to add it, that no longer holds.

I assume you found the history and .inc file I pointed out ? They explain a
some of what I have above, but maybe not clearly enough. Those exports
are special, and are for the c library. They are not for kernel exports to
userspace. That's the way the system works, and it is to ensure a sane and
santized mapping between the c library and the kernel.

board specific exports (which is what you are describing), are done in board
specific ways, which I described as the options. When your application is
looking for something that is specific to your kernel, the application is by
definition board/arch specific, so can depend on the kernel to get the
headers that it needs.


I understand that glibc was built against the headers from
linux-libc-headers, but that shouldn't matter since no one else but me
knows about this new header.
It's the slippery slope. Don't install into that structure since someone can
inadvertently change a syscall number, function signature, or something
else fundamental.

I realize you aren't doing that, but eventually someone will .. so simply
saying "don't do that", is the right thing to keep the system sane and correct.


Is there a legitimate way for me to add to linux-libc-headers?
You can bbappend and patch the source code. That means that you've
considered the change, and want it explicitly exported to userspace via the
libc-headers. That will also trigger the libc-headers signature to change and
then chain to a full system rebuild (Which is the other reason we simply
don't install into the c headers path).

Instead of doing that, see my suggestion about installing into an alternate
location and have your application put it on it's include path .. a -I is pretty
easy to add. Since the application is clearly aware and in need of a special
kernel capability, either looking at the source directly, or using that
alternate include are not out of the ordinary.
Thanks for the detailed explanation. I will head in the direction of a separate
location for that (and any other board-specific) headers.

MV


Re: Exporting kernel header from patch

Bruce Ashfield <bruce.ashfield@...>
 

On 14-04-24 03:54 PM, Vuille, Martin (Martin) wrote:
From: Bruce Ashfield
Sent: April 24, 2014 2:01 PM
To: Vuille, Martin (Martin); yocto@yoctoproject.org
Subject: Re: [yocto] Exporting kernel header from patch

On 14-04-24 01:52 PM, Vuille, Martin (Martin) wrote:
From: Bruce Ashfield
Sent: April 24, 2014 1:32 PM

On 14-04-24 11:57 AM, Vuille, Martin (Martin) wrote:
I have a custom layer to add patches to my vendor's BSP layer

(based on Linux 3.4, if it matters) and a .bbappend to list the

patches.

One of the patches adds a header, and this header needs to

be exported to the sysroot.

I added the following to my .bbappend, based on a discussion

I found:

do_install_append() {

install -d ${D}${includedir}/linux

install -m 644 ${S}/include/linux/uc1698u.h
${D}${includedir}/linux/uc1698u.h

}

It "works" (i.e., the header is installed in the sysroot) but there
must

be more to it than that because I also get a warning about the
header

being "installed but not shipped in any package".

What's the correct way to do this?
Not answering the question directly, but I can say that kernel's
shouldn't be exporting their header files over the sysroot's
include/linux/* directory structure, since that is where
linux-libc-headers installs and manages the userspace safe headers for
the c-library.

Sure you are probably installing a new file, and one that doesn't
conflict with the existing libc-headers, but as soon as you start
working in that directory structure .. you will eventually clobber an
existing file.

There have been quite a few discussions on this topic over time on
the oe- core and yocto lists. Look at the comment in the
linux-libc-headers.inc file, and you'll see a note from Richard
explaining why this shouldn't be done (searches on the mailing list
archives will also find more hits).

When you install into the sysroot, the header file should also be in
a FILES_<package> as part of your recipe .. and that is why you are
seeing the warning. packaging it would remove the warning, but you'll
still have the problem I mention above.

The right way is for your application to look at the
STAGING_KERNEL_DIR, which will have a copy of that same header file.

Alternatively, you can stage your header file at a different sysroot
location than include/linux/* and have your application look there.

I have an open enhancement that I'm doing for yocto 1.7 which
automates the alternate header file structure, but doing it
explicitly in your recipes will work for now.
Hi Bruce,

Thanks for your response. But I'm afraid I'm not entirely following
you. I am quite new to Yocto/OE, so I may be missing something
fundamental/obvious.

Leaving aside the patch and .bbappend for the moment, presumably it is
normal for the kernel in the BSP layer to export headers for
userland's consumption. How is that specified? Where is the
FILES_<package> that lists those headers?
Actually, in the yocto world, it isn't. At least not in the sense that you are
looking for.

The kernel's source tree is staged for consumption by other packages in the
sysroot, accessible via the variable STAGING_KERNEL_DIR. That's the first
choice for an application to look for kernel header files.

The sysroots /usr/include/linux/* is strictly for the linux-libc-headers
package, and nothing else should be installing into that structure.

If you do need to export something to the sysroot, that isn't already in the
libc-headers, and you can't use the STAGING_KERNEL_DIR, then you should
be installing it to another directory structure like:
/usr-alt/include/linux/*
and have your applications look there. You'd export and install them
similarly to what you are doing, and you'd need to package them similarly.

i.e. in the recipe:

PACKAGES += " kernel-extra-headers"
FILES_kernel-extra-headers = "/usr-alt/linux/*'

And you'd get the header in the sysroot, and avoid the QA warning about it
not being packaged.
I probably should've mentioned earlier that this header contains some ioctl
definitions that I need to import into some userland code.

If I include the header from STAGING_KERNEL_DIR, isn't that the "raw"
header, unprepared for inclusion from userland? (Of course, that was also
a problem with my original way of doing it, which I omitted from my OP).
Yep, it is the kernel header without having been run through the uapi
export. But that doesn't mean it is immediately wrong, applications that
know what they are doing can look at headers directly.


What is special about the headers added to sysroot by linux-libc-headers?
If this driver were part of upstream instead of added by me, wouldn't its
header file be included in the sysroot by linux-libc-headers?
Yes it would be, and then it forms part of the released kernel's ABI,
and is what the libc interface is based on. It also means that the
definitions are consistent across kernels of that same version. If you
are patching the kernel to add it, that no longer holds.

I assume you found the history and .inc file I pointed out ? They
explain a some of what I have above, but maybe not clearly enough. Those
exports are special, and are for the c library. They are not for kernel
exports to userspace. That's the way the system works, and it is to
ensure a sane and santized mapping between the c library and the kernel.

board specific exports (which is what you are describing), are done in
board specific ways, which I described as the options. When your application
is looking for something that is specific to your kernel, the application
is by definition board/arch specific, so can depend on the kernel to
get the headers that it needs.


I understand that glibc was built against the headers from linux-libc-headers,
but that shouldn't matter since no one else but me knows about this new
header.
It's the slippery slope. Don't install into that structure since
someone can inadvertently change a syscall number, function signature,
or something else fundamental.

I realize you aren't doing that, but eventually someone will .. so
simply saying "don't do that", is the right thing to keep the system
sane and correct.


Is there a legitimate way for me to add to linux-libc-headers?
You can bbappend and patch the source code. That means that you've considered
the change, and want it explicitly exported to userspace via the
libc-headers. That will also trigger the libc-headers signature to
change and then chain to a full system rebuild (Which is the
other reason we simply don't install into the c headers path).

Instead of doing that, see my suggestion about installing into an
alternate location and have your application put it on it's
include path .. a -I is pretty easy to add. Since the application
is clearly aware and in need of a special kernel capability, either
looking at the source directly, or using that alternate include are
not out of the ordinary.

Cheers,

Bruce


Apologies if I've gotten myself confused.

MV


Re: Exporting kernel header from patch

Vuille, Martin (Martin) <vmartin@...>
 

From: Bruce Ashfield
Sent: April 24, 2014 2:01 PM
To: Vuille, Martin (Martin); yocto@yoctoproject.org
Subject: Re: [yocto] Exporting kernel header from patch

On 14-04-24 01:52 PM, Vuille, Martin (Martin) wrote:
From: Bruce Ashfield
Sent: April 24, 2014 1:32 PM

On 14-04-24 11:57 AM, Vuille, Martin (Martin) wrote:
I have a custom layer to add patches to my vendor's BSP layer

(based on Linux 3.4, if it matters) and a .bbappend to list the

patches.

One of the patches adds a header, and this header needs to

be exported to the sysroot.

I added the following to my .bbappend, based on a discussion

I found:

do_install_append() {

install -d ${D}${includedir}/linux

install -m 644 ${S}/include/linux/uc1698u.h
${D}${includedir}/linux/uc1698u.h

}

It "works" (i.e., the header is installed in the sysroot) but there
must

be more to it than that because I also get a warning about the
header

being "installed but not shipped in any package".

What's the correct way to do this?
Not answering the question directly, but I can say that kernel's
shouldn't be exporting their header files over the sysroot's
include/linux/* directory structure, since that is where
linux-libc-headers installs and manages the userspace safe headers for
the c-library.

Sure you are probably installing a new file, and one that doesn't
conflict with the existing libc-headers, but as soon as you start
working in that directory structure .. you will eventually clobber an
existing file.

There have been quite a few discussions on this topic over time on
the oe- core and yocto lists. Look at the comment in the
linux-libc-headers.inc file, and you'll see a note from Richard
explaining why this shouldn't be done (searches on the mailing list
archives will also find more hits).

When you install into the sysroot, the header file should also be in
a FILES_<package> as part of your recipe .. and that is why you are
seeing the warning. packaging it would remove the warning, but you'll
still have the problem I mention above.

The right way is for your application to look at the
STAGING_KERNEL_DIR, which will have a copy of that same header file.

Alternatively, you can stage your header file at a different sysroot
location than include/linux/* and have your application look there.

I have an open enhancement that I'm doing for yocto 1.7 which
automates the alternate header file structure, but doing it
explicitly in your recipes will work for now.
Hi Bruce,

Thanks for your response. But I'm afraid I'm not entirely following
you. I am quite new to Yocto/OE, so I may be missing something
fundamental/obvious.

Leaving aside the patch and .bbappend for the moment, presumably it is
normal for the kernel in the BSP layer to export headers for
userland's consumption. How is that specified? Where is the
FILES_<package> that lists those headers?
Actually, in the yocto world, it isn't. At least not in the sense that you are
looking for.

The kernel's source tree is staged for consumption by other packages in the
sysroot, accessible via the variable STAGING_KERNEL_DIR. That's the first
choice for an application to look for kernel header files.

The sysroots /usr/include/linux/* is strictly for the linux-libc-headers
package, and nothing else should be installing into that structure.

If you do need to export something to the sysroot, that isn't already in the
libc-headers, and you can't use the STAGING_KERNEL_DIR, then you should
be installing it to another directory structure like:
/usr-alt/include/linux/*
and have your applications look there. You'd export and install them
similarly to what you are doing, and you'd need to package them similarly.

i.e. in the recipe:

PACKAGES += " kernel-extra-headers"
FILES_kernel-extra-headers = "/usr-alt/linux/*'

And you'd get the header in the sysroot, and avoid the QA warning about it
not being packaged.
I probably should've mentioned earlier that this header contains some ioctl
definitions that I need to import into some userland code.

If I include the header from STAGING_KERNEL_DIR, isn't that the "raw"
header, unprepared for inclusion from userland? (Of course, that was also
a problem with my original way of doing it, which I omitted from my OP).

What is special about the headers added to sysroot by linux-libc-headers?
If this driver were part of upstream instead of added by me, wouldn't its
header file be included in the sysroot by linux-libc-headers?

I understand that glibc was built against the headers from linux-libc-headers,
but that shouldn't matter since no one else but me knows about this new
header.

Is there a legitimate way for me to add to linux-libc-headers?

Apologies if I've gotten myself confused.

MV


Re: Rgardring GSTreamer1.0 integration on Yocto Dora

Chris Tapp
 

On 24 Apr 2014, at 09:45, Iorga, Cristian <cristian.iorga@intel.com> wrote:

Hello Dipesh,
YP dora is already released, as such, won't receive any new features or package upgrades.
And if you need GStreamer upgrade that badly, well, why don't do it yourself??
What kind of documentation you need?

There are companies that can help you in this kind of endeavor, offering commercial Yocto Project support, I assume that's a solution also, right?
There's also https://github.com/dv1/meta-gstreamer1.0. I've used this with danny without any problems.

Regards,
Cristian Iorga
YP
Intel Corporation

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Dipesh Karmakar
Sent: Wednesday, April 23, 2014 11:06 AM
To: yocto@yoctoproject.org
Cc: Carlos Rafael Giani
Subject: Re: [yocto] Rgardring GSTreamer1.0 integration on Yocto Dora

Hi All,

Can we integrate GST-1.2.3 to Dora? Is there any document available? We need it badly.

Thanks,
Dipesh

-----Original Message-----
From: Dipesh Karmakar
Sent: Tuesday, April 22, 2014 12:41 PM
To: 'Carlos Rafael Giani'
Cc: yocto@yoctoproject.org; Meenakumari Shedole
Subject: [yocto] Rgardring GSTreamer1.0 integration on Yocto Dora

Hi Carlos,

Do you have any plan to integrate Gstreamer-1.2.3 to Dora? I believe current Dora10.0.1 has GST-1.0.9.

Thanks,
Dipesh

-----Original Message-----
From: Carlos Rafael Giani [mailto:dv@pseudoterminal.org]
Sent: Sunday, February 02, 2014 9:14 PM
To: Khaja Hussain Shaik
Cc: Nicolas Dechesne; yocto@yoctoproject.org; Dipesh Karmakar; Paul Eggleton; Kishore Divvela -ERS, HCL Tech
Subject: Re: [yocto] Rgardring GSTreamer1.0 integration on Yocto dylan

On 2014-01-28 13:49, Khaja Hussain Shaik wrote:
Hi Carlos,

Did you get a chance to look into the porting of gst1.0 to Dylan?

Regards
Khaja
I have now upgraded the recipes in meta-gstreamer1.0 to version 1.2.2.
It is a backport from the current OE-core recipes. Furthermore, I added the Orc OE-core recipes to this layer. This way, gstreamer is built with Orc support by default, even for danny and dylan.

cheers,
Carlos


::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.

----------------------------------------------------------------------------------------------------------------------------------------------------
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Chris Tapp

opensource@keylevel.com
www.keylevel.com


Re: [meta-selinux][PATCH 0/4] add targeted/minimum policy and some updates

Joe MacDonald
 

Hey guys,

Sorry about the delayed response on these, I merged them today with a
minor update to the targeted description based on the explanation below.

Thanks,
-J.

[Re: [yocto] [meta-selinux][PATCH 0/4] add targeted/minimum policy and some updates] On 14.04.04 (Fri 15:57) Pascal Ouyang wrote:

于 14-4-4 下午2:57, Pascal Ouyang 写道:
于 14-4-4 上午3:20, Joe MacDonald 写道:
Hey Wenzong,

I merged two of these four.

[[yocto] [meta-selinux][PATCH 0/4] add targeted/minimum policy and
some updates] On 14.03.24 (Mon 21:07) wenzong.fan@windriver.com wrote:

From: Wenzong Fan <wenzong.fan@windriver.com>

Changes:
* backport tmpfs_t patch from upstream;
* add rules for /var/log symlink on poky;
These both went in. These:

* add targeted policy type
* add minimum targeted policy
I'm less clear on. They both look like significant changes to
refpolicy-* behaviour, which is fine, but in that case I think it'd be
better to give them a different name. Or one that differentiates them
significantly. For example the "minimum" policy has users unconfined
and applications confined? Or neither? I'm not sure what the value is
of these.

If they really are just specialized versions of the standard reference
policy, they should at least be ported to use the refpolicy_common
infrastructure Phil set up a while back.
Hi Joe&Wenzong,

According to the origin design, both policy types are targeted policies.

For targeted policies,
* Users will login into shells on unconfined domain.
* For applications with no policy module or with policy module disabled,
they will also run on unconfined domain.
* For applications "targeted", they would have policy module enabled,
with rules to do domtrans from unconfined/init* domain to their own domain.

The result will be:
- standard/mls :
un-ruled applications(usually bin_t) will run on unconfined domain,
so operations will *not* be blocked.
s#standard/mls#targeted/minimum#

- targeted/minimum
un-ruled applications will run on user's current domain, such as
user_t,sysadm_t, so most privileged operations will be blocked.
s#targeted/minimum#standard/mls#

:-;

- Pascal


Difference between refpolicy-minium&refpolicy-targeted
* refpolicy-minium = targeted policy with only core policies
It should just be used for admins to defined their own policy.
For example, a httpd server could just use refpolicy-minium + httpd
module. Actually, I have thought to use refpolicy-targeted-minium as its
name, but not in the end.
* refpolicy-targeted = targeted policy with all 300+ modules

Thanks. :)

- Pascal


Thanks,
-J.


The following changes since commit
a6079a43719e79e12a57e609923a0cccdba06916:

refpolicy: fix real path for su.shadow (2014-02-13 10:52:07 -0500)

are available in the git repository at:

git://git.pokylinux.org/poky-contrib wenzong/ref-minimum

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


Wenzong Fan (4):
refpolicy: associate tmpfs_t (shm) to device_t (devtmpfs) file
systems
refpolicy: add rules for /var/log symlink on poky
refpolicy: add targeted policy type
refpolicy: add minimum targeted policy

...associate-tmpfs_t-shm-to-device_t-devtmpf.patch | 30 +++
...ky-policy-add-rules-for-syslogd_t-symlink.patch | 30 +++
...rules-for-var-log-symlink-audisp_remote_t.patch | 29 +++
.../refpolicy/refpolicy-minimum_2.20130424.bb | 46 +++++
...olicy-fix-optional-issue-on-sysadm-module.patch | 60 ++++++
.../refpolicy-unconfined_u-default-user.patch | 198
++++++++++++++++++++
.../refpolicy/refpolicy-targeted_2.20130424.bb | 18 ++
.../refpolicy/refpolicy_2.20130424.inc | 3 +
8 files changed, 414 insertions(+)
create mode 100644
recipes-security/refpolicy/refpolicy-2.20130424/filesystem-associate-tmpfs_t-shm-to-device_t-devtmpf.patch

create mode 100644
recipes-security/refpolicy/refpolicy-2.20130424/poky-policy-add-rules-for-syslogd_t-symlink.patch

create mode 100644
recipes-security/refpolicy/refpolicy-2.20130424/poky-policy-add-rules-for-var-log-symlink-audisp_remote_t.patch

create mode 100644
recipes-security/refpolicy/refpolicy-minimum_2.20130424.bb
create mode 100644
recipes-security/refpolicy/refpolicy-targeted/refpolicy-fix-optional-issue-on-sysadm-module.patch

create mode 100644
recipes-security/refpolicy/refpolicy-targeted/refpolicy-unconfined_u-default-user.patch

create mode 100644
recipes-security/refpolicy/refpolicy-targeted_2.20130424.bb
--
-Joe MacDonald.
:wq


Re: eglibc-2.18 is not compiling

Kai Ulrich <kaiu@...>
 

Hi,

good news  tried it with
- GNU Awk 4.1.1, API: 1.1
- GNU Make 4.0

it worked fine.
Thanx


2014-04-23 10:33 GMT+02:00 Kai Ulrich <kaiu@...>:

I am using GNU Awk 4.0.2



2014-04-22 22:01 GMT+02:00 Khem Raj <raj.khem@...>:


On Apr 22, 2014 12:47 PM, "Kai Ulrich" <kaiu@...> wrote:
>
> thanx for your interest
> yes, it seams all right
> gcc-Version 4.7.3 (Gentoo 4.7.3-r1 p1.4, pie-0.5.5)
> make-Version GNU Make 3.82 Built for x86_64-pc-linux-gnu
>
>
>
> 2014-04-22 18:10 GMT+02:00 Khem Raj <raj.khem@...>:
>
>> On Tue, Apr 22, 2014 at 7:08 AM, Kai Ulrich <kaiu@...> wrote:
>> > tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/eglibc/2.18-r0/build-arm-poky-linux-gnueabi/shlib.lds:150:
>> > syntax error
>> > collect2: error: ld returned 1 exit status
>> > make[2]: ***
>> > [/home/kulrich/Development/yocto_dora/poky/build_beagle_xm_ml/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/eglibc/2.18-r0/build-arm-poky-linux-gnueabi/libc.so]
>> > Error 1
>> > make[2]: Leaving directory
>> > `/home/kulrich/Development/yocto_dora/poky/build_beagle_xm_ml/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/eglibc/2.18-r0/eglibc-2.18/libc/elf'
>> > make[1]: *** [elf/subdir_lib] Error 2
>> > make[1]: Leaving directory
>> > `/home/kulrich/Development/yocto_dora/poky/build_beagle_xm_ml/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/eglibc/2.18-r0/eglibc-2.18/libc'
>> > make: *** [all] Error 2
>>
>>
>> whats the make version on your build host which is being used here. I
>> hope its 3.82 or newer.
>
>

and you are using gawk and not mawk or something else




Re: Exporting kernel header from patch

Bruce Ashfield <bruce.ashfield@...>
 

On 14-04-24 01:52 PM, Vuille, Martin (Martin) wrote:
From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
Sent: April 24, 2014 1:32 PM

On 14-04-24 11:57 AM, Vuille, Martin (Martin) wrote:
I have a custom layer to add patches to my vendor's BSP layer

(based on Linux 3.4, if it matters) and a .bbappend to list the

patches.

One of the patches adds a header, and this header needs to

be exported to the sysroot.

I added the following to my .bbappend, based on a discussion

I found:

do_install_append() {

install -d ${D}${includedir}/linux

install -m 644 ${S}/include/linux/uc1698u.h
${D}${includedir}/linux/uc1698u.h

}

It "works" (i.e., the header is installed in the sysroot) but there
must

be more to it than that because I also get a warning about the header

being "installed but not shipped in any package".

What's the correct way to do this?
Not answering the question directly, but I can say that kernel's shouldn't be
exporting their header files over the sysroot's
include/linux/* directory structure, since that is where linux-libc-headers
installs and manages the userspace safe headers for the c-library.

Sure you are probably installing a new file, and one that doesn't conflict
with the existing libc-headers, but as soon as you start working in that
directory structure .. you will eventually clobber an existing file.

There have been quite a few discussions on this topic over time on the oe-
core and yocto lists. Look at the comment in the linux-libc-headers.inc file,
and you'll see a note from Richard explaining why this shouldn't be done
(searches on the mailing list archives will also find more hits).

When you install into the sysroot, the header file should also be in a
FILES_<package> as part of your recipe .. and that is why you are seeing the
warning. packaging it would remove the warning, but you'll still have the
problem I mention above.

The right way is for your application to look at the STAGING_KERNEL_DIR,
which will have a copy of that same header file.

Alternatively, you can stage your header file at a different sysroot location
than include/linux/* and have your application look there.

I have an open enhancement that I'm doing for yocto 1.7 which automates
the alternate header file structure, but doing it explicitly in your recipes will
work for now.
Hi Bruce,

Thanks for your response. But I'm afraid I'm not entirely following you. I am
quite new to Yocto/OE, so I may be missing something fundamental/obvious.

Leaving aside the patch and .bbappend for the moment, presumably it is
normal for the kernel in the BSP layer to export headers for userland's
consumption. How is that specified? Where is the FILES_<package> that
lists those headers?
Actually, in the yocto world, it isn't. At least not in the sense that
you are looking for.

The kernel's source tree is staged for consumption by other packages
in the sysroot, accessible via the variable STAGING_KERNEL_DIR. That's
the first choice for an application to look for kernel header files.

The sysroots /usr/include/linux/* is strictly for the linux-libc-headers
package, and nothing else should be installing into that structure.

If you do need to export something to the sysroot, that isn't already
in the libc-headers, and you can't use the STAGING_KERNEL_DIR, then you
should be installing it to another directory structure like: /usr-alt/include/linux/*
and have your applications look there. You'd export and install them similarly
to what you are doing, and you'd need to package them similarly.

i.e. in the recipe:

PACKAGES += " kernel-extra-headers"
FILES_kernel-extra-headers = "/usr-alt/linux/*'

And you'd get the header in the sysroot, and avoid the QA warning about
it not being packaged.

Bruce




MV


Re: Exporting kernel header from patch

Vuille, Martin (Martin) <vmartin@...>
 

From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
Sent: April 24, 2014 1:32 PM

On 14-04-24 11:57 AM, Vuille, Martin (Martin) wrote:
I have a custom layer to add patches to my vendor's BSP layer

(based on Linux 3.4, if it matters) and a .bbappend to list the

patches.

One of the patches adds a header, and this header needs to

be exported to the sysroot.

I added the following to my .bbappend, based on a discussion

I found:

do_install_append() {

install -d ${D}${includedir}/linux

install -m 644 ${S}/include/linux/uc1698u.h
${D}${includedir}/linux/uc1698u.h

}

It "works" (i.e., the header is installed in the sysroot) but there
must

be more to it than that because I also get a warning about the header

being "installed but not shipped in any package".

What's the correct way to do this?
Not answering the question directly, but I can say that kernel's shouldn't be
exporting their header files over the sysroot's
include/linux/* directory structure, since that is where linux-libc-headers
installs and manages the userspace safe headers for the c-library.

Sure you are probably installing a new file, and one that doesn't conflict
with the existing libc-headers, but as soon as you start working in that
directory structure .. you will eventually clobber an existing file.

There have been quite a few discussions on this topic over time on the oe-
core and yocto lists. Look at the comment in the linux-libc-headers.inc file,
and you'll see a note from Richard explaining why this shouldn't be done
(searches on the mailing list archives will also find more hits).

When you install into the sysroot, the header file should also be in a
FILES_<package> as part of your recipe .. and that is why you are seeing the
warning. packaging it would remove the warning, but you'll still have the
problem I mention above.

The right way is for your application to look at the STAGING_KERNEL_DIR,
which will have a copy of that same header file.

Alternatively, you can stage your header file at a different sysroot location
than include/linux/* and have your application look there.

I have an open enhancement that I'm doing for yocto 1.7 which automates
the alternate header file structure, but doing it explicitly in your recipes will
work for now.
Hi Bruce,

Thanks for your response. But I'm afraid I'm not entirely following you. I am
quite new to Yocto/OE, so I may be missing something fundamental/obvious.

Leaving aside the patch and .bbappend for the moment, presumably it is
normal for the kernel in the BSP layer to export headers for userland's
consumption. How is that specified? Where is the FILES_<package> that
lists those headers?

MV


Re: Exporting kernel header from patch

Bruce Ashfield <bruce.ashfield@...>
 

On 14-04-24 11:57 AM, Vuille, Martin (Martin) wrote:
I have a custom layer to add patches to my vendor’s BSP layer

(based on Linux 3.4, if it matters) and a .bbappend to list the

patches.

One of the patches adds a header, and this header needs to

be exported to the sysroot.

I added the following to my .bbappend, based on a discussion

I found:

do_install_append() {

install -d ${D}${includedir}/linux

install -m 644 ${S}/include/linux/uc1698u.h
${D}${includedir}/linux/uc1698u.h

}

It “works” (i.e., the header is installed in the sysroot) but there must

be more to it than that because I also get a warning about the header

being “installed but not shipped in any package”.

What’s the correct way to do this?
Not answering the question directly, but I can say that kernel's
shouldn't be exporting their header files over the sysroot's
include/linux/* directory structure, since that is where linux-libc-headers
installs and manages the userspace safe headers for the c-library.

Sure you are probably installing a new file, and one that doesn't
conflict with the existing libc-headers, but as soon as you start
working in that directory structure .. you will eventually clobber
an existing file.

There have been quite a few discussions on this topic over time on the
oe-core and yocto lists. Look at the comment in the linux-libc-headers.inc
file, and you'll see a note from Richard explaining why this shouldn't
be done (searches on the mailing list archives will also find more
hits).

When you install into the sysroot, the header file should also be
in a FILES_<package> as part of your recipe .. and that is why you
are seeing the warning. packaging it would remove the warning, but
you'll still have the problem I mention above.

The right way is for your application to look at the STAGING_KERNEL_DIR,
which will have a copy of that same header file.

Alternatively, you can stage your header file at a different sysroot
location than include/linux/* and have your application look there.

I have an open enhancement that I'm doing for yocto 1.7 which automates
the alternate header file structure, but doing it explicitly in your
recipes will work for now.

Cheers,

Bruce



MV



Exporting kernel header from patch

Vuille, Martin (Martin) <vmartin@...>
 

I have a custom layer to add patches to my vendor’s BSP layer

(based on Linux 3.4, if it matters) and a .bbappend to list the

patches.

 

One of the patches adds a header, and this header needs to

be exported to the sysroot.

 

I added the following to my .bbappend, based on a discussion

I found:

 

do_install_append() {

    install -d ${D}${includedir}/linux

    install -m 644 ${S}/include/linux/uc1698u.h ${D}${includedir}/linux/uc1698u.h

}

 

It “works” (i.e., the header is installed in the sysroot) but there must

be more to it than that because I also get a warning about the header

being “installed but not shipped in any package”.

 

What’s the correct way to do this?

 

MV


patching issue

Rohit2 Jindal <rohit2.jindal@...>
 

Hi,

I have scenario like the following:

SRC_URI = "\
http://ftp.gnu.org/gnu/glibc/glibc-ports-2.13.tar.gz;name=ports \
http://ftp.gnu.org/gnu/glibc/glibc-2.13.tar.gz;name=glibc \
file://glibc.patch \
file://newlib.patch
"
SRC_URI[ports.md5sum] = "094e3c9b57da605917a780ab24575187"
SRC_URI[ports.sha256sum] = "41cbdc05bd7b233464d649b59b34405e5bf3998522640b9f98f2c4eb91e87322"
SRC_URI[glibc.md5sum] = "fafabe01cb9748acb0a11a6879ebaa7e"
SRC_URI[glibc.sha256sum] = "bd90d6119bcc2898befd6e1bbb2cb1ed3bb1c2997d5eaa6fdbca4ee16191a906"

LIC_FILES_CHKSUM = "file://LICENSES;md5=98a1128c4b58120182cbea3b1752d8b9"

#newlib source fetching
SRC_URI[newlib.md5sum] = "e5488f545c46287d360e68a801d470e8"
SRC_URI[newlib.sha256sum] = "c644b2847244278c57bec2ddda69d8fab5a7c767f3b9af69aa7aa3da823ff692"

SRC_URI_newlib = "\
http://sourceforge.net/projects/devkitpro/files/sources/newlib/newlib-1.20.0.tar.gz;name=newlib"

I have two patches and two different source as shown with fetching controlled using SRC_URI_newlib and SRC_URI and I want to apply patches conditionally on SRC_URI and SRC_URI_newlib . But fails to do so.
Can u help how to apply newlib.patch in SRC_URI_newlib and glibc.patch in SRC_URI.

If I keep newlib.patch in SRC_URI_newlib it is not considered and ignored.

Please help me out

Thanks in advance!!


Regards,
Rohit Jindal

"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."


[meta-ivi][PATCH] weston: Add weston.ini config file

Sujith H <sujith.h@...>
 

Adding weston.ini to /etc/xdg. With this change
user can login and launch weston with ivi-shell.

Signed-off-by: Sujith H <Sujith_Haridasan@mentor.com>
---
recipes-graphics/wayland/weston_1.4.0.bbappend | 15 +++++++++++++++
1 file changed, 15 insertions(+)

diff --git a/recipes-graphics/wayland/weston_1.4.0.bbappend b/recipes-graphics/wayland/weston_1.4.0.bbappend
index 7a8ba6f..1bcb327 100644
--- a/recipes-graphics/wayland/weston_1.4.0.bbappend
+++ b/recipes-graphics/wayland/weston_1.4.0.bbappend
@@ -12,3 +12,18 @@ PR = "r1"

FILES_${PN} += "${libdir}/weston/*"
FILES_${PN}-dbg += "${libdir}/weston/.debug/*"
+
+do_install_append() {
+ WESTON_INI_CONFIG=${sysconfdir}/xdg/weston
+ install -d ${D}${WESTON_INI_CONFIG}
+ install -m 0644 ${S}/ivi-shell/weston.ini.in ${D}${WESTON_INI_CONFIG}/weston.ini
+ sed -i -e 's/hmi-controller.so/hmi-controller.so,ivi-controller.so/' \
+ -e 's|\@libexecdir\@|${libexecdir}|' \
+ -e 's|\@abs_top_builddir\@\/data|${datadir}\/weston|' \
+ -e 's|\@abs_top_builddir\@\/clients|${bindir}|' ${D}${WESTON_INI_CONFIG}/weston.ini
+
+}
+
+PACKAGES += "${PN}-ini"
+
+FILES_${PN}-ini = "${sysconfdir}/xdg"
--
1.8.4


How to run c++ programs?

Edward Vidal <vidal.develone@...>
 

Hello,
In the poky/documentation folder I execute the following:
#!/bin/bash
make DOC=adt-manual 
make DOC=kernel-dev    
make DOC=mega-manual
make DOC=bsp-guide  
make DOC=kernel-manual 
make DOC=ref-manual 
make DOC=yocto-project-qs
make DOC=dev-manual 
make DOC=profile-manual 
find . -name *.pdf
This generates my documentation for yocto .
What you need is the adt-manual. see Chapter 4. Using the Command
Line.
You also need to build SDK with bitbake.  Then a script in images/sdk  which you installs in /opt/poky/1.xxxx
Hope this helps.  I also am using a zedboard.  I recently got sound, 2 C920 cameras, openCV, gnuplot, gsl, vlc, and gnuradio working with meta-topic instead of meta-xilinx thanks to Mike Looijmans on the meta-xilinx mailing list.