Re: [OE-core] [PATCH] binutils : enable production of EFI binaries on x86-64
On Tue, Jul 24, 2018 at 8:16 PM Christopher Clark wrote: > > From: Christopher Clark > > When MACHINE_FEATURES includes "efi" and target is x86-64, > enable the linker to produce Portable Executables: EFI binaries. > > Supplies "--enable-targets=x86_64-pep" in EXTRA_OECONF. > > Enables building the EFI variant of the Xen hypervisor. > > Signed-off-by: Christopher Clark > --- > meta/recipes-devtools/binutils/binutils.inc | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/meta/recipes-devtools/binutils/binutils.inc > b/meta/recipes-devtools/binutils/binutils.inc > index 37813dd..eedcc7e 100644 > --- a/meta/recipes-devtools/binutils/binutils.inc > +++ b/meta/recipes-devtools/binutils/binutils.inc > @@ -69,12 +69,15 @@ python do_package_prepend() { > > B = "${S}/build.${HOST_SYS}.${TARGET_SYS}" > > +ENABLE_EFI_BINARIES_x86-64 = "--enable-targets=x86_64-pep" > + > EXTRA_OECONF = "--program-prefix=${TARGET_PREFIX} \ > --disable-werror \ > --enable-deterministic-archives \ > --enable-plugins \ > ${LDGOLD} \ > -${@bb.utils.contains('DISTRO_FEATURES', 'multiarch', > '--enable-64-bit-bfd', '', d)}" > +${@bb.utils.contains('DISTRO_FEATURES', 'multiarch', > '--enable-64-bit-bfd', '', d)} \ > +${@bb.utils.contains('MACHINE_FEATURES', 'efi', > '${ENABLE_EFI_BINARIES}', '', d)}" I think we should avoid using machine features rather enable this emulation unconditionally for efi enabled targets, which for now are arm/x86/x86_64/aarch64 > > LDGOLD_class-native = "" > LDGOLD_class-crosssdk = "" > -- > 2.7.4 > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] binutils : enable production of EFI binaries on x86-64
From: Christopher Clark When MACHINE_FEATURES includes "efi" and target is x86-64, enable the linker to produce Portable Executables: EFI binaries. Supplies "--enable-targets=x86_64-pep" in EXTRA_OECONF. Enables building the EFI variant of the Xen hypervisor. Signed-off-by: Christopher Clark --- meta/recipes-devtools/binutils/binutils.inc | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/meta/recipes-devtools/binutils/binutils.inc b/meta/recipes-devtools/binutils/binutils.inc index 37813dd..eedcc7e 100644 --- a/meta/recipes-devtools/binutils/binutils.inc +++ b/meta/recipes-devtools/binutils/binutils.inc @@ -69,12 +69,15 @@ python do_package_prepend() { B = "${S}/build.${HOST_SYS}.${TARGET_SYS}" +ENABLE_EFI_BINARIES_x86-64 = "--enable-targets=x86_64-pep" + EXTRA_OECONF = "--program-prefix=${TARGET_PREFIX} \ --disable-werror \ --enable-deterministic-archives \ --enable-plugins \ ${LDGOLD} \ -${@bb.utils.contains('DISTRO_FEATURES', 'multiarch', '--enable-64-bit-bfd', '', d)}" +${@bb.utils.contains('DISTRO_FEATURES', 'multiarch', '--enable-64-bit-bfd', '', d)} \ +${@bb.utils.contains('MACHINE_FEATURES', 'efi', '${ENABLE_EFI_BINARIES}', '', d)}" LDGOLD_class-native = "" LDGOLD_class-crosssdk = "" -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] udev-extraconf: Add systemd-mount to udev-extraconf/mount.sh
ping.. // Hongzhi On 2018年07月13日 17:15, Hongzhi, Song wrote: ping. Please. -- Hongzhi On 2018年07月03日 11:40, Hongzhi, Song wrote: ping. The patch fixes the real problem. Please review it. //Hongzhi On 2018年04月24日 04:20, Randy MacLeod wrote: On 2018-04-22 11:37 PM, Hongzhi, Song wrote: ping Please be patient. 0e-core-2.5 rc1 is being tested now and only critical blocking fixes are being accepted. Once the results of 2.5 tests are good, then commits such as this one can be added to the master[-next] branch and then later cherry-picked back to 2.5.1 if needed. Give people a few days (or more if things don't go well) to get 2.5 out the door. ../Randy // Hongzhi On 2018年04月17日 15:03, Hongzhi.Song wrote: Udev-extraconf works correctly with sysvinit in the aspect of automounting block devices. But it has a serious problem in case of systemd. Block devices automounted by udev is unaccessible to host space(out of udevd's private namespace). For example, we cannot format those block devices. e.g. root@qemux86:~# mkfs.ext4 /dev/sda1 mke2fs 1.43.8 (1-Jan-2018) /dev/sda1 contains a ext4 file system last mounted on Tue Apr 3 06:22:41 2018 Proceed anyway? (y,N) y /dev/sda1 is apparently in use by the system; will not make a filesystem here! Other distributions has no such problem, because they use a series of rules to manager block devices. Different types of block devices match different rules. But udev-extraconf just use one rule, automount.rules, which results in this problem. The 'systemd-mount' command is recommended by the systemd community to solve such problems. This patch makes use of 'systemd-mount' to solve the above problem. [YOCTO #12644] Signed-off-by: Hongzhi.Song --- meta/recipes-core/udev/udev-extraconf/mount.sh | 83 -- meta/recipes-core/udev/udev-extraconf_1.1.bb | 3 + 2 files changed, 69 insertions(+), 17 deletions(-) diff --git a/meta/recipes-core/udev/udev-extraconf/mount.sh b/meta/recipes-core/udev/udev-extraconf/mount.sh index d760328..067d4e2 100644 --- a/meta/recipes-core/udev/udev-extraconf/mount.sh +++ b/meta/recipes-core/udev/udev-extraconf/mount.sh @@ -4,10 +4,28 @@ # # Attempt to mount any added block devices and umount any removed devices +BASE_INIT="`readlink "@base_sbindir@/init"`" +INIT_SYSTEMD="@systemd_unitdir@/systemd" + +if [ "x$BASE_INIT" = "x$INIT_SYSTEMD" ];then + # systemd as init uses systemd-mount to mount block devices + MOUNT="/usr/bin/systemd-mount" + UMOUNT="/usr/bin/systemd-umount" + + if [ -x $MOUNT ] && [ -x $UMOUNT ]; + then + logger "Using systemd-mount to finish mount" + else + logger "Linux init is using systemd, so please install systemd-mount to finish mount" + exit 1 + fi +else + MOUNT="/bin/mount" + UMOUNT="/bin/umount" +fi -MOUNT="/bin/mount" PMOUNT="/usr/bin/pmount" -UMOUNT="/bin/umount" + for line in `grep -h -v ^# /etc/udev/mount.blacklist /etc/udev/mount.blacklist.d/*` do if [ ` expr match "$DEVNAME" "$line" ` -gt 0 ]; @@ -17,7 +35,35 @@ do fi done -automount() { +automount_systemd() { + name="`basename "$DEVNAME"`" + + [ -d "/run/media/$name" ] || mkdir -p "/run/media/$name" + + MOUNT="$MOUNT -o silent" + + # If filesystemtype is vfat, change the ownership group to 'disk', and + # grant it with w/r/x permissions. + case $ID_FS_TYPE in + vfat|fat) + MOUNT="$MOUNT -o umask=007,gid=`awk -F':' '/^disk/{print $3}' /etc/group`" + ;; + # TODO + *) + ;; + esac + + if ! $MOUNT --no-block -t auto $DEVNAME "/run/media/$name" + then + #logger "mount.sh/automount" "$MOUNT -t auto $DEVNAME \"/run/media/$name\" failed!" + rm_dir "/run/media/$name" + else + logger "mount.sh/automount" "Auto-mount of [/run/media/$name] successful" + touch "/tmp/.automount-$name" + fi +} + +automount() { name="`basename "$DEVNAME"`" ! test -d "/run/media/$name" && mkdir -p "/run/media/$name" @@ -26,7 +72,7 @@ automount() { then MOUNT="$MOUNT -o silent" fi - + # If filesystem type is vfat, change the ownership group to 'disk', and # grant it with w/r/x permissions. case $ID_FS_TYPE in @@ -68,23 +114,26 @@ if [ "$ACTION" = "add" ] && [ -n "$DEVNAME" ] && [ -n "$ID_FS_TYPE" -o "$media_t elif [ -x $MOUNT ]; then $MOUNT $DEVNAME 2> /dev/null fi - + # If the device isn't mounted at this point, it isn't # configured in fstab (note the root filesystem can show up as # /dev/root in /proc/mounts, so check the device number too) - if expr $MAJOR "*" 256 + $MINOR != `stat -c %d /`; then - grep -q "^$DEVNAME " /proc/mounts || automount - fi + if expr $MAJOR "*" 256 + $MINOR != `stat -c %d /`; then + if [ "`basename $MOUNT`" = "systemd-mount" ];then + grep -q "^$DEVNAME " /
[OE-core] aclocal question
aclocal can generate rather large command lines (194000 characters) when calling autom4te to trace macros. I think that this breaks at a little beyond the argument length I've mentioned. I'm not familiar with this code but I think the bulk of the items could be piped into autom4te rather than the way it is done now. This might not solve the problem but I wondered if anyone has looked at this issue. Specifically, we have seen failures when building libvirt for a project with a long pathname. Joe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-oe][PATCH] perl: native modules will not trigger build perl for target.
On Tue, Jul 24, 2018 at 12:22 AM, Krzysztof Taborski wrote: > Hello, > Example recipe (recipe.bb for example): > """ > LICENSE="CLOSED" > > RDEPENDS_${PN} = "perl-module-file-glob" > > BBCLASSEXTEND = "native nativesdk" > do_install() { > install -d ${D}/${bindir} > echo "my perl script" > ${D}/${bindir}/recipe.pl > } > inherit perlnative > "" > > When my patch is removed and I will call: "'bitbake recipe-native". > Then I have dependency: > recipe-native -> perl (target version) > This is not correct, that native recipe has dependency to target recipe. There are two parts to this issue. First, the dependency between recipe-native and perl is certainly a bug and your fix for that in the perl recipe looks good, ie setting PACKAGES_DYNAMIC += "^perl-module-.*(? perl dependency will be gone, trying to build your recipe-native should now generate a build failure - bitbake will correctly report that nothing provides a package called "perl-module-file-glob-native". The question is really how to fix that new build failure. One approach (the approach you took - the second part of your patch) is to update the perl-native recipe so that pretends to provide packages named "perl-module-XXX-native". The alternative approach is to explicitly set RDEPENDS for the -native build of your recipe to over-ride the false dependency added by the native class dependency renaming e.g. RDEPENDS_${PN}_class-native = "perl-native" That second approach is basically what the autoconf recipe does to solve a similar problem: http://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/autoconf/autoconf.inc?h=sumo As to which is the more "correct" approach, I'm not really sure. Opinions welcome... > When I called (bitbake recipe-native -g) I can find: > "recipe-native" -> "perl" > in recipe-depends.dot > > This was my original problem. Please correct me, if missed something. > > usage of += with an over-ride - I've just copied it from nativesdk > over-ride, which was already in perl recipe. > > > Best regards, > Krzysztof Taborski > > 2018-07-23 19:23 GMT+02:00 Andre McCurdy : >> >> On Mon, Jul 23, 2018 at 5:57 AM, Krzysztof Taborski >> wrote: >> > Change was already merged: >> > >> > http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-devtools?id=7dd9772eca6df52db09b65537fdf689f1aa3fd8f >> > >> > Is your request still valid? >> >> Yes, although the change was merged, it's not clear that it was correct. >> >> Native recipes aren't split into packages, so there are no -native >> versions of the perl modules. If you have a recipe which depends on >> "perl-module-XXX-native" it's likely a bug in that recipe - not in >> perl-native. >> >> What recipe did you find which depends on a -native version of a perl >> module? >> >> > 2018-07-09 21:40 GMT+02:00 Andre McCurdy : >> >> >> >> On Wed, May 9, 2018 at 7:16 AM, taborskikrzysztof >> >> wrote: >> >> > Can I request review? >> >> > Oryginalna wiadomość >> >> > Od: Krzysztof Taborski >> >> > Data: 08.05.2018 18:46 (GMT+01:00) >> >> > Do: openembedded-core@lists.openembedded.org >> >> > DW: Krzysztof Taborski >> >> > Temat: [meta-oe][PATCH] perl: native modules will not trigger build >> >> > perl >> >> > for >> >> > target. >> >> > >> >> > Currently building perl-native modules triggers >> >> > build perl for target due to PACKAGES_DYNAMIC regex. >> >> > >> >> > This commit will cause, that perl native modules will >> >> > trigger perl-native build. >> >> >> >> Can you give an example of how to reproduce the problem? >> >> >> >> > Signed-off-by: Krzysztof Taborski >> >> > --- >> >> > meta/recipes-devtools/perl/perl-native_5.24.1.bb | 2 ++ >> >> > meta/recipes-devtools/perl/perl_5.24.1.bb| 2 +- >> >> > 2 files changed, 3 insertions(+), 1 deletion(-) >> >> > >> >> > diff --git a/meta/recipes-devtools/perl/perl-native_5.24.1.bb >> >> > b/meta/recipes-devtools/perl/perl-native_5.24.1.bb >> >> > index a9ab17d16c..71f45890b0 100644 >> >> > --- a/meta/recipes-devtools/perl/perl-native_5.24.1.bb >> >> > +++ b/meta/recipes-devtools/perl/perl-native_5.24.1.bb >> >> > @@ -135,3 +135,5 @@ EOF >> >> > >> >> > # Fix the path in sstate >> >> > SSTATE_SCAN_FILES += "*.pm *.pod *.h *.pl *.sh" >> >> > +PACKAGES_DYNAMIC_class-native += "^perl-module-.*native$" >> >> >> >> This usage of += with an over-ride is not correct. >> >> >> >> However, regardless of that, was this change actually needed? >> >> >> >> If you know of a -native recipe which depends on a >> >> perl-module-XXX-native package then it's probably a bug in the -native >> >> recipe. Having perl-native pretend to provide perl-module packages >> >> probably isn't the right solution. >> >> >> >> > diff --git a/meta/recipes-devtools/perl/perl_5.24.1.bb >> >> > b/meta/recipes-devtools/perl/perl_5.24.1.bb >> >> > index 53a426289a..4c6a71082f 100644 >> >> > --- a/meta/recipes-devtools/perl/perl_5.24.1.bb >> >> > +++ b/meta/recipes-devtools/perl/perl_5.24.1.bb >> >> > @@ -339,7
Re: [OE-core] [PATCH] lsof: Update SRC_URI
On 07/24/2018 04:37 AM, Alexander Kanavin wrote: Also, if an upgrade is undesirable for some reason, then such changes need UPSTREAM_CHECK_URI, or we'll be missing new upstream releases. Alex 2018-07-24 10:07 GMT+02:00 Burton, Ross : Well for master if there's a new version then a better fix would be to upgrade, Yes, there's a 4.91 as of March and a github repo in the works according to the members-only list archive: On Fri Jun 22 09:55:59 EDT 2018, Victor Abell wrote: I am slowly making progress for the release of lsof to GitHUB from its Purdue Research Foundation copyright. I have finally reached a person who works on open source distribution issues. He and I have had several discussions about lsof and its copyright and he now understands what needs to be done. He has formulated a request to the senior IP officer for the release and we are waiting the response. so for oe-core-2.6, we should use 4.91. but we do need to make sure the previous releases are using mirrors. I expect that Ovidiu just forgot the branch prefix in his subject line. Do you want him to resend for 2.5 and 2.4 ? ../Randy On 24 July 2018 at 08:48, Ovidiu Panait wrote: lsof 4.89 archive has been moved to OLD directory and turned into tar.gz, so update SRC_URI and checksums. Signed-off-by: Ovidiu Panait --- meta/recipes-extended/lsof/lsof_4.89.bb | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/meta/recipes-extended/lsof/lsof_4.89.bb b/meta/recipes-extended/lsof/lsof_4.89.bb index 14546db23c..b58b8281f9 100644 --- a/meta/recipes-extended/lsof/lsof_4.89.bb +++ b/meta/recipes-extended/lsof/lsof_4.89.bb @@ -11,12 +11,12 @@ LIC_FILES_CHKSUM = "file://00README;beginline=645;endline=679;md5=964df275d26429 # https://people.freebsd.org/~abe/ ). http://www.mirrorservice.org seems to be # the most commonly used alternative. -SRC_URI = "http://www.mirrorservice.org/sites/lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_${PV}.tar.bz2 \ +SRC_URI = "http://www.mirrorservice.org/sites/lsof.itap.purdue.edu/pub/tools/unix/lsof/OLD/lsof_${PV}.tar.gz \ file://lsof-remove-host-information.patch \ " -SRC_URI[md5sum] = "1b9cd34f3fb86856a125abbf2be3a386" -SRC_URI[sha256sum] = "81ac2fc5fdc944793baf41a14002b6deb5a29096b387744e28f8c30a360a3718" +SRC_URI[md5sum] = "8afbaff3ee308edc130bdc5df0801c8f" +SRC_URI[sha256sum] = "5d08da7ebe049c9d9a6472d6afb81aa5af54c4733a3f8822cbc22b57867633c9" LOCALSRC = "file://${WORKDIR}/lsof_${PV}/lsof_${PV}_src.tar" -- 2.17.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- # Randy MacLeod # Wind River Linux -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Setting include path in a recipe
On Tue, Jul 24, 2018 at 6:52 AM, Adam Lee wrote: > > How do I defined a custom include path for an autotools recipe? > > This may as well be explained somewhere in the reference manual, but I can't > seem to find it. Assuming you want to add a custom directory which is within sysroot: CPPFLAGS += "-I=/usr/include/specialheaders" -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Yocto Project Unassigned Bugs - Help Needed
All, The triage team meets weekly and does its best to handle the bugs reported into the bugzilla. The numbers of people attending that meeting have fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 327 unassigned bugs. We're hoping people may be able to spare some time now and again to help out with these. Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system. There are also roughly three different "priority" classes right now, "2.6", "2.99" and "Future", the more pressing/urgent issues being in "2.6". Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (stephen.k.jol...@intel.com) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a bugzilla account). The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_Bugs Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 *Cell:(208) 244-4460 * Email: stephen.k.jol...@intel.com -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Yocto Project Status WW30’18
Current Dev Position: YP 2.6 M3. Next Deadline: YP 2.6 M2 Release Target is July 27, 2018 SWAT Team Rotation: · SWAT lead is currently: Amanda · SWAT team rotation: Amanda -> Tracy on July 27, 2018 · SWAT team rotation: Tracy -> Armin on Aug. 3, 2018 · https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: · YP 2.6 M2 is in QA. See https://wiki.yoctoproject.org/wiki/2.6_QA_Status. It is 84% complete. · YP 2.3.4 has been released. This is the final release of the YP 2.3 (pyro) series. · YP 2.2.4 is out of QA and will release this week. This will be the final release of the YP 2.2 (morty) series. · A new version of uninative-tarball will be released this week to fix issues sharing sstate from newer distros. · Oe-selftest patches have merged however there are race issues in the test cases, particularly where the modify metadata as part of the test. This has meant we’ve not enabled parallelisation by default yet. · RP is compiling a list of broken selftests so we can figure out fixing them by monitoring the repository for changes as the tests run. If anyone is interested in helping let us know! Faster oe-selftest times mean faster patch testing and merging. · We lack a good mechanism for flagging work which someone new to the project who wants to help could take on. Richard posted one such task onto the OE-Core mailing list last week (“OE-core] Request for help - Simple cleanup/optimisation task”) · Master now has significant parallelism improvements for do_package which take the wall clock time for ltp from 605s to 163s. Some of that was through parallel execution of tasks, removal of the use of subprocess shells also helped. Planned Releases for YP 2.6: · YP 2.6 M2 Build ia in QA. · YP 2.6 M2 Release Target is July 27, 2018 · YP 2.6 M3 Build Target is Aug. 27, 2018 · YP 2.6 M3 Release Target is Sept. 7, 2018 · YP 2.6 M4 Build Target is Oct. 1, 2018 · YP 2.6 M4 Release Target is Oct. 26, 2018 Planned upcoming dot releases: · YP 2.5.1 (Sumo) will be targeted after YP 2.6 M2 is done. · YP 2.4.4 (Rocko) will be targeted after YP 2.6 M4 is done. Tracking Metrics: · WDD 2618 (last week 2646) (https://wiki.yoctoproject.org/charts/combo.html) · Poky Patch Metrics oTotal patches found: 1619 (last week 1628) oPercentage of patches in the Pending State: 762 (46%) [last week 762 (47%)] Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.6_Status https://wiki.yoctoproject.org/wiki/Yocto_2.6_Schedule https://wiki.yoctoproject.org/wiki/Yocto_2.6_Features The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status [If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!] Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 •Cell:(208) 244-4460 • Email: stephen.k.jol...@intel.com -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] defaultsetup.conf: Enable security flags+pie by default
On Mon, Jul 23, 2018 at 11:42 PM Anuj Mittal wrote: > > On 07/24/2018 03:09 AM, Khem Raj wrote: > > This has been an opt-in for so long, some distributions e.g. > > poky-lsb uses it by default however, since most of linux > > distros have started to default to these settings for security > > enhancements, time has come for OE to make it default too > > Should be removed from poky-lsb in that case otherwise gives duplicate > inclusion warnings. > yes. after this patch lands we can do that. > > > > Signed-off-by: Khem Raj > > --- > > meta/conf/distro/defaultsetup.conf | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/meta/conf/distro/defaultsetup.conf > > b/meta/conf/distro/defaultsetup.conf > > index ca2f9178d2..352e279596 100644 > > --- a/meta/conf/distro/defaultsetup.conf > > +++ b/meta/conf/distro/defaultsetup.conf > > @@ -1,6 +1,7 @@ > > include conf/distro/include/default-providers.inc > > include conf/distro/include/default-versions.inc > > include conf/distro/include/default-distrovars.inc > > +require conf/distro/include/security_flags.inc > > include conf/distro/include/world-broken.inc > > > > TCMODE ?= "default" > > > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] defaultsetup.conf: Enable security flags+pie by default
On Tue, Jul 24, 2018 at 12:30 AM ChenQi wrote: > > Hi Khem, > > The comments in security-flags.inc also needs to be modified to remove > 'poky-lsb' info. > > I'd suggest we still put it into distro conf file (poky.conf) instead of > defaultsetup.conf, because defaultsetup.conf is included by > bitbake.conf. I think things in defaultsetup.conf should be necessary > default values to build things out. I don't think security flags is > necessary to build things out. this is the default setup, even non-poky users will get consistent experience. > > Also, I got a question when I just looked at this file. > Do you think we should adjust CFLAGS and LDFALGS in security_flags.inc > instead of the current TARGET_CC_ARCH and TARGET_LDFLAGS? in many cases packages do not honor CFLAGS/LDFLAGS say during configure We are naming > variables to SECURITY_CFLAGS and SECURITY_LDFLAGS, it seems that they > belong to CFLAGS and LDFLAGS naturally. But I'm not sure about it. > yes they do, but this makes it easy to override the setting for packages where these options are needed to be overridden or modified. > Best Regards, > Chen Qi > > > On 07/24/2018 03:09 AM, Khem Raj wrote: > > This has been an opt-in for so long, some distributions e.g. > > poky-lsb uses it by default however, since most of linux > > distros have started to default to these settings for security > > enhancements, time has come for OE to make it default too > > > > Signed-off-by: Khem Raj > > --- > > meta/conf/distro/defaultsetup.conf | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/meta/conf/distro/defaultsetup.conf > > b/meta/conf/distro/defaultsetup.conf > > index ca2f9178d2..352e279596 100644 > > --- a/meta/conf/distro/defaultsetup.conf > > +++ b/meta/conf/distro/defaultsetup.conf > > @@ -1,6 +1,7 @@ > > include conf/distro/include/default-providers.inc > > include conf/distro/include/default-versions.inc > > include conf/distro/include/default-distrovars.inc > > +require conf/distro/include/security_flags.inc > > include conf/distro/include/world-broken.inc > > > > TCMODE ?= "default" > > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Setting include path in a recipe
How do I defined a custom include path for an autotools recipe? This may as well be explained somewhere in the reference manual, but I can't seem to find it. Thank you, Adam -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v5 6/6] gstreamer1.0-libav: Replace German umlaut to avoid parsing problems
I'll just drop it, no need to resend. Thanks Ross On 24 July 2018 at 14:15, Carlos Rafael Giani wrote: > I wanted to add details to this as a response to your comment, but my old > setup where this happens now refuses to work anymore, and I don't remember > said details. > > Okay, I propose we skip this patch and commit it later in case this problem > reappears. > > Is a v6 necessary now, or can patchwork skip the last patch? > > > > On 2018-07-24 13:04, Burton, Ross wrote: >> >> It can? Where? That's surely a bug... >> >> Ross >> >> On 24 July 2018 at 11:52, Carlos Rafael Giani >> wrote: >>> >>> The umlaut can cause issues related to encoding; avoid by replacing it >>> >>> Signed-off-by: Carlos Rafael Giani >>> --- >>> .../workaround-to-build-gst-libav-for-i586-with-gcc.patch | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git >>> a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch >>> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch >>> index 36abf8607e..5355480aa4 100644 >>> --- >>> a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch >>> +++ >>> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch >>> @@ -1,5 +1,5 @@ >>> Description: Workaround to build libav for i586 with gcc 4.9.2 by >>> avoiding memset >>> -Author: Bernhard Übelacker >>> +Author: Bernhard Uebelacker >>> >>> --- >>> Bug-Debian: https://bugs.debian.org/783082 >>> -- >>> 2.17.1 >>> >>> -- >>> ___ >>> Openembedded-core mailing list >>> Openembedded-core@lists.openembedded.org >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core > > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v5 6/6] gstreamer1.0-libav: Replace German umlaut to avoid parsing problems
I wanted to add details to this as a response to your comment, but my old setup where this happens now refuses to work anymore, and I don't remember said details. Okay, I propose we skip this patch and commit it later in case this problem reappears. Is a v6 necessary now, or can patchwork skip the last patch? On 2018-07-24 13:04, Burton, Ross wrote: It can? Where? That's surely a bug... Ross On 24 July 2018 at 11:52, Carlos Rafael Giani wrote: The umlaut can cause issues related to encoding; avoid by replacing it Signed-off-by: Carlos Rafael Giani --- .../workaround-to-build-gst-libav-for-i586-with-gcc.patch | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch index 36abf8607e..5355480aa4 100644 --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch @@ -1,5 +1,5 @@ Description: Workaround to build libav for i586 with gcc 4.9.2 by avoiding memset -Author: Bernhard Übelacker +Author: Bernhard Uebelacker --- Bug-Debian: https://bugs.debian.org/783082 -- 2.17.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] shadow: fix CVE-2017-2616
Signed-off-by: Andrej Valek --- .../shadow/files/CVE-2017-2616.patch | 64 ++ meta/recipes-extended/shadow/shadow.inc| 1 + 2 files changed, 65 insertions(+) create mode 100644 meta/recipes-extended/shadow/files/CVE-2017-2616.patch diff --git a/meta/recipes-extended/shadow/files/CVE-2017-2616.patch b/meta/recipes-extended/shadow/files/CVE-2017-2616.patch new file mode 100644 index 00..ee728f0952 --- /dev/null +++ b/meta/recipes-extended/shadow/files/CVE-2017-2616.patch @@ -0,0 +1,64 @@ +shadow-4.2.1: Fix CVE-2017-2616 + +[No upstream tracking] -- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855943 + +su: properly clear child PID + +If su is compiled with PAM support, it is possible for any local user +to send SIGKILL to other processes with root privileges. There are +only two conditions. First, the user must be able to perform su with +a successful login. This does NOT have to be the root user, even using +su with the same id is enough, e.g. "su $(whoami)". Second, SIGKILL +can only be sent to processes which were executed after the su process. +It is not possible to send SIGKILL to processes which were already +running. I consider this as a security vulnerability, because I was +able to write a proof of concept which unlocked a screen saver of +another user this way. + +Upstream-Status: Backport [https://github.com/shadow-maint/shadow/commit/08fd4b69e84364677a10e519ccb25b71710ee686] +CVE: CVE-2017-2616 +bug: 855943 +Signed-off-by: Andrej Valek + +diff --git a/src/su.c b/src/su.c +index 3704217..1efcd61 100644 +--- a/src/su.c b/src/su.c +@@ -363,20 +363,35 @@ static void prepare_pam_close_session (void) + /* wake child when resumed */ + kill (pid, SIGCONT); + stop = false; ++ } else { ++ pid_child = 0; + } + } while (!stop); + } + +- if (0 != caught) { ++ if (0 != caught && 0 != pid_child) { + (void) fputs ("\n", stderr); + (void) fputs (_("Session terminated, terminating shell..."), + stderr); + (void) kill (-pid_child, caught); + + (void) signal (SIGALRM, kill_child); ++ (void) signal (SIGCHLD, catch_signals); + (void) alarm (2); + +- (void) wait (&status); ++ sigemptyset (&ourset); ++ if ((sigaddset (&ourset, SIGALRM) != 0) ++ || (sigprocmask (SIG_BLOCK, &ourset, NULL) != 0)) { ++ fprintf (stderr, _("%s: signal masking malfunction\n"), Prog); ++ kill_child (0); ++ } else { ++ while (0 == waitpid (pid_child, &status, WNOHANG)) { ++ sigsuspend (&ourset); ++ } ++ pid_child = 0; ++ (void) sigprocmask (SIG_UNBLOCK, &ourset, NULL); ++ } ++ + (void) fputs (_(" ...terminated.\n"), stderr); + } + diff --git a/meta/recipes-extended/shadow/shadow.inc b/meta/recipes-extended/shadow/shadow.inc index 9a08918818..6efe4a9119 100644 --- a/meta/recipes-extended/shadow/shadow.inc +++ b/meta/recipes-extended/shadow/shadow.inc @@ -18,6 +18,7 @@ SRC_URI = "https://downloads.yoctoproject.org/mirror/sources/${BP}.tar.xz \ file://check_size_of_uid_t_and_gid_t_using_AC_CHECK_SIZEOF.patch \ file://0001-useradd-copy-extended-attributes-of-home.patch \ file://0001-shadow-CVE-2017-12424 \ + file://CVE-2017-2616.patch \ ${@bb.utils.contains('PACKAGECONFIG', 'pam', '${PAM_SRC_URI}', '', d)} \ " -- 2.11.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for "[v5] gstreamer1.0-plugin-base:..." and 5 more
== Series Details == Series: "[v5] gstreamer1.0-plugin-base:..." and 5 more Revision: 1 URL : https://patchwork.openembedded.org/series/13175/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fixRebase your series on top of targeted branch Targeted branch master (currently at f9c233908e) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v5 6/6] gstreamer1.0-libav: Replace German umlaut to avoid parsing problems
It can? Where? That's surely a bug... Ross On 24 July 2018 at 11:52, Carlos Rafael Giani wrote: > The umlaut can cause issues related to encoding; avoid by replacing it > > Signed-off-by: Carlos Rafael Giani > --- > .../workaround-to-build-gst-libav-for-i586-with-gcc.patch | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git > a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch > > b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch > index 36abf8607e..5355480aa4 100644 > --- > a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch > +++ > b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch > @@ -1,5 +1,5 @@ > Description: Workaround to build libav for i586 with gcc 4.9.2 by avoiding > memset > -Author: Bernhard Übelacker > +Author: Bernhard Uebelacker > > --- > Bug-Debian: https://bugs.debian.org/783082 > -- > 2.17.1 > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/6] package: Use subprocess to be consistent with the rest of the class
Using 'sub' in one function just confuses things, standardise and fix formatting of the parameters too. Signed-off-by: Richard Purdie --- meta/classes/package.bbclass | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass index df5206bda9e..be76b30f31c 100644 --- a/meta/classes/package.bbclass +++ b/meta/classes/package.bbclass @@ -1575,7 +1575,7 @@ SHLIBSWORKDIR = "${PKGDESTWORK}/${MLPREFIX}shlibs2" python package_do_shlibs() { import re, pipes -import subprocess as sub +import subprocess exclude_shlibs = d.getVar('EXCLUDE_FROM_SHLIBS', False) if exclude_shlibs: @@ -1677,7 +1677,7 @@ python package_do_shlibs() { sonames.add(prov) if file.endswith('.dylib') or file.endswith('.so'): rpath = [] -p = sub.Popen([d.expand("${HOST_PREFIX}otool"), '-l', file],stdout=sub.PIPE,stderr=sub.PIPE) +p = subprocess.Popen([d.expand("${HOST_PREFIX}otool"), '-l', file], stdout=subprocess.PIPE, stderr=subprocess.PIPE) out, err = p.communicate() # If returned successfully, process stdout for results if p.returncode == 0: @@ -1686,7 +1686,7 @@ python package_do_shlibs() { if l.startswith('path '): rpath.append(l.split()[1]) -p = sub.Popen([d.expand("${HOST_PREFIX}otool"), '-L', file],stdout=sub.PIPE,stderr=sub.PIPE) +p = subprocess.Popen([d.expand("${HOST_PREFIX}otool"), '-L', file], stdout=subprocess.PIPE, stderr=subprocess.PIPE) out, err = p.communicate() # If returned successfully, process stdout for results if p.returncode == 0: @@ -1710,7 +1710,7 @@ python package_do_shlibs() { if (file.endswith(".dll") or file.endswith(".exe")): # use objdump to search for "DLL Name: .*\.dll" -p = sub.Popen([d.expand("${HOST_PREFIX}objdump"), "-p", file], stdout = sub.PIPE, stderr= sub.PIPE) +p = subprocess.Popen([d.expand("${HOST_PREFIX}objdump"), "-p", file], stdout=subprocess.PIPE, stderr=subprocess.PIPE) out, err = p.communicate() # process the output, grabbing all .dll names if p.returncode == 0: -- 2.17.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/6] license_image: Fix race
The current code pokes into do_deploy manifests from do_image_complete when the do_image_complete task may or may not depend upon the do_deploy tasks in question. Often it gets lucky, sometimes it results in build failures. To fix this, split the functionality to its own task which can have the correct task dependencies. This means the data in BB_TASKDEPDATA is definitive, the other code can be dropped, as can the IMAGE_EXTRATYPES do_populate_lic dependencies from image.bbclass. This fixes bugs which show up as: NOTE: recipe linux-yocto-4.14.48+gitAUTOINC+d64aec9793_97c8063d2d-r0: task do_deploy: Started ERROR: core-image-minimal-1.0-r0 do_image_complete: Error executing a python function in exec_python_func() autogenerated: The stack trace of python calls that resulted in this exception/failure was: File: 'exec_python_func() autogenerated', lineno: 2, function: 0001: *** 0002:write_deploy_manifest(d) 0003: File: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/classes/license.bbclass', lineno: 33, function: write_deploy_manifest 0029:'w+').write(output) 0030:} 0031: 0032:python write_deploy_manifest() { *** 0033:license_deployed_manifest(d) 0034:} 0035: 0036:python license_create_manifest() { 0037:import oe.packagedata File: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/classes/license.bbclass', lineno: 191, function: license_deployed_manifest 0187:# It is necessary to mark this will be used for image manifest 0188:man_dic[dep]["IMAGE_MANIFEST"] = True 0189:man_dic[dep]["PN"] = dep 0190:man_dic[dep]["FILES"] = \ *** 0191:" ".join(get_deployed_files(dep_dic[dep])) 0192:with open(os.path.join(lic_dir, dep, "recipeinfo"), "r") as f: 0193:for line in f.readlines(): 0194:key,val = line.split(": ", 1) 0195:man_dic[dep][key] = val[:-1] File: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/classes/license.bbclass', lineno: 289, function: get_deployed_files 0285:""" 0286: 0287:dep_files = [] 0288:excluded_files = [] *** 0289:with open(man_file, "r") as manifest: 0290:all_files = manifest.read() 0291:for f in all_files.splitlines(): 0292:if ((not (os.path.islink(f) or os.path.isdir(f))) and 0293:not os.path.basename(f) in excluded_files): Exception: FileNotFoundError: [Errno 2] No such file or directory: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/build-st-730/tmp/sstate-control/manifest-qemux86_64-linux-yocto.deploy' ERROR: core-image-minimal-1.0-r0 do_image_complete: Function failed: write_deploy_manifest ERROR: Logfile of failure stored in: /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/build-st-730/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/temp/log.do_image_complete.50537 NOTE: recipe core-image-minimal-1.0-r0: task do_image_complete: Failed ERROR: Task (/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/recipes-core/images/core-image-minimal.bb:do_image_complete) failed with exit code '1' NOTE: recipe linux-yocto-4.14.48+gitAUTOINC+d64aec9793_97c8063d2d-r0: task do_deploy: Succeeded Signed-off-by: Richard Purdie --- meta/classes/image.bbclass | 1 - meta/classes/license_image.bbclass | 58 -- 2 files changed, 6 insertions(+), 53 deletions(-) diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass index adc50c99bcd..c3e73676dca 100644 --- a/meta/classes/image.bbclass +++ b/meta/classes/image.bbclass @@ -141,7 +141,6 @@ python () { deps += " %s:%s" % (dep, task) return deps -d.appendVarFlag('do_image', 'depends', extraimage_getdepends('do_populate_lic')) d.appendVarFlag('do_image_complete', 'depends', extraimage_getdepends('do_populate_sysroot')) deps = " " + imagetypes_getdepends(d) diff --git a/meta/classes/license_image.bbclass b/meta/classes/license_image.bbclass index efeedce519f..f0fbb763f1d 100644 --- a/meta/classes/license_image.bbclass +++ b/meta/classes/license_image.bbclass @@ -11,10 +11,6 @@ python write_package_manifest() { 'w+').write(output) } -python write_deploy_manifest() { -license_deployed_manifest(d) -} - python license_create_manifest() { import oe.packagedata from oe.rootfs import image_list_installed_packages @@ -197,11 +193,6 @@ def get_deployed_dependencies(d): depends = list(set([dep[0] for dep in list(taskdata.values()) if not dep[0].endswith("-native")])) -extra_depends = d.getVar("EXTRA_IMAGEDEPENDS") -boot_depends = get_boot_dependencies(d) -depends.extend(extra_depends.split()) -depends.extend(b
[OE-core] [PATCH 4/6] license: Split image license functions to a separate class
This means the image code is only included in image recipes through the IMAGE_CLASSES variable. This sets things up to allow us to fix image deploy dependency problems. Signed-off-by: Richard Purdie --- meta/classes/license.bbclass | 284 + meta/classes/license_image.bbclass | 284 + 2 files changed, 285 insertions(+), 283 deletions(-) create mode 100644 meta/classes/license_image.bbclass diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass index 141af5de4d3..2ac15a1bc89 100644 --- a/meta/classes/license.bbclass +++ b/meta/classes/license.bbclass @@ -16,284 +16,6 @@ addtask populate_lic after do_patch before do_build do_populate_lic[dirs] = "${LICSSTATEDIR}/${PN}" do_populate_lic[cleandirs] = "${LICSSTATEDIR}" -python write_package_manifest() { -# Get list of installed packages -license_image_dir = d.expand('${LICENSE_DIRECTORY}/${IMAGE_NAME}') -bb.utils.mkdirhier(license_image_dir) -from oe.rootfs import image_list_installed_packages -from oe.utils import format_pkg_list - -pkgs = image_list_installed_packages(d) -output = format_pkg_list(pkgs) -open(os.path.join(license_image_dir, 'package.manifest'), -'w+').write(output) -} - -python write_deploy_manifest() { -license_deployed_manifest(d) -} - -python license_create_manifest() { -import oe.packagedata -from oe.rootfs import image_list_installed_packages - -build_images_from_feeds = d.getVar('BUILD_IMAGES_FROM_FEEDS') -if build_images_from_feeds == "1": -return 0 - -pkg_dic = {} -for pkg in sorted(image_list_installed_packages(d)): -pkg_info = os.path.join(d.getVar('PKGDATA_DIR'), -'runtime-reverse', pkg) -pkg_name = os.path.basename(os.readlink(pkg_info)) - -pkg_dic[pkg_name] = oe.packagedata.read_pkgdatafile(pkg_info) -if not "LICENSE" in pkg_dic[pkg_name].keys(): -pkg_lic_name = "LICENSE_" + pkg_name -pkg_dic[pkg_name]["LICENSE"] = pkg_dic[pkg_name][pkg_lic_name] - -rootfs_license_manifest = os.path.join(d.getVar('LICENSE_DIRECTORY'), -d.getVar('IMAGE_NAME'), 'license.manifest') -write_license_files(d, rootfs_license_manifest, pkg_dic) -} - -def write_license_files(d, license_manifest, pkg_dic): -import re - -bad_licenses = (d.getVar("INCOMPATIBLE_LICENSE") or "").split() -bad_licenses = map(lambda l: canonical_license(d, l), bad_licenses) -bad_licenses = expand_wildcard_licenses(d, bad_licenses) - -with open(license_manifest, "w") as license_file: -for pkg in sorted(pkg_dic): -if bad_licenses: -try: -(pkg_dic[pkg]["LICENSE"], pkg_dic[pkg]["LICENSES"]) = \ -oe.license.manifest_licenses(pkg_dic[pkg]["LICENSE"], -bad_licenses, canonical_license, d) -except oe.license.LicenseError as exc: -bb.fatal('%s: %s' % (d.getVar('P'), exc)) -else: -pkg_dic[pkg]["LICENSES"] = re.sub('[|&()*]', ' ', pkg_dic[pkg]["LICENSE"]) -pkg_dic[pkg]["LICENSES"] = re.sub(' *', ' ', pkg_dic[pkg]["LICENSES"]) -pkg_dic[pkg]["LICENSES"] = pkg_dic[pkg]["LICENSES"].split() - -if not "IMAGE_MANIFEST" in pkg_dic[pkg]: -# Rootfs manifest -license_file.write("PACKAGE NAME: %s\n" % pkg) -license_file.write("PACKAGE VERSION: %s\n" % pkg_dic[pkg]["PV"]) -license_file.write("RECIPE NAME: %s\n" % pkg_dic[pkg]["PN"]) -license_file.write("LICENSE: %s\n\n" % pkg_dic[pkg]["LICENSE"]) - -# If the package doesn't contain any file, that is, its size is 0, the license -# isn't relevant as far as the final image is concerned. So doing license check -# doesn't make much sense, skip it. -if pkg_dic[pkg]["PKGSIZE_%s" % pkg] == "0": -continue -else: -# Image manifest -license_file.write("RECIPE NAME: %s\n" % pkg_dic[pkg]["PN"]) -license_file.write("VERSION: %s\n" % pkg_dic[pkg]["PV"]) -license_file.write("LICENSE: %s\n" % pkg_dic[pkg]["LICENSE"]) -license_file.write("FILES: %s\n\n" % pkg_dic[pkg]["FILES"]) - -for lic in pkg_dic[pkg]["LICENSES"]: -lic_file = os.path.join(d.getVar('LICENSE_DIRECTORY'), -pkg_dic[pkg]["PN"], "generic_%s" % -re.sub('\+', '', lic)) -# add explicity avoid of CLOSED license because isn't generic -if lic == "CLOSED": - continue - -if not os.path.exists(lic_file): - bb.warn("The license listed %s was not in the "\ -
[OE-core] [PATCH 6/6] uninative-tarball: Add nativesdk-libnss-nis to resolve glibc symbol issues
We need this to avoid symbol mismatch issues for binaries that use this on newer systems which then won't run on older ones where it isn't present. Signed-off-by: Richard Purdie --- meta/recipes-core/meta/uninative-tarball.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-core/meta/uninative-tarball.bb b/meta/recipes-core/meta/uninative-tarball.bb index c38c2a445e9..e0cb9ffee0d 100644 --- a/meta/recipes-core/meta/uninative-tarball.bb +++ b/meta/recipes-core/meta/uninative-tarball.bb @@ -16,6 +16,7 @@ TOOLCHAIN_HOST_TASK = "\ nativesdk-glibc-gconv-libjis \ nativesdk-patchelf \ nativesdk-libxcrypt \ +nativesdk-libnss-nis \ " INHIBIT_DEFAULT_DEPS = "1" -- 2.17.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v5 1/6] gstreamer1.0-plugin-base: Update packageconfigs
* Add patches for gbm, libpng, libjpeg to conditionally enable/disable them in the configure script * Reorder the packageconfigs alphabetically Signed-off-by: Carlos Rafael Giani --- ...r-explicitely-enabling-disabling-GBM.patch | 70 +++ ...for-explicitely-enabling-disabling-P.patch | 109 ++ .../gstreamer1.0-plugins-base_1.14.1.bb | 24 ++-- 3 files changed, 194 insertions(+), 9 deletions(-) create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0010-gl-Add-switch-for-explicitely-enabling-disabling-GBM.patch create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0011-gl-Add-switches-for-explicitely-enabling-disabling-P.patch diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0010-gl-Add-switch-for-explicitely-enabling-disabling-GBM.patch b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0010-gl-Add-switch-for-explicitely-enabling-disabling-GBM.patch new file mode 100644 index 00..45ba50750d --- /dev/null +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0010-gl-Add-switch-for-explicitely-enabling-disabling-GBM.patch @@ -0,0 +1,70 @@ +From a1b59ca6b1781442f37ffc1b697635db126b3a22 Mon Sep 17 00:00:00 2001 +From: Carlos Rafael Giani +Date: Thu, 19 Jul 2018 10:30:54 +0200 +Subject: [PATCH] gl: Add switch for explicitely enabling/disabling GBM support + +Upstream-Status: Submitted [https://bugzilla.gnome.org/show_bug.cgi?id=796833] + +Signed-off-by: Carlos Rafael Giani +--- + m4/gst-gl.m4 | 30 -- + 1 file changed, 28 insertions(+), 2 deletions(-) + +diff --git a/m4/gst-gl.m4 b/m4/gst-gl.m4 +index 1e9724094..aca5295cc 100644 +--- a/m4/gst-gl.m4 b/m4/gst-gl.m4 +@@ -117,6 +117,15 @@ AC_ARG_ENABLE([dispmanx], +*) AC_MSG_ERROR([bad value ${enableval} for --enable-dispmanx]) ;; + esac],[NEED_DISPMANX=auto]) + ++AC_ARG_ENABLE([gbm], ++ [ --enable-gbmEnable Mesa3D GBM support (requires EGL) @<:@default=auto@:>@], ++ [case "${enableval}" in ++ yes) NEED_GBM=yes ;; ++ no) NEED_GBM=no ;; ++ auto) NEED_GBM=auto ;; ++ *) AC_MSG_ERROR([bad value ${enableval} for --enable-gbm]) ;; ++ esac],[NEED_GBM=auto]) ++ + AG_GST_PKG_CHECK_MODULES(X11_XCB, x11-xcb) + save_CPPFLAGS="$CPPFLAGS" + save_LIBS="$LIBS" +@@ -172,15 +181,32 @@ case $host in + AC_CHECK_LIB([EGL], [fbGetDisplay], [HAVE_VIV_FB_EGL=yes]) + fi + +-if test "x$HAVE_EGL" = "xyes"; then ++if test "x$NEED_GBM" != "xno"; then ++ if test "x$HAVE_EGL" = "xyes"; then + PKG_CHECK_MODULES(DRM, libdrm >= 2.4.55, HAVE_DRM=yes, HAVE_DRM=no) + AC_SUBST(DRM_CFLAGS) + AC_SUBST(DRM_LIBS) ++if test "x$NEED_GBM" = "xyes"; then ++ if test "x$HAVE_DRM" = "xno"; then ++AC_MSG_ERROR([GBM support requested but libdrm is not available]) ++ fi ++ if test "x$HAVE_GUDEV" = "xno"; then ++AC_MSG_ERROR([GBM support requested but gudev is not available]) ++ fi ++fi + if test "x$HAVE_DRM" = "xyes" -a "x$HAVE_GUDEV" = "xyes"; then + PKG_CHECK_MODULES(GBM, gbm, HAVE_GBM_EGL=yes, HAVE_GBM_EGL=no) ++ if test "x$HAVE_GBM_EGL" = "xno" -a "x$NEED_GBM" = "xyes"; then ++AC_MSG_ERROR([GBM support requested but gbm library is not available]) ++ fi + AC_SUBST(GBM_CFLAGS) + AC_SUBST(GBM_LIBS) +- fi ++fi ++ elif test "x$NEED_GBM" = "xyes"; then ++AC_MSG_ERROR([GBM support requested but EGL is not available]) ++ else ++AC_MSG_NOTICE([GBM support requested but EGL is not available; not enabling GBM support]) ++ fi + fi + + dnl FIXME: Mali EGL depends on GLESv1 or GLESv2 +-- +2.17.1 + diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0011-gl-Add-switches-for-explicitely-enabling-disabling-P.patch b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0011-gl-Add-switches-for-explicitely-enabling-disabling-P.patch new file mode 100644 index 00..65d191a396 --- /dev/null +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0011-gl-Add-switches-for-explicitely-enabling-disabling-P.patch @@ -0,0 +1,109 @@ +From 092aadfc1df69c46d920b0cd39f98d363d6988b3 Mon Sep 17 00:00:00 2001 +From: Carlos Rafael Giani +Date: Thu, 19 Jul 2018 11:16:05 +0200 +Subject: [PATCH] gl: Add switches for explicitely enabling/disabling PNG and + JPEG support + +Upstream-Status: Submitted [https://bugzilla.gnome.org/show_bug.cgi?id=796833] + +Signed-off-by: Carlos Rafael Giani +--- + m4/gst-gl.m4 | 66 + 1 file changed, 46 insertions(+), 20 deletions(-) + +diff --git a/m4/gst-gl.m4 b/m4/gst-gl.m4 +index 20b2233de..f8809981c 100644 +--- a/m4/gst-gl.m4 b/m4/gst-gl.m4 +@@ -126,6 +126,24 @@ AC_ARG_ENABLE([gbm], +*) AC_MSG_ERROR([bad value ${
[OE-core] [PATCH v5 5/6] gstreamer1.0-vaapi: Add patch for EGL CFLAGS for proper EGL support
Signed-off-by: Carlos Rafael Giani --- ...le.am-Add-EGL_CFLAGS-to-libgstvaapi-.patch | 33 +++ .../gstreamer/gstreamer1.0-vaapi_1.14.1.bb| 1 + 2 files changed, 34 insertions(+) create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-gst-vaapi-Makefile.am-Add-EGL_CFLAGS-to-libgstvaapi-.patch diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-gst-vaapi-Makefile.am-Add-EGL_CFLAGS-to-libgstvaapi-.patch b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-gst-vaapi-Makefile.am-Add-EGL_CFLAGS-to-libgstvaapi-.patch new file mode 100644 index 00..d7b8984953 --- /dev/null +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-gst-vaapi-Makefile.am-Add-EGL_CFLAGS-to-libgstvaapi-.patch @@ -0,0 +1,33 @@ +From 5403a89e6a7ac72a23e0221075c0c19b5f85a021 Mon Sep 17 00:00:00 2001 +From: Fabio Berton +Date: Wed, 13 Jun 2018 09:09:25 -0300 +Subject: [PATCH] gst/vaapi/Makefile.am: Add EGL_CFLAGS to libgstvaapi CFLAGS +Organization: O.S. Systems Software LTDA. + +We need this to pass correctly EGL CFLAGS when building with EGL support. + +Upstream-Status: Pending + +Signed-off-by: Fabio Berton +--- + gst/vaapi/Makefile.am | 4 + 1 file changed, 4 insertions(+) + +diff --git a/gst/vaapi/Makefile.am b/gst/vaapi/Makefile.am +index b299ac98..d6cab71f 100644 +--- a/gst/vaapi/Makefile.am b/gst/vaapi/Makefile.am +@@ -24,6 +24,10 @@ libgstvaapi_LIBS += $(top_builddir)/gst-libs/gst/vaapi/libgstvaapi-glx.la + endif + + if USE_EGL ++libgstvaapi_CFLAGS += \ ++ $(EGL_CFLAGS) \ ++ $(NULL) ++ + libgstvaapi_LIBS += $(top_builddir)/gst-libs/gst/vaapi/libgstvaapi-egl.la + endif + +-- +2.17.1 + diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb index e647458fab..63290326a5 100644 --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb @@ -9,6 +9,7 @@ LICENSE = "LGPLv2.1+" LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=4fbd65380cdd255951079008b364516c" SRC_URI = "https://gstreamer.freedesktop.org/src/${REALPN}/${REALPN}-${PV}.tar.xz \ + file://0001-gst-vaapi-Makefile.am-Add-EGL_CFLAGS-to-libgstvaapi-.patch \ " SRC_URI[md5sum] = "38c5b2390797b7a0a269a5ab6c8cbe8f" -- 2.17.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v5 4/6] gstreamer1.0-vaapi: Remove unnecessary FILESPATH modification
Signed-off-by: Carlos Rafael Giani --- meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb | 1 - 1 file changed, 1 deletion(-) diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb index 906dc6e6c4..e647458fab 100644 --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb @@ -4,7 +4,6 @@ based plugins for GStreamer and helper libraries: `vaapidecode', \ `vaapiconvert', and `vaapisink'." REALPN = "gstreamer-vaapi" -FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${REALPN}", "${FILE_DIRNAME}/${REALPN}"], d)}" LICENSE = "LGPLv2.1+" LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=4fbd65380cdd255951079008b364516c" -- 2.17.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/6] selftest/wic: clean up runCmd error code handling
runCmd handles checking exit 0 internally unless specified otherwise and its error messages are much more useful including the failed command output. Clean up the unneeded 0 exit code checks in the wic tests. Signed-off-by: Richard Purdie --- meta/lib/oeqa/selftest/cases/wic.py | 192 1 file changed, 82 insertions(+), 110 deletions(-) diff --git a/meta/lib/oeqa/selftest/cases/wic.py b/meta/lib/oeqa/selftest/cases/wic.py index 6793efb62e9..cfee9d1e71d 100644 --- a/meta/lib/oeqa/selftest/cases/wic.py +++ b/meta/lib/oeqa/selftest/cases/wic.py @@ -99,58 +99,58 @@ class Wic(WicTestCase): @OETestID(1552) def test_version(self): """Test wic --version""" -self.assertEqual(0, runCmd('wic --version').status) +runCmd('wic --version') @OETestID(1208) def test_help(self): """Test wic --help and wic -h""" -self.assertEqual(0, runCmd('wic --help').status) -self.assertEqual(0, runCmd('wic -h').status) +runCmd('wic --help') +runCmd('wic -h') @OETestID(1209) def test_createhelp(self): """Test wic create --help""" -self.assertEqual(0, runCmd('wic create --help').status) +runCmd('wic create --help') @OETestID(1210) def test_listhelp(self): """Test wic list --help""" -self.assertEqual(0, runCmd('wic list --help').status) +runCmd('wic list --help') @OETestID(1553) def test_help_create(self): """Test wic help create""" -self.assertEqual(0, runCmd('wic help create').status) +runCmd('wic help create') @OETestID(1554) def test_help_list(self): """Test wic help list""" -self.assertEqual(0, runCmd('wic help list').status) +runCmd('wic help list') @OETestID(1215) def test_help_overview(self): """Test wic help overview""" -self.assertEqual(0, runCmd('wic help overview').status) +runCmd('wic help overview') @OETestID(1216) def test_help_plugins(self): """Test wic help plugins""" -self.assertEqual(0, runCmd('wic help plugins').status) +runCmd('wic help plugins') @OETestID(1217) def test_help_kickstart(self): """Test wic help kickstart""" -self.assertEqual(0, runCmd('wic help kickstart').status) +runCmd('wic help kickstart') @OETestID(1555) def test_list_images(self): """Test wic list images""" -self.assertEqual(0, runCmd('wic list images').status) +runCmd('wic list images') @OETestID(1556) def test_list_source_plugins(self): """Test wic list source-plugins""" -self.assertEqual(0, runCmd('wic list source-plugins').status) +runCmd('wic list source-plugins') @OETestID(1557) def test_listed_images_help(self): @@ -158,7 +158,7 @@ class Wic(WicTestCase): output = runCmd('wic list images').output imagelist = [line.split()[0] for line in output.splitlines()] for image in imagelist: -self.assertEqual(0, runCmd('wic list %s help' % image).status) +runCmd('wic list %s help' % image) @OETestID(1213) def test_unsupported_subcommand(self): @@ -174,7 +174,7 @@ class Wic(WicTestCase): def test_build_image_name(self): """Test wic create wictestdisk --image-name=core-image-minimal""" cmd = "wic create wictestdisk --image-name=core-image-minimal -o %s" % self.resultdir -self.assertEqual(0, runCmd(cmd).status) +runCmd(cmd) self.assertEqual(1, len(glob(self.resultdir + "wictestdisk-*.direct"))) @OETestID(1157) @@ -182,7 +182,7 @@ class Wic(WicTestCase): def test_gpt_image(self): """Test creation of core-image-minimal with gpt table and UUID boot""" cmd = "wic create directdisk-gpt --image-name core-image-minimal -o %s" % self.resultdir -self.assertEqual(0, runCmd(cmd).status) +runCmd(cmd) self.assertEqual(1, len(glob(self.resultdir + "directdisk-*.direct"))) @OETestID(1346) @@ -196,7 +196,7 @@ class Wic(WicTestCase): bitbake('core-image-minimal core-image-minimal-initramfs') self.remove_config(config) cmd = "wic create mkhybridiso --image-name core-image-minimal -o %s" % self.resultdir -self.assertEqual(0, runCmd(cmd).status) +runCmd(cmd) self.assertEqual(1, len(glob(self.resultdir + "HYBRID_ISO_IMG-*.direct"))) self.assertEqual(1, len(glob(self.resultdir + "HYBRID_ISO_IMG-*.iso"))) @@ -205,7 +205,7 @@ class Wic(WicTestCase): def test_qemux86_directdisk(self): """Test creation of qemux-86-directdisk image""" cmd = "wic create qemux86-directdisk -e core-image-minimal -o %s" % self.resultdir -self.assertEqual(0, runCmd(cmd).status) +runCmd(cmd) self.assertEqual(1, len(glob(self.resultdir + "qemux86-directdisk-*direct
[OE-core] [PATCH 1/6] selftest/wic: Improve error message got test_fixed_size
Currently this can fail with a message like 127 != 0 which is unhelpful. If we remove the ignore_status=False, the debugging from runCmd is much more helpful printing status.output. Also remove the now unneeded exit code check. Signed-off-by: Richard Purdie --- meta/lib/oeqa/selftest/cases/wic.py | 2 -- 1 file changed, 2 deletions(-) diff --git a/meta/lib/oeqa/selftest/cases/wic.py b/meta/lib/oeqa/selftest/cases/wic.py index ba4d3be7a86..6793efb62e9 100644 --- a/meta/lib/oeqa/selftest/cases/wic.py +++ b/meta/lib/oeqa/selftest/cases/wic.py @@ -695,9 +695,7 @@ class Wic2(WicTestCase): # verify partition size with wic res = runCmd("parted -m %s unit mib p 2>/dev/null" % wicimg, - ignore_status=True, native_sysroot=self.native_sysroot) -self.assertEqual(0, res.status) # parse parted output which looks like this: # BYT;\n -- 2.17.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v5 6/6] gstreamer1.0-libav: Replace German umlaut to avoid parsing problems
The umlaut can cause issues related to encoding; avoid by replacing it Signed-off-by: Carlos Rafael Giani --- .../workaround-to-build-gst-libav-for-i586-with-gcc.patch | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch index 36abf8607e..5355480aa4 100644 --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch @@ -1,5 +1,5 @@ Description: Workaround to build libav for i586 with gcc 4.9.2 by avoiding memset -Author: Bernhard Übelacker +Author: Bernhard Uebelacker --- Bug-Debian: https://bugs.debian.org/783082 -- 2.17.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v5 3/6] gstreamer1.0-plugin-bad: Update packageconfigs
* Add packageconfigs for gl, libde265, lcms2, openh264, tinyalsa, ttml, webrtc, webrtcdsp * Remove unnecessary gstglconfig.h line, since that file is no longer part of -bad (it is in -base now) * Update EXTRA_OECONF flags, since new plugins got added to -bad * Add ttml to the default packageconfigs since its dependencies are all in oe-core Signed-off-by: Carlos Rafael Giani --- .../gstreamer1.0-plugins-bad_1.14.1.bb| 30 +-- 1 file changed, 21 insertions(+), 9 deletions(-) diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.14.1.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.14.1.bb index 0e477e5a9c..64d565135b 100644 --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.14.1.bb +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.14.1.bb @@ -27,9 +27,14 @@ PACKAGECONFIG ??= " \ ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez', '', d)} \ ${@bb.utils.filter('DISTRO_FEATURES', 'directfb vulkan', d)} \ ${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'wayland', '', d)} \ -bz2 curl dash dtls hls rsvg sbc smoothstreaming sndfile uvch264 webp \ +${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'gl', '', d)} \ +bz2 curl dash dtls hls rsvg sbc smoothstreaming sndfile ttml uvch264 webp \ " +# the gl packageconfig enables OpenGL elements that haven't been ported +# to -base yet. They depend on the gstgl library in -base, so we do +# not add GL dependencies here, since these are taken care of in -base. + PACKAGECONFIG[assrender] = "--enable-assrender,--disable-assrender,libass" PACKAGECONFIG[bluez] = "--enable-bluez,--disable-bluez,${BLUEZ}" PACKAGECONFIG[bz2] = "--enable-bz2,--disable-bz2,bzip2" @@ -43,13 +48,17 @@ PACKAGECONFIG[faad]= "--enable-faad,--disable-faad,faad2" PACKAGECONFIG[flite] = "--enable-flite,--disable-flite,flite-alsa" PACKAGECONFIG[fluidsynth] = "--enable-fluidsynth,--disable-fluidsynth,fluidsynth" PACKAGECONFIG[hls] = "--enable-hls --with-hls-crypto=nettle,--disable-hls,nettle" +PACKAGECONFIG[gl] = "--enable-gl,--disable-gl," PACKAGECONFIG[kms] = "--enable-kms,--disable-kms,libdrm" +PACKAGECONFIG[libde265]= "--enable-libde265,--disable-libde265,libde265" PACKAGECONFIG[libmms] = "--enable-libmms,--disable-libmms,libmms" PACKAGECONFIG[libssh2] = "--enable-libssh2,--disable-libssh2,libssh2" +PACKAGECONFIG[lcms2] = "--enable-lcms2,--disable-lcms2,lcms" PACKAGECONFIG[modplug] = "--enable-modplug,--disable-modplug,libmodplug" PACKAGECONFIG[neon]= "--enable-neon,--disable-neon,neon" PACKAGECONFIG[openal] = "--enable-openal,--disable-openal,openal-soft" PACKAGECONFIG[opencv] = "--enable-opencv,--disable-opencv,opencv" +PACKAGECONFIG[openh264]= "--enable-openh264,--disable-openh264,openh264" PACKAGECONFIG[openjpeg]= "--enable-openjpeg,--disable-openjpeg,openjpeg" # the opus encoder/decoder elements are now in the -base package, # but the opus parser remains in -bad @@ -61,28 +70,34 @@ PACKAGECONFIG[sbc] = "--enable-sbc,--disable-sbc,sbc" PACKAGECONFIG[smoothstreaming] = "--enable-smoothstreaming,--disable-smoothstreaming,libxml2" PACKAGECONFIG[sndfile] = "--enable-sndfile,--disable-sndfile,libsndfile1" PACKAGECONFIG[srtp]= "--enable-srtp,--disable-srtp,libsrtp" +PACKAGECONFIG[tinyalsa]= "--enable-tinyalsa,--disable-tinyalsa,tinyalsa" +PACKAGECONFIG[ttml]= "--enable-ttml,--disable-ttml,libxml2 pango cairo" PACKAGECONFIG[uvch264] = "--enable-uvch264,--disable-uvch264,libusb1 libgudev" PACKAGECONFIG[voaacenc]= "--enable-voaacenc,--disable-voaacenc,vo-aacenc" PACKAGECONFIG[voamrwbenc] = "--enable-voamrwbenc,--disable-voamrwbenc,vo-amrwbenc" PACKAGECONFIG[vulkan] = "--enable-vulkan,--disable-vulkan,vulkan" PACKAGECONFIG[wayland] = "--enable-wayland,--disable-wayland,wayland-native wayland wayland-protocols libdrm" PACKAGECONFIG[webp]= "--enable-webp,--disable-webp,libwebp" +PACKAGECONFIG[webrtc] = "--enable-webrtc,--disable-webrtc,libnice" +PACKAGECONFIG[webrtcdsp] = "--enable-webrtcdsp,--disable-webrtcdsp,webrtc-audio-processing" # these plugins have no corresponding library in OE-core or meta-openembedded: # openni2 winks direct3d directsound winscreencap acm apple_media iqa -# android_media avc bs2b chromaprint daala dts fdkaac gme gsm kate ladspa libde265 -# lv2 mpeg2enc mplex msdk musepack nvenc ofa openh264 opensles soundtouch spandsp -# spc teletextdec tinyalsa vdpau wasapi x265 zbar webrtcdsp +# android_media avc bs2b chromaprint daala dts fdkaac gme gsm kate ladspa +# lv2 mpeg2enc mplex msdk musepack nvenc ofa openmpt opensles soundtouch +# spandsp spc teletextdec vdpau wasapi x265 zbar EXTRA_OEC
[OE-core] [PATCH v5 2/6] gstreamer1.0-plugin-good: Update packageconfigs
* There is no twolame recipe in oe-core or in meta-openembedded, so disable it * Reorder the packageconfigs alphabetically Signed-off-by: Carlos Rafael Giani --- .../gstreamer/gstreamer1.0-plugins-good_1.14.1.bb | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.14.1.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.14.1.bb index 673bf10918..b80cd129be 100644 --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.14.1.bb +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.14.1.bb @@ -27,20 +27,24 @@ inherit gettext PACKAGECONFIG ??= " \ ${GSTREAMER_ORC} \ ${@bb.utils.filter('DISTRO_FEATURES', 'pulseaudio x11', d)} \ -cairo flac gdk-pixbuf gudev jpeg libpng soup speex taglib v4l2 bz2 zlib mpg123 lame \ +bz2 cairo flac gdk-pixbuf gudev jpeg lame libpng mpg123 soup speex taglib v4l2 zlib \ " X11DEPENDS = "virtual/libx11 libsm libxrender libxfixes libxdamage" +PACKAGECONFIG[bz2]= "--enable-bz2,--disable-bz2,bzip2" PACKAGECONFIG[cairo] = "--enable-cairo,--disable-cairo,cairo" PACKAGECONFIG[dv1394] = "--enable-dv1394,--disable-dv1394,libiec61883 libavc1394 libraw1394" PACKAGECONFIG[flac] = "--enable-flac,--disable-flac,flac" PACKAGECONFIG[gdk-pixbuf] = "--enable-gdk_pixbuf,--disable-gdk_pixbuf,gdk-pixbuf" +PACKAGECONFIG[gtk]= "--enable-gtk3,--disable-gtk3,gtk+3" PACKAGECONFIG[gudev] = "--with-gudev,--without-gudev,libgudev" PACKAGECONFIG[jack] = "--enable-jack,--disable-jack,jack" PACKAGECONFIG[jpeg] = "--enable-jpeg,--disable-jpeg,jpeg" +PACKAGECONFIG[lame] = "--enable-lame,--disable-lame,lame" PACKAGECONFIG[libpng] = "--enable-libpng,--disable-libpng,libpng" PACKAGECONFIG[libv4l2]= "--with-libv4l2,--without-libv4l2,v4l-utils" +PACKAGECONFIG[mpg123] = "--enable-mpg123,--disable-mpg123,mpg123" PACKAGECONFIG[pulseaudio] = "--enable-pulse,--disable-pulse,pulseaudio" PACKAGECONFIG[soup] = "--enable-soup,--disable-soup,libsoup-2.4" PACKAGECONFIG[speex] = "--enable-speex,--disable-speex,speex" @@ -49,11 +53,7 @@ PACKAGECONFIG[v4l2] = "--enable-gst_v4l2 --enable-v4l2-probe,--disable-gst PACKAGECONFIG[vpx]= "--enable-vpx,--disable-vpx,libvpx" PACKAGECONFIG[wavpack]= "--enable-wavpack,--disable-wavpack,wavpack" PACKAGECONFIG[x11]= "--enable-x,--disable-x,${X11DEPENDS}" -PACKAGECONFIG[bz2]= "--enable-bz2,--disable-bz2,bzip2" PACKAGECONFIG[zlib] = "--enable-zlib,--disable-zlib,zlib" -PACKAGECONFIG[lame] = "--enable-lame,--disable-lame,lame" -PACKAGECONFIG[mpg123] = "--enable-mpg123,--disable-mpg123,mpg123" -PACKAGECONFIG[gtk]= "--enable-gtk3,--disable-gtk3,gtk+3" # qt5 support is disabled, because it is not present in OE core, and requires more work than # just adding a packageconfig (it requires access to moc, uic, rcc, and qmake paths). @@ -70,9 +70,10 @@ EXTRA_OECONF += " \ --disable-oss4 \ --disable-osx_audio \ --disable-osx_video \ +--disable-qt \ --disable-shout2 \ +--disable-twolame \ --disable-waveform \ ---disable-qt \ " FILES_${PN}-equalizer += "${datadir}/gstreamer-1.0/presets/*.prs" -- 2.17.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] lsof: Update SRC_URI
Also, if an upgrade is undesirable for some reason, then such changes need UPSTREAM_CHECK_URI, or we'll be missing new upstream releases. Alex 2018-07-24 10:07 GMT+02:00 Burton, Ross : > Well for master if there's a new version then a better fix would be to > upgrade, but we do need to make sure the previous releases are using > mirrors. > > On 24 July 2018 at 08:48, Ovidiu Panait wrote: >> lsof 4.89 archive has been moved to OLD directory and turned into tar.gz, >> so update SRC_URI and checksums. >> >> Signed-off-by: Ovidiu Panait >> --- >> meta/recipes-extended/lsof/lsof_4.89.bb | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/meta/recipes-extended/lsof/lsof_4.89.bb >> b/meta/recipes-extended/lsof/lsof_4.89.bb >> index 14546db23c..b58b8281f9 100644 >> --- a/meta/recipes-extended/lsof/lsof_4.89.bb >> +++ b/meta/recipes-extended/lsof/lsof_4.89.bb >> @@ -11,12 +11,12 @@ LIC_FILES_CHKSUM = >> "file://00README;beginline=645;endline=679;md5=964df275d26429 >> # https://people.freebsd.org/~abe/ ). http://www.mirrorservice.org seems to >> be >> # the most commonly used alternative. >> >> -SRC_URI = >> "http://www.mirrorservice.org/sites/lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_${PV}.tar.bz2 >> \ >> +SRC_URI = >> "http://www.mirrorservice.org/sites/lsof.itap.purdue.edu/pub/tools/unix/lsof/OLD/lsof_${PV}.tar.gz >> \ >> file://lsof-remove-host-information.patch \ >>" >> >> -SRC_URI[md5sum] = "1b9cd34f3fb86856a125abbf2be3a386" >> -SRC_URI[sha256sum] = >> "81ac2fc5fdc944793baf41a14002b6deb5a29096b387744e28f8c30a360a3718" >> +SRC_URI[md5sum] = "8afbaff3ee308edc130bdc5df0801c8f" >> +SRC_URI[sha256sum] = >> "5d08da7ebe049c9d9a6472d6afb81aa5af54c4733a3f8822cbc22b57867633c9" >> >> LOCALSRC = "file://${WORKDIR}/lsof_${PV}/lsof_${PV}_src.tar" >> >> -- >> 2.17.1 >> >> -- >> ___ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] coreutils: fix compile error since use wrong libnss_nis.so
Hi RP, On 07/09/2018 04:46 PM, Richard Purdie wrote: On Mon, 2018-07-09 at 15:49 +0800, changqing...@windriver.com wrote: From: Changqing Li id: relocation error: /lib/x86_64-linux-gnu/libnss_nis.so.2: symbol _nsl_default_nss version GLIBC_PRIVATE not defined in file libnsl.so.1 with link time reference Recent glibc change removed libnss-nis module from glibc and a new recipe libnss-nis.bb was added. After this change, we need to include native libnss_nis in coreutils. otherwise, with "nis" in host /etc/nssswitch.conf, id will use host libnss_nis.so, which will cause above error Signed-off-by: Changqing Li --- meta/recipes-core/coreutils/coreutils_8.29.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) I think this would be fixed by a new version of uninative-tarball after the recent change to include libnss-nis in it. We should probably have a new release of uninative rather than starting to add these DEPENDS everywhere... When do you plan to rebuild uninative-tarball, please ? I can help if needed. // Robert Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] lsof: Update SRC_URI
Well for master if there's a new version then a better fix would be to upgrade, but we do need to make sure the previous releases are using mirrors. On 24 July 2018 at 08:48, Ovidiu Panait wrote: > lsof 4.89 archive has been moved to OLD directory and turned into tar.gz, > so update SRC_URI and checksums. > > Signed-off-by: Ovidiu Panait > --- > meta/recipes-extended/lsof/lsof_4.89.bb | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/meta/recipes-extended/lsof/lsof_4.89.bb > b/meta/recipes-extended/lsof/lsof_4.89.bb > index 14546db23c..b58b8281f9 100644 > --- a/meta/recipes-extended/lsof/lsof_4.89.bb > +++ b/meta/recipes-extended/lsof/lsof_4.89.bb > @@ -11,12 +11,12 @@ LIC_FILES_CHKSUM = > "file://00README;beginline=645;endline=679;md5=964df275d26429 > # https://people.freebsd.org/~abe/ ). http://www.mirrorservice.org seems to > be > # the most commonly used alternative. > > -SRC_URI = > "http://www.mirrorservice.org/sites/lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_${PV}.tar.bz2 > \ > +SRC_URI = > "http://www.mirrorservice.org/sites/lsof.itap.purdue.edu/pub/tools/unix/lsof/OLD/lsof_${PV}.tar.gz > \ > file://lsof-remove-host-information.patch \ >" > > -SRC_URI[md5sum] = "1b9cd34f3fb86856a125abbf2be3a386" > -SRC_URI[sha256sum] = > "81ac2fc5fdc944793baf41a14002b6deb5a29096b387744e28f8c30a360a3718" > +SRC_URI[md5sum] = "8afbaff3ee308edc130bdc5df0801c8f" > +SRC_URI[sha256sum] = > "5d08da7ebe049c9d9a6472d6afb81aa5af54c4733a3f8822cbc22b57867633c9" > > LOCALSRC = "file://${WORKDIR}/lsof_${PV}/lsof_${PV}_src.tar" > > -- > 2.17.1 > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] lsof: Update SRC_URI
lsof 4.89 archive has been moved to OLD directory and turned into tar.gz, so update SRC_URI and checksums. Signed-off-by: Ovidiu Panait --- meta/recipes-extended/lsof/lsof_4.89.bb | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/meta/recipes-extended/lsof/lsof_4.89.bb b/meta/recipes-extended/lsof/lsof_4.89.bb index 14546db23c..b58b8281f9 100644 --- a/meta/recipes-extended/lsof/lsof_4.89.bb +++ b/meta/recipes-extended/lsof/lsof_4.89.bb @@ -11,12 +11,12 @@ LIC_FILES_CHKSUM = "file://00README;beginline=645;endline=679;md5=964df275d26429 # https://people.freebsd.org/~abe/ ). http://www.mirrorservice.org seems to be # the most commonly used alternative. -SRC_URI = "http://www.mirrorservice.org/sites/lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_${PV}.tar.bz2 \ +SRC_URI = "http://www.mirrorservice.org/sites/lsof.itap.purdue.edu/pub/tools/unix/lsof/OLD/lsof_${PV}.tar.gz \ file://lsof-remove-host-information.patch \ " -SRC_URI[md5sum] = "1b9cd34f3fb86856a125abbf2be3a386" -SRC_URI[sha256sum] = "81ac2fc5fdc944793baf41a14002b6deb5a29096b387744e28f8c30a360a3718" +SRC_URI[md5sum] = "8afbaff3ee308edc130bdc5df0801c8f" +SRC_URI[sha256sum] = "5d08da7ebe049c9d9a6472d6afb81aa5af54c4733a3f8822cbc22b57867633c9" LOCALSRC = "file://${WORKDIR}/lsof_${PV}/lsof_${PV}_src.tar" -- 2.17.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] defaultsetup.conf: Enable security flags+pie by default
Hi Khem, The comments in security-flags.inc also needs to be modified to remove 'poky-lsb' info. I'd suggest we still put it into distro conf file (poky.conf) instead of defaultsetup.conf, because defaultsetup.conf is included by bitbake.conf. I think things in defaultsetup.conf should be necessary default values to build things out. I don't think security flags is necessary to build things out. Also, I got a question when I just looked at this file. Do you think we should adjust CFLAGS and LDFALGS in security_flags.inc instead of the current TARGET_CC_ARCH and TARGET_LDFLAGS? We are naming variables to SECURITY_CFLAGS and SECURITY_LDFLAGS, it seems that they belong to CFLAGS and LDFLAGS naturally. But I'm not sure about it. Best Regards, Chen Qi On 07/24/2018 03:09 AM, Khem Raj wrote: This has been an opt-in for so long, some distributions e.g. poky-lsb uses it by default however, since most of linux distros have started to default to these settings for security enhancements, time has come for OE to make it default too Signed-off-by: Khem Raj --- meta/conf/distro/defaultsetup.conf | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/conf/distro/defaultsetup.conf b/meta/conf/distro/defaultsetup.conf index ca2f9178d2..352e279596 100644 --- a/meta/conf/distro/defaultsetup.conf +++ b/meta/conf/distro/defaultsetup.conf @@ -1,6 +1,7 @@ include conf/distro/include/default-providers.inc include conf/distro/include/default-versions.inc include conf/distro/include/default-distrovars.inc +require conf/distro/include/security_flags.inc include conf/distro/include/world-broken.inc TCMODE ?= "default" -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-oe][PATCH] perl: native modules will not trigger build perl for target.
Hello, Example recipe (recipe.bb for example): """ LICENSE="CLOSED" RDEPENDS_${PN} = "perl-module-file-glob" BBCLASSEXTEND = "native nativesdk" do_install() { install -d ${D}/${bindir} echo "my perl script" > ${D}/${bindir}/recipe.pl } inherit perlnative "" When my patch is removed and I will call: "'bitbake recipe-native". Then I have dependency: recipe-native -> perl (target version) This is not correct, that native recipe has dependency to target recipe. When I called (bitbake recipe-native -g) I can find: "recipe-native" -> "perl" in recipe-depends.dot This was my original problem. Please correct me, if missed something. usage of += with an over-ride - I've just copied it from nativesdk over-ride, which was already in perl recipe. Best regards, Krzysztof Taborski 2018-07-23 19:23 GMT+02:00 Andre McCurdy : > On Mon, Jul 23, 2018 at 5:57 AM, Krzysztof Taborski > wrote: > > Change was already merged: > > http://cgit.openembedded.org/openembedded-core/commit/meta/ > recipes-devtools?id=7dd9772eca6df52db09b65537fdf689f1aa3fd8f > > > > Is your request still valid? > > Yes, although the change was merged, it's not clear that it was correct. > > Native recipes aren't split into packages, so there are no -native > versions of the perl modules. If you have a recipe which depends on > "perl-module-XXX-native" it's likely a bug in that recipe - not in > perl-native. > > What recipe did you find which depends on a -native version of a perl > module? > > > 2018-07-09 21:40 GMT+02:00 Andre McCurdy : > >> > >> On Wed, May 9, 2018 at 7:16 AM, taborskikrzysztof > >> wrote: > >> > Can I request review? > >> > Oryginalna wiadomość > >> > Od: Krzysztof Taborski > >> > Data: 08.05.2018 18:46 (GMT+01:00) > >> > Do: openembedded-core@lists.openembedded.org > >> > DW: Krzysztof Taborski > >> > Temat: [meta-oe][PATCH] perl: native modules will not trigger build > perl > >> > for > >> > target. > >> > > >> > Currently building perl-native modules triggers > >> > build perl for target due to PACKAGES_DYNAMIC regex. > >> > > >> > This commit will cause, that perl native modules will > >> > trigger perl-native build. > >> > >> Can you give an example of how to reproduce the problem? > >> > >> > Signed-off-by: Krzysztof Taborski > >> > --- > >> > meta/recipes-devtools/perl/perl-native_5.24.1.bb | 2 ++ > >> > meta/recipes-devtools/perl/perl_5.24.1.bb| 2 +- > >> > 2 files changed, 3 insertions(+), 1 deletion(-) > >> > > >> > diff --git a/meta/recipes-devtools/perl/perl-native_5.24.1.bb > >> > b/meta/recipes-devtools/perl/perl-native_5.24.1.bb > >> > index a9ab17d16c..71f45890b0 100644 > >> > --- a/meta/recipes-devtools/perl/perl-native_5.24.1.bb > >> > +++ b/meta/recipes-devtools/perl/perl-native_5.24.1.bb > >> > @@ -135,3 +135,5 @@ EOF > >> > > >> > # Fix the path in sstate > >> > SSTATE_SCAN_FILES += "*.pm *.pod *.h *.pl *.sh" > >> > +PACKAGES_DYNAMIC_class-native += "^perl-module-.*native$" > >> > >> This usage of += with an over-ride is not correct. > >> > >> However, regardless of that, was this change actually needed? > >> > >> If you know of a -native recipe which depends on a > >> perl-module-XXX-native package then it's probably a bug in the -native > >> recipe. Having perl-native pretend to provide perl-module packages > >> probably isn't the right solution. > >> > >> > diff --git a/meta/recipes-devtools/perl/perl_5.24.1.bb > >> > b/meta/recipes-devtools/perl/perl_5.24.1.bb > >> > index 53a426289a..4c6a71082f 100644 > >> > --- a/meta/recipes-devtools/perl/perl_5.24.1.bb > >> > +++ b/meta/recipes-devtools/perl/perl_5.24.1.bb > >> > @@ -339,7 +339,7 @@ python split_perl_packages () { > >> > d.setVar(d.expand("RRECOMMENDS_${PN}-modules"), ' > '.join(packages)) > >> > } > >> > > >> > -PACKAGES_DYNAMIC += "^perl-module-.*" > >> > +PACKAGES_DYNAMIC += "^perl-module-.*(? >> > PACKAGES_DYNAMIC_class-nativesdk += "^nativesdk-perl-module-.*" > >> > >> This usage of += with an over-ride is not correct. > >> > >> > RPROVIDES_perl-lib = "perl-lib" > >> > -- > >> > 2.13.6 > >> > > >> > > >> > -- > >> > ___ > >> > Openembedded-core mailing list > >> > Openembedded-core@lists.openembedded.org > >> > http://lists.openembedded.org/mailman/listinfo/openembedded-core > >> > > > > > > > > > > > -- > > Pozdrawiam, > > Krzysiek Taborski > -- Pozdrawiam, Krzysiek Taborski -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core