Re: [yocto] [OE-core] Patchwork and incoming patch testing
On Wed 2017-01-18 @ 07:05:58 AM, Paul Eggleton wrote: > This should give us a bit more visibility into > where patches are at in the process, although we are still working on a few > places where patch series status needs to be updated (e.g. when a patch goes > into testing). Is the testing process for OE patches formalized? I'm not referring to the Yocto Project's release testing. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Flatbuffers
Curious if anyone has ever built googles flatbuffers for embedded and whether or not they might share their recipe? Thanks, Terry -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [Openembedded-architecture] Patchwork and incoming patch testing
I was replying to the wrong mailing list. Sorry for the spam. :( On 01/18/2017 04:40 PM, Jose Lamego wrote: > > On 01/18/2017 08:52 AM, Leonardo Sandoval wrote: >> + Jose Lamego >> >> >> Jose is doing recent work on the patchwork UI, perhaps there are already >> bugs for the items you are asking. >> >> >> On 01/18/2017 02:40 AM, Jussi Kukkonen wrote: >>> This looks great, thanks. >>> >>> On 17 January 2017 at 20:05, Paul Eggleton >>> mailto:paul.eggle...@linux.intel.com>> >>> wrote: >>> >>> In any event we are now finally in the >>> position where our patchwork instance can be relied upon to >>> collect emails, >>> and the UI is much improved. This should give us a bit more >>> visibility into >>> where patches are at in the process, although we are still working >>> on a few >>> places where patch series status needs to be updated (e.g. when a >>> patch goes >>> into testing). >>> >>> >>> What's the plan for these status updates -- is the idea that you go to >>> patchwork UI to see the state of a specific patch set? >>> Or maybe a reply to either patch sender or even the ML? >>> There is a request to enable email notifications to submitter for patch status changes in the future: https://bugzilla.yoctoproject.org/show_bug.cgi?id=7684 The idea is that users should have the option to use what they prefer: either the email notifications, or the patchwork web interface. > >>> On top of patchwork we have built a simple smoke-testing framework >>> called >>> "patchtest" [5] along with a suite of corresponding tests for OE >>> [6]. These >>> tests are fairly simplistic at this point but check the basics >>> such as whether >>> a patch has been properly signed off, etc. We should soon start >>> seeing replies >>> sent to the mailing list and to submitters with results if there >>> are any >>> failures, saving us from noticing and pointing out some of the >>> more obvious >>> classes of mistakes. >>> >>> >>> Is there a reason for patchwork only showing "success" or "failure" >>> in the web ui, instead of linking to test results at least in in the >>> failure case? >> >> Jussi, that is a good idea. Right now we need to click into the series, >> then into the patches and then one can see the patch test results, >> obviously, not the best way. >> >>> >>> >>> >>> - Jussi >>> -- Jose Lamego | OTC Embedded Platforms & Tools | GDC signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [layerindex-web][PATCH 1/2] views.py: Redirect to recipe details for single results
From: Alex Franco
When a recipe search returns only one result, clicking the single
result at the results view is still required to view further
recipe detail.
This change automatically redirects to the recipe details view
when the recipe search returns a single result.
[YOCTO #6618]
Signed-off-by: Jose Lamego
---
layerindex/views.py | 8
1 file changed, 8 insertions(+)
diff --git a/layerindex/views.py b/layerindex/views.py
index 0f73e93..03fadbb 100644
--- a/layerindex/views.py
+++ b/layerindex/views.py
@@ -372,6 +372,14 @@ class RecipeSearchView(ListView):
context_object_name = 'recipe_list'
paginate_by = 50
+def render_to_response(self, context, **kwargs):
+if len(self.object_list) == 1:
+return HttpResponseRedirect("/layerindex/recipe/%s/"
+% self.object_list[0].id)
+else:
+return super(ListView, self).render_to_response(context,
+**kwargs)
+
def get_queryset(self):
_check_url_branch(self.kwargs)
query_string = self.request.GET.get('q', '')
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [layerindex-web][PATCH 2/2] views.py: Consider layer name in recipe search
From: Alex Franco Recipe search cannot be narrowed to a specific layer, producing unnecessary results. This change allows including a layers name when searching for recipes to narrow the yielded results by adding a layer name to the simplesearch.getquery call in the recipe search view. [YOCTO #6618] Signed-off-by: Jose Lamego --- layerindex/views.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/layerindex/views.py b/layerindex/views.py index 03fadbb..5db6fbc 100644 --- a/layerindex/views.py +++ b/layerindex/views.py @@ -406,7 +406,8 @@ class RecipeSearchView(ListView): qs0 = init_qs.filter(pn=query_string).order_by(*order_by) qs0 = recipes_preferred_count(qs0) -entry_query = simplesearch.get_query(query_string, ['pn']) +entry_query = simplesearch.get_query( +query_string, ['pn', 'layerbranch__layer__name']) qs1 = init_qs.filter(entry_query).order_by(*order_by) qs1 = recipes_preferred_count(qs1) -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [layerindex-web][PATCH 0/2] Improvements to recipe search
These changes improve recipe searches in the OpenEmbedded Layer Index by allowing the layer name to be include as parameter to search and automatically redirecting to the recipe details view when a single result is yielded. [YOCTO #6618] Alex Franco (2): views.py: Redirect to recipe details for single results views.py: Consider layer name in recipe search layerindex/views.py | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Changing over to systemd (no dhcp)
On Wed, Jan 18, 2017 at 7:10 AM, wrote:
> We have a configuration for our embedded system which is working via SysV,
> but we’re investigating moving over to systemd.
>
> Not sure if this is ‘wise’ – if anyone has technological arguments
> for/against then I’d be interested – but I wanted to investigate it anyway.
>
> I’ve modified local.conf (right or wrong) with
>
> DISTRO_FEATURES_append = " systemd"
> VIRTUAL-RUNTIME_init_manager = "systemd"
> DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
> VIRTUAL-RUNTIME_initscripts = ""
> KERNEL_ENABLE_CGROUPS = "1"
>
> I also found a readme
> (https://cgit.freedesktop.org/systemd/systemd/tree/README#n37) about the
> kernel requirements for systemd, and it does at least now boot.
>
> However although eth0 is coming up (‘ifconfig eth0’), there doesn’t seem to
> be any dhcp happening – no IP etc.
>
> Previously (under SysV) I had the busybox dhcp client; now it seems that is
> missing. There’s a symlink /etc/systemd/system/busybox-udhcpc.service to
> /dev/null
>
> I’m using
>
> Poky Jethro
> Kernel 4.4.0
> Busybox 1.23.2 (with ‘CONFIG_FEATURE_SYSTEMD=y’)
>
> I wondered if this is just a simple switch I’m missing somewhere, or is
> there a whole load more modifications I need to dig into and hand-craft?
> (Was hoping for something ‘out of the box’….)
Try:
VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"
Enabling systemd is somewhat documented by the example in
{meta-poky,openembedded-core/meta}/conf/local.conf.sample.extended,
which is:
#
# Use systemd for system initialization
#
# DISTRO_FEATURES_append = " systemd"
# DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
# VIRTUAL-RUNTIME_init_manager = "systemd"
# VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Openembedded-architecture] Layer index enhancements
On Wed, 18 Jan 2017 23:02:00 Paul Eggleton wrote: > * We now pick up layer dependencies (and recommends) specified in the > layer.conf, but only if they match the layer name - we don't handle > collection names yet, so this won't currently work where the collection > name doesn't match the layer name (e.g. oe-core, meta-oe...). I was wrong about this - the collection name is collected and used in the dependency resolution. New layers / branches should have this information populated, however we haven't collected collection names for all of the existing layers. I have just gone in and checked meta-oe and oe-core are set up for master, morty, krogoth & jethro. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 0/2] Drop kernel versions 4.7 and 4.8
Andrei, On Wed, Jan 18, 2017 at 5:30 PM, Andrei Gherzan wrote: > On Wed, Jan 18, 2017 at 05:24:05PM +0100, Leon Woestenberg wrote: > > On Wed, Jan 18, 2017 at 4:40 PM, Andrei Gherzan > wrote: > > > > > > > > Based we should only keep 4.4 and 4.10 (or 4.9). > > > > > > Ane comments before I proceed? :) > > > > > > > > I think keeping 4.9 (Long Term Support kernel) for sure. > > Is it? > https://www.kernel.org/category/releases.html > > The maintainer says so: https://plus.google.com/+gregkroahhartman/posts/DjCWwSo7kqY Regards, Leon. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [[PATCH][yocto-autobuilder] 1/2] buildsteps/CreateAutoConf.py: Add support for specify MACHINE by build prop
On 01/18/2017 12:13 PM, Joshua Lock wrote:
> On Mon, 2017-01-16 at 10:25 -0600, Aníbal Limón wrote:
>> Sometimes is a good idea to could specify a machine to build via a
>> build
>> property.
>
> Why's that? I can guess but the commit log should really tell me what
> the motivation for the change is.
In the performance buildset patch [1] there is a build property to
specify the machine via the web interface, without this change the
machine is overwrite to predefined in the buildset.
Cheers,
alimon
[1]
http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/tree/buildset-config.yocto-qa/nightly-oe-build-perf-test.conf?h=contrib/alimon/devel&id=6c25a37cd801f2cdecc21c76499625a117e08ff7#n7
>
>>
>> Signed-off-by: Aníbal Limón
>> ---
>> .../site-
>> packages/autobuilder/buildsteps/CreateAutoConf.py | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/lib/python2.7/site-
>> packages/autobuilder/buildsteps/CreateAutoConf.py
>> b/lib/python2.7/site-
>> packages/autobuilder/buildsteps/CreateAutoConf.py
>> index 021f542..7915dd5 100644
>> --- a/lib/python2.7/site-
>> packages/autobuilder/buildsteps/CreateAutoConf.py
>> +++ b/lib/python2.7/site-
>> packages/autobuilder/buildsteps/CreateAutoConf.py
>> @@ -174,7 +174,11 @@ class CreateAutoConf(ShellCommand):
>> fout = fout + 'baselib = \\042${@d.getVar(\\047B
>> ASE_LIB_tune-\\047 + (d.getVar(\\047DEFAULTTUNE\\047, True) or
>> \\047INVALID\\047), True) or \\047lib\\047}\\042 \n'
>> if self.distro == "poky-rt":
>> fout = fout +
>> 'PREFERRED_PROVIDER_virtual/kernel="linux-yocto-rt" \n'
>> -machine=self.machine
>> +machine=self.getProperty('custom_machine')
>> +if machine:
>> +self.machine = machine
>> +else:
>> +machine = self.machine
>> if layerversion is not None and int(layerversion) > 1:
>> if self.machine == "atom-pc":
>> machine = self.machine.replace("atom-pc",
>> "genericx86")
signature.asc
Description: OpenPGP digital signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [[PATCH][yocto-autobuilder] 1/2] buildsteps/CreateAutoConf.py: Add support for specify MACHINE by build prop
On Mon, 2017-01-16 at 10:25 -0600, Aníbal Limón wrote:
> Sometimes is a good idea to could specify a machine to build via a
> build
> property.
Why's that? I can guess but the commit log should really tell me what
the motivation for the change is.
>
> Signed-off-by: Aníbal Limón
> ---
> .../site-
> packages/autobuilder/buildsteps/CreateAutoConf.py | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/lib/python2.7/site-
> packages/autobuilder/buildsteps/CreateAutoConf.py
> b/lib/python2.7/site-
> packages/autobuilder/buildsteps/CreateAutoConf.py
> index 021f542..7915dd5 100644
> --- a/lib/python2.7/site-
> packages/autobuilder/buildsteps/CreateAutoConf.py
> +++ b/lib/python2.7/site-
> packages/autobuilder/buildsteps/CreateAutoConf.py
> @@ -174,7 +174,11 @@ class CreateAutoConf(ShellCommand):
> fout = fout + 'baselib = \\042${@d.getVar(\\047B
> ASE_LIB_tune-\\047 + (d.getVar(\\047DEFAULTTUNE\\047, True) or
> \\047INVALID\\047), True) or \\047lib\\047}\\042 \n'
> if self.distro == "poky-rt":
> fout = fout +
> 'PREFERRED_PROVIDER_virtual/kernel="linux-yocto-rt" \n'
> -machine=self.machine
> +machine=self.getProperty('custom_machine')
> +if machine:
> +self.machine = machine
> +else:
> +machine = self.machine
> if layerversion is not None and int(layerversion) > 1:
> if self.machine == "atom-pc":
> machine = self.machine.replace("atom-pc",
> "genericx86")
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/2] linux-raspberrypi_4.4: Update to 4.4.43
Signed-off-by: Andrei Gherzan
---
recipes-kernel/linux/linux-raspberrypi_4.4.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/recipes-kernel/linux/linux-raspberrypi_4.4.bb
b/recipes-kernel/linux/linux-raspberrypi_4.4.bb
index 3317c02..0f78225 100644
--- a/recipes-kernel/linux/linux-raspberrypi_4.4.bb
+++ b/recipes-kernel/linux/linux-raspberrypi_4.4.bb
@@ -1,8 +1,8 @@
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-LINUX_VERSION ?= "4.4.39"
+LINUX_VERSION ?= "4.4.43"
-SRCREV = "5e46914b3417fe9ff42546dcacd0f41f9a0fb172"
+SRCREV = "17ca1c930978a9ea6ddfec61fd0e2043e8ab3b17"
SRC_URI =
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.4.y \
file://0001-fix-dtbo-rules.patch \
"
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 2/2] linux-raspberrypi_4.9: Update to 4.9.4
On Wed, Jan 18, 2017 at 06:34:02PM +0100, Andrei Gherzan wrote:
> Signed-off-by: Andrei Gherzan
> ---
> recipes-kernel/linux/linux-raspberrypi_4.9.bb | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/recipes-kernel/linux/linux-raspberrypi_4.9.bb
> b/recipes-kernel/linux/linux-raspberrypi_4.9.bb
> index 20f43aa..cffea1a 100644
> --- a/recipes-kernel/linux/linux-raspberrypi_4.9.bb
> +++ b/recipes-kernel/linux/linux-raspberrypi_4.9.bb
> @@ -1,8 +1,8 @@
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
>
> -LINUX_VERSION ?= "4.9.2"
> +LINUX_VERSION ?= "4.9.4"
>
> -SRCREV = "4052b0da7dbab0df22ca8733cf50b3e573e221e0"
> +SRCREV = "8b0be887f834e7eccf0de3edf630003880779a5f"
> SRC_URI =
> "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.9.y \
> "
> require linux-raspberrypi.inc
> --
> 2.7.4
>
Merged both to master.
--
Andrei Gherzan
signature.asc
Description: PGP signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/2] linux-raspberrypi_4.9: Update to 4.9.4
Signed-off-by: Andrei Gherzan
---
recipes-kernel/linux/linux-raspberrypi_4.9.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/recipes-kernel/linux/linux-raspberrypi_4.9.bb
b/recipes-kernel/linux/linux-raspberrypi_4.9.bb
index 20f43aa..cffea1a 100644
--- a/recipes-kernel/linux/linux-raspberrypi_4.9.bb
+++ b/recipes-kernel/linux/linux-raspberrypi_4.9.bb
@@ -1,8 +1,8 @@
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-LINUX_VERSION ?= "4.9.2"
+LINUX_VERSION ?= "4.9.4"
-SRCREV = "4052b0da7dbab0df22ca8733cf50b3e573e221e0"
+SRCREV = "8b0be887f834e7eccf0de3edf630003880779a5f"
SRC_URI =
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.9.y \
"
require linux-raspberrypi.inc
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] gstreamer1.0-omx: Add 1.10x support
On Sat, Dec 31, 2016 at 01:28:46PM -0800, Khem Raj wrote:
> On Thu, Dec 29, 2016 at 10:16 AM, Andrei Gherzan wrote:
> > On Wed, Dec 21, 2016 at 11:59:21PM -0800, Khem Raj wrote:
> >> Restructure the bbappends such that common portions
> >> can be put in a common bbappend and version specific
> >> bbappend then only do the patching
> >>
> >> Signed-off-by: Khem Raj
> >> ---
> >> .../gstreamer/gstreamer1.0-omx%.bbappend | 9 ++
> >> ...o-acquire-buffer-when-src-pad-isn-t-activ.patch | 48
> >> .../0001-config-files-path.patch | 137
> >> +
> >> .../0002-fix-decoder-flushing.patch| 16 +++
> >> .../0003-no-timeout-on-get-state.patch | 16 +++
> >> ...erly-handle-drain-requests-while-flushing.patch | 30 +
> >> ...-gst_omx_video_dec_set_format-if-there-s-.patch | 30 +
> >> .../gstreamer/gstreamer1.0-omx_1.10%.bbappend | 13 ++
> >> .../gstreamer/gstreamer1.0-omx_1.2.0.bbappend | 10 --
> >> .../gstreamer/gstreamer1.0-omx_git.bbappend| 9 --
> >> 10 files changed, 299 insertions(+), 19 deletions(-)
> >> create mode 100644 recipes-multimedia/gstreamer/gstreamer1.0-omx%.bbappend
> >> create mode 100644
> >> recipes-multimedia/gstreamer/gstreamer1.0-omx-1.10/0001-Don-t-try-to-acquire-buffer-when-src-pad-isn-t-activ.patch
> >> create mode 100644
> >> recipes-multimedia/gstreamer/gstreamer1.0-omx-1.10/0001-config-files-path.patch
> >> create mode 100644
> >> recipes-multimedia/gstreamer/gstreamer1.0-omx-1.10/0002-fix-decoder-flushing.patch
> >> create mode 100644
> >> recipes-multimedia/gstreamer/gstreamer1.0-omx-1.10/0003-no-timeout-on-get-state.patch
> >> create mode 100644
> >> recipes-multimedia/gstreamer/gstreamer1.0-omx-1.10/0004-Properly-handle-drain-requests-while-flushing.patch
> >> create mode 100644
> >> recipes-multimedia/gstreamer/gstreamer1.0-omx-1.10/0005-Don-t-abort-gst_omx_video_dec_set_format-if-there-s-.patch
> >> create mode 100644
> >> recipes-multimedia/gstreamer/gstreamer1.0-omx_1.10%.bbappend
> >>
> >> diff --git a/recipes-multimedia/gstreamer/gstreamer1.0-omx%.bbappend
> >> b/recipes-multimedia/gstreamer/gstreamer1.0-omx%.bbappend
> >> new file mode 100644
> >> index 000..67e46de
> >> --- /dev/null
> >> +++ b/recipes-multimedia/gstreamer/gstreamer1.0-omx%.bbappend
> >
> > Is the wildcard working like this? A potentially TIL
> >
> >> @@ -0,0 +1,9 @@
> >> +GSTREAMER_1_0_OMX_TARGET_rpi = "rpi"
> >> +GSTREAMER_1_0_OMX_CORE_NAME_rpi = "${libdir}/libopenmaxil.so"
> >> +
> >> +
> >> +# How to make this RPI specific?
> >> +EXTRA_OECONF_append_rpi = " CFLAGS="$CFLAGS
> >> -I${STAGING_DIR_TARGET}/usr/include/IL
> >> -I${STAGING_DIR_TARGET}/usr/include/interface/vcos/pthreads
> >> -I${STAGING_DIR_TARGET}/usr/include/interface/vmcs_host/linux""
> >> +#examples only build with GL but not GLES, so disable it for RPI
> >> +EXTRA_OECONF_append_rpi = " --disable-examples"
> >> +
> >> diff --git
> >> a/recipes-multimedia/gstreamer/gstreamer1.0-omx-1.10/0001-Don-t-try-to-acquire-buffer-when-src-pad-isn-t-activ.patch
> >>
> >> b/recipes-multimedia/gstreamer/gstreamer1.0-omx-1.10/0001-Don-t-try-to-acquire-buffer-when-src-pad-isn-t-activ.patch
> >> new file mode 100644
> >> index 000..815a7c2
> >> --- /dev/null
> >> +++
> >> b/recipes-multimedia/gstreamer/gstreamer1.0-omx-1.10/0001-Don-t-try-to-acquire-buffer-when-src-pad-isn-t-activ.patch
> >> @@ -0,0 +1,48 @@
> >> +From 2e111e52f96f0b942abda120c30a876629bd73fc Mon Sep 17 00:00:00 2001
> >> +From: =?UTF-8?q?Enrique=20Oca=C3=B1a=20Gonz=C3=A1lez?=
> >>
> >> +Date: Mon, 25 May 2015 14:53:35 +0200
> >> +Subject: [PATCH] Don't try to acquire buffer when src pad isn't active
> >> +
> >> +This solves a race condition when setting the pipeline from PAUSE to
> >> +NULL while the decoder loop is still running. Without this patch, the
> >> +thread which interacts with the decode sink pad gets blocked here:
> >> +
> >> + gst_element_change_state()
> >> + gst_element_change_state_func()
> >> + gst_element_pads_activate() --> Deactivating pads
> >> + activate_pads()
> >> + gst_pad_set_active()
> >> + gst_pad_activate_mode()
> >> + post_activate()
> >> + GST_PAD_STREAM_LOCK()
> >> +
> >> +while gst_omx_port_acquire_buffer() gets stalled forever in
> >> +gst_omx_component_wait_message() waiting for a message that will never
> >> +arrive:
> >> +
> >> + gst_omx_video_dec_loop()
> >> + gst_omx_port_acquire_buffer()
> >> + gst_omx_component_wait_message()
> >> +---
> >> + omx/gstomxvideodec.c | 5 +
> >> + 1 file changed, 5 insertions(+)
> >> +
> >> +diff --git a/omx/gstomxvideodec.c b/omx/gstomxvideodec.c
> >> +index cd24944..57a61dd 100644
> >> +--- a/omx/gstomxvideodec.c
> >> b/omx/gstomxvideodec.c
> >> +@@ -1247,6 +1247,11 @@ gst_omx_video_dec_loop (GstOMXVideoDec * self)
> >> + GstClockTimeDiff deadline;
> >> + OMX_ERRORTYPE err;
> >> +
> >> ++ if (!gst_pad_is_active(GST_VIDEO_DECODER_SRC_PAD (s
Re: [yocto] [meta-raspberrypi][PATCH v2] linux-raspberrypi-rt: add
On Thu, Jan 05, 2017 at 10:54:01PM -0500, Trevor Woerner wrote: > On Thu, Jan 5, 2017 at 4:59 PM, Paul Barker wrote: > > On Thu, 5 Jan 2017 15:16:19 -0500 > > Trevor Woerner wrote: > > > >> On Thu 2017-01-05 @ 07:33:38 PM, Paul Barker wrote: > >> > On Thu, 5 Jan 2017 12:42:29 -0500 > >> > Trevor Woerner wrote: > >> > > >> > > Add an -rt kernel recipe for Raspberry Pi that includes the FIQ patch > >> > > which > >> > > adds stability to the -rt kernel (with full preemption enabled) and is > >> > > an > >> > > improvement to simply disabling FIQ on the kernel cmdline. > >> > > > >> > > Signed-off-by: Trevor Woerner > >> > > --- > >> > > > >> > > changes since v1: > >> > > - use "make savedefconfig" to generate the defconfig instead of just > >> > > using the full .config > >> > > > >> > > .../0001-fix-dtbo-rules.patch |44 + > >> > > .../FIQ_PREEMPT_RT_on_raspi.patch | 310 + > >> > > .../linux/linux-raspberrypi-rt-4.4/defconfig | 1249 + > >> > > .../patch-4.4.32-rt43.patch| 31403 > >> > > +++ > >> > > recipes-kernel/linux/linux-raspberrypi-rt_4.4.bb |55 + > >> > > 5 files changed, 33061 insertions(+) > >> > > create mode 100644 > >> > > recipes-kernel/linux/linux-raspberrypi-rt-4.4/0001-fix-dtbo-rules.patch > >> > > create mode 100644 > >> > > recipes-kernel/linux/linux-raspberrypi-rt-4.4/FIQ_PREEMPT_RT_on_raspi.patch > >> > > create mode 100644 > >> > > recipes-kernel/linux/linux-raspberrypi-rt-4.4/defconfig > >> > > create mode 100644 > >> > > recipes-kernel/linux/linux-raspberrypi-rt-4.4/patch-4.4.32-rt43.patch > >> > > create mode 100644 recipes-kernel/linux/linux-raspberrypi-rt_4.4.bb > >> > > > >> > > >> > Would it be possible to point SRC_URI at kernel.org [1] instead of > >> > including the whole patch in meta-raspberrypi? It feels a bit much to > >> > me to include a >1MB patch file. > >> > > >> > [1]: > >> > https://www.kernel.org/pub/linux/kernel/projects/rt/4.4/older/patch-4.4.32-rt43.patch.gz > >> > >> The "virgin" -rt patch from kernel.org doesn't apply cleanly. First off > >> there > >> is a slight version mismatch and secondly this is the raspberrypi kernel, > >> not > >> a pure upstream kernel. > >> > >> Is there a way to patch a patch before it gets applied? If it could be > >> fetched from kernel.org then patched before applying that would be ideal! > >> The diff isn't that big; it's sad to have to provide a >1MB patch for such > >> a small tweak. I guess that's why the yocto kernels/patches have their own > >> repositories on yoctoproject.org? > > > > I think it depends how you want to maintain it going forward. With > > frequent upgrades to linux-raspberrypi I can see that >1MB patch being > > modified very often and I'm not sure how good it will be for the git > > repository size and efficiency. > > Okay, agreed. > > > A linux-raspberrypi-rt repository on GitLab[1] or some other git hosting > > service may be a good idea. I can see this having value outside the > > OpenEmbedded/Yocto Project world, especially if the vanilla -rt patches > > don't directly apply to linux-raspberrypi. If you decide to go this > > route and need any support to make it happen, let me know and I'll see > > what I can do. I vote for a rt repository externally maintained too. Having it here might not be the best idea on the long term. > > Sounds good... and Wow! GitLab looks awesome! I guess I'll look at how > the yocto kernels are managed and see if it applies. > Does it? :) > > Also, are you thinking of moving the -rt recipe to the 4.9 series when > > upstream linux-raspberrypi declares that stable? > > Yes. > > > When they declared 4.4 > > stable they stopped updating the 4.1 series pretty much immediately. I'm > > currently investigating whether there is any value in maintaining the > > 4.4 series ourselves after upstream moves on. > > I want to see how managing one goes. > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- Andrei Gherzan signature.asc Description: PGP signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 0/2] Drop kernel versions 4.7 and 4.8
On Wed, Jan 18, 2017 at 05:24:05PM +0100, Leon Woestenberg wrote: > On Wed, Jan 18, 2017 at 4:40 PM, Andrei Gherzan wrote: > > > > > Based we should only keep 4.4 and 4.10 (or 4.9). > > > > Ane comments before I proceed? :) > > > > > I think keeping 4.9 (Long Term Support kernel) for sure. Is it? https://www.kernel.org/category/releases.html > > Regards, > > Leon. -- Andrei Gherzan signature.asc Description: PGP signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 0/2] Drop kernel versions 4.7 and 4.8
On Wed, Jan 18, 2017 at 4:40 PM, Andrei Gherzan wrote: > > Based we should only keep 4.4 and 4.10 (or 4.9). > > Ane comments before I proceed? :) > > I think keeping 4.9 (Long Term Support kernel) for sure. Regards, Leon. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 0/2] Drop kernel versions 4.7 and 4.8
On Mon, Jan 16, 2017 at 07:26:55AM +, Paul Barker wrote: > As discussed recently on the list, we can just keep LTS versions now > that v4.9 is available. > > I'm sending these so anyone who still needs v4.7 or v4.8 can shout > 'stop!' before we remove them. > > Paul Barker (2): > linux-raspberrypi: Drop v4.7 > linux-raspberrypi: Drop v4.8 > > .../0001-fix-dtbo-rules.patch | 44 > -- > recipes-kernel/linux/linux-raspberrypi_4.7.bb | 9 - > recipes-kernel/linux/linux-raspberrypi_4.8.bb | 8 > 3 files changed, 61 deletions(-) > delete mode 100644 > recipes-kernel/linux/linux-raspberrypi-4.7/0001-fix-dtbo-rules.patch > delete mode 100644 recipes-kernel/linux/linux-raspberrypi_4.7.bb > delete mode 100644 recipes-kernel/linux/linux-raspberrypi_4.8.bb > > -- > 2.1.4 > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto Merged to master. -- Andrei Gherzan signature.asc Description: PGP signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 0/3] Kernel update and getVar cleanup
On Mon, Jan 02, 2017 at 01:20:10PM +, Paul Barker wrote: > These patches have been boot tested for both raspberrypi and raspberrypi3. > > The first patch in the series probably breaks things for the morty branch. I'm > also proposing we drop support for linux-raspberrypi v4.1 as it's currently > broken on master. We should create a morty branch for meta-raspberrypi before > applying these patches. > > Any objections to dropping linux-raspberrypi v4.1 or making a morty branch at > this point? > Created a morty branch and merged these patches in master. Thank you. -- Andrei Gherzan signature.asc Description: PGP signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 0/3] Kernel update and getVar cleanup
On Mon, Jan 16, 2017 at 07:15:23AM +, Paul Barker wrote: > On Mon, 2 Jan 2017 13:20:10 + > Paul Barker wrote: > > > These patches have been boot tested for both raspberrypi and raspberrypi3. > > > > The first patch in the series probably breaks things for the morty branch. > > I'm > > also proposing we drop support for linux-raspberrypi v4.1 as it's currently > > broken on master. We should create a morty branch for meta-raspberrypi > > before > > applying these patches. > > > > Any objections to dropping linux-raspberrypi v4.1 or making a morty branch > > at > > this point? > > > > Paul Barker (3): > > Remove True option to getVar calls > > linux-raspberrypi: Drop v4.1 > > linux-raspberrypi: Upgrade to v4.4.39 > > > > classes/linux-raspberrypi-base.bbclass | 4 +- > > .../0001-dts-add-overlay-for-pitft22.patch | 110 > > - > > ...ove-unused-sm_cache_map_vector-definition.patch | 31 -- > > .../linux-raspberrypi-4.1/0003-fix-gcc6.patch | 78 --- > > recipes-kernel/linux/linux-raspberrypi.inc | 4 +- > > recipes-kernel/linux/linux-raspberrypi_4.1.bb | 12 --- > > recipes-kernel/linux/linux-raspberrypi_4.4.bb | 4 +- > > 7 files changed, 6 insertions(+), 237 deletions(-) > > delete mode 100644 > > recipes-kernel/linux/linux-raspberrypi-4.1/0001-dts-add-overlay-for-pitft22.patch > > delete mode 100644 > > recipes-kernel/linux/linux-raspberrypi-4.1/0002-vmcs-Remove-unused-sm_cache_map_vector-definition.patch > > delete mode 100644 > > recipes-kernel/linux/linux-raspberrypi-4.1/0003-fix-gcc6.patch > > delete mode 100644 recipes-kernel/linux/linux-raspberrypi_4.1.bb > > > > Ping on this patch series. On it right now. -- Andrei Gherzan signature.asc Description: PGP signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 0/2] Drop kernel versions 4.7 and 4.8
On Mon, Jan 16, 2017 at 03:12:51PM +, Paul Barker wrote: > On 16 January 2017 14:51:55 GMT+00:00, Gary Thomas wrote: > >On 2017-01-16 15:48, Gary Thomas wrote: > >> On 2017-01-16 08:26, Paul Barker wrote: > >>> As discussed recently on the list, we can just keep LTS versions now > >>> that v4.9 is available. > >>> > >>> I'm sending these so anyone who still needs v4.7 or v4.8 can shout > >>> 'stop!' before we remove them. > >>> > >>> Paul Barker (2): > >>> linux-raspberrypi: Drop v4.7 > >>> linux-raspberrypi: Drop v4.8 > >>> > >>> .../0001-fix-dtbo-rules.patch | 44 > >-- > >>> recipes-kernel/linux/linux-raspberrypi_4.7.bb | 9 - > >>> recipes-kernel/linux/linux-raspberrypi_4.8.bb | 8 > >>> 3 files changed, 61 deletions(-) > >>> delete mode 100644 > >recipes-kernel/linux/linux-raspberrypi-4.7/0001-fix-dtbo-rules.patch > >>> delete mode 100644 recipes-kernel/linux/linux-raspberrypi_4.7.bb > >>> delete mode 100644 recipes-kernel/linux/linux-raspberrypi_4.8.bb > >>> > >> > >> +1 at least for 4.7 given that with today's repo I get this: > >> > >> ERROR: linux-raspberrypi-1_4.7.7+gitAUTOINC+c2cbd9c611-r0 > >do_kernel_version_sanity_check: Package Version > >> (4.7.7+gitAUTOINC+c2cbd9c611) does not match of kernel being built > >(4.7.10). Please update the PV variable to match the > >> kernel source. > >> ERROR: linux-raspberrypi-1_4.7.7+gitAUTOINC+c2cbd9c611-r0 > >do_kernel_version_sanity_check: Function failed: > >> do_kernel_version_sanity_check (log file is located at > >> > >/build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspberrypi/1_4.7.7+gitAUTOINC+c2cbd9c611-r0/temp/log.do_kernel_version_sanity_check.27925) > >> > >> ERROR: Logfile of failure stored in: > >> > >/build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspberrypi/1_4.7.7+gitAUTOINC+c2cbd9c611-r0/temp/log.do_kernel_version_sanity_check.27925 > >> > >> ERROR: Task > >> > >(/local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.7.bb:do_kernel_version_sanity_check) > >> failed with exit code '1' > >> > > > > > >However, there is this error when I tried to switch to 4.9: > >ERROR: linux-raspberrypi-1_4.9.2+gitAUTOINC+4052b0da7d-r0 do_fetch: > >Fetcher failure: Unable to find revision > >4052b0da7dbab0df22ca8733cf50b3e573e221e0 in branch rpi-4.9.y even from > >upstream > >ERROR: linux-raspberrypi-1_4.9.2+gitAUTOINC+4052b0da7d-r0 do_fetch: > >Fetcher failure for URL: > >'git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.9.y'. > >Unable to fetch URL from any source. > >ERROR: linux-raspberrypi-1_4.9.2+gitAUTOINC+4052b0da7d-r0 do_fetch: > >Function failed: base_do_fetch > >ERROR: Logfile of failure stored in: > >/build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspberrypi/1_4.9.2+gitAUTOINC+4052b0da7d-r0/temp/log.do_fetch.13098 > >ERROR: Task > >(/local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.9.bb:do_fetch) > >failed > >with exit code '1' > > > >Using meta-raspberrypi:e1f69daa805cb02ddd123ae2d4d48035cb5b41d0 > > I think any upstream branch after 4.4.y is still at risk of being rebased at > the minute. I think the best solution is to still drop 4.7.y and 4.8.y, but > try to get an update in for 4.9.y first. I totally agree with this. I left this thread for a while to see if people are really attached to these versions. Our last decision was to keep: 1. last LTS 2. current stable version as considered by the upstream [default] 3. the latest bleading edge Based we should only keep 4.4 and 4.10 (or 4.9). Ane comments before I proceed? :) > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- Andrei Gherzan signature.asc Description: PGP signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Changing over to systemd (no dhcp)
We have a configuration for our embedded system which is working via SysV,
but we're investigating moving over to systemd.
Not sure if this is 'wise' - if anyone has technological arguments
for/against then I'd be interested - but I wanted to investigate it anyway.
I've modified local.conf (right or wrong) with
DISTRO_FEATURES_append = " systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
VIRTUAL-RUNTIME_initscripts = ""
KERNEL_ENABLE_CGROUPS = "1"
I also found a readme
(https://cgit.freedesktop.org/systemd/systemd/tree/README#n37) about the
kernel requirements for systemd, and it does at least now boot.
However although eth0 is coming up ('ifconfig eth0'), there doesn't seem to
be any dhcp happening - no IP etc.
Previously (under SysV) I had the busybox dhcp client; now it seems that is
missing. There's a symlink /etc/systemd/system/busybox-udhcpc.service to
/dev/null
I'm using
Poky Jethro
Kernel 4.4.0
Busybox 1.23.2 (with 'CONFIG_FEATURE_SYSTEMD=y')
I wondered if this is just a simple switch I'm missing somewhere, or is
there a whole load more modifications I need to dig into and hand-craft?
(Was hoping for something 'out of the box'..)
Thanks
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Pulseaudio: build issue
Hi Gowtham, On Wed, Jan 18, 2017 at 12:00:52PM +, Gowtham Pandi wrote: > >Hi All, > >I am using Raspberry Pi 3 model B. I am facing build issues while building >bitbake pulseaudio. > >Please find my configuration details: > >Yocto : Jethro branch >pulseaudio.inc RDEPENDS_pulseaudio-server += "alsa-plugins-pulseaudio-conf" >we are using alsa-plugins_1.0.29.bb >bitbake pulseaudio >ERROR: Nothing RPROVIDES 'alsa-plugins-pulseaudio-conf' > (but > /home/guest/openembedded-core/meta/recipes-multimedia/pulseaudio/pulseaudio_6.0.bb > RDEPENDS on or otherwise requires it) > >NOTE: Runtime target 'alsa-plugins-pulseaudio-conf' is unbuildable, >removing... >Missing or unbuildable dependency chain was: ['alsa-plugins-pulseaudio-conf'] > ERROR: Required build target 'pulseaudio' has no buildable providers. > Missing or unbuildable dependency chain was: ['pulseaudio', > 'alsa-plugins-pulseaudio-conf'] > > >Please share your inputs. Please make sure that "pulseaudio" is present in the 'DISTRO_FEATURES'. To test this, add the following line in your "local.conf" file and build again: DISTRO_FEATURES_append =" pulseaudio" > >Thanks >Gowtham P Best Regards, Maxin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Openembedded-architecture] Patchwork and incoming patch testing
+ Jose Lamego Jose is doing recent work on the patchwork UI, perhaps there are already bugs for the items you are asking. On 01/18/2017 02:40 AM, Jussi Kukkonen wrote: This looks great, thanks. On 17 January 2017 at 20:05, Paul Eggleton mailto:paul.eggle...@linux.intel.com>> wrote: In any event we are now finally in the position where our patchwork instance can be relied upon to collect emails, and the UI is much improved. This should give us a bit more visibility into where patches are at in the process, although we are still working on a few places where patch series status needs to be updated (e.g. when a patch goes into testing). What's the plan for these status updates -- is the idea that you go to patchwork UI to see the state of a specific patch set? Or maybe a reply to either patch sender or even the ML? On top of patchwork we have built a simple smoke-testing framework called "patchtest" [5] along with a suite of corresponding tests for OE [6]. These tests are fairly simplistic at this point but check the basics such as whether a patch has been properly signed off, etc. We should soon start seeing replies sent to the mailing list and to submitters with results if there are any failures, saving us from noticing and pointing out some of the more obvious classes of mistakes. Is there a reason for patchwork only showing "success" or "failure" in the web ui, instead of linking to test results at least in in the failure case? Jussi, that is a good idea. Right now we need to click into the series, then into the patches and then one can see the patch test results, obviously, not the best way. - Jussi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Pulseaudio: build issue
Hi All, I am using Raspberry Pi 3 model B. I am facing build issues while building bitbake pulseaudio. Please find my configuration details: Yocto : Jethro branch pulseaudio.inc RDEPENDS_pulseaudio-server += "alsa-plugins-pulseaudio-conf" we are using alsa-plugins_1.0.29.bb bitbake pulseaudio ERROR: Nothing RPROVIDES 'alsa-plugins-pulseaudio-conf' (but /home/guest/openembedded-core/meta/recipes-multimedia/pulseaudio/pulseaudio_6.0.bb RDEPENDS on or otherwise requires it) NOTE: Runtime target 'alsa-plugins-pulseaudio-conf' is unbuildable, removing... Missing or unbuildable dependency chain was: ['alsa-plugins-pulseaudio-conf'] ERROR: Required build target 'pulseaudio' has no buildable providers. Missing or unbuildable dependency chain was: ['pulseaudio', 'alsa-plugins-pulseaudio-conf'] Please share your inputs. Thanks Gowtham P -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Whats the better way to maintain the Yocto project for an embedded product - git submodules or repo or using Combo-layer
> -Original Message- > From: yocto-boun...@yoctoproject.org [mailto:yocto- > boun...@yoctoproject.org] On Behalf Of Paul Barker > Sent: Wednesday, January 18, 2017 11:09 AM > To: yocto@yoctoproject.org; Eswaran Vinothkumar (BEG-PT/PJ-IOT1) > > Subject: Re: [yocto] Whats the better way to maintain the Yocto project for > an embedded product - git submodules or repo or using Combo-layer > > On 18 January 2017 09:32:15 GMT+00:00, "Eswaran Vinothkumar (BEG-PT/PJ- > IOT1)" wrote: > >Hello Yocto community members, > > > >Currently I am working on the task of using Yocto to build customized > >Embedded Linux distribution for an embedded product. I have created a > >new BSP layer for my project (meta-custommachine) and have successfully > >created barebox, Linux Kernel and root filesystem images for my board. > > > >Now I wish to create an internal repository for Yocto project to track > >and maintain the changes. I am unclear what is the better way to create > >an repository. I googled for the same and found that the Freescale > >community is maintaining their Yocto project using the repo tool. So I > >tried to have a similar structure for my project. I created a repo with > >the default.xml file which has the information about where to fetch the > >repositories for poky, meta-ptx and meta-custommachine. I am seeing the > >folder structures as expected and build is also fine. > > > >I had a discussion with one of my senior team member about this and he > >is interested in using git submodules. So I tried to add the layers > >meta-custommachine and meta-ptx within poky repository as sub- > modules. > >Is this the proper way of adding new layers within the poky repository? > >Or may I know how can I maintain a Yocto repository using git > >submodules. Does git submodules work better than repo tool ? > > > >I am newbie to create and maintain a repo, so I am not able to > >visualize what is the future effect of choosing one over the other. > >Currently I am using the krogoth release of Yocto and planning to > >update this with new Yocto releases. > > > >Any information on the topic would be helpful. > > Both of these approaches are widely used, I'd go with whichever feels most > comfortable to you/your team. Personally I'm a fan of using repo as I can set > it to check out the latest commits on a given branch (eg. krogoth) instead of > always having to set an exact commit hash to use. > > If using git submodules it is often advised to have a separate top level > repository which just pulls in the submodules. Alexander Kanevskiy (aka Sasha) touched on some of that especially in the context of delivering a Continuous Integration and Continuous Delivery mechanism in his presentation at the last ELCE in Berlin. You can view his slides here: http://events.linuxfoundation.org/sites/events/files/slides/Creating%20Continuous%20Delivery%20for%20Yocto%20Based%20IoT%20Distribution%2020161012%20LF.pdf There is a quick summary of the pro's and con's of using combo-tool vs. git submodule on slide 20. Geoffroy -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sstate-cache and native recipes
On 18 January 2017 at 09:51, Gary Thomas wrote: > How would one change the recipe to reflect that? Is there an > override that effectively says "not -native"? > do_install_class-target. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sstate-cache and native recipes
On 18 January 2017 at 11:51, Gary Thomas wrote:
> On 2017-01-18 10:35, Burton, Ross wrote:
>
>>
>> On 18 January 2017 at 09:13, Gary Thomas > g...@mlbassoc.com>> wrote:
>>
>> * glib-2.0-native depends on ${DISTRO_FEATURES}
>> To me this seems silly as "native" should be "native" and
>> not depend on any distribution settings. Here's the code
>> that's causing it (in do_install)
>>
>> if [ -f
>> ${D}${datadir}/installed-tests/glib/gdbus-serialization.test
>> ]; then
>> if ${@bb.utils.contains("DISTRO_FEATURES", "x11",
>> "false", "true", d)}; then
>> rm ${D}${datadir}/installed-tests
>> /glib/gdbus-serialization.test
>> fi
>> fi
>>
>> Obviously this isn't important for a native package. Any
>> suggestions on how I might keep this from creeping in?
>>
>>
>> The tests are only installed for target builds anyway, so that do_install
>> part could be target-specific.
>>
>
> How would one change the recipe to reflect that? Is there an
> override that effectively says "not -native"?
>
do_install_append_class-target () should work.
- Jussi
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Whats the better way to maintain the Yocto project for an embedded product - git submodules or repo or using Combo-layer
On 18 January 2017 09:32:15 GMT+00:00, "Eswaran Vinothkumar (BEG-PT/PJ-IOT1)" wrote: >Hello Yocto community members, > >Currently I am working on the task of using Yocto to build customized >Embedded Linux distribution for an embedded product. I have created a >new BSP layer for my project (meta-custommachine) and have successfully >created barebox, Linux Kernel and root filesystem images for my board. > >Now I wish to create an internal repository for Yocto project to track >and maintain the changes. I am unclear what is the better way to create >an repository. I googled for the same and found that the Freescale >community is maintaining their Yocto project using the repo tool. So I >tried to have a similar structure for my project. I created a repo with >the default.xml file which has the information about where to fetch the >repositories for poky, meta-ptx and meta-custommachine. I am seeing the >folder structures as expected and build is also fine. > >I had a discussion with one of my senior team member about this and he >is interested in using git submodules. So I tried to add the layers >meta-custommachine and meta-ptx within poky repository as sub-modules. >Is this the proper way of adding new layers within the poky repository? >Or may I know how can I maintain a Yocto repository using git >submodules. Does git submodules work better than repo tool ? > >I am newbie to create and maintain a repo, so I am not able to >visualize what is the future effect of choosing one over the other. >Currently I am using the krogoth release of Yocto and planning to >update this with new Yocto releases. > >Any information on the topic would be helpful. Both of these approaches are widely used, I'd go with whichever feels most comfortable to you/your team. Personally I'm a fan of using repo as I can set it to check out the latest commits on a given branch (eg. krogoth) instead of always having to set an exact commit hash to use. If using git submodules it is often advised to have a separate top level repository which just pulls in the submodules. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Layer index enhancements
Hi all, We've done some work recently on the OE layer index [1] and I thought it might be useful to give a summary of what's been implemented: * Upgraded to Django 1.8. This was a bunch of work without much visible impact, however it does mean we are now on an LTS version of Django which is much easier to maintain and will receive security updates until some time in 2018. * Added the ability to search for recipes inheriting a specific class - just add inherits:classname to the search text. For example [2] - you can even search for recipes inheriting several classes [3] (i.e. all specified classes must be inherited in order to match). Note: any other search words are interpreted as part of a string that must be present - we haven't switched to doing keyword-based searching. * Distros provided by each layer are now collected. I still have to sort out an issue with the collection so most of them aren't showing up in the index yet, but the capability exists. * Update records - each time we do an update (every three hours) or when a manual update is triggered by Michael, we record the output against the layer plus a separate overall record for the update showing the output for all layers (if you log in this is available from Tools -> Updates, but anyone can access it at [4]). The latter also lets us see how long updates are taking. If you look over the recent update logs you can see we still have to fix up some issues with the data (e.g. because of branches and repos going away, missing dependencies or other metadata issues, etc.). Hopefully making this more visible will help us to tidy these up. * The layer submission/editing page now lets you select a git web interface, so if you're submitting a layer that's hosted on a server providing a cgit, gitweb or gitlab web interface that isn't one of the common servers we know about (e.g. git.openembedded.org, github, etc.) then you won't have to figure out the syntax for the file/tree URLs, you just select the type and it'll set those fields automatically. * Fixed a bug that caused recipes to show up twice in the search results if the searched string appeared in both the name and description. Exact matches on name now show up first in the search results as well. * Fixed a recently introduced bug in the OE-Classic search that resulted in Internal Server errors when searching by name * We now pick up layer dependencies (and recommends) specified in the layer.conf, but only if they match the layer name - we don't handle collection names yet, so this won't currently work where the collection name doesn't match the layer name (e.g. oe-core, meta-oe...). * Counts for recipes, machines, classes, appends, and distros are now shown on each tab on the layer detail page Thanks to Michael Halstead, Liam Howlett and Mark Hatle for helping me with these. Cheers, Paul [1] https://layers.openembedded.org/ [2] http://layers.openembedded.org/layerindex/branch/master/recipes/?q=inherits%3Acmake [3] http://layers.openembedded.org/layerindex/branch/master/recipes/?q=inherits%3Acmake+inherits%3Apkgconfig [4] https://layers.openembedded.org/layerindex/updates/ -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sstate-cache and native recipes
On 2017-01-18 10:35, Burton, Ross wrote:
On 18 January 2017 at 09:13, Gary Thomas mailto:g...@mlbassoc.com>> wrote:
* glib-2.0-native depends on ${DISTRO_FEATURES}
To me this seems silly as "native" should be "native" and
not depend on any distribution settings. Here's the code
that's causing it (in do_install)
if [ -f
${D}${datadir}/installed-tests/glib/gdbus-serialization.test ]; then
if ${@bb.utils.contains("DISTRO_FEATURES", "x11", "false",
"true", d)}; then
rm
${D}${datadir}/installed-tests/glib/gdbus-serialization.test
fi
fi
Obviously this isn't important for a native package. Any
suggestions on how I might keep this from creeping in?
The tests are only installed for target builds anyway, so that do_install part
could be target-specific.
How would one change the recipe to reflect that? Is there an
override that effectively says "not -native"?
Thanks
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sstate-cache and native recipes
On 18 January 2017 at 09:13, Gary Thomas wrote:
> * glib-2.0-native depends on ${DISTRO_FEATURES}
> To me this seems silly as "native" should be "native" and
> not depend on any distribution settings. Here's the code
> that's causing it (in do_install)
>
> if [ -f ${D}${datadir}/installed-tests/glib/gdbus-serialization.test
> ]; then
> if ${@bb.utils.contains("DISTRO_FEATURES", "x11",
> "false", "true", d)}; then
> rm ${D}${datadir}/installed-tests
> /glib/gdbus-serialization.test
> fi
> fi
>
> Obviously this isn't important for a native package. Any
> suggestions on how I might keep this from creeping in?
>
The tests are only installed for target builds anyway, so that do_install
part could be target-specific.
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Whats the better way to maintain the Yocto project for an embedded product - git submodules or repo or using Combo-layer
Hello Yocto community members, Currently I am working on the task of using Yocto to build customized Embedded Linux distribution for an embedded product. I have created a new BSP layer for my project (meta-custommachine) and have successfully created barebox, Linux Kernel and root filesystem images for my board. Now I wish to create an internal repository for Yocto project to track and maintain the changes. I am unclear what is the better way to create an repository. I googled for the same and found that the Freescale community is maintaining their Yocto project using the repo tool. So I tried to have a similar structure for my project. I created a repo with the default.xml file which has the information about where to fetch the repositories for poky, meta-ptx and meta-custommachine. I am seeing the folder structures as expected and build is also fine. I had a discussion with one of my senior team member about this and he is interested in using git submodules. So I tried to add the layers meta-custommachine and meta-ptx within poky repository as sub-modules. Is this the proper way of adding new layers within the poky repository? Or may I know how can I maintain a Yocto repository using git submodules. Does git submodules work better than repo tool ? I am newbie to create and maintain a repo, so I am not able to visualize what is the future effect of choosing one over the other. Currently I am using the krogoth release of Yocto and planning to update this with new Yocto releases. Any information on the topic would be helpful. Mit freundlichen Grüßen / Best regards Vinothkumar Eswaran -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sstate-cache and native recipes
On 2017-01-18 10:13, Gary Thomas wrote:
I've been trying to understand (as was recently posted here by
another user) why native recipes are not being well shared/reused
by the sstate-cache mechanism. I have a build machine where I
do lots of builds for various targets. I would think (hope!)
that xxx-native packages would be the same for every build and
if I have the sstate mirror set up correctly, be shared appropriately.
To this end, I have one "master" build that I always run first
whenever the metadata changes, then point all the other builds
at that tree.
For the most part, this works pretty well, but there are still
some places where it doesn't. Here are a couple of examples
which I've investigated:
* glib-2.0-native depends on ${DISTRO_FEATURES}
To me this seems silly as "native" should be "native" and
not depend on any distribution settings. Here's the code
that's causing it (in do_install)
if [ -f ${D}${datadir}/installed-tests/glib/gdbus-serialization.test ];
then
if ${@bb.utils.contains("DISTRO_FEATURES", "x11", "false",
"true", d)}; then
rm
${D}${datadir}/installed-tests/glib/gdbus-serialization.test
fi
fi
Obviously this isn't important for a native package. Any
suggestions on how I might keep this from creeping in?
BTW, once glib-2.0-native can't be shared, a number of other native
packages will also have to be rebuilt because of build dependencies.
I discovered this when qemu-native was being rebuilt on almost all
of my targets...
* xxx-native packages are not shared if ${DISTRO} is different.
Again, this seems wrong as "native" packages should really only
depend on the build ${HOST}, not ${DISTRO}
I'm looking at this for the sole purpose of reducing the load on my
build machine. Any package that can be shared and not have to be
rebuilt just makes it more productive :-)
Thanks for any ideas or comments
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] x86 testing
On 18 January 2017 at 07:02, Gary Thomas wrote: > It used to be that I could run qemu and it would pop up a separate > window that emulated a display+keyboard+mouse. That doesn't seem > to be the same now, or at least I don't see how to make it work. > Advice on this would be great as I need to test the "native" X > setup, not VNC connections. > Still is the case if you have 'sdl' in qemu-native's PACKAGECONFIG. See the sample local.conf, this was a change in behaviour a year or so ago so there's a chance your local.conf doesn't do this. > I'd also be happy to try this on real hardware, e.g. my wife's > laptop, but I need some way to do that non-destructively. Again, > pointers would be greatly appreciated. > Build an image using ideally meta-intel's intel-corei7-64 (or core2-32) machine and put the hddimg on a USB stick. This can live boot from the stick directly. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] x86 testing
On 18 January 2017 at 09:02, Gary Thomas wrote:
> I'm trying to track down some recent changes in the X server
> (using the latest Poky/Yocto master). I've had failures on
> a number of the embedded targets I work with, so I thought
> I'd give it a go on platforms with a larger base - x86 machines.
> It used to be that I could run qemu and it would pop up a separate
> window that emulated a display+keyboard+mouse. That doesn't seem
> to be the same now, or at least I don't see how to make it work.
>
This is lacking a bit of detail ... What did you try and what failed?
Building a qemux86-64 (or qemux86) image and running it should certainly
work ("runqemu qemux86-64").
Advice on this would be great as I need to test the "native" X
> setup, not VNC connections.
>
> I'd also be happy to try this on real hardware, e.g. my wife's
> laptop, but I need some way to do that non-destructively. Again,
> pointers would be greatly appreciated.
>
The hddimg is both an installer and a live image: in other words if you
build e.g. a x86-64 core-image-sato you can dd it to a USB disk and boot a
typical laptop from USB without installing anything on hard drive.
Jussi
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] x86 testing
On Wed, 2017-01-18 at 08:02 +0100, Gary Thomas wrote: > I'm trying to track down some recent changes in the X server > (using the latest Poky/Yocto master). I've had failures on > a number of the embedded targets I work with, so I thought > I'd give it a go on platforms with a larger base - x86 machines. > > It used to be that I could run qemu and it would pop up a separate > window that emulated a display+keyboard+mouse. That doesn't seem > to be the same now, or at least I don't see how to make it work. qemu-native was changed to not depend on SDL. Instead of opening its own window, it now provides access via VNC. If you want the old behavior back, you need to compile with (from Poky's local.conf.sample): # By default qemu will build with a builtin VNC server where graphical output can be # seen. The two lines below enable the SDL backend too. By default libsdl-native will # be built, if you want to use your host's libSDL instead of the minimal libsdl built # by libsdl-native then uncomment the ASSUME_PROVIDED line below. PACKAGECONFIG_append_pn-qemu-native = " sdl" PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl" #ASSUME_PROVIDED += "libsdl-native" > Advice on this would be great as I need to test the "native" X > setup, not VNC connections. For the guest OS it shouldn't make a difference whether qemu uses its own window or VNC. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] sstate-cache and native recipes
I've been trying to understand (as was recently posted here by
another user) why native recipes are not being well shared/reused
by the sstate-cache mechanism. I have a build machine where I
do lots of builds for various targets. I would think (hope!)
that xxx-native packages would be the same for every build and
if I have the sstate mirror set up correctly, be shared appropriately.
To this end, I have one "master" build that I always run first
whenever the metadata changes, then point all the other builds
at that tree.
For the most part, this works pretty well, but there are still
some places where it doesn't. Here are a couple of examples
which I've investigated:
* glib-2.0-native depends on ${DISTRO_FEATURES}
To me this seems silly as "native" should be "native" and
not depend on any distribution settings. Here's the code
that's causing it (in do_install)
if [ -f ${D}${datadir}/installed-tests/glib/gdbus-serialization.test ];
then
if ${@bb.utils.contains("DISTRO_FEATURES", "x11", "false",
"true", d)}; then
rm
${D}${datadir}/installed-tests/glib/gdbus-serialization.test
fi
fi
Obviously this isn't important for a native package. Any
suggestions on how I might keep this from creeping in?
* xxx-native packages are not shared if ${DISTRO} is different.
Again, this seems wrong as "native" packages should really only
depend on the build ${HOST}, not ${DISTRO}
I'm looking at this for the sole purpose of reducing the load on my
build machine. Any package that can be shared and not have to be
rebuilt just makes it more productive :-)
Thanks for any ideas or comments
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Openembedded-architecture] Patchwork and incoming patch testing
This looks great, thanks. On 17 January 2017 at 20:05, Paul Eggleton wrote: > In any event we are now finally in the > position where our patchwork instance can be relied upon to collect emails, > and the UI is much improved. This should give us a bit more visibility into > where patches are at in the process, although we are still working on a few > places where patch series status needs to be updated (e.g. when a patch > goes > into testing). What's the plan for these status updates -- is the idea that you go to patchwork UI to see the state of a specific patch set? Or maybe a reply to either patch sender or even the ML? On top of patchwork we have built a simple smoke-testing framework called > "patchtest" [5] along with a suite of corresponding tests for OE [6]. These > tests are fairly simplistic at this point but check the basics such as > whether > a patch has been properly signed off, etc. We should soon start seeing > replies > sent to the mailing list and to submitters with results if there are any > failures, saving us from noticing and pointing out some of the more obvious > classes of mistakes. Is there a reason for patchwork only showing "success" or "failure" in the web ui, instead of linking to test results at least in in the failure case? - Jussi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
