* Re: [PATCH] gstreamer1.0-plugins-bad: Add PKG_CONFIG_SYSROOT_DIR to output of pkg-config
From: Khem Raj @ 2016-12-05 16:46 UTC (permalink / raw)
To: Jussi Kukkonen; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CAHiDW_ERJNEoc4OfTQtV6Bi3UPzQkt9RMPJDUx-RAVJnrj2feA@mail.gmail.com>
On Mon, Dec 5, 2016 at 5:20 AM, Jussi Kukkonen <jussi.kukkonen@intel.com> wrote:
>
>
> On 1 December 2016 at 10:37, Khem Raj <raj.khem@gmail.com> wrote:
>>
>> When configure pokes for wayland-protocols isntallations it ended up
>> using the ones from host, which is because it did not account for sysroot
>> prefix
>>
>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>> ---
>> .../gstreamer/gstreamer1.0-plugins-bad.inc | 2 +-
>> ...G_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch | 37
>> ++++++++++++++++++++++
>> .../gstreamer/gstreamer1.0-plugins-bad_1.10.1.bb | 1 +
>> 3 files changed, 39 insertions(+), 1 deletion(-)
>> create mode 100644
>> meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0001-Prepend-PKG_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch
>>
>> diff --git
>> a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
>> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
>> index d26a6a9..d3c5326 100644
>> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
>> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
>> @@ -64,7 +64,7 @@ PACKAGECONFIG[srtp] =
>> "--enable-srtp,--disable-srtp,libsrtp"
>> 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[wayland] =
>> "--enable-wayland,--disable-wayland,wayland-native wayland"
>> +PACKAGECONFIG[wayland] =
>> "--enable-wayland,--disable-wayland,wayland-native wayland
>> wayland-protocols"
>> PACKAGECONFIG[webp] = "--enable-webp,--disable-webp,libwebp"
>>
>> # these plugins have not been ported to 1.0 (yet):
>> diff --git
>> a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0001-Prepend-PKG_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch
>> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0001-Prepend-PKG_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch
>> new file mode 100644
>> index 0000000..eb789df
>> --- /dev/null
>> +++
>> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0001-Prepend-PKG_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch
>> @@ -0,0 +1,37 @@
>> +From c271503d7e233428ac0323c51d6517113e26bef7 Mon Sep 17 00:00:00 2001
>> +From: Khem Raj <raj.khem@gmail.com>
>> +Date: Thu, 1 Dec 2016 00:27:13 -0800
>> +Subject: [PATCH] Prepend PKG_CONFIG_SYSROOT_DIR to pkg-config output
>> +
>> +In cross environment we have to prepend the sysroot to the path found by
>> +pkgconfig since the path returned from pkgconfig does not have sysroot
>> prefixed
>> +it ends up using the files from host system. If build host has wayland
>> installed
>> +the build will succeed but if you dont have wayland-protocols installed
>> on build host then
>> +it wont find the files on build host
>> +
>> +This should work ok with non sysrooted builds too since in those cases
>> PKG_CONFIG_SYSROOT_DIR
>> +will be empty
>> +
>> +Upstream-Status: Pending
>> +
>> +Signed-off-by: Khem Raj <raj.khem@gmail.com>
>> +---
>> + configure.ac | 2 +-
>> + 1 file changed, 1 insertion(+), 1 deletion(-)
>> +
>> +diff --git a/configure.ac b/configure.ac
>> +index f8ac96b..dc87b08 100644
>> +--- a/configure.ac
>> ++++ b/configure.ac
>> +@@ -2233,7 +2233,7 @@ AG_GST_CHECK_FEATURE(WAYLAND, [wayland sink],
>> wayland , [
>> + PKG_CHECK_MODULES(WAYLAND_PROTOCOLS, wayland-protocols >= 1.4, [
>> + if test "x$wayland_scanner" != "x"; then
>> + HAVE_WAYLAND="yes"
>> +- AC_SUBST(WAYLAND_PROTOCOLS_DATADIR, `$PKG_CONFIG
>> --variable=pkgdatadir wayland-protocols`)
>> ++ AC_SUBST(WAYLAND_PROTOCOLS_DATADIR,
>> ${PKG_CONFIG_SYSROOT_DIR}`$PKG_CONFIG --variable=pkgdatadir
>> wayland-protocols`)
>
>
> I believe this breaks multilib because wayland-protocols is allarch so
> PKG_CONFIG_SYSROOT_DIR may then be incorrect.
how so ?
^ permalink raw reply
* Re: non-standard library locations and rpath
From: Jack Mitchell @ 2016-12-05 17:41 UTC (permalink / raw)
To: Khem Raj; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CAMKF1sqWBAAdT7v7vky3-wEfxXZ-aDNe-JH_jzKgkB6_E8Da7g@mail.gmail.com>
On 05/12/16 16:43, Khem Raj wrote:
> On Mon, Dec 5, 2016 at 2:54 AM, Jack Mitchell <ml@embed.me.uk> wrote:
>>
>>
>> On 05/12/16 10:44, Jack Mitchell wrote:
>>>
>>> On 02/12/16 07:08, Khem Raj wrote:
>>>>
>>>> On Thu, Dec 1, 2016 at 8:18 AM, Jack Mitchell <ml@embed.me.uk> wrote:
>>>>>
>>>>> I'm having some troubles with shared library, shared library
>>>>> dependencies
>>>>> and rpaths. I have libfoo, which depends on libbar when I try to link
>>>>> libfoo
>>>>> with my app, it requires libbar to be found. libbar is in a non-standard
>>>>> location, /usr/local/bar when I compiled libfoo, I used -Wl,rpath-link
>>>>> ${STAGING_SYSROOT}/usr/local/bar and -Wl,rpath /usr/local/bar. Now
>>>>> when I
>>>>> come to try link my app with libfoo, it fails to link as it can't find
>>>>> libbar, which I assume means the rpath in libfoo isn't being properly
>>>>> prepending with sysroot what is the proper way to support this in OE? My
>>>>> library has the following rpath information:
>>>>>
>>>>> 0x0000000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]
>>>>>
>>>>> So why isn't the rpath being prepended with the sysroot when I
>>>>> compile my
>>>>> app and link libfoo? The apps build system is using cmake, but this
>>>>> should
>>>>> be a built in linker feature, correct?
>>>>
>>>>
>>>> Only first path ( before :) is relative to location of binary at runtime
>>>>
>>>
>>> Exactly, so how can you make an OE build use the rpaths of libs that
>>> point to the build sysroot. What I have at the moment is
>>>
>>> 0x0000000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]
>>>
>>> Which would be correct if I was linking on the target. However when OE
>>> sees the rpath in it's cross compile environment it should prepend it
>>> with the build sysroot so you end up with something like
>>>
>>> 0x0000000f (RPATH) Library rpath:
>>> [$ORIGIN/../lib:/path/to/build/sysroot/usr/local/bar]
>>>
>>> And then the SDK should end up with something like
>>>
>>> 0x0000000f (RPATH) Library rpath:
>>> [$ORIGIN/../lib:/path/to/sdk/sysroot/usr/local/bar]
>>>
>>> Is this what is expected to happen, or am I stumbling into an
>>> unsupported scenario.
>>>
>>> Cheers,
>>
>>
>> I think basically what I'm saying is that does the linker prepend it's
>> --sysroot value to absolute rpaths, and if not, should it?
>
> having absolute build paths into rpaths is not a good thing. Linker
> will search the libs during link in sysroot its configured to do so.
>
Ok, that makes sense. So something like this would be more appropriate?
rel_path = relative_path(mylib, otherlib)
-Wl,-rpath $ORIGIN${relpath}
^ permalink raw reply
* RFC BuildAppliance future
From: Brian Avery @ 2016-12-05 18:04 UTC (permalink / raw)
To: openembedded-architecture, yocto, openembedded-core
[-- Attachment #1: Type: text/plain, Size: 1874 bytes --]
Please note, this is going out to 3 lists in an attempt to insure that no
one who would be impacted by this change misses it. Implied spam apology
included.
The Yocto Project currently provides a virtual machine image called the
Build Appliance (
https://downloads.yoctoproject.org/releases/yocto/yocto-2.2/build-appliance/).
This image can be run using either VirtualBox or VMware. It enables you to
build and boot a custom embedded Linux image with the Yocto Project on a
non-Linux development system. It is not intended for day to day
development use, but instead, is intended to allow users to “try out” the
tools even if they do not have access to a Linux system.
We are considering replacing the VM based Build Appliance with a set of
containers (https://hub.docker.com/r/crops/poky/, or if you want a user
interface (https://hub.docker.com/r/crops/toaster-master/ ). These
containers currently provide most of the functionality of the Build
Appliance and should shortly be at feature parity with the Build
Appliance. We are actively adding to and supporting the containers as some
of our developers are using them in their day to day development in order
to benefit from the host isolation and ease with which other distributions
can be tested.
This is an RFC to see what features in the Build Appliance are important
to you but would not be provided by the container solutions. If the
community would be just as content using the container approach as using
the VM based Build Appliance image, then we’d be better off deprecating the
Build Appliance and applying those resources elsewhere. If there are
important features the Build Appliance provides which the container
solution does not, or cannot provide, we’d love to hear what they are!
Thanks in advance for any feedback,
-Brian
an Intel Employee
[-- Attachment #2: Type: text/html, Size: 3160 bytes --]
^ permalink raw reply
* Re: non-standard library locations and rpath
From: Khem Raj @ 2016-12-05 18:18 UTC (permalink / raw)
To: Jack Mitchell; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <e98508b9-e5e0-3c43-2532-a4ac54d1326f@embed.me.uk>
On Mon, Dec 5, 2016 at 9:41 AM, Jack Mitchell <ml@embed.me.uk> wrote:
>
>
> On 05/12/16 16:43, Khem Raj wrote:
>>
>> On Mon, Dec 5, 2016 at 2:54 AM, Jack Mitchell <ml@embed.me.uk> wrote:
>>>
>>>
>>>
>>> On 05/12/16 10:44, Jack Mitchell wrote:
>>>>
>>>>
>>>> On 02/12/16 07:08, Khem Raj wrote:
>>>>>
>>>>>
>>>>> On Thu, Dec 1, 2016 at 8:18 AM, Jack Mitchell <ml@embed.me.uk> wrote:
>>>>>>
>>>>>>
>>>>>> I'm having some troubles with shared library, shared library
>>>>>> dependencies
>>>>>> and rpaths. I have libfoo, which depends on libbar when I try to link
>>>>>> libfoo
>>>>>> with my app, it requires libbar to be found. libbar is in a
>>>>>> non-standard
>>>>>> location, /usr/local/bar when I compiled libfoo, I used -Wl,rpath-link
>>>>>> ${STAGING_SYSROOT}/usr/local/bar and -Wl,rpath /usr/local/bar. Now
>>>>>> when I
>>>>>> come to try link my app with libfoo, it fails to link as it can't find
>>>>>> libbar, which I assume means the rpath in libfoo isn't being properly
>>>>>> prepending with sysroot what is the proper way to support this in OE?
>>>>>> My
>>>>>> library has the following rpath information:
>>>>>>
>>>>>> 0x0000000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]
>>>>>>
>>>>>> So why isn't the rpath being prepended with the sysroot when I
>>>>>> compile my
>>>>>> app and link libfoo? The apps build system is using cmake, but this
>>>>>> should
>>>>>> be a built in linker feature, correct?
>>>>>
>>>>>
>>>>>
>>>>> Only first path ( before :) is relative to location of binary at
>>>>> runtime
>>>>>
>>>>
>>>> Exactly, so how can you make an OE build use the rpaths of libs that
>>>> point to the build sysroot. What I have at the moment is
>>>>
>>>> 0x0000000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]
>>>>
>>>> Which would be correct if I was linking on the target. However when OE
>>>> sees the rpath in it's cross compile environment it should prepend it
>>>> with the build sysroot so you end up with something like
>>>>
>>>> 0x0000000f (RPATH) Library rpath:
>>>> [$ORIGIN/../lib:/path/to/build/sysroot/usr/local/bar]
>>>>
>>>> And then the SDK should end up with something like
>>>>
>>>> 0x0000000f (RPATH) Library rpath:
>>>> [$ORIGIN/../lib:/path/to/sdk/sysroot/usr/local/bar]
>>>>
>>>> Is this what is expected to happen, or am I stumbling into an
>>>> unsupported scenario.
>>>>
>>>> Cheers,
>>>
>>>
>>>
>>> I think basically what I'm saying is that does the linker prepend it's
>>> --sysroot value to absolute rpaths, and if not, should it?
>>
>>
>> having absolute build paths into rpaths is not a good thing. Linker
>> will search the libs during link in sysroot its configured to do so.
>>
>
> Ok, that makes sense. So something like this would be more appropriate?
>
> rel_path = relative_path(mylib, otherlib)
>
> -Wl,-rpath $ORIGIN${relpath}
This could work.
>
>
>
^ permalink raw reply
* Re: [PATCH 1/2] diffutils: do_configure: fix "Argument list too long"
From: Khem Raj @ 2016-12-05 18:23 UTC (permalink / raw)
To: Robert Yang; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <981a3fcb8a50c6277be726177a5895c64296d2ac.1480949616.git.liezhi.yang@windriver.com>
On Mon, Dec 5, 2016 at 6:54 AM, Robert Yang <liezhi.yang@windriver.com> wrote:
> Fixed when len(TMPDIR) = 410:
> aclocal: error: cannot open echo [snip]: Argument list too long
>
> This is becuase it has a lot of m4 files, use relative path for them
> can fix the problem.
>
> It doesn't happen when MACHINE="qemux86", I think it is because
> intel-x86-64 is longer than qemux86.
>
> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
> ---
> meta/recipes-extended/diffutils/diffutils_3.4.bb | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/meta/recipes-extended/diffutils/diffutils_3.4.bb b/meta/recipes-extended/diffutils/diffutils_3.4.bb
> index cb7092b..be280ec 100644
> --- a/meta/recipes-extended/diffutils/diffutils_3.4.bb
> +++ b/meta/recipes-extended/diffutils/diffutils_3.4.bb
> @@ -10,6 +10,9 @@ SRC_URI = "${GNU_MIRROR}/diffutils/diffutils-${PV}.tar.xz \
>
> EXTRA_OECONF += "--without-libsigsegv-prefix"
>
> +# Fix "Argument list too long" error when len(TMPDIR) = 410
> +acpaths = "-I ./m4"
it looks ok if this work ok with externalsrc
> +
> do_configure_prepend () {
> # Need to remove gettext macros with weird mix of versions
> for i in codeset.m4 gettext_gl.m4 intlmacosx.m4 inttypes-pri.m4 lib-ld_gl.m4 lib-prefix_gl.m4 po_gl.m4 ssize_t.m4 wchar_t.m4 wint_t.m4; do
> --
> 2.9.0
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply
* Re: [Openembedded-architecture] RFC BuildAppliance future
From: Mark Hatle @ 2016-12-05 18:37 UTC (permalink / raw)
To: Brian Avery, openembedded-architecture, yocto, openembedded-core
In-Reply-To: <CAKV_0ei2fHx-byfoVD85KFEpKkA23jgoVC9PUyK=6gJZQGTugA@mail.gmail.com>
On 12/5/16 12:04 PM, Brian Avery wrote:
> Please note, this is going out to 3 lists in an attempt to insure that no one
> who would be impacted by this change misses it. Implied spam apology included.
>
> The Yocto Project currently provides a virtual machine image called the Build
> Appliance
> (https://downloads.yoctoproject.org/releases/yocto/yocto-2.2/build-appliance/).
> This image can be run using either VirtualBox or VMware. It enables you to build
> and boot a custom embedded Linux image with the Yocto Project on a non-Linux
> development system. It is not intended for day to day development use, but
> instead, is intended to allow users to “try out” the tools even if they do not
> have access to a Linux system.
What are the requirements for a Windows user to use this, instead of the VM
approach. (In the past it was easy for a Windows user to get the VM, and just
run it to test out things.)
--Mark
> We are considering replacing the VM based Build Appliance with a set of
> containers (https://hub.docker.com/r/crops/poky/, or if you want a user
> interface (https://hub.docker.com/r/crops/toaster-master/ ). These containers
> currently provide most of the functionality of the Build Appliance and should
> shortly be at feature parity with the Build Appliance. We are actively adding
> to and supporting the containers as some of our developers are using them in
> their day to day development in order to benefit from the host isolation and
> ease with which other distributions can be tested.
>
> This is an RFC to see what features in the Build Appliance are important to
> you but would not be provided by the container solutions. If the community
> would be just as content using the container approach as using the VM based
> Build Appliance image, then we’d be better off deprecating the Build Appliance
> and applying those resources elsewhere. If there are important features the
> Build Appliance provides which the container solution does not, or cannot
> provide, we’d love to hear what they are!
>
>
Thanks in advance for any feedback,
>
> -Brian
>
> an Intel Employee
>
>
>
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>
^ permalink raw reply
* Re: [Openembedded-architecture] RFC BuildAppliance future
From: Khem Raj @ 2016-12-05 18:42 UTC (permalink / raw)
To: Brian Avery
Cc: yocto@yoctoproject.org, openembedded-architecture,
Patches and discussions about the oe-core layer
In-Reply-To: <CAKV_0ei2fHx-byfoVD85KFEpKkA23jgoVC9PUyK=6gJZQGTugA@mail.gmail.com>
On Mon, Dec 5, 2016 at 10:04 AM, Brian Avery <avery.brian@gmail.com> wrote:
> Please note, this is going out to 3 lists in an attempt to insure that no
> one who would be impacted by this change misses it. Implied spam apology
> included.
>
> The Yocto Project currently provides a virtual machine image called the
> Build Appliance
> (https://downloads.yoctoproject.org/releases/yocto/yocto-2.2/build-appliance/).
> This image can be run using either VirtualBox or VMware. It enables you to
> build and boot a custom embedded Linux image with the Yocto Project on a
> non-Linux development system. It is not intended for day to day development
> use, but instead, is intended to allow users to “try out” the tools even if
> they do not have access to a Linux system.
>
> We are considering replacing the VM based Build Appliance with a set of
> containers (https://hub.docker.com/r/crops/poky/, or if you want a user
> interface (https://hub.docker.com/r/crops/toaster-master/ ). These
> containers currently provide most of the functionality of the Build
> Appliance and should shortly be at feature parity with the Build Appliance.
> We are actively adding to and supporting the containers as some of our
> developers are using them in their day to day development in order to
> benefit from the host isolation and ease with which other distributions can
> be tested.
>
> This is an RFC to see what features in the Build Appliance are important
> to you but would not be provided by the container solutions. If the
> community would be just as content using the container approach as using the
> VM based Build Appliance image, then we’d be better off deprecating the
> Build Appliance and applying those resources elsewhere. If there are
> important features the Build Appliance provides which the container solution
> does not, or cannot provide, we’d love to hear what they are!
Personally, I dont use build appliance but I think using containers is a good
step forward, provided, we can address all build host OSes that
virtual appliance
could.
Build appliance is also a sort of "eat your own dog-food" for ensuring that we
are doing ok on preparing cloud images for deployment. Hopefully we wont
lose that testing, may be we can add another image to cover that.
>
>
Thanks in advance for any feedback,
>
> -Brian
>
> an Intel Employee
>
>
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>
^ permalink raw reply
* Re: [PATCH] gstreamer1.0-plugins-bad: Add PKG_CONFIG_SYSROOT_DIR to output of pkg-config
From: Khem Raj @ 2016-12-05 19:08 UTC (permalink / raw)
To: Jussi Kukkonen; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CAHiDW_ERJNEoc4OfTQtV6Bi3UPzQkt9RMPJDUx-RAVJnrj2feA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6695 bytes --]
> On Dec 5, 2016, at 5:20 AM, Jussi Kukkonen <jussi.kukkonen@intel.com> wrote:
>
>
>
> On 1 December 2016 at 10:37, Khem Raj <raj.khem@gmail.com <mailto:raj.khem@gmail.com>> wrote:
> When configure pokes for wayland-protocols isntallations it ended up
> using the ones from host, which is because it did not account for sysroot
> prefix
>
> Signed-off-by: Khem Raj <raj.khem@gmail.com <mailto:raj.khem@gmail.com>>
> ---
> .../gstreamer/gstreamer1.0-plugins-bad.inc | 2 +-
> ...G_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch | 37 ++++++++++++++++++++++
> .../gstreamer/gstreamer1.0-plugins-bad_1.10.1.bb <http://gstreamer1.0-plugins-bad_1.10.1.bb/> | 1 +
> 3 files changed, 39 insertions(+), 1 deletion(-)
> create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0001-Prepend-PKG_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch
>
> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
> index d26a6a9..d3c5326 100644
> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
> @@ -64,7 +64,7 @@ PACKAGECONFIG[srtp] = "--enable-srtp,--disable-srtp,libsrtp"
> 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[wayland] = "--enable-wayland,--disable-wayland,wayland-native wayland"
> +PACKAGECONFIG[wayland] = "--enable-wayland,--disable-wayland,wayland-native wayland wayland-protocols"
> PACKAGECONFIG[webp] = "--enable-webp,--disable-webp,libwebp"
>
> # these plugins have not been ported to 1.0 (yet):
> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0001-Prepend-PKG_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0001-Prepend-PKG_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch
> new file mode 100644
> index 0000000..eb789df
> --- /dev/null
> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0001-Prepend-PKG_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch
> @@ -0,0 +1,37 @@
> +From c271503d7e233428ac0323c51d6517113e26bef7 Mon Sep 17 00:00:00 2001
> +From: Khem Raj <raj.khem@gmail.com <mailto:raj.khem@gmail.com>>
> +Date: Thu, 1 Dec 2016 00:27:13 -0800
> +Subject: [PATCH] Prepend PKG_CONFIG_SYSROOT_DIR to pkg-config output
> +
> +In cross environment we have to prepend the sysroot to the path found by
> +pkgconfig since the path returned from pkgconfig does not have sysroot prefixed
> +it ends up using the files from host system. If build host has wayland installed
> +the build will succeed but if you dont have wayland-protocols installed on build host then
> +it wont find the files on build host
> +
> +This should work ok with non sysrooted builds too since in those cases PKG_CONFIG_SYSROOT_DIR
> +will be empty
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Khem Raj <raj.khem@gmail.com <mailto:raj.khem@gmail.com>>
> +---
> + configure.ac <http://configure.ac/> | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/configure.ac <http://configure.ac/> b/configure.ac <http://configure.ac/>
> +index f8ac96b..dc87b08 100644
> +--- a/configure.ac <http://configure.ac/>
> ++++ b/configure.ac <http://configure.ac/>
> +@@ -2233,7 +2233,7 @@ AG_GST_CHECK_FEATURE(WAYLAND, [wayland sink], wayland , [
> + PKG_CHECK_MODULES(WAYLAND_PROTOCOLS, wayland-protocols >= 1.4, [
> + if test "x$wayland_scanner" != "x"; then
> + HAVE_WAYLAND="yes"
> +- AC_SUBST(WAYLAND_PROTOCOLS_DATADIR, `$PKG_CONFIG --variable=pkgdatadir wayland-protocols`)
> ++ AC_SUBST(WAYLAND_PROTOCOLS_DATADIR, ${PKG_CONFIG_SYSROOT_DIR}`$PKG_CONFIG --variable=pkgdatadir wayland-protocols`)
>
> I believe this breaks multilib because wayland-protocols is allarch so PKG_CONFIG_SYSROOT_DIR may then be incorrect.
Realized my last reply is too terse. expanding on it a bit more.
this is not really the case. Since PKG_CONFIG_SYSROOT_DIR is set to STAGING_DIR_HOST which is then set to ${STAGING_DIR}/${MACHINE} so effectively its just
reusing an existing var compared to your case where a new redundant variable is introduced.
having said that, there could be a multilib issue if pkgdatadir thats in .pc file from wayland-protocols package is using variables like ${libdir} which then are
multilib dependent, if this is the case then we need to fix .pc file. however when I look at the <target-sysroot>/usr/share/pkgconfig/wayland-protocols.pc it has
prefix=/usr
datarootdir=${prefix}/share
pkgdatadir=/usr/share/wayland-protocols
seems to be free of multilib deps.
>
> I've set "WAYLAND_PROTOCOLS_SYSROOT_DIR=${STAGING_DIR}/${MACHINE}" in EXTRA_OECONF in other recipes and used that variable in the patches. It's not pretty but seems to work.
>
> Jussi
>
> + else
> + AC_MSG_RESULT([wayland-scanner is required to build the wayland plugin])
> + HAVE_WAYLAND="no"
> +--
> +2.10.2
> +
> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.10.1.bb <http://gstreamer1.0-plugins-bad_1.10.1.bb/> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.10.1.bb <http://gstreamer1.0-plugins-bad_1.10.1.bb/>
> index 9cd892e..6c6f011 100644
> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.10.1.bb <http://gstreamer1.0-plugins-bad_1.10.1.bb/>
> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.10.1.bb <http://gstreamer1.0-plugins-bad_1.10.1.bb/>
> @@ -14,6 +14,7 @@ SRC_URI = " \
> file://0001-gstreamer-gl.pc.in-don-t-append-GL_CFLAGS-to-CFLAGS.patch \
> file://0009-glimagesink-Downrank-to-marginal.patch \
> file://0001-introspection.m4-prefix-pkgconfig-paths-with-PKG_CON.patch \
> + file://0001-Prepend-PKG_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch \
> "
> SRC_URI[md5sum] = "491d2d5aab55ffc60c66e714d3d664ea"
> SRC_URI[sha256sum] = "133e0ed9fe21011b15d3898e3d3a9d17ab74eed31996da2e353353e688ca921d"
> --
> 2.10.2
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org <mailto:Openembedded-core@lists.openembedded.org>
> http://lists.openembedded.org/mailman/listinfo/openembedded-core <http://lists.openembedded.org/mailman/listinfo/openembedded-core>
[-- Attachment #2: Type: text/html, Size: 12496 bytes --]
^ permalink raw reply
* Re: [Openembedded-architecture] RFC BuildAppliance future
From: Brian Avery @ 2016-12-05 19:22 UTC (permalink / raw)
To: Khem Raj
Cc: yocto@yoctoproject.org, openembedded-architecture,
Patches and discussions about the oe-core layer
In-Reply-To: <CAMKF1spKHmuzxvW=JtWp7LPRFfDkb24A4sdUp7-hL1dqU16Mgg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5794 bytes --]
Excellent Questions!
Dogfooding – Good point. The
https://bugzilla.yoctoproject.org/show_bug.cgi?id=9502 bug is intended to
address that. With this, we can build and test container images just as we
can do with the Build Appliance. As an added win, those folks building
Busybox based minimal sized containers would have a different way to do
that...
OS availability: Docker is available for Windows, Mac, and Linux. Were
there fears about specific Linux distributions?
It does not seem to be too much harder to try Docker on Windows than it was
to try Virtualbox. That being said, Docker is moving/changing more quickly
so it may have more bumps in the road but more features too…
Windows explained more in depth or one of those bumps…:
The answer is a little complicated, so please bear with me. There are 2
different versions of Docker for Windows. The original version is known as
“Docker Toolbox” https://www.docker.com/products/docker-toolbox. This is
basically Docker running in a minimal VirtualBox Linux VM. They made a
separate host binary called docker-machine to help manage the images. This
is, in my opinion, a little clunky and does add some complexity when
switching from Docker running on Linux to Docker Toolbox running on
Windows. The clunkiness is largely due to the VirtualBox VM being “between”
the host and the Docker Engine. This version is targeted to people whose
Windows version does not meet the requirements specified below.
If you have 64bit Windows 10 Pro, Enterprise and Education (1511 November
update, Build 10586 or later) and Microsoft Hyper-V, then you can download
“Docker for Windows” https://docs.docker.com/docker-for-windows/. This is
a Docker implementation for Windows that relies on Hyper-V and a much
smaller vm. It is also better integrated into the host environment so that
the discontinuity between the host side and the Docker Engine is no longer
as jarring. For example, you get a disk tray icon for Docker, can set up
http proxies for it, can manage how much memory and how many cpus it will
get…
This (https://docs.docker.com/docker-for-mac/docker-toolbox/) is nice page
that addresses the difference between the newer hypervisor approach and the
older "Docker Toolbox aka VirtualBox" approach. The page is discussing it
from a Mac perspective but if you replace xhyve with Windows 10 Hyper-V,
the page is relevant to Windows as well.
The Mac implementation is functionally equivalent to “Docker for Windows”
and is called “Docker for Mac”
https://docs.docker.com/engine/installation/mac/. It runs on a modified
xhyve hypervisor.
The Linux implementation runs as a container and uses the same kernel as
the host.
Thanks for the feedback and if I missed or shortchanged something please
let me know,
-Brian
an intel employee
On Mon, Dec 5, 2016 at 10:42 AM, Khem Raj <raj.khem@gmail.com> wrote:
> On Mon, Dec 5, 2016 at 10:04 AM, Brian Avery <avery.brian@gmail.com>
> wrote:
> > Please note, this is going out to 3 lists in an attempt to insure that
> no
> > one who would be impacted by this change misses it. Implied spam apology
> > included.
> >
> > The Yocto Project currently provides a virtual machine image called the
> > Build Appliance
> > (https://downloads.yoctoproject.org/releases/yocto/yocto-2.2/build-
> appliance/).
> > This image can be run using either VirtualBox or VMware. It enables you
> to
> > build and boot a custom embedded Linux image with the Yocto Project on a
> > non-Linux development system. It is not intended for day to day
> development
> > use, but instead, is intended to allow users to “try out” the tools even
> if
> > they do not have access to a Linux system.
> >
> > We are considering replacing the VM based Build Appliance with a set of
> > containers (https://hub.docker.com/r/crops/poky/, or if you want a user
> > interface (https://hub.docker.com/r/crops/toaster-master/ ). These
> > containers currently provide most of the functionality of the Build
> > Appliance and should shortly be at feature parity with the Build
> Appliance.
> > We are actively adding to and supporting the containers as some of our
> > developers are using them in their day to day development in order to
> > benefit from the host isolation and ease with which other distributions
> can
> > be tested.
> >
> > This is an RFC to see what features in the Build Appliance are
> important
> > to you but would not be provided by the container solutions. If the
> > community would be just as content using the container approach as using
> the
> > VM based Build Appliance image, then we’d be better off deprecating the
> > Build Appliance and applying those resources elsewhere. If there are
> > important features the Build Appliance provides which the container
> solution
> > does not, or cannot provide, we’d love to hear what they are!
>
> Personally, I dont use build appliance but I think using containers is a
> good
> step forward, provided, we can address all build host OSes that
> virtual appliance
> could.
>
> Build appliance is also a sort of "eat your own dog-food" for ensuring
> that we
> are doing ok on preparing cloud images for deployment. Hopefully we wont
> lose that testing, may be we can add another image to cover that.
>
> >
> > Thanks in advance for any feedback,
> >
> > -Brian
> >
> > an Intel Employee
> >
> >
> > _______________________________________________
> > Openembedded-architecture mailing list
> > Openembedded-architecture@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
> >
>
[-- Attachment #2: Type: text/html, Size: 9231 bytes --]
^ permalink raw reply
* Re: [PATCH] u-boot: Add RPROVIDES bootloader
From: Paul Eggleton @ 2016-12-05 19:31 UTC (permalink / raw)
To: Fabio Berton; +Cc: openembedded-core
In-Reply-To: <1480687192-4813-1-git-send-email-fabio.berton@ossystems.com.br>
Hi Fabio,
On Fri, 02 Dec 2016 11:59:52 Fabio Berton wrote:
> This change allow to install u-boot in /boot partition using
> MACHINE_ESSENTIAL_EXTRA_RDEPENDS variable e.g.:
>
> MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "bootloader"
>
> This is usefull when system has only one partition and u-boot,
> kernel and device tree need to be installed in /boot.
If the intention is that other packages also have "bootloader" in RPROVIDES, I
thought that these kinds of "virtual provides" weren't supported well by all
of the package managers. (We might get away with it here since they probably
will all be in their own separate machine-specific feeds, though).
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply
* Re: [PATCH] u-boot: Add RPROVIDES bootloader
From: Otavio Salvador @ 2016-12-05 19:45 UTC (permalink / raw)
To: Paul Eggleton; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <1956643.Hk647jXyjn@peggleto-mobl.ger.corp.intel.com>
On Mon, Dec 5, 2016 at 5:31 PM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Fri, 02 Dec 2016 11:59:52 Fabio Berton wrote:
>> This change allow to install u-boot in /boot partition using
>> MACHINE_ESSENTIAL_EXTRA_RDEPENDS variable e.g.:
>>
>> MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "bootloader"
>>
>> This is usefull when system has only one partition and u-boot,
>> kernel and device tree need to be installed in /boot.
>
> If the intention is that other packages also have "bootloader" in RPROVIDES, I
> thought that these kinds of "virtual provides" weren't supported well by all
> of the package managers. (We might get away with it here since they probably
> will all be in their own separate machine-specific feeds, though).
The point in having the bootloader is because different bootloaders
may provide the functionality for the board. This is especially keen
for commercial distributions where a U-Boot fork may include fixes and
this should be used on top of the BSP default and without many changes
on the layer.
As you pointed out, the U-Boot usually has a single provider as it is
a MACHINE_ARCH package. I think it is a safe addition, isn't it?
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply
* Re: [PATCH] u-boot: Add RPROVIDES bootloader
From: Paul Eggleton @ 2016-12-05 19:56 UTC (permalink / raw)
To: Otavio Salvador; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CAP9ODKpVhncn-aZ=mJRef8WM5495nGafBaOmByXtUL_aOBQfkg@mail.gmail.com>
On Mon, 05 Dec 2016 17:45:40 Otavio Salvador wrote:
> On Mon, Dec 5, 2016 at 5:31 PM, Paul Eggleton
>
> <paul.eggleton@linux.intel.com> wrote:
> > On Fri, 02 Dec 2016 11:59:52 Fabio Berton wrote:
> >> This change allow to install u-boot in /boot partition using
> >> MACHINE_ESSENTIAL_EXTRA_RDEPENDS variable e.g.:
> >>
> >> MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "bootloader"
> >>
> >> This is usefull when system has only one partition and u-boot,
> >> kernel and device tree need to be installed in /boot.
> >
> > If the intention is that other packages also have "bootloader" in
> > RPROVIDES, I thought that these kinds of "virtual provides" weren't
> > supported well by all of the package managers. (We might get away with it
> > here since they probably will all be in their own separate
> > machine-specific feeds, though).
>
> The point in having the bootloader is because different bootloaders
> may provide the functionality for the board. This is especially keen
> for commercial distributions where a U-Boot fork may include fixes and
> this should be used on top of the BSP default and without many changes
> on the layer.
>
> As you pointed out, the U-Boot usually has a single provider as it is
> a MACHINE_ARCH package. I think it is a safe addition, isn't it?
If we can guarantee that there will only be one runtime provider of
"bootloader", then I would assume so, yes.
One question - at OEDEM (based on the minutes, I wasn't there) the
proliferation of u-boot recipes across BSPs was discussed and there was at
least a desire to try to move to a single recipe where practically possible.
Do you have any opinions on that? I bring it up because if there was only
"u-boot" presumably we wouldn't need the "bootloader" RPROVIDES at all.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply
* Re: [PATCH] u-boot: Add RPROVIDES bootloader
From: Otavio Salvador @ 2016-12-05 20:22 UTC (permalink / raw)
To: Paul Eggleton; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <1602179.NQvUR1FKDG@peggleto-mobl.ger.corp.intel.com>
On Mon, Dec 5, 2016 at 5:56 PM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Mon, 05 Dec 2016 17:45:40 Otavio Salvador wrote:
>> On Mon, Dec 5, 2016 at 5:31 PM, Paul Eggleton
>>
>> <paul.eggleton@linux.intel.com> wrote:
>> > On Fri, 02 Dec 2016 11:59:52 Fabio Berton wrote:
>> >> This change allow to install u-boot in /boot partition using
>> >> MACHINE_ESSENTIAL_EXTRA_RDEPENDS variable e.g.:
>> >>
>> >> MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "bootloader"
>> >>
>> >> This is usefull when system has only one partition and u-boot,
>> >> kernel and device tree need to be installed in /boot.
>> >
>> > If the intention is that other packages also have "bootloader" in
>> > RPROVIDES, I thought that these kinds of "virtual provides" weren't
>> > supported well by all of the package managers. (We might get away with it
>> > here since they probably will all be in their own separate
>> > machine-specific feeds, though).
>>
>> The point in having the bootloader is because different bootloaders
>> may provide the functionality for the board. This is especially keen
>> for commercial distributions where a U-Boot fork may include fixes and
>> this should be used on top of the BSP default and without many changes
>> on the layer.
>>
>> As you pointed out, the U-Boot usually has a single provider as it is
>> a MACHINE_ARCH package. I think it is a safe addition, isn't it?
>
> If we can guarantee that there will only be one runtime provider of
> "bootloader", then I would assume so, yes.
>
> One question - at OEDEM (based on the minutes, I wasn't there) the
> proliferation of u-boot recipes across BSPs was discussed and there was at
> least a desire to try to move to a single recipe where practically possible.
> Do you have any opinions on that? I bring it up because if there was only
> "u-boot" presumably we wouldn't need the "bootloader" RPROVIDES at all.
I agree and I think this should be a continuous goal for the entire
project and Yocto Project members, however, this is unlikely to happen
as internal BSPs and custom boards will always keep forked versions
around.
Even though having a single recipe is not going to happen, reducing
the fragmentation is very possible and desirable. We did some of work
on meta-freescale on this direction making many board to use
u-boot-fslc as provider. Some vendors moved to it while others keep
using their forks.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply
* Re: [PATCH] gdb-cross-canadian: Depend on nativesdk-python3-misc
From: Burton, Ross @ 2016-12-05 21:21 UTC (permalink / raw)
To: George McCollister; +Cc: OE-core
In-Reply-To: <20161205163827.21941-1-george.mccollister@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 408 bytes --]
On 5 December 2016 at 16:38, George McCollister <
george.mccollister@gmail.com> wrote:
> Add missing dependency on nativesdk-python3-misc so the imp Python
> module is installed.
>
So imp is the Python-facing API for 'import', and python-misc is a grab-bag
of random stuff. Should imp be moved to be in python3-importlib (where its
replacement already lives) or moved into python3-core?
Ross
[-- Attachment #2: Type: text/html, Size: 830 bytes --]
^ permalink raw reply
* [PATCH] run-postinsts: Print message before running deferred postinst scripts
From: Haris Okanovic @ 2016-12-05 21:48 UTC (permalink / raw)
To: openembedded-core; +Cc: haris.okanovic
Opkg can defer running postinst scripts to first boot, which can take
a while on some systems. The output of `opkg configure` (or whatever pm
is used) is redirected to a file when logging is enabled
(I.e. $POSTINST_LOGGING == 1), making the machine appear hung during
this process. This change simply prints a wait message on the console
to inform the user of this potentially long and silent operation so
that they do not mistakenly reboot their machine.
Why not simply `tee` the output instead?
Tee might be provided by BusyBox in some distros, which may need to run
update-alternatives in the very postinst scripts being executed by this
process. It's therefore not safe to assume Tee (or any other packaged
util) is available until the configure process finishes.
Signed-off-by: Haris Okanovic <haris.okanovic@ni.com>
---
meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
index 04ba394..660ddc2 100755
--- a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
+++ b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
@@ -46,6 +46,9 @@ if [ -z "$pi_dir" ]; then
exit 0
fi
+echo "Configuring packages on first boot...."
+echo " (This may take several minutes. Please do not power off the machine.)"
+
[ -e #SYSCONFDIR#/default/postinst ] && . #SYSCONFDIR#/default/postinst
if [ "$POSTINST_LOGGING" = "1" ]; then
--
2.10.1
^ permalink raw reply related
* [PATCH] connman: Simplify and fix packaging of VPN plug-ins
From: Andreas Oberritter @ 2016-12-05 22:41 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <CAJTo0Lb-snEZi_qqFW1_onvjK+_tJz47tDJtbAC4G3fum=DGmA@mail.gmail.com>
- Use simple static packaging.
- Move VPN runtime dependencies from connman to the individual plug-ins.
- Create a connmann-ppp package containing libppp-plugin.so, which is
a shared library needed by l2tp and pptp plug-ins.
- Let connman suggest VPN packages instead of recommending them, so they
don't get installed by default.
- Remove unknown configure options (--with-pptp --with-l2tp)
Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
---
v2: Made dependencies from meta-networking conditional. Now the reported
errors should appear only if meta-network is not available and a
packageconfig option related to VPN was enabled.
Note: I can't build-test it right now, because python3-native has weird
conflicts populating sysroot. But this patch doesn't cause parse
errors, so I guess syntax is fine.
meta/recipes-connectivity/connman/connman.inc | 95 +++++++++------------------
1 file changed, 32 insertions(+), 63 deletions(-)
diff --git a/meta/recipes-connectivity/connman/connman.inc b/meta/recipes-connectivity/connman/connman.inc
index 35a7eed..671d533 100644
--- a/meta/recipes-connectivity/connman/connman.inc
+++ b/meta/recipes-connectivity/connman/connman.inc
@@ -46,24 +46,17 @@ PACKAGECONFIG[wifi] = "--enable-wifi, --disable-wifi, wpa-supplicant, wpa-suppli
PACKAGECONFIG[bluez] = "--enable-bluetooth, --disable-bluetooth, ${BLUEZ}, ${BLUEZ}"
PACKAGECONFIG[3g] = "--enable-ofono, --disable-ofono, ofono, ofono"
PACKAGECONFIG[tist] = "--enable-tist,--disable-tist,"
-PACKAGECONFIG[openvpn] = "--enable-openvpn --with-openvpn=${sbindir}/openvpn,--disable-openvpn,,openvpn"
-PACKAGECONFIG[vpnc] = "--enable-vpnc --with-vpnc=${sbindir}/vpnc,--disable-vpnc,,vpnc"
-PACKAGECONFIG[l2tp] = "--enable-l2tp --with-l2tp=${sbindir}/xl2tpd,--disable-l2tp,,xl2tpd"
-PACKAGECONFIG[pptp] = "--enable-pptp --with-pptp=${sbindir}/pptp,--disable-pptp,,pptp-linux"
+PACKAGECONFIG[openvpn] = "--enable-openvpn --with-openvpn=${sbindir}/openvpn,--disable-openvpn"
+PACKAGECONFIG[vpnc] = "--enable-vpnc --with-vpnc=${sbindir}/vpnc,--disable-vpnc"
+PACKAGECONFIG[l2tp] = "--enable-l2tp,--disable-l2tp"
+PACKAGECONFIG[pptp] = "--enable-pptp,--disable-pptp"
# WISPr support for logging into hotspots, requires TLS
PACKAGECONFIG[wispr] = "--enable-wispr,--disable-wispr,gnutls,"
INITSCRIPT_NAME = "connman"
INITSCRIPT_PARAMS = "start 05 5 2 3 . stop 22 0 1 6 ."
-python __anonymous () {
- systemd_packages = "${PN}"
- pkgconfig = d.getVar('PACKAGECONFIG', True)
- if ('openvpn' or 'vpnc' or 'l2tp' or 'pptp') in pkgconfig.split():
- systemd_packages += " ${PN}-vpn"
- d.setVar('SYSTEMD_PACKAGES', systemd_packages)
-}
-
+SYSTEMD_PACKAGES = "${PN} ${PN}-vpn"
SYSTEMD_SERVICE_${PN} = "connman.service"
SYSTEMD_SERVICE_${PN}-vpn = "connman-vpn.service"
SYSTEMD_SERVICE_${PN}-wait-online = "connman-wait-online.service"
@@ -103,36 +96,6 @@ RDEPENDS_${PN} = "\
dbus \
"
-PACKAGES_DYNAMIC += "^${PN}-plugin-.*"
-
-def add_rdepends(bb, d, file, pkg, depmap, multilib_prefix, add_insane_skip):
- plugintype = pkg.split( '-' )[-1]
- if plugintype in depmap:
- rdepends = map(lambda x: multilib_prefix + x, \
- depmap[plugintype].split())
- d.setVar("RDEPENDS_%s" % pkg, " ".join(rdepends))
- if add_insane_skip:
- d.appendVar("INSANE_SKIP_%s" % pkg, "dev-so")
-
-python populate_packages_prepend() {
- depmap = dict(pppd="ppp")
- multilib_prefix = (d.getVar("MLPREFIX", True) or "")
-
- hook = lambda file,pkg,x,y,z: \
- add_rdepends(bb, d, file, pkg, depmap, multilib_prefix, False)
- plugin_dir = d.expand('${libdir}/connman/plugins/')
- plugin_name = d.expand('${PN}-plugin-%s')
- do_split_packages(d, plugin_dir, '^(.*).so$', plugin_name, \
- '${PN} plugin for %s', extra_depends='', hook=hook, prepend=True )
-
- hook = lambda file,pkg,x,y,z: \
- add_rdepends(bb, d, file, pkg, depmap, multilib_prefix, True)
- plugin_dir = d.expand('${libdir}/connman/plugins-vpn/')
- plugin_name = d.expand('${PN}-plugin-vpn-%s')
- do_split_packages(d, plugin_dir, '^(.*).so$', plugin_name, \
- '${PN} VPN plugin for %s', extra_depends='', hook=hook, prepend=True )
-}
-
PACKAGES =+ "${PN}-tools ${PN}-tests ${PN}-client"
FILES_${PN}-tools = "${bindir}/wispr"
@@ -152,7 +115,12 @@ FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*.so.* \
FILES_${PN}-dev += "${libdir}/connman/*/*.la"
-PACKAGES =+ "${PN}-vpn ${PN}-wait-online"
+PACKAGES =+ "${PN}-vpn ${PN}-wait-online \
+ ${PN}-ppp \
+ ${PN}-plugin-vpn-l2tp \
+ ${PN}-plugin-vpn-openvpn \
+ ${PN}-plugin-vpn-pptp \
+ ${PN}-plugin-vpn-vpnc"
SUMMARY_${PN}-vpn = "A daemon for managing VPN connections within embedded devices"
DESCRIPTION_${PN}-vpn = "The ConnMan VPN provides a daemon for \
@@ -161,10 +129,10 @@ operating system. The connman-vpnd handles all the VPN connections \
and starts/stops VPN client processes when necessary. The connman-vpnd \
provides a DBus API for managing VPN connections. All the different \
VPN technogies are implemented using plug-ins."
-FILES_${PN}-vpn += "${sbindir}/connman-vpnd \
- ${sysconfdir}/dbus-1/system.d/connman-vpn-dbus.conf \
- ${datadir}/dbus-1/system-services/net.connman.vpn.service \
- ${systemd_unitdir}/system/connman-vpn.service"
+FILES_${PN}-vpn = "${sbindir}/connman-vpnd \
+ ${sysconfdir}/dbus-1/system.d/connman-vpn-dbus.conf \
+ ${datadir}/dbus-1/system-services/net.connman.vpn.service \
+ ${systemd_unitdir}/system/connman-vpn.service"
SUMMARY_${PN}-wait-online = "A program that will return once ConnMan has connected to a network"
DESCRIPTION_${PN}-wait-online = "A service that can be enabled so that \
@@ -175,31 +143,32 @@ FILES_${PN}-wait-online += "${sbindir}/connmand-wait-online \
SUMMARY_${PN}-plugin-vpn-openvpn = "An OpenVPN plugin for ConnMan VPN"
DESCRIPTION_${PN}-plugin-vpn-openvpn = "The ConnMan OpenVPN plugin uses openvpn client \
to create a VPN connection to OpenVPN server."
-FILES_${PN}-plugin-vpn-openvpn += "${libdir}/connman/scripts/openvpn-script \
- ${libdir}/connman/plugins-vpn/openvpn.so"
-RDEPENDS_${PN}-plugin-vpn-openvpn += "${PN}-vpn"
-RRECOMMENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG','openvpn','${PN}-plugin-vpn-openvpn', '', d)}"
+FILES_${PN}-plugin-vpn-openvpn = "${libdir}/connman/scripts/openvpn-script \
+ ${libdir}/connman/plugins-vpn/openvpn.so"
+RDEPENDS_${PN}-plugin-vpn-openvpn = "${PN}-vpn ${@bb.utils.contains('PACKAGECONFIG', 'openvpn', 'openvpn', '', d)}"
+RSUGGESTS_${PN} += "${@bb.utils.contains('PACKAGECONFIG','openvpn','${PN}-plugin-vpn-openvpn', '', d)}"
SUMMARY_${PN}-plugin-vpn-vpnc = "A vpnc plugin for ConnMan VPN"
DESCRIPTION_${PN}-plugin-vpn-vpnc = "The ConnMan vpnc plugin uses vpnc client \
to create a VPN connection to Cisco3000 VPN Concentrator."
-FILES_${PN}-plugin-vpn-vpnc += "${libdir}/connman/scripts/openconnect-script \
- ${libdir}/connman/plugins-vpn/vpnc.so"
-RDEPENDS_${PN}-plugin-vpn-vpnc += "${PN}-vpn"
-RRECOMMENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG','vpnc','${PN}-plugin-vpn-vpnc', '', d)}"
+FILES_${PN}-plugin-vpn-vpnc = "${libdir}/connman/scripts/openconnect-script \
+ ${libdir}/connman/plugins-vpn/vpnc.so"
+RDEPENDS_${PN}-plugin-vpn-vpnc = "${PN}-vpn ${@bb.utils.contains('PACKAGECONFIG', 'vpnc', 'vpnc', '', d)}"
+RSUGGESTS_${PN} += "${@bb.utils.contains('PACKAGECONFIG','vpnc','${PN}-plugin-vpn-vpnc', '', d)}"
SUMMARY_${PN}-plugin-vpn-l2tp = "A L2TP plugin for ConnMan VPN"
DESCRIPTION_${PN}-plugin-vpn-l2tp = "The ConnMan L2TP plugin uses xl2tpd daemon \
to create a VPN connection to L2TP server."
-FILES_${PN}-plugin-vpn-l2tp += "${libdir}/connman/scripts/libppp-plugin.so* \
- ${libdir}/connman/plugins-vpn/l2tp.so"
-RDEPENDS_${PN}-plugin-vpn-l2tp += "${PN}-vpn"
-RRECOMMENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG','l2tp','${PN}-plugin-vpn-l2tp', '', d)}"
+FILES_${PN}-plugin-vpn-l2tp = "${libdir}/connman/plugins-vpn/l2tp.so"
+RDEPENDS_${PN}-plugin-vpn-l2tp = "${PN}-vpn ${PN}-ppp ${@bb.utils.contains('PACKAGECONFIG', 'l2tp', 'xl2tpd', '', d)}"
+RSUGGESTS_${PN} += "${@bb.utils.contains('PACKAGECONFIG','l2tp','${PN}-plugin-vpn-l2tp', '', d)}"
SUMMARY_${PN}-plugin-vpn-pptp = "A PPTP plugin for ConnMan VPN"
DESCRIPTION_${PN}-plugin-vpn-pptp = "The ConnMan PPTP plugin uses pptp-linux client \
to create a VPN connection to PPTP server."
-FILES_${PN}-plugin-vpn-pptp += "${libdir}/connman/scripts/libppp-plugin.so* \
- ${libdir}/connman/plugins-vpn/pptp.so"
-RDEPENDS_${PN}-plugin-vpn-pptp += "${PN}-vpn"
-RRECOMMENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG','pptp','${PN}-plugin-vpn-pptp', '', d)}"
+FILES_${PN}-plugin-vpn-pptp = "${libdir}/connman/plugins-vpn/pptp.so"
+RDEPENDS_${PN}-plugin-vpn-pptp = "${PN}-vpn ${PN}-ppp ${@bb.utils.contains('PACKAGECONFIG', 'pptp', 'pptp-linux', '', d)}"
+RSUGGESTS_${PN} += "${@bb.utils.contains('PACKAGECONFIG','pptp','${PN}-plugin-vpn-pptp', '', d)}"
+
+FILES_${PN}-ppp = "${libdir}/connman/scripts/libppp-plugin.so"
+RDEPENDS_${PN}-ppp = "ppp"
^ permalink raw reply related
* Re: [PATCH] run-postinsts: Print message before running deferred postinst scripts
From: Burton, Ross @ 2016-12-05 22:51 UTC (permalink / raw)
To: Haris Okanovic; +Cc: OE-core
In-Reply-To: <20161205214818.13342-1-haris.okanovic@ni.com>
[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]
On 5 December 2016 at 21:48, Haris Okanovic <haris.okanovic@ni.com> wrote:
> Opkg can defer running postinst scripts to first boot, which can take
> a while on some systems. The output of `opkg configure` (or whatever pm
> is used) is redirected to a file when logging is enabled
> (I.e. $POSTINST_LOGGING == 1), making the machine appear hung during
> this process. This change simply prints a wait message on the console
> to inform the user of this potentially long and silent operation so
> that they do not mistakenly reboot their machine.
>
This isn't opkg specific, all backends can do it.
> Why not simply `tee` the output instead?
> Tee might be provided by BusyBox in some distros, which may need to run
> update-alternatives in the very postinst scripts being executed by this
> process. It's therefore not safe to assume Tee (or any other packaged
> util) is available until the configure process finishes.
>
Are the alternatives not configured at rootfs time, so it should be fine to
run tee? (as if tee isn't safe, then neither is sed).
Ross
[-- Attachment #2: Type: text/html, Size: 1726 bytes --]
^ permalink raw reply
* Re: [PATCH] webkitgtk: drop patch 0001-WebKitMacros-Append-to-I-and-not-to-isystem.patch
From: Khem Raj @ 2016-12-05 22:56 UTC (permalink / raw)
To: Carlos Alberto Lopez Perez; +Cc: openembedded-core
In-Reply-To: <1478627553-13710-1-git-send-email-clopez@igalia.com>
[-- Attachment #1: Type: text/plain, Size: 10780 bytes --]
Carlos
webkitgtk fails now e.g. see
http://errors.yoctoproject.org/Errors/Details/111221/ <http://errors.yoctoproject.org/Errors/Details/111221/>
fatal error: 'stdlib.h' file not found
#include_next <stdlib.h>
This is when building with clang, I think its too early to drop this patch.
> On Nov 8, 2016, at 9:52 AM, Carlos Alberto Lopez Perez <clopez@igalia.com> wrote:
>
> * This patch is not longer needed. Upstream has fixed this issue in:
> https://trac.webkit.org/changeset/205672 which is already included
> in WebKitGTK+ >= 2.14.0
>
> Signed-off-by: Carlos Alberto Lopez Perez <clopez@igalia.com>
> ---
> ...bKitMacros-Append-to-I-and-not-to-isystem.patch | 181 ---------------------
> meta/recipes-sato/webkit/webkitgtk_2.14.1.bb | 1 -
> 2 files changed, 182 deletions(-)
> delete mode 100644 meta/recipes-sato/webkit/files/0001-WebKitMacros-Append-to-I-and-not-to-isystem.patch
>
> diff --git a/meta/recipes-sato/webkit/files/0001-WebKitMacros-Append-to-I-and-not-to-isystem.patch b/meta/recipes-sato/webkit/files/0001-WebKitMacros-Append-to-I-and-not-to-isystem.patch
> deleted file mode 100644
> index ef209c8..0000000
> --- a/meta/recipes-sato/webkit/files/0001-WebKitMacros-Append-to-I-and-not-to-isystem.patch
> +++ /dev/null
> @@ -1,181 +0,0 @@
> -From 20ee11dd188e1538f8cdd17a289dc6f9c63a011e Mon Sep 17 00:00:00 2001
> -From: Khem Raj <raj.khem@gmail.com>
> -Date: Sun, 17 Apr 2016 12:35:41 -0700
> -Subject: [PATCH] WebKitMacros: Append to -I and not to -isystem
> -
> -gcc-6 has now introduced stdlib.h in libstdc++ for better
> -compliance and its including the C library stdlib.h using
> -include_next which is sensitive to order of system header
> -include paths. Its infact better to not tinker with the
> -system header include paths at all. Since adding /usr/include
> -to -system is redundant and compiler knows about it moreover
> -now with gcc6 it interferes with compiler's functioning
> -and ends up with compile errors e.g.
> -
> -/usr/include/c++/6.0.0/cstdlib:75:25: fatal error: stdlib.h: No such file or directory
> -
> -Signed-off-by: Khem Raj <raj.khem@gmail.com>
> -Upstream-Status: Pending
> ----
> - Source/JavaScriptCore/shell/CMakeLists.txt | 2 +-
> - Source/WebCore/PlatformGTK.cmake | 6 +++---
> - Source/WebKit2/PlatformGTK.cmake | 2 +-
> - Source/cmake/WebKitMacros.cmake | 2 +-
> - Tools/DumpRenderTree/TestNetscapePlugIn/CMakeLists.txt | 2 +-
> - Tools/ImageDiff/CMakeLists.txt | 2 +-
> - Tools/MiniBrowser/gtk/CMakeLists.txt | 2 +-
> - Tools/TestWebKitAPI/PlatformGTK.cmake | 2 +-
> - Tools/TestWebKitAPI/Tests/WebKit2Gtk/CMakeLists.txt | 2 +-
> - Tools/WebKitTestRunner/CMakeLists.txt | 2 +-
> - 10 files changed, 12 insertions(+), 12 deletions(-)
> -
> -diff --git a/Source/JavaScriptCore/shell/CMakeLists.txt b/Source/JavaScriptCore/shell/CMakeLists.txt
> -index 155c797..80fe22b 100644
> ---- a/Source/JavaScriptCore/shell/CMakeLists.txt
> -+++ b/Source/JavaScriptCore/shell/CMakeLists.txt
> -@@ -20,7 +20,7 @@ WEBKIT_INCLUDE_CONFIG_FILES_IF_EXISTS()
> -
> - WEBKIT_WRAP_SOURCELIST(${JSC_SOURCES})
> - include_directories(./ ${JavaScriptCore_INCLUDE_DIRECTORIES})
> --include_directories(SYSTEM ${JavaScriptCore_SYSTEM_INCLUDE_DIRECTORIES})
> -+include_directories(${JavaScriptCore_SYSTEM_INCLUDE_DIRECTORIES})
> - add_executable(jsc ${JSC_SOURCES})
> - target_link_libraries(jsc ${JSC_LIBRARIES})
> -
> -diff --git a/Source/WebCore/PlatformGTK.cmake b/Source/WebCore/PlatformGTK.cmake
> -index 567bd79..1fabea8 100644
> ---- a/Source/WebCore/PlatformGTK.cmake
> -+++ b/Source/WebCore/PlatformGTK.cmake
> -@@ -340,7 +340,7 @@ if (ENABLE_PLUGIN_PROCESS_GTK2)
> - ${GTK2_INCLUDE_DIRS}
> - ${GDK2_INCLUDE_DIRS}
> - )
> -- target_include_directories(WebCorePlatformGTK2 SYSTEM PRIVATE
> -+ target_include_directories(WebCorePlatformGTK2 PRIVATE
> - ${WebCore_SYSTEM_INCLUDE_DIRECTORIES}
> - )
> - target_link_libraries(WebCorePlatformGTK2
> -@@ -365,7 +365,7 @@ WEBKIT_SET_EXTRA_COMPILER_FLAGS(WebCorePlatformGTK)
> - target_include_directories(WebCorePlatformGTK PRIVATE
> - ${WebCore_INCLUDE_DIRECTORIES}
> - )
> --target_include_directories(WebCorePlatformGTK SYSTEM PRIVATE
> -+target_include_directories(WebCorePlatformGTK PRIVATE
> - ${WebCore_SYSTEM_INCLUDE_DIRECTORIES}
> - ${GTK_INCLUDE_DIRS}
> - ${GDK_INCLUDE_DIRS}
> -@@ -383,7 +383,7 @@ include_directories(
> - "${DERIVED_SOURCES_GOBJECT_DOM_BINDINGS_DIR}"
> - )
> -
> --include_directories(SYSTEM
> -+include_directories(
> - ${WebCore_SYSTEM_INCLUDE_DIRECTORIES}
> - )
> -
> -diff --git a/Source/WebKit2/PlatformGTK.cmake b/Source/WebKit2/PlatformGTK.cmake
> -index e4805a4..c57df5d 100644
> ---- a/Source/WebKit2/PlatformGTK.cmake
> -+++ b/Source/WebKit2/PlatformGTK.cmake
> -@@ -822,7 +822,7 @@ if (ENABLE_PLUGIN_PROCESS_GTK2)
> - target_include_directories(WebKitPluginProcess2 PRIVATE
> - ${WebKit2CommonIncludeDirectories}
> - )
> -- target_include_directories(WebKitPluginProcess2 SYSTEM PRIVATE
> -+ target_include_directories(WebKitPluginProcess2 PRIVATE
> - ${WebKit2CommonSystemIncludeDirectories}
> - ${GTK2_INCLUDE_DIRS}
> - ${GDK2_INCLUDE_DIRS}
> -diff --git a/Source/cmake/WebKitMacros.cmake b/Source/cmake/WebKitMacros.cmake
> -index 043e78e..8b3b642 100644
> ---- a/Source/cmake/WebKitMacros.cmake
> -+++ b/Source/cmake/WebKitMacros.cmake
> -@@ -224,7 +224,7 @@ endmacro()
> -
> - macro(WEBKIT_FRAMEWORK _target)
> - include_directories(${${_target}_INCLUDE_DIRECTORIES})
> -- include_directories(SYSTEM ${${_target}_SYSTEM_INCLUDE_DIRECTORIES})
> -+ include_directories(${${_target}_SYSTEM_INCLUDE_DIRECTORIES})
> - add_library(${_target} ${${_target}_LIBRARY_TYPE}
> - ${${_target}_HEADERS}
> - ${${_target}_SOURCES}
> -diff --git a/Tools/DumpRenderTree/TestNetscapePlugIn/CMakeLists.txt b/Tools/DumpRenderTree/TestNetscapePlugIn/CMakeLists.txt
> -index c431667..6dff244 100644
> ---- a/Tools/DumpRenderTree/TestNetscapePlugIn/CMakeLists.txt
> -+++ b/Tools/DumpRenderTree/TestNetscapePlugIn/CMakeLists.txt
> -@@ -42,7 +42,7 @@ set(WebKitTestNetscapePlugin_SYSTEM_INCLUDE_DIRECTORIES
> - )
> -
> - include_directories(${WebKitTestNetscapePlugin_INCLUDE_DIRECTORIES})
> --include_directories(SYSTEM ${WebKitTestNetscapePlugin_SYSTEM_INCLUDE_DIRECTORIES})
> -+include_directories(${WebKitTestNetscapePlugin_SYSTEM_INCLUDE_DIRECTORIES})
> -
> - set(WebKitTestNetscapePlugin_LIBRARIES
> - ${X11_LIBRARIES}
> -diff --git a/Tools/ImageDiff/CMakeLists.txt b/Tools/ImageDiff/CMakeLists.txt
> -index b15443f..87e03bf 100644
> ---- a/Tools/ImageDiff/CMakeLists.txt
> -+++ b/Tools/ImageDiff/CMakeLists.txt
> -@@ -14,6 +14,6 @@ set(IMAGE_DIFF_LIBRARIES
> - WEBKIT_INCLUDE_CONFIG_FILES_IF_EXISTS()
> -
> - include_directories(${IMAGE_DIFF_INCLUDE_DIRECTORIES})
> --include_directories(SYSTEM ${IMAGE_DIFF_SYSTEM_INCLUDE_DIRECTORIES})
> -+include_directories(${IMAGE_DIFF_SYSTEM_INCLUDE_DIRECTORIES})
> - add_executable(ImageDiff ${IMAGE_DIFF_SOURCES})
> - target_link_libraries(ImageDiff ${IMAGE_DIFF_LIBRARIES})
> -diff --git a/Tools/MiniBrowser/gtk/CMakeLists.txt b/Tools/MiniBrowser/gtk/CMakeLists.txt
> -index 0704bc6..619e5a5 100644
> ---- a/Tools/MiniBrowser/gtk/CMakeLists.txt
> -+++ b/Tools/MiniBrowser/gtk/CMakeLists.txt
> -@@ -58,7 +58,7 @@ endif ()
> - add_definitions(-DGDK_VERSION_MIN_REQUIRED=GDK_VERSION_3_6)
> -
> - include_directories(${MiniBrowser_INCLUDE_DIRECTORIES})
> --include_directories(SYSTEM ${MiniBrowser_SYSTEM_INCLUDE_DIRECTORIES})
> -+include_directories(${MiniBrowser_SYSTEM_INCLUDE_DIRECTORIES})
> - add_executable(MiniBrowser ${MiniBrowser_SOURCES})
> - target_link_libraries(MiniBrowser ${MiniBrowser_LIBRARIES})
> -
> -diff --git a/Tools/TestWebKitAPI/PlatformGTK.cmake b/Tools/TestWebKitAPI/PlatformGTK.cmake
> -index 7552cc2..2eb44d5 100644
> ---- a/Tools/TestWebKitAPI/PlatformGTK.cmake
> -+++ b/Tools/TestWebKitAPI/PlatformGTK.cmake
> -@@ -20,7 +20,7 @@ include_directories(
> - ${WEBKIT2_DIR}/UIProcess/API/gtk
> - )
> -
> --include_directories(SYSTEM
> -+include_directories(
> - ${GDK3_INCLUDE_DIRS}
> - ${GLIB_INCLUDE_DIRS}
> - ${GTK3_INCLUDE_DIRS}
> -diff --git a/Tools/TestWebKitAPI/Tests/WebKit2Gtk/CMakeLists.txt b/Tools/TestWebKitAPI/Tests/WebKit2Gtk/CMakeLists.txt
> -index b0b4739..434e4ca 100644
> ---- a/Tools/TestWebKitAPI/Tests/WebKit2Gtk/CMakeLists.txt
> -+++ b/Tools/TestWebKitAPI/Tests/WebKit2Gtk/CMakeLists.txt
> -@@ -23,7 +23,7 @@ include_directories(
> - ${TOOLS_DIR}/TestWebKitAPI/gtk/WebKit2Gtk
> - )
> -
> --include_directories(SYSTEM
> -+include_directories(
> - ${ATSPI_INCLUDE_DIRS}
> - ${GLIB_INCLUDE_DIRS}
> - ${GSTREAMER_INCLUDE_DIRS}
> -diff --git a/Tools/WebKitTestRunner/CMakeLists.txt b/Tools/WebKitTestRunner/CMakeLists.txt
> -index 7db90f2..a4f917f 100644
> ---- a/Tools/WebKitTestRunner/CMakeLists.txt
> -+++ b/Tools/WebKitTestRunner/CMakeLists.txt
> -@@ -116,7 +116,7 @@ GENERATE_BINDINGS(WebKitTestRunner_SOURCES
> - WEBKIT_INCLUDE_CONFIG_FILES_IF_EXISTS()
> -
> - include_directories(${WebKitTestRunner_INCLUDE_DIRECTORIES})
> --include_directories(SYSTEM ${WebKitTestRunner_SYSTEM_INCLUDE_DIRECTORIES})
> -+include_directories(${WebKitTestRunner_SYSTEM_INCLUDE_DIRECTORIES})
> -
> - add_library(TestRunnerInjectedBundle SHARED ${WebKitTestRunnerInjectedBundle_SOURCES})
> - target_link_libraries(TestRunnerInjectedBundle ${WebKitTestRunner_LIBRARIES})
> ---
> -2.9.3
> -
> diff --git a/meta/recipes-sato/webkit/webkitgtk_2.14.1.bb b/meta/recipes-sato/webkit/webkitgtk_2.14.1.bb
> index a2586de..69c9f11 100644
> --- a/meta/recipes-sato/webkit/webkitgtk_2.14.1.bb
> +++ b/meta/recipes-sato/webkit/webkitgtk_2.14.1.bb
> @@ -18,7 +18,6 @@ SRC_URI = "http://www.webkitgtk.org/releases/${BPN}-${PV}.tar.xz \
> file://ppc-musl-fix.patch \
> file://0001-Fix-racy-parallel-build-of-WebKit2-4.0.gir.patch \
> file://0001-Tweak-gtkdoc-settings-so-that-gtkdoc-generation-work.patch \
> - file://0001-WebKitMacros-Append-to-I-and-not-to-isystem.patch \
> "
>
> SRC_URI[md5sum] = "8d6c60dc41604d3bbd43165a674c07e5"
> --
> 2.1.4
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
[-- Attachment #2: Type: text/html, Size: 16194 bytes --]
^ permalink raw reply
* Re: [PATCH] gdb-cross-canadian: Depend on nativesdk-python3-misc
From: George McCollister @ 2016-12-06 0:16 UTC (permalink / raw)
To: Burton, Ross; +Cc: OE-core
In-Reply-To: <CAJTo0La_rfxyJRgJgjdknqXAACkqxRB3dgqdyiOv7VCa+z8rFA@mail.gmail.com>
On Mon, Dec 5, 2016 at 3:21 PM, Burton, Ross <ross.burton@intel.com> wrote:
>
> On 5 December 2016 at 16:38, George McCollister
> <george.mccollister@gmail.com> wrote:
>>
>> Add missing dependency on nativesdk-python3-misc so the imp Python
>> module is installed.
>
>
> So imp is the Python-facing API for 'import', and python-misc is a grab-bag
> of random stuff. Should imp be moved to be in python3-importlib (where its
> replacement already lives) or moved into python3-core?
importlib is the replacement for imp (it's deprecated since version
3.4) so this sounds reasonable to me. Shall I send a patch to add
imp.py to python3-importlib and another to add python3-importlib to
PACKAGECONFIG[python] in gdb-cross-canadian.inc?
-George
^ permalink raw reply
* [PATCH 1/5] mesa: update to 13.0.2
From: Andreas Müller @ 2016-12-06 0:19 UTC (permalink / raw)
To: openembedded-core
Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
---
meta/recipes-graphics/mesa/{mesa-gl_13.0.1.bb => mesa-gl_13.0.2.bb} | 0
meta/recipes-graphics/mesa/{mesa_13.0.1.bb => mesa_13.0.2.bb} | 4 ++--
2 files changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-graphics/mesa/{mesa-gl_13.0.1.bb => mesa-gl_13.0.2.bb} (100%)
rename meta/recipes-graphics/mesa/{mesa_13.0.1.bb => mesa_13.0.2.bb} (91%)
diff --git a/meta/recipes-graphics/mesa/mesa-gl_13.0.1.bb b/meta/recipes-graphics/mesa/mesa-gl_13.0.2.bb
similarity index 100%
rename from meta/recipes-graphics/mesa/mesa-gl_13.0.1.bb
rename to meta/recipes-graphics/mesa/mesa-gl_13.0.2.bb
diff --git a/meta/recipes-graphics/mesa/mesa_13.0.1.bb b/meta/recipes-graphics/mesa/mesa_13.0.2.bb
similarity index 91%
rename from meta/recipes-graphics/mesa/mesa_13.0.1.bb
rename to meta/recipes-graphics/mesa/mesa_13.0.2.bb
index 7c9a4b7..ffdd5b4 100644
--- a/meta/recipes-graphics/mesa/mesa_13.0.1.bb
+++ b/meta/recipes-graphics/mesa/mesa_13.0.2.bb
@@ -17,8 +17,8 @@ SRC_URI = "ftp://ftp.freedesktop.org/pub/mesa/${PV}/mesa-${PV}.tar.xz \
file://0012-vc4-Try-compiling-our-FSes-in-multithreaded-mode-on-.patch \
"
-SRC_URI[md5sum] = "72b7f4d0c2407f367484abd201cb8276"
-SRC_URI[sha256sum] = "71962fb2bf77d33b0ad4a565b490dbbeaf4619099c6d9722f04a73187957a731"
+SRC_URI[md5sum] = "9442c2dee914cde3d1f090371ab04113"
+SRC_URI[sha256sum] = "a6ed622645f4ed61da418bf65adde5bcc4bb79023c36ba7d6b45b389da4416d5"
#because we cannot rely on the fact that all apps will use pkgconfig,
#make eglplatform.h independent of MESA_EGL_NO_X11_HEADER
--
2.5.5
^ permalink raw reply related
* [PATCH 2/5] libdrm: update to 2.4.74
From: Andreas Müller @ 2016-12-06 0:19 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1480983561-11437-1-git-send-email-schnitzeltony@googlemail.com>
Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
---
meta/recipes-graphics/drm/{libdrm_2.4.73.bb => libdrm_2.4.74.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-graphics/drm/{libdrm_2.4.73.bb => libdrm_2.4.74.bb} (93%)
diff --git a/meta/recipes-graphics/drm/libdrm_2.4.73.bb b/meta/recipes-graphics/drm/libdrm_2.4.74.bb
similarity index 93%
rename from meta/recipes-graphics/drm/libdrm_2.4.73.bb
rename to meta/recipes-graphics/drm/libdrm_2.4.74.bb
index 3315014..c67d356 100644
--- a/meta/recipes-graphics/drm/libdrm_2.4.73.bb
+++ b/meta/recipes-graphics/drm/libdrm_2.4.74.bb
@@ -16,8 +16,8 @@ SRC_URI = "http://dri.freedesktop.org/libdrm/${BP}.tar.bz2 \
file://0001-configure.ac-Allow-explicit-enabling-of-cunit-tests.patch \
"
-SRC_URI[md5sum] = "bc1cee09cde72ffe3b952e8f50ccdaa8"
-SRC_URI[sha256sum] = "96bfd39242fe168017d95f22e141645a35591f5902a7d98c2fa4ca8c31df5e4d"
+SRC_URI[md5sum] = "31964aa15bdea1a40c5941d4ce0962ee"
+SRC_URI[sha256sum] = "d80dd5a76c401f4c8756dcccd999c63d7e0a3bad258d96a829055cfd86ef840b"
inherit autotools pkgconfig manpages
--
2.5.5
^ permalink raw reply related
* [PATCH 3/5] libsdl2: add EXTRA_OECONF[vardepsexclude] = "MACHINE"
From: Andreas Müller @ 2016-12-06 0:19 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1480983561-11437-1-git-send-email-schnitzeltony@googlemail.com>
fixes Martin's MACHINE checksum test [1]
[1] http://lists.openembedded.org/pipermail/openembedded-core/2016-November/129464.html
Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
---
meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb b/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
index ac7312b..b104a43 100644
--- a/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
+++ b/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
@@ -34,6 +34,7 @@ EXTRA_OECONF = "--disable-oss --disable-esd --disable-arts \
--enable-sdl-dlopen \
--disable-rpath \
WAYLAND_PROTOCOLS_SYSROOT_DIR=${STAGING_DIR}/${MACHINE}"
+EXTRA_OECONF[vardepsexclude] = "MACHINE"
# opengl packageconfig factored out to make it easy for distros
# and BSP layers to pick either (desktop) opengl, gles2, or no GL
--
2.5.5
^ permalink raw reply related
* [PATCH 4/5] libsdl2: add wayland--protocols to to depends of PACKAGECONFIG[wayland]
From: Andreas Müller @ 2016-12-06 0:19 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1480983561-11437-1-git-send-email-schnitzeltony@googlemail.com>
Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
---
meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb b/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
index b104a43..bb75316 100644
--- a/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
+++ b/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
@@ -54,7 +54,7 @@ PACKAGECONFIG[gles2] = "--enable-video-opengles,--disable-video-opengles,vi
PACKAGECONFIG[opengl] = "--enable-video-opengl,--disable-video-opengl,virtual/libgl"
PACKAGECONFIG[pulseaudio] = "--enable-pulseaudio,--disable-pulseaudio,pulseaudio"
PACKAGECONFIG[tslib] = "--enable-input-tslib,--disable-input-tslib,tslib"
-PACKAGECONFIG[wayland] = "--enable-video-wayland,--disable-video-wayland,wayland libxkbcommon"
+PACKAGECONFIG[wayland] = "--enable-video-wayland,--disable-video-wayland,wayland wayland-protocols libxkbcommon"
PACKAGECONFIG[x11] = "--enable-video-x11,--disable-video-x11,virtual/libx11 libxext libxrandr libxrender"
EXTRA_AUTORECONF += "--include=acinclude --exclude=autoheader"
--
2.5.5
^ permalink raw reply related
* [PATCH 5/5] libsdl2: fix build on wayland(-dev)less hosts
From: Andreas Müller @ 2016-12-06 0:19 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1480983561-11437-1-git-send-email-schnitzeltony@googlemail.com>
* add sysroot prefix to wayland core protocols
* do not use pkg-config to find wayland-scanner
Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
---
...-sysroot-path-so-that-make-finds-our-wayl.patch | 8 +++---
...void-finding-build-host-s-wayland-scanner.patch | 31 ++++++++++++++++++++++
meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb | 1 +
3 files changed, 37 insertions(+), 3 deletions(-)
create mode 100644 meta/recipes-graphics/libsdl2/libsdl2/0002-Avoid-finding-build-host-s-wayland-scanner.patch
diff --git a/meta/recipes-graphics/libsdl2/libsdl2/0001-prepend-our-sysroot-path-so-that-make-finds-our-wayl.patch b/meta/recipes-graphics/libsdl2/libsdl2/0001-prepend-our-sysroot-path-so-that-make-finds-our-wayl.patch
index d042430..efc8418 100644
--- a/meta/recipes-graphics/libsdl2/libsdl2/0001-prepend-our-sysroot-path-so-that-make-finds-our-wayl.patch
+++ b/meta/recipes-graphics/libsdl2/libsdl2/0001-prepend-our-sysroot-path-so-that-make-finds-our-wayl.patch
@@ -11,18 +11,20 @@ Upstream-Status: Inappropriate [embedded specific]
Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
---
- configure.in | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
+ configure.in | 4 +-
+ 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.in b/configure.in
index 726ded3..3376600 100644
--- a/configure.in
+++ b/configure.in
@@ -1206,7 +1206,7 @@ AC_HELP_STRING([--enable-video-wayland-qt-touch], [QtWayland server support for
+ WAYLAND_CFLAGS=`$PKG_CONFIG --cflags wayland-client wayland-egl wayland-cursor xkbcommon`
WAYLAND_LIBS=`$PKG_CONFIG --libs wayland-client wayland-egl wayland-cursor xkbcommon`
WAYLAND_SCANNER=`$PKG_CONFIG --variable=wayland_scanner wayland-scanner`
- WAYLAND_CORE_PROTOCOL_DIR=`$PKG_CONFIG --variable=pkgdatadir wayland-client`
+- WAYLAND_CORE_PROTOCOL_DIR=`$PKG_CONFIG --variable=pkgdatadir wayland-client`
- WAYLAND_PROTOCOLS_DIR=`$PKG_CONFIG --variable=pkgdatadir wayland-protocols`
++ WAYLAND_CORE_PROTOCOL_DIR=${WAYLAND_PROTOCOLS_SYSROOT_DIR}`$PKG_CONFIG --variable=pkgdatadir wayland-client`
+ WAYLAND_PROTOCOLS_DIR=${WAYLAND_PROTOCOLS_SYSROOT_DIR}`$PKG_CONFIG --variable=pkgdatadir wayland-protocols`
video_wayland=yes
fi
diff --git a/meta/recipes-graphics/libsdl2/libsdl2/0002-Avoid-finding-build-host-s-wayland-scanner.patch b/meta/recipes-graphics/libsdl2/libsdl2/0002-Avoid-finding-build-host-s-wayland-scanner.patch
new file mode 100644
index 0000000..7837315
--- /dev/null
+++ b/meta/recipes-graphics/libsdl2/libsdl2/0002-Avoid-finding-build-host-s-wayland-scanner.patch
@@ -0,0 +1,31 @@
+From ae879091cf65cb70293b375ec7e61ed12a96d8a7 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andreas=20M=C3=BCller?= <schnitzeltony@googlemail.com>
+Date: Fri, 2 Dec 2016 09:39:25 +0100
+Subject: [PATCH] Avoid finding build host's wayland-scanner
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Upstream-Status: Inappropriate [embedded specific]
+
+Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
+---
+ configure.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/configure.in b/configure.in
+index 3376600..2aa6ed4 100644
+--- a/configure.in
++++ b/configure.in
+@@ -1204,7 +1204,7 @@ AC_HELP_STRING([--enable-video-wayland-qt-touch], [QtWayland server support for
+ if $PKG_CONFIG --exists wayland-client wayland-scanner wayland-protocols wayland-egl wayland-cursor egl xkbcommon ; then
+ WAYLAND_CFLAGS=`$PKG_CONFIG --cflags wayland-client wayland-egl wayland-cursor xkbcommon`
+ WAYLAND_LIBS=`$PKG_CONFIG --libs wayland-client wayland-egl wayland-cursor xkbcommon`
+- WAYLAND_SCANNER=`$PKG_CONFIG --variable=wayland_scanner wayland-scanner`
++ AC_PATH_PROG([WAYLAND_SCANNER], [wayland-scanner])
+ WAYLAND_CORE_PROTOCOL_DIR=${WAYLAND_PROTOCOLS_SYSROOT_DIR}`$PKG_CONFIG --variable=pkgdatadir wayland-client`
+ WAYLAND_PROTOCOLS_DIR=${WAYLAND_PROTOCOLS_SYSROOT_DIR}`$PKG_CONFIG --variable=pkgdatadir wayland-protocols`
+ video_wayland=yes
+--
+2.7.4
+
diff --git a/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb b/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
index bb75316..606e6fb 100644
--- a/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
+++ b/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
@@ -18,6 +18,7 @@ SRC_URI = " \
http://www.libsdl.org/release/SDL2-${PV}.tar.gz \
file://linkage.patch \
file://0001-prepend-our-sysroot-path-so-that-make-finds-our-wayl.patch \
+ file://0002-Avoid-finding-build-host-s-wayland-scanner.patch \
"
S = "${WORKDIR}/SDL2-${PV}"
--
2.5.5
^ permalink raw reply related
* Re: [PATCH 3/5] libsdl2: add EXTRA_OECONF[vardepsexclude] = "MACHINE"
From: Khem Raj @ 2016-12-06 0:24 UTC (permalink / raw)
To: Andreas Müller; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <1480983561-11437-3-git-send-email-schnitzeltony@googlemail.com>
[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]
There probably is no need to use this additional variable. We can just use
PKG_CONFIG_SYSROOT
On Dec 5, 2016 4:19 PM, "Andreas Müller" <schnitzeltony@googlemail.com>
wrote:
> fixes Martin's MACHINE checksum test [1]
>
> [1] http://lists.openembedded.org/pipermail/openembedded-core/
> 2016-November/129464.html
>
> Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
> ---
> meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
> b/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
> index ac7312b..b104a43 100644
> --- a/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
> +++ b/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
> @@ -34,6 +34,7 @@ EXTRA_OECONF = "--disable-oss --disable-esd
> --disable-arts \
> --enable-sdl-dlopen \
> --disable-rpath \
> WAYLAND_PROTOCOLS_SYSROOT_DIR=${STAGING_DIR}/${MACHINE}"
> +EXTRA_OECONF[vardepsexclude] = "MACHINE"
>
> # opengl packageconfig factored out to make it easy for distros
> # and BSP layers to pick either (desktop) opengl, gles2, or no GL
> --
> 2.5.5
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
[-- Attachment #2: Type: text/html, Size: 2573 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox