[yocto] [meta-selinux][PATCH 1/3] V2 refpolicy:20140311 update for systemd
From: Shrikant Bobade Systemd init type and related allow rules updated for refpolicy. Signed-off-by: Shrikant Bobade --- .../refpolicy-update-for_systemd.patch | 46 .../refpolicy/refpolicy_2.20140311.inc |1 + 2 files changed, 47 insertions(+) create mode 100644 recipes-security/refpolicy/refpolicy-2.20140311/refpolicy-update-for_systemd.patch diff --git a/recipes-security/refpolicy/refpolicy-2.20140311/refpolicy-update-for_systemd.patch b/recipes-security/refpolicy/refpolicy-2.20140311/refpolicy-update-for_systemd.patch new file mode 100644 index 000..80b420c --- /dev/null +++ b/recipes-security/refpolicy/refpolicy-2.20140311/refpolicy-update-for_systemd.patch @@ -0,0 +1,46 @@ +refpolicy: update for systemd + +It provides the systemd support for refpolicy +and related allow rules. +The restorecon provides systemd init labeled +as init_exec_t. + +Upstream-Status: Pending + + +Signed-off-by: Shrikant Bobade + +--- a/policy/modules/contrib/shutdown.fc b/policy/modules/contrib/shutdown.fc +@@ -5,6 +5,9 @@ + /sbin/shutdown-- gen_context(system_u:object_r:shutdown_exec_t,s0) + /sbin/shutdown\.sysvinit -- gen_context(system_u:object_r:shutdown_exec_t,s0) + ++# systemd support ++/bin/systemctl-- gen_context(system_u:object_r:shutdown_exec_t,s0) ++ + /usr/lib/upstart/shutdown -- gen_context(system_u:object_r:shutdown_exec_t,s0) + + /usr/sbin/shutdown-- gen_context(system_u:object_r:shutdown_exec_t,s0) +--- a/policy/modules/system/init.fc b/policy/modules/system/init.fc +@@ -31,6 +31,8 @@ + # + /sbin/init(ng)? -- gen_context(system_u:object_r:init_exec_t,s0) + /sbin/init\.sysvinit -- gen_context(system_u:object_r:init_exec_t,s0) ++# systemd support ++/lib/systemd/systemd -- gen_context(system_u:object_r:init_exec_t,s0) + # because nowadays, /sbin/init is often a symlink to /sbin/upstart + /sbin/upstart -- gen_context(system_u:object_r:init_exec_t,s0) + +--- a/policy/modules/system/init.te b/policy/modules/system/init.te +@@ -913,3 +913,8 @@ + optional_policy(` + zebra_read_config(initrc_t) + ') ++ ++# systemd related allow rules ++allow kernel_t init_t:process dyntransition; ++allow devpts_t device_t:filesystem associate; ++allow init_t self:capability2 block_suspend; diff --git a/recipes-security/refpolicy/refpolicy_2.20140311.inc b/recipes-security/refpolicy/refpolicy_2.20140311.inc index 8894583..557b4ab 100644 --- a/recipes-security/refpolicy/refpolicy_2.20140311.inc +++ b/recipes-security/refpolicy/refpolicy_2.20140311.inc @@ -29,6 +29,7 @@ SRC_URI += "file://poky-fc-subs_dist.patch \ file://poky-fc-rpm.patch \ file://poky-fc-ftpwho-dir.patch \ file://poky-fc-fix-real-path_su.patch \ +file://refpolicy-update-for_systemd.patch \ " # Specific policy for Poky -- 1.7.9.5 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-selinux][PATCH 2/3] selinux-init: update for systemd
From: Shrikant Bobade
selinux-init.sh updated to reboot system
normally to fix the labelling during systemd
execution. Due to force reboot labelling won't
be proper and system continuously reboot to
label it like first time boot.
Signed-off-by: Shrikant Bobade
---
.../selinux/selinux-config/selinux-init.sh |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/recipes-security/selinux/selinux-config/selinux-init.sh
b/recipes-security/selinux/selinux-config/selinux-init.sh
index 9aaf454..f9f0914 100644
--- a/recipes-security/selinux/selinux-config/selinux-init.sh
+++ b/recipes-security/selinux/selinux-config/selinux-init.sh
@@ -48,7 +48,7 @@ if [ -f /.autorelabel ]; then
${FIXFILES} -F -f relabel
/bin/rm -f /.autorelabel
echo " * Relabel done, rebooting the system."
- /sbin/reboot -f
+ /sbin/reboot
fi
# If first booting, the security context type of init would be
@@ -62,7 +62,7 @@ if [ "`${SECON} -t --pid 1`" = "kernel_t" ]; then
${RESTORECON} -RF /
${RESTORECON} -F /
echo " * Relabel done, rebooting the system."
- /sbin/reboot -f
+ /sbin/reboot
fi
# Now, we should relabel /dev for most services.
--
1.7.9.5
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-selinux][PATCH 3/3] pkggrp-core-selinux: coreutils addition
From: Shrikant Bobade
To add coreutils to packagegroup-core-selinux
inorder to get chcon avaibility.
Signed-off-by: Shrikant Bobade
---
.../packagegroups/packagegroup-core-selinux.bb |1 +
1 file changed, 1 insertion(+)
diff --git a/recipes-security/packagegroups/packagegroup-core-selinux.bb
b/recipes-security/packagegroups/packagegroup-core-selinux.bb
index 1852aba..40b35d1 100644
--- a/recipes-security/packagegroups/packagegroup-core-selinux.bb
+++ b/recipes-security/packagegroups/packagegroup-core-selinux.bb
@@ -25,4 +25,5 @@ RDEPENDS_${PN} = " \
selinux-config \
refpolicy-standard \
refpolicy-mls \
+ coreutils \
"
--
1.7.9.5
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Busybox sh link
On 11/19/2014 07:00 AM, ChenQi wrote: On 11/19/2014 12:34 AM, Stefan Eichenberger wrote: On 11/18/2014 04:07 AM, ChenQi wrote: On 11/17/2014 10:07 PM, Stefan Eichenberger wrote: Hello all I have a question regarding busybox and sh. If I want to install bash together with busybox ash, yocto does not consider the ALTERNATIVE_PRIORITY in each case (e.g. if bash is installed before busybox). The problem is that do_install of busybox creates a link to busybox.nosuid. Is there a reason for that? Shouldn't update-alternatives create that link for us? There is already a patch available that targets this problem (467b19efbaa9c0cb04d2665e8cd9a0919849a5ed ) but it only works if ash is completely disabled in the busybox config. So the main question is, wouldn't it be possible to remove this lines completely? Regards, Stefan I can confirm that this is indeed a problem. And we need to fix this. I think the reason for this line is mainly to make 'busybox' provide '/bin/sh' so that do_rootfs would succeed. Regards, Chen Qi Probably I miss something but I don't understand why do_rootfs fails if the link is not provided? Isn't the link created anyhow during package installation in the postinstall script with update-alternatives if necessary? For testing I removed the link creation temporary from the recipe and built the core-image-minimal for qemux86, it was creating the link correctly in this case. Regards, Stefan Hi Stefan, I did some testing, and could not reproduce the problem. I then realized that as the sh link is managed by ALTERNATIVES mechanism, it will always point to bash instead of busybox. I tested it by the following steps: 1. build core-image-minimal with bash installed 2. reinstall bash 3. reinstall busybox So I think the current code is right. I'm not sure if I missed something. If so, could you please provide more information? Best Regards, Chen Qi Hi Chen, You are right, sorry! I think I figured out what I've missed. On an image I have disabled busybox ash completely, therefore I didn't saw the update-alternative running for sh. Because it was an older version of yocto without the above patch, I've got an invalid image. I then tough the same problem would appear if I enable busybox ash again, but in this case update-alternative would run, so the problem wouldn't appear. Sorry for the false alarm! Regards, Stefan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to build the uclibc toolchain by Yocto
Hi all, The eglibc is used for meta-toolchain build in Yocto, may I know how to build the uclibc meta-toolchain in Yocto? Best Regards, Zhenhua -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to build the uclibc toolchain by Yocto
Hi Zhenhua, On Wednesday 19 November 2014 09:43:59 zhenhua@freescale.com wrote: > The eglibc is used for meta-toolchain build in Yocto, may I know how to > build the uclibc meta-toolchain in Yocto? It should be as easy as setting TCLIBC = "uclibc" in your custom distro config. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] autobuilder: How to set PREMIRRORS?
All,
I'm getting close to implementing this feature, but I'm having some issues
getting auto.conf formatted correctly. See below.
> -Original Message-
> From: Bryan Evenson
> Sent: Monday, November 17, 2014 9:08 AM
> To: Bryan Evenson; yocto@yoctoproject.org; elizabeth.flana...@intel.com
> Subject: RE: autobuilder: How to set PREMIRRORS?
>
> All,
>
> After looking through the autobuilder code, I don't see anywhere in which
> PREMIRRORS can be set and used. I see in CreateAutoConf.py that
> PREMIRRORS is always set to "". I don't think it'd be that difficult to add
> PREMIRRORS as a CreateAutoConf parameter for the buildsets. I can work
> on the change and submit the patch. But before I start I have a few
> questions:
>
> 1. I plan on implementing the PREMIRRORS parameter as an array, similar to
> 'layerdirs' for CreateBBLayersConf. For example:
>
> {'CreateAutoConf' : {'PREMIRRORS' : ['git://.*/.*
> http://our/local/mirror/path/mirror/sources/ ',
> 'ftp://.*/.* http://our/local/mirror/path /mirror/sources/ ',
> 'http://.*/.* http://our/local/mirror/path/mirror/sources/ ',
> 'https://.*/.* http://our/local/mirror/path/mirror/sources/ ']}
>
> would add the following to auto.conf:
>
> PREMIRRORS = 'git://.*/.* http://our/local/mirror/path/mirror/sources/ \
> ftp://.*/.* http://our/local/mirror/path /mirror/sources/ \
> http://.*/.* http://our/local/mirror/path/mirror/sources/ \
> https://.*/.* http://our/local/mirror/path/mirror/sources/ '
>
> Does this sound reasonable, or would a different parameter format be
> preferred?
I am trying to add a single PREMIRROR using the syntax I specified above. At
this time it is getting inserted in auto.conf. However, the system is going
into an infinite loop building the PREMIRROR path. The added content to
auto.conf at this time looks like:
PREMIRRORS = " \
http://.*.* http://server.repo.local/mirror/sources/ \n \
"
And from looking at log.do_fetch for the package that attempts to use the
PREMIRROR, the log is filled with
"server.repo.localserver.repo.localserver.repo.local" repeating. Any tips on
how PREMIRRORS should be built?
Here's what I have so far in CreateAutoConf.py:
self.PREMIRRORS=""
fout = fout + 'PREMIRRORS = " \ \n'
if list(self.PREMIRRORS):
for premirror in self.PREMIRRORS:
fout = fout + premirror + ' n \ \n'
fout = fout + '" \n'
Any tips on how to change things so PREMIRRORS is correctly parsed?
Thanks,
Bryan
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Layer model doomed, unless we all work together
On 11/18/2014 06:03 PM, Martin Jansa wrote: > On Tue, Nov 18, 2014 at 09:57:30PM +, Burton, Ross wrote: >> Looking over the duplicate list, there's some obvious low-hanging fruit. >> Angstrom duplicates recipes that are in meta-multimedia. meta-webos and >> meta-webos-ports seem to be full of duplicates. meta-guacamayo has some > > meta-webos-ports is fork of meta-webos, so duplicates between these 2 > are expected. Paul explained you can use the filter button to adjust the layers scanned for dupes. This should be all layers minus meta-webos-ports: http://layers.openembedded.org/layerindex/branch/master/duplicates/?l=91&l=123&l=30&l=147&l=168&l=148&l=31&l=65&l=66&l=32&l=124&l=164&l=67&l=149&l=77&l=101&l=118&l=33&l=3&l=34&l=142&l=169&l=35&l=137&l=171&l=139&l=108&l=162&l=81&l=82&l=95&l=125&l=145&l=146&l=114&l=4&l=36&l=68&l=140&l=83&l=132&l=5&l=154&l=120&l=84&l=6&l=93&l=112&l=7&l=37&l=167&l=38&l=8&l=98&l=39&l=165&l=40&l=105&l=69&l=9&l=10&l=110&l=107&l=11&l=12&l=13&l=14&l=41&l=15&l=99&l=151&l=170&l=85&l=42&l=43&l=113&l=159&l=16&l=78&l=92&l=103&l=157&l=97&l=119&l=70&l=152&l=153&l=71&l=126&l=115&l=136&l=44&l=45&l=163&l=17&l=102&l=150&l=46&l=18&l=19&l=79&l=2&l=138&l=174&l=20&l=21&l=128&l=129&l=130&l=131&l=47&l=104&l=48&l=135&l=22&l=173&l=121&l=23&l=160&l=49&l=106&l=24&l=50&l=117&l=143&l=87&l=51&l=52&l=25&l=133&l=116&l=53&l=72&l=122&l=73&l=54&l=55&l=172&l=88&l=109&l=56&l=57&l=100&l=26&l=155&l=90&l=58&l=144&l=59&l=60&l=74&l=61&l=75&l=158&l=134&l=62&l=111&l=27&l=76&l=28&l=141&l=1&l=64 Although that url might fail, you get the idea how to use the tool better :) Philip > > Also meta-webos master branch is compatible only with 1.4 dylan release, > so some of the duplicated recipes are actually backports from newer OE. > signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] sharing directories between users on same machine
Hello, we try to share the sstate-cache and download directory between multiple users on the same machine. It seems that this don't work as yocto want to overwrite some files in those directories, but does not have the rights (since another user created them). Is this not an use case? - If it should work, can somebody give pointers what might went wrong (some missing configuration or so) - If it can not work, can we do that differently? Thanks Urs -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] lighttpd webDav does not allow files to save
I am running Yocto 1.6.1 with standard atmel build or
atmel-qt5-demo-image
I have added a a lighttpd_1.4.33.bbappend recipe in the directory
~/poky/meta-atmel-lsp/recipes-extended/lighttpd with the following
contents:___FILESEXTRAPATHS_prepend :=
"${THISDIR}/${PN}:"
RDEPENDS_${PN} += " lighttpd-module-webdav"
SRC_URI += " file://lighttpd.conf file://index.htm
file://config.jsn "
do_install_append() { rm -f ${D}/www/pages/index.html install -m 0777
-d ${D}/www/pages/dav install -m 0555 $WORKDIR}/index.htm
${D}/www/pages/ install -m 0777 ${WORKDIR}/config.jsn
${D}/www/pages/}___
In the subdirectory "lighttpd" I have modified the standard
lighttpd.conf file by uncommenting "mod_webdav" and I have added:
$HTTP["url"] =~ "^/dav($|/)" { webdav.activate = "enable"
webdav.is-readonly = "disable"}
I have also added my own index.htm and config.htm file
When I load and run the new image, my modified index.html pages gets
served up ok. Also, I can map the /www/pages/dav/ to a Windows dirive
and view an open the files it contains.However, the system does not
allow me to store anything.
1. If I use the Windows Mapped drive to store a text file into the
dav directory, it gives me an error.2. If I use my index.html page to
update the config.jsn file via a 'PUT', it does not save the new file.
Here is some extra informationroot@sama5d3xek:/www/pages# ls
-l-rwxrwxrwx 1 root root 83 Nov 19 08:51 config.jsndrwxrwxrwx 2
root root 160 Nov 19 10:02 dav-r-xr-xr-x 1 root root 47641 Nov 19
08:51 index.htm
root@sama5d3xek:/www# ls -ldrwxrwxrwx 8 root root 904 Nov 19 09:55
pages
Can anyone advise why the lighttpd is serving data but wont allow
either the web client or the dav client to save/update files in theri
appropriate folders?
ThanksLachlan
Message sent via Adam Internet WebMail - http://www.adam.com.au/
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [oe] [meta-selinux][PATCH] ustr: Change the SRC_URI to upstream and add a new patch
Thanks for the submission. Just a couple of comments.
[[oe] [meta-selinux][PATCH] ustr: Change the SRC_URI to upstream and add a new
patch] On 14.11.19 (Wed 15:34) Qian Lei wrote:
> Official upstream is still Ok, using it first.
> Add a new patch which is applied in Fedora20
As these are two unrelated issues, I think two patches would've been
appropriate with 1/2 being the one that updates the SRC_URI and 2/2
being the c99 patch.
You should also provide an upstream-status for the C99 patch. As you
say it came from Fedora, odds are it is already submitted upstream, so
'pending' could be appropriate here, but I don't know.
Finally, meta-selinux patches should go to yocto@yoctoproject.org (cc'd
here), not the openembedded-dev@ list.
I'm fine with making the changes I described above or you can send out a
new version of the patch/patches if you like. I won't do anything with
it before tomorrow, either way, to give everyone time to have a look.
-J.
>
> Signed-off-by: Qian Lei
> ---
> recipes-extended/ustr/ustr/ustr-c99-inline.patch | 44
>
> recipes-extended/ustr/ustr_1.0.4.bb | 8 ++---
> 2 files changed, 47 insertions(+), 5 deletions(-)
> create mode 100644 recipes-extended/ustr/ustr/ustr-c99-inline.patch
>
> diff --git a/recipes-extended/ustr/ustr/ustr-c99-inline.patch
> b/recipes-extended/ustr/ustr/ustr-c99-inline.patch
> new file mode 100644
> index 000..5f2d5da
> --- /dev/null
> +++ b/recipes-extended/ustr/ustr/ustr-c99-inline.patch
> @@ -0,0 +1,44 @@
> +From 1b1c36ec67b7976d0bca0b6c7b766540cb541c1e Mon Sep 17 00:00:00 2001
> +From: Qian Lei
> +Date: Wed, 19 Nov 2014 14:48:18 +0800
> +Subject: [PATCH] c99-inline
> +
> +Signed-off-by: Qian Lei
> +---
> + ustr-compiler.h | 12 +---
> + 1 file changed, 9 insertions(+), 3 deletions(-)
> +
> +diff --git a/ustr-compiler.h b/ustr-compiler.h
> +index 642e6e8..63735e0 100644
> +--- a/ustr-compiler.h
> b/ustr-compiler.h
> +@@ -113,17 +113,23 @@
> + #endif
> +
> + #ifndef USTR_CONF_EI_PROTO /* external inline */
> +-# if USTR_CONF_INCLUDE_CODEONLY_HEADERS
> ++# if USTR_CONF_INCLUDE_CODEONLY_HEADERS || ! defined(__GNUC__) || \
> ++ ! USTR_CONF_COMPILE_USE_INLINE
> + # define USTR_CONF_EI_PROTO static USTR__INLINE
> + # else
> + # define USTR_CONF_EI_PROTO extern
> + # endif
> + #endif
> + #ifndef USTR_CONF_II_PROTO /* implementation of inline */
> +-# if USTR_CONF_INCLUDE_CODEONLY_HEADERS
> ++# if USTR_CONF_INCLUDE_CODEONLY_HEADERS || ! defined(__GNUC__) || \
> ++ ! USTR_CONF_COMPILE_USE_INLINE
> + # define USTR_CONF_II_PROTO static USTR__INLINE
> + # else
> +-# define USTR_CONF_II_PROTO extern inline
> ++# if defined(__GNUC_STDC_INLINE__) || defined(__GNUC_GNU_INLINE__)
> ++# define USTR_CONF_II_PROTO extern inline __attribute__ ((__gnu_inline__))
> ++# else
> ++# define USTR_CONF_II_PROTO extern inline
> ++# endif
> + # endif
> + #endif
> +
> +--
> +1.8.3.1
> +
> diff --git a/recipes-extended/ustr/ustr_1.0.4.bb
> b/recipes-extended/ustr/ustr_1.0.4.bb
> index 6651a73..485e80d 100644
> --- a/recipes-extended/ustr/ustr_1.0.4.bb
> +++ b/recipes-extended/ustr/ustr_1.0.4.bb
> @@ -11,13 +11,11 @@ LIC_FILES_CHKSUM =
> "file://LICENSE;md5=c79c6e2ae13418d16d7dc82df960a1e7 \
> file://LICENSE_LGPL;md5=d8045f3b8f929c1cb29a1e3fd737b499 \
> file://LICENSE_MIT;md5=c61e779b782608472bd87593c3c3916f"
>
> -# Official upstream seems to be offline.. replace w/ a Fedora Project mirror.
> -# http://www.and.org/ustr/1.0.4/ustr-1.0.4.tar.bz2
> -
> SRC_URI = "\
> -
> http://pkgs.fedoraproject.org/repo/pkgs/ustr/ustr-1.0.4.tar.bz2/93147d9f0c9765d4cd0f04f7e44bdfce/ustr-1.0.4.tar.bz2
> \
> +http://www.and.org/ustr/${PV}/${PN}-${PV}.tar.bz2 \
> file://ustr-makefile-fix.patch;patch=1 \
> -file://ustr-fix__va_copy-not-defined.patch;patch=2"
> +file://ustr-fix__va_copy-not-defined.patch;patch=2 \
> +file://ustr-c99-inline.patch;patch=3"
> SRC_URI[md5sum] = "93147d9f0c9765d4cd0f04f7e44bdfce"
> SRC_URI[sha256sum] =
> "3daf6eae9f78de1e872c0b2b83cce35515b94d4bb8a074e48f331fd99e1fc2c4"
>
> --
> 1.8.3.1
>
--
-Joe MacDonald.
:wq
signature.asc
Description: Digital signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] New recipe for toolchain fails install, "ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored."
Hi Joseph,
Thanks for the clarification.
As far as I understand, I have restructured my recipe as you directed.
However, when I bitbake -c populate_sdk core-image-full-cmdline, the sdk
installer script still does not contain the LLVM/clang stuff.
I'm hoping that you can see what I have done wrong.
When I look for build artifacts, here's what I find for clang in the work
directory.
[jimr@krusty work]$ find . -name clang -ls |grep bin/clang
99906923 45428 -rwxr-xr-x 1 jimr jimr 46517960 Nov 19 12:00
./spectra_ls-poky-linux/core-image-full-cmdline/1.0-r0/sdk/image/usr/bin/clang
94263147 45428 -rwxr-xr-x 2 jimr jimr 46517960 Nov 19 12:00
./x86_64-nativesdk-pokysdk-linux/nativesdk-llvm/3.5.0-r0/packages-split/nativesdk-llvm/usr/bin/clang
94263147 45428 -rwxr-xr-x 2 jimr jimr 46517960 Nov 19 12:00
./x86_64-nativesdk-pokysdk-linux/nativesdk-llvm/3.5.0-r0/package/usr/bin/clang
88904578 56380 -rwxr-xr-x 1 jimr jimr 57732373 Nov 19 11:51
./x86_64-nativesdk-pokysdk-linux/nativesdk-llvm/3.5.0-r0/llvm-3.5.0/Release+Asserts/bin/clang
89415572 45432 -rwxr-xr-x 1 jimr jimr 46517960 Nov 19 12:00
./x86_64-nativesdk-pokysdk-linux/nativesdk-llvm/3.5.0-r0/image/usr/bin/clang
Finding the clang executable in
/spectra_ls-poky-linux/core-image-full-cmdline/1.0-r0/sdk/image/usr/bin/clang
would seem to suggest that it should be in the SDK, but it is not.
Here are the recipes...
++ meta-spectra-ls-utils/recipes-devtools/llvm/llvm_3.5.0.bb:
#
# This recipe requires package perl-podlators to be installed on the build
# workstation in order to work.
#
# TBD: look for yocto recipe for perl-podlators to be added to REQUIRE
# for this recipe, to remove build machine dependency.
#
SUMMARY = "Clang c/c++ compiler with llvm framework"
HOMEPAGE = "http://clang.llvm.org";
LICENSE = "NCSA"
PR = "r0"
LIC_FILES_CHKSUM = "file://LICENSE.TXT;md5=47e311aa9caedd1b3abf098bd7814d1d"
SRC_URI = "file://llvm-3.5.0.tar.gz \
"
SRC_URI[md5sum] = "e2dd127722ffb305c981d2a02687b4ff"
SRC_URI[sha256sum] =
"1badb762129feb7ced9484a7969c88cebab9b01b80b83002fc9690933cd7d0e0"
#EXTRA_OECONF = "--config=Linux-yocto "
INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
INSANE_SKIP_${PN} = "staticdev already-stripped"
REQUIRES = "virtual/x86_64-pokysdk-linux-gcc-crosssdk"
#everything installed under /usr/ hierarchy.
FILES_${PN} = "/usr "
inherit autotools
do_configure () {
./configure --enable-optimized --enable-targets=x86,x86_64 --prefix=/usr
}
#EXTRA_OECONF="--enable-optimized --enable-targets=x86,x86_64 --prefix=/usr "
BBCLASSEXTEND="native nativesdk"
++meta-spectra-ls-utils/recipes-devtools/llvm/packagegroup-llvm.bb
LICENSE="NCSA"
RDEPENDS_${PN}= "\
llvm \
"
++meta-spectra-ls-utils/recipes-devtools/llvm/packagegroup-nativesdk-llvm.bb
LICENSE="NCSA"
RDEPENDS_${PN}= "\
llvm \
"
++meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
#
# Copyright (C) 2007 OpenedHand Ltd
#
SUMMARY = "Host packages for the standalone SDK or external toolchain"
PR = "r12"
LICENSE = "MIT"
inherit packagegroup nativesdk
PACKAGEGROUP_DISABLE_COMPLEMENTARY = "1"
RDEPENDS_${PN} = "\
nativesdk-pkgconfig \
nativesdk-qemu \
nativesdk-qemu-helper \
nativesdk-pseudo \
nativesdk-unfs3 \
nativesdk-opkg \
nativesdk-libtool \
nativesdk-autoconf \
nativesdk-automake \
nativesdk-shadow \
nativesdk-makedevs \
nativesdk-smartpm \
nativesdk-llvm \
nativesdk-postinst-intercept \
"
RDEPENDS_${PN}_darwin = "\
nativesdk-pkgconfig \
nativesdk-opkg \
nativesdk-libtool \
"
Thank you very much in advance,
-Jim-
From: Joseph Andrew de la Peña [jdelap...@lexmark.com]
Sent: Tuesday, November 18, 2014 8:52 PM
To: Jim Rafert
Cc: nick; yocto@yoctoproject.org
Subject: Re: [yocto] New recipe for toolchain fails install, "ERROR: ld.so:
object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored."
Good day Jim,
Partly correct. To add more info, native is basically intended for host tools
that should be placed into the native/host sysroot. Please don't disregard that.
The clang compiler is built onto the target sysroot (i586) basically because of
your recipe.
The beauty of BBCLASSEXTEND is you don't need to name your recipe such as
naitvesdk-.bb or -native.bb (when using inherit).
By default, with no inherits or BBCLASSEXTEND, the recipe's packages files will
be installed into the target sysroot, i586 (which you have experienced).
Here's a quick recipe content for a tool that will be placed in native and
nativesdk sysroot.
++ tool_1.0.bb
SUMMARY=tool
LICENSE=""
SRC_URI=""
S=""
# nothing fancy
# FILES_${PN} already includes /usr/bin/* path.
# Thus, all binaries installed in /usr/bin will be part of the primary package.
BBCLASSEXTEND="native nativesdk"
++ packagegroup-.bb (the specific packagegroup your package must be
included)
RDEPENDS_${PN} = "\
t
[yocto] How to adjust patching striplevel while using SCC
I’m using SCC file to list all my kernel patches, and like to adjust the patching striplevel much the way how the “striplevel” option works for SRC_URI. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to adjust patching striplevel while using SCC
On 2014-11-19, 6:54 PM, Lin Shen (lshen) wrote: I’m using SCC file to list all my kernel patches, and like to adjust the patching striplevel much the way how the “striplevel” option works for SRC_URI. It's not possible. scc uses git and git porcelean patches to apply changes to the kernel .. which means that they need to be properly formatted patches acceptable to git. If you are trying to mess around with strip level .. you have to ask yourself "why", and you are better off fixing up the patches to the expected format. Bruce -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [oe] [meta-selinux][PATCH] ustr: Change the SRC_URI to upstream and add a new patch
On Wed, 19 Nov 2014 15:56:47 -0500 Joe MacDonald wrote: > Thanks for the submission. Just a couple of comments. > > [[oe] [meta-selinux][PATCH] ustr: Change the SRC_URI to upstream and add a > new patch] On 14.11.19 (Wed 15:34) Qian Lei wrote: > > > Official upstream is still Ok, using it first. > > Add a new patch which is applied in Fedora20 > > As these are two unrelated issues, I think two patches would've been > appropriate with 1/2 being the one that updates the SRC_URI and 2/2 > being the c99 patch. > > You should also provide an upstream-status for the C99 patch. As you > say it came from Fedora, odds are it is already submitted upstream, so > 'pending' could be appropriate here, but I don't know. > > Finally, meta-selinux patches should go to yocto@yoctoproject.org (cc'd > here), not the openembedded-dev@ list. > > I'm fine with making the changes I described above or you can send out a > new version of the patch/patches if you like. I won't do anything with > it before tomorrow, either way, to give everyone time to have a look. > > -J. Thanks for your reply.It really help me a lot. I'll take your advice and send a new version of patches to yocto soon. Qian Lei -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Layer model doomed, unless we all work together
Hey Philip, [[yocto] Layer model doomed, unless we all work together] On 14.11.18 (Tue 16:28) Philip Balister wrote: > As evidence, please review this list: > > http://layers.openembedded.org/layerindex/branch/master/duplicates/ > > I mean FOUR recipes for alsa-plugins? > > I am trying to fix the pyqt recipe in meta-oe, and had th eidea to check > for it in other layers. This leads me to meta-ivi-demo, which has an > update for sip-native and another pyqt recipe. To be fair, they are > using Qt5, so it is a little more complex. > > At any rate, we need to stop ripping recipes out of layers and maing > local copies, or worse, updating our local copies and not the primary > layer. The intent of the layer concept was not to fragment development > across many separate repositories. I completely agree and I'm glad you brought it up. I'm all for doing what I can to help on this. I also second Ross' suggestion, perhaps we could start working on an implementation of RFC5841 as a first phase, though I'm thinking that may not be the healthiest thing for me. :-) > I see a couple of issues we need to start talking about: > > 1) recipes that need to move closer to core because a range of other > packages use them. This was actually the only thing I thought needed further discussion (everything else should largely be a nod-in-agreement thing), as in some cases I'm not sure it's always clear what constitutes "closer to the core". Poky and oe-core layers are pretty clear, but the next step beyond that isn't. Are all layers hosted on git.yoctoproject.org inherhently "more core" than layers on git.openenbedded.org? And there's a number of shells when you start including all of the github projects, setting aside other open-source project hosting services. Looking at the link you sent out based on Paul's suggestion, I see I'm actually on both sides of this equation, so yay! And I'll limit the discussion to what's indexed there. Here're my examples. iscsi-initiator-utils: both in meta-networking nd meta-openstack. Both at the same version currently but wildly different contents. meta-openstack is a git.yoctoproject.org project, so does that make it closer to the core? I would think not, but as I recall there had been some comment about the openstack layer intending to limit layer dependencies outside Yocto core when it first appeared, so maybe making meta-networking a dependency is a non-starter for them. That said, I feel sorry for Alex's meta-cgl layer since it looks like it uses both meta-networking and meta-openstack and bbappends to iscsi-initiator-utils, which have significantly different patch sets. It hasn't bitten me in any of my testing with meta-cgl yet, but I didn't even notice this before now and I wasn't testing iscsi. I would not be at all surprised if different people have different results using iscsi with meta-cgl now. On the other side of the coin is the swig recipe in meta-selinux and meta-oe. The selinux build requires swig, so the meta-selinux layer needs to know it is there. I was actually gearing up a while back to ditch the swig recipe in meta-selinux since it was so old and obviously behind the meta-oe version, but didn't ... for reasons that now escape me but could have been "because that would make meta-selinux depend on meta-oe", which isn't necessarily a dependency we wanted to bring in for meta-selinux. But I'm highly allergic to duplicating (and inevitably diverging) data, so I'd still like to kick swig out of meta-selinux. But I also almost never build meta-selinux projects without some of meta-oe kicking around too. Maybe that's everyone who uses meta-selinux, I don't know. Anyway, just to keep it really interesting, is meta-selinux and meta-security, both including recipes for libcap-ng, both at the same version, both different again (though not nearly so bad as the example above). Which of these is more core? I honestly don't know, since I have used them together and separately on roughly equal number of projects and I expect that trend will continue for a good long while for me. I think this might be a scenario where meta-selinux and meta-security could make a case for trying to push this recipe further toward the core. Also, in light of this discovery, I'll be sending a patch for meta-security soon, since the meta-selinux changes for libcap-ng are almost certainly wanted there too. But that's neither here nor there. > 2) people feel they have to remove recipes from layers and make local > copies. > > And just so people know what seriously pisses me off :) Copying a recipe > from a layer, updating it, and not sending the recipe to the layer they > got the update from. I don't know if that's what has happened with any of the recipes in the layers I baby-sit, but if it is, it was absolutely not intentional and I'll see what I can do about recovering a bit of karma by tidying up about the place a bit. :-) -J. > > Thanks for letting me vent, > > Phili
Re: [yocto] New recipe for toolchain fails install, "ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored."
Good day Jim,
Please take a look at the dependency chain for the nativesdk-host and also
FILES for nativesdk-llvm.
Just wanted to clarify if you've verified it in /path/to/sdk/sysroots//usr/bin?
Thanks,
Joseph
On Thu, Nov 20, 2014 at 6:41 AM, Jim Rafert wrote:
> Hi Joseph,
>
> Thanks for the clarification.
>
> As far as I understand, I have restructured my recipe as you directed.
>
> However, when I bitbake -c populate_sdk core-image-full-cmdline, the sdk
> installer script still does not contain the LLVM/clang stuff.
>
> I'm hoping that you can see what I have done wrong.
>
> When I look for build artifacts, here's what I find for clang in the work
> directory.
>
> [jimr@krusty work]$ find . -name clang -ls |grep bin/clang
> 99906923 45428 -rwxr-xr-x 1 jimr jimr 46517960 Nov 19 12:00
> ./spectra_ls-poky-linux/core-image-full-cmdline/1.0-r0/sdk/image/usr/bin/clang
> 94263147 45428 -rwxr-xr-x 2 jimr jimr 46517960 Nov 19 12:00
> ./x86_64-nativesdk-pokysdk-linux/nativesdk-llvm/3.5.0-r0/packages-split/nativesdk-llvm/usr/bin/clang
> 94263147 45428 -rwxr-xr-x 2 jimr jimr 46517960 Nov 19 12:00
> ./x86_64-nativesdk-pokysdk-linux/nativesdk-llvm/3.5.0-r0/package/usr/bin/clang
> 88904578 56380 -rwxr-xr-x 1 jimr jimr 57732373 Nov 19 11:51
> ./x86_64-nativesdk-pokysdk-linux/nativesdk-llvm/3.5.0-r0/llvm-3.5.0/Release+Asserts/bin/clang
> 89415572 45432 -rwxr-xr-x 1 jimr jimr 46517960 Nov 19 12:00
> ./x86_64-nativesdk-pokysdk-linux/nativesdk-llvm/3.5.0-r0/image/usr/bin/clang
>
> Finding the clang executable in
> /spectra_ls-poky-linux/core-image-full-cmdline/1.0-r0/sdk/image/usr/bin/clang
> would seem to suggest that it should be in the SDK, but it is not.
>
> Here are the recipes...
>
> ++ meta-spectra-ls-utils/recipes-devtools/llvm/llvm_3.5.0.bb:
> #
> # This recipe requires package perl-podlators to be installed on the build
> # workstation in order to work.
> #
> # TBD: look for yocto recipe for perl-podlators to be added to REQUIRE
> # for this recipe, to remove build machine dependency.
> #
> SUMMARY = "Clang c/c++ compiler with llvm framework"
> HOMEPAGE = "http://clang.llvm.org";
> LICENSE = "NCSA"
> PR = "r0"
> LIC_FILES_CHKSUM =
> "file://LICENSE.TXT;md5=47e311aa9caedd1b3abf098bd7814d1d"
>
> SRC_URI = "file://llvm-3.5.0.tar.gz \
> "
>
> SRC_URI[md5sum] = "e2dd127722ffb305c981d2a02687b4ff"
> SRC_URI[sha256sum] =
> "1badb762129feb7ced9484a7969c88cebab9b01b80b83002fc9690933cd7d0e0"
>
> #EXTRA_OECONF = "--config=Linux-yocto "
>
> INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
>
> INSANE_SKIP_${PN} = "staticdev already-stripped"
> REQUIRES = "virtual/x86_64-pokysdk-linux-gcc-crosssdk"
>
> #everything installed under /usr/ hierarchy.
> FILES_${PN} = "/usr "
> inherit autotools
>
> do_configure () {
> ./configure --enable-optimized --enable-targets=x86,x86_64
> --prefix=/usr
> }
>
> #EXTRA_OECONF="--enable-optimized --enable-targets=x86,x86_64
> --prefix=/usr "
>
>
> BBCLASSEXTEND="native nativesdk"
>
>
> ++meta-spectra-ls-utils/recipes-devtools/llvm/packagegroup-llvm.bb
> LICENSE="NCSA"
> RDEPENDS_${PN}= "\
> llvm \
> "
>
> ++meta-spectra-ls-utils/recipes-devtools/llvm/
> packagegroup-nativesdk-llvm.bb
> LICENSE="NCSA"
> RDEPENDS_${PN}= "\
> llvm \
> "
> ++meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
> #
> # Copyright (C) 2007 OpenedHand Ltd
> #
>
> SUMMARY = "Host packages for the standalone SDK or external toolchain"
> PR = "r12"
> LICENSE = "MIT"
>
> inherit packagegroup nativesdk
>
> PACKAGEGROUP_DISABLE_COMPLEMENTARY = "1"
>
> RDEPENDS_${PN} = "\
> nativesdk-pkgconfig \
> nativesdk-qemu \
> nativesdk-qemu-helper \
> nativesdk-pseudo \
> nativesdk-unfs3 \
> nativesdk-opkg \
> nativesdk-libtool \
> nativesdk-autoconf \
> nativesdk-automake \
> nativesdk-shadow \
> nativesdk-makedevs \
> nativesdk-smartpm \
> nativesdk-llvm \
> nativesdk-postinst-intercept \
> "
>
> RDEPENDS_${PN}_darwin = "\
> nativesdk-pkgconfig \
> nativesdk-opkg \
> nativesdk-libtool \
> "
>
> Thank you very much in advance,
> -Jim-
> --
> *From:* Joseph Andrew de la Peña [jdelap...@lexmark.com]
> *Sent:* Tuesday, November 18, 2014 8:52 PM
>
> *To:* Jim Rafert
> *Cc:* nick; yocto@yoctoproject.org
> *Subject:* Re: [yocto] New recipe for toolchain fails install, "ERROR:
> ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored."
>
> Good day Jim,
>
> Partly correct. To add more info, native is basically intended for host
> tools that should be placed into the native/host sysroot. Please don't
> disregard that.
>
> The clang compiler is built onto the target sysroot (i586) basically
> because of your recipe.
>
> The beauty of BBCLASSEXTEND is you don't need to name your recipe such
> as naitvesdk-.bb or -native.bb (when using inherit). By
> default, with no inherits or BBCLASSEXTEND, the recipe's packages files
> will be installed i
Re: [yocto] sharing directories between users on same machine
For the "download" directory, just set the permissions for the group to allow writing. I've used this with an NFS share that holds all downloads. The machien also runs apache and shares this directory via http. I share the sstate-cache via http, and there's one machine that runs all builds every night, so that the cache is usually up to date. But I think chmod g+w on the sstate-cache dir should accomplish the same. On 11/19/2014 04:20 PM, Urs Fässler wrote: Hello, we try to share the sstate-cache and download directory between multiple users on the same machine. It seems that this don't work as yocto want to overwrite some files in those directories, but does not have the rights (since another user created them). Is this not an use case? - If it should work, can somebody give pointers what might went wrong (some missing configuration or so) - If it can not work, can we do that differently? Thanks Urs Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Systems Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: (+31) (0) 499 33 69 79 Telefax: (+31) (0) 499 33 69 70 E-mail: mike.looijm...@topic.nl Website: www.topic.nl Please consider the environment before printing this e-mail Visit us at Bits & Chips Smart Systems 20th November, 1931 Congrescentum Brabanthallen 's-Hertogenbosch, stand number 34 http://bc-smartsystems.nl -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
