Re: [yocto] [meta-raspberrypi] Current master broken

[Paul Barker]

On Tue, 6 Dec 2016 21:17:55 -0500
Trevor Woerner  wrote:

> On Tue 2016-12-06 @ 11:00:34 PM, Paul Barker wrote:
> > Upstream effectively support one version, currently 4.4. When upstream
> > made that the default branch, the changes to the 4.1 branch stopped -
> > there wasn't really much overlap. Everything post-4.4 is active
> > development and gets rebased at will. At some point they'll move to the
> > next LTS release (4.9) and 4.4 will be dropped.
> 
> Are you speaking specifically about the kernel for raspberry pi, or in
> general?

Raspberrypi specifically.

> Because the kernel for raspberry pi has several branches that are all
> maintained and kept up-to-date. It's actually quite commendable how this
> repository is maintained. Branches for 4.4, 4.7, 4.8, 4.9 and others are all
> usable (ignoring the constant rebasing thing...)

4.4 is stable and never gets rebased.

4.7 was last updated Oct 25th so it's now inactive.

4.8 and 4.9 will be almost the same set of patches rebased on top of
the mainline kernel. I think they do things this way to make
upstreaming patches easier.

This is the pattern I've seen for the last couple of years - one stable
branch that never gets rebased and one or two development branches
which do get rebased.

> 
> > I'd class all recipes for kernel versions other than default branch
> > upstream as experimental. Perhaps we should just go with AUTOREV here?
> > Anything else is going to need changing really often.
> 
> Not every revision of those branches are usable for raspberry pi. Someone
> named "popcornmix" has been keeping everything aligned with upstream, and
> merging in the support for raspberry pi.
> 
> If you took the rpi-4.8.y branch, for example, and happened to check out
> commit 356ccf6d2b0cfe9dca6c5d961bfd04dc8c0f4e64, you wouldn't have something
> that would build.
> 
> The problem is they keep rebasing, which messes up the SRC_URIs :-(

This is true, AUTOREV would lead to occasionally picking up bad
commits.

How about mirroring the Raspberrypi Linux repository so that we can
control when certain commits disappear from the repository? We could
either have AUTOREV in the recipe and only update the mirror with
tested commits, or update meta-raspberrypi regularly as well.

Thanks,
Paul
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] update mechanisms

[Kristian Amlie]

On 06/12/16 23:38, Stefano Babic wrote:
> On 06/12/2016 19:45, Philip Balister wrote:
>> I just skimmed the page and the table format isn't working well with the
>> length of the blocks of text.
>>
> 
> Agree - I think it is better to have a section per project.

And now I added yet another one, Mender, to
https://wiki.yoctoproject.org/wiki/System_Update.

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

Re: [yocto] [recipetool] Failure to create a new recipe (failed to parse setup.py)

[Vincent Rubiolo]

Hi Paul,

On 12/04/2016 11:14 AM, Paul Eggleton wrote:

Hmm, it looks like we're treating a byte array as a string (i.e. missing
decoding) and that doesn't work. Likely this broke during the Python3
migration, and since there are a number of different code paths in
recipetool's python handling code our relatively simplistic automated tests
didn't hit it. I have a fix here and will send it out soon.


Thanks for the quick and fast reply. Looking forward to the patch, I'll 
let you know how it goes on my setup.


Cheers,

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

[yocto] Release Candidate Build for yocto-2.0.3.rc1.rc1 now available.

[Poky Build User]

A release candidate build for yocto-2.0.3.rc1 is now available at:


http://autobuilder.yoctoproject.org/pub/releases/yocto-2.0.3.rc1


Please begin QA on this build as soon as possible.


Build hash information: 
meta-qt4 : 2c7f8df9039be498f8a2232d1428adb7f4e5e800 
meta-intel : 28c774bf25eec43020983416ad02a3b4307aaf0c 
meta-qt3 : b08996efbfb3b26e62b608f34ebf5e671b36ec61 
poky : adb34b8ddcd8cc34ae7d2b1b2e4b4d291d790f56 

\nThis is an automated message from\nThe Yocto Project Autobuilder\nGit: 
git://git.yoctoproject.org/yocto-autobuilder\nEmail: pi...@toganlabs.com 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ***SPAM*** Re: [meta-raspberrypi] Current master broken

[Trevor Woerner]

On Tue 2016-12-06 @ 11:00:34 PM, Paul Barker wrote:
> Upstream effectively support one version, currently 4.4. When upstream
> made that the default branch, the changes to the 4.1 branch stopped -
> there wasn't really much overlap. Everything post-4.4 is active
> development and gets rebased at will. At some point they'll move to the
> next LTS release (4.9) and 4.4 will be dropped.

Are you speaking specifically about the kernel for raspberry pi, or in
general? Because the kernel for raspberry pi has several branches that are all
maintained and kept up-to-date. It's actually quite commendable how this
repository is maintained. Branches for 4.4, 4.7, 4.8, 4.9 and others are all
usable (ignoring the constant rebasing thing...)

> I'd class all recipes for kernel versions other than default branch
> upstream as experimental. Perhaps we should just go with AUTOREV here?
> Anything else is going to need changing really often.

Not every revision of those branches are usable for raspberry pi. Someone
named "popcornmix" has been keeping everything aligned with upstream, and
merging in the support for raspberry pi.

If you took the rpi-4.8.y branch, for example, and happened to check out
commit 356ccf6d2b0cfe9dca6c5d961bfd04dc8c0f4e64, you wouldn't have something
that would build.

The problem is they keep rebasing, which messes up the SRC_URIs :-(
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ***SPAM*** Re: [meta-raspberrypi] Current master broken

[Paul Barker]

On Tue, 6 Dec 2016 22:21:50 +0100
Herve Jourdain  wrote:

> Sorry, a bit tired...
> I meant we need to track the changes happening to the versions we decide we
> want to support, and update the recipes accordingly.
> My understanding is we're interested in 4.4, 4.8 and 4.9. And I have a
> personal interest in 4.7 for the moment, so I can try to keep the 4.7 recipe
> up to date with the changes.
> If 4.4 is "stable", then we need some people to focus on tracking the
> changes happening on 4.8 and 4.9.
> 
> Cheers,
> Herve
> 

I've ran into this myself before.

Upstream effectively support one version, currently 4.4. When upstream
made that the default branch, the changes to the 4.1 branch stopped -
there wasn't really much overlap. Everything post-4.4 is active
development and gets rebased at will. At some point they'll move to the
next LTS release (4.9) and 4.4 will be dropped.

I'd class all recipes for kernel versions other than default branch
upstream as experimental. Perhaps we should just go with AUTOREV here?
Anything else is going to need changing really often.

Thanks,
Paul
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] Current master broken

[Paul Barker]

On Tue, 6 Dec 2016 15:29:02 +
Andrei Gherzan  wrote:

> On Mon, Dec 5, 2016 at 4:50 PM, Khem Raj  wrote:
> > On Sun, Dec 4, 2016 at 10:03 PM, Gary Thomas  wrote:
> >> On 2016-12-05 01:54, Andrei Gherzan wrote:
> >>>
> >>> Hi Gary,
> >>>
> >>>
> >>> On Sat, Dec 3, 2016 at 2:16 PM, Paul Barker  wrote:
> 
> 
>  It looks like the following oe-core commit broke the build for
>  meta-raspberrypi:
> 
> 
>  http://git.openembedded.org/openembedded-core/commit/?id=83d10e2acef936b1f38804988f10eafa48db36f9
> 
>  Applying the following patch from the oe-core mailing list fixes it for
>  me:
> 
> 
>  http://lists.openembedded.org/pipermail/openembedded-core/2016-December/129567.html
> 
>  I'm just going to apply that locally until it's merged into master.
> >>>
> >>>
> >>> Does the referenced patch by Paul fix your issue here?
> >>
> >>
> >> Yes, for version 4.4.x
> >>

> 
> I managed to hit this too. @Paul Is that patch coming to oe-core master soon?

I'll let people know on the oe-core list that we need this. I'd imagine
it won't be stuck in the queue for long but depends how busy things
are I suppose.

Thanks,
Paul
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] update mechanisms

[Stefano Babic]

Hi Philip,

On 06/12/2016 19:45, Philip Balister wrote:
> On 12/06/2016 06:11 AM, Lopez, Mariano wrote:
>>
>>
>> On 12/6/2016 3:45 AM, Patrick Ohly wrote:
>>> On Tue, 2016-12-06 at 10:01 +0100, Stefano Babic wrote:
 Hi Patrick,

 On 30/11/2016 15:59, Patrick Ohly wrote:
> I've started a Wiki page
> https://wiki.yoctoproject.org/wiki/System_Update - rudimentary at the
> moment, but might as well be mentioned already now.
 I have seen Mariano added an entry for SWUpdate, too, thanks  - I would
 like to edit for better explanation on some parts. Should I try to edit
 directly the page or is it better to discuss it here ?
>>
>> It will be interesting to have your input directly, I tried to fill the
>> table with my experience with SWUpdate but I think you could give a
>> better insight of this. Thanks for joining the effort.
>>
>>> Use your own judgment. If its uncontroversial, the feel free to edit the
>>> page directly, otherwise let's discuss it here.
>>>
>>> If feel that putting information directly into the table is too limiting
>>> (it should be brief), then feel free to start a complete section about
>>> SWUpdate.
>>>
>>> I'll do the same for swupd. Editing the sections should be possible
>>> without conflicts, we just have to be more careful about editing the
>>> table concurrently.
>>>
>>
>> I agree with you, that we need to have a section per project, the table
>> is too limiting.
> 
> I just skimmed the page and the table format isn't working well with the
> length of the blocks of text.
> 

Agree - I think it is better to have a section per project.

> I'd also suggest referencing Matt Porter's talk from ELCE 2016 about
> software update technology:
> 
> http://elinux.org/images/3/31/Comparison_of_Linux_Software_Update_Technologies.pdf
> 
> https://youtu.be/pdHV9H9nZks?list=PLbzoR-pLrL6pRFP6SOywVJWdEHlmQE51q
> 

I have added references to the talks at last ELCE from Matt, Chris and
Silvano.

Stefano


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] Current master broken

[Trevor Woerner]

Just to clarify, in the last couple days, there have been *two* major issues
that have independently broken raspi builds:

1) the rebase of the raspi kernel repository at
   git://github.com/raspberrypi/linux.git
2) a bug in a recent commit to oe-core's kernel tools

Andrei pushed patches today to update the src revs so, as of this moment, the
SRC_URIs in meta-raspberrypi should be valid.

A patch for the kernel tools in oe-core is on the mailing list; hopefully it
will be pushed to master soon. Incidentally, this same bad commit also
included a second bug that made it impossible for two different users on the
same machine to perform OE builds. The fix addresses both issues.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ***SPAM*** Re: [meta-raspberrypi] Current master broken

[Herve Jourdain]

Sorry, a bit tired...
I meant we need to track the changes happening to the versions we decide we
want to support, and update the recipes accordingly.
My understanding is we're interested in 4.4, 4.8 and 4.9. And I have a
personal interest in 4.7 for the moment, so I can try to keep the 4.7 recipe
up to date with the changes.
If 4.4 is "stable", then we need some people to focus on tracking the
changes happening on 4.8 and 4.9.

Cheers,
Herve

-Original Message-
From: Andrei Gherzan [mailto:and...@gherzan.ro] 
Sent: mardi 6 décembre 2016 19:11
To: Herve Jourdain 
Cc: 'Khem Raj' ; yocto@yoctoproject.org; 'Gary Thomas'

Subject: Re: ***SPAM*** Re: [yocto] [meta-raspberrypi] Current master broken

On Tue, Dec 06, 2016 at 07:04:31PM +0100, Herve Jourdain wrote:
> Hi Andrei,
>
> But I believe that the core of the problem is not necessarily the 
> patch in oe-core to detect the kernel version itself, but like Khem 
> mentioned the fact that a "well known" SRCREV is only valid for a 
> brief period of time under the RPI tree "constant" rebasing we've been
experiencing lately.
> So basically, the SRCREV that is used is not corresponding to what it 
> used to be, if it's still there in the tree, and the oe-core detects 
> that - the SRCREV thought it was one version of the kernel, and it 
> just happened that it corresponds to a different codebase with a different
linux version.
> Killing the error reporting by a patch will probably not prevent the 
> mismatch happening behind the scene.
> So like Khem mentioned, either we find a way to "prevent" the rebasing 
> at the source, or we need to track down every version we want to 
> support, and update SRCREV and corresponding kernel version for those.

Got it now. What do you mean by "track down every version we want"?
--
Andrei Gherzan

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

Re: [yocto] [meta-raspberrypi][PATCH] Do not rely on DISTRO_TYPE to enable/disable kernel debug

[Andrei Gherzan]

On Mon, Nov 28, 2016 at 08:37:45PM +0100, Frank Meerkoetter wrote:
> DISTRO_TYPE doesn't seem to be set anywhere in OE/poky. This causes
> CMDLINE_DEBUG to default to "debug" which is very noisy. This is
> especially true when building a systemd based system, as systemd
> also looks at the kernel commandline to set the debug level.
> Such a system is nearly unuseable from the serial console due
> to the amount of data logged by systemd.
> ---
>  recipes-kernel/linux/linux-rpi.inc | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/recipes-kernel/linux/linux-rpi.inc 
> b/recipes-kernel/linux/linux-rpi.inc
> index 95a9530..53383b0 100644
> --- a/recipes-kernel/linux/linux-rpi.inc
> +++ b/recipes-kernel/linux/linux-rpi.inc
> @@ -13,9 +13,9 @@ ARM_KEEP_OABI ?= "1"
>  # Quirk for udev greater or equal 141
>  UDEV_GE_141 ?= "1"
>
> -# Set the verbosity of kernel messages during runtime
> -# You can define CMDLINE_DEBUG in your local.conf or distro.conf to override 
> this behaviour
> -CMDLINE_DEBUG ?= '${@base_conditional("DISTRO_TYPE", "release", "quiet", 
> "debug", d)}'
> +# You can define CMDLINE_DEBUG as "debug" in your local.conf or distro.conf
> +# to enable kernel debugging.
> +CMDLINE_DEBUG ?= ""
>  CMDLINE_append = " ${CMDLINE_DEBUG}"
>
>  KERNEL_INITRAMFS ?= '${@base_conditional("INITRAMFS_IMAGE_BUNDLE", "1", "1", 
> "", d)}'

I had to change the git log a little. Please make sure you submit other
patches using the format described here:
http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines

Thanks for you contribution.

--
Andrei Gherzan


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] Do not rely on DISTRO_TYPE to enable/disable kernel debug

[Andrei Gherzan]

On Mon, Nov 28, 2016 at 08:37:45PM +0100, Frank Meerkoetter wrote:
> DISTRO_TYPE doesn't seem to be set anywhere in OE/poky. This causes
> CMDLINE_DEBUG to default to "debug" which is very noisy. This is
> especially true when building a systemd based system, as systemd
> also looks at the kernel commandline to set the debug level.
> Such a system is nearly unuseable from the serial console due
> to the amount of data logged by systemd.
> ---
>  recipes-kernel/linux/linux-rpi.inc | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/recipes-kernel/linux/linux-rpi.inc 
> b/recipes-kernel/linux/linux-rpi.inc
> index 95a9530..53383b0 100644
> --- a/recipes-kernel/linux/linux-rpi.inc
> +++ b/recipes-kernel/linux/linux-rpi.inc
> @@ -13,9 +13,9 @@ ARM_KEEP_OABI ?= "1"
>  # Quirk for udev greater or equal 141
>  UDEV_GE_141 ?= "1"
>
> -# Set the verbosity of kernel messages during runtime
> -# You can define CMDLINE_DEBUG in your local.conf or distro.conf to override 
> this behaviour
> -CMDLINE_DEBUG ?= '${@base_conditional("DISTRO_TYPE", "release", "quiet", 
> "debug", d)}'
> +# You can define CMDLINE_DEBUG as "debug" in your local.conf or distro.conf
> +# to enable kernel debugging.
> +CMDLINE_DEBUG ?= ""
>  CMDLINE_append = " ${CMDLINE_DEBUG}"
>
>  KERNEL_INITRAMFS ?= '${@base_conditional("INITRAMFS_IMAGE_BUNDLE", "1", "1", 
> "", d)}'
> --

I like this. Let's merge it. Master it is.

--
Andrei Gherzan


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] update mechanisms

[Philip Balister]

On 12/06/2016 06:11 AM, Lopez, Mariano wrote:
> 
> 
> On 12/6/2016 3:45 AM, Patrick Ohly wrote:
>> On Tue, 2016-12-06 at 10:01 +0100, Stefano Babic wrote:
>>> Hi Patrick,
>>>
>>> On 30/11/2016 15:59, Patrick Ohly wrote:
 I've started a Wiki page
 https://wiki.yoctoproject.org/wiki/System_Update - rudimentary at the
 moment, but might as well be mentioned already now.
>>> I have seen Mariano added an entry for SWUpdate, too, thanks  - I would
>>> like to edit for better explanation on some parts. Should I try to edit
>>> directly the page or is it better to discuss it here ?
> 
> It will be interesting to have your input directly, I tried to fill the
> table with my experience with SWUpdate but I think you could give a
> better insight of this. Thanks for joining the effort.
> 
>> Use your own judgment. If its uncontroversial, the feel free to edit the
>> page directly, otherwise let's discuss it here.
>>
>> If feel that putting information directly into the table is too limiting
>> (it should be brief), then feel free to start a complete section about
>> SWUpdate.
>>
>> I'll do the same for swupd. Editing the sections should be possible
>> without conflicts, we just have to be more careful about editing the
>> table concurrently.
>>
> 
> I agree with you, that we need to have a section per project, the table
> is too limiting.

I just skimmed the page and the table format isn't working well with the
length of the blocks of text.

I'd also suggest referencing Matt Porter's talk from ELCE 2016 about
software update technology:

http://elinux.org/images/3/31/Comparison_of_Linux_Software_Update_Technologies.pdf

https://youtu.be/pdHV9H9nZks?list=PLbzoR-pLrL6pRFP6SOywVJWdEHlmQE51q

Philip


> 
> Mariano
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] linux-raspberrypi-base.bbclass: allow -rt kernels

[Andrei Gherzan]

On Tue, Dec 06, 2016 at 06:27:32PM +, Andrei Gherzan wrote:
> On Mon, Nov 28, 2016 at 08:37:09PM -0500, Trevor Woerner wrote:
> > On Mon 2016-11-28 @ 03:16:11 PM, Khem Raj wrote:
> > >
> > > > On Nov 28, 2016, at 11:07 AM, Trevor Woerner  wrote:
> > > >
> > > > If the PREEMPT_RT patch is applied, the kernel version becomes, say,
> > > > 4.4.32-rt43 (instead of 4.4.32). This confuses the version handling 
> > > > code in
> > > > this class. Update how the version string is processed so that trailing 
> > > > rt-
> > > > strings are properly handled, in addition to handling the existing 
> > > > cases.
> > > >
> > >
> > > This probably will solve the issue I see with 4.9-rcX recipes that are in 
> > > my tree on kraj/master
> >
> > I'm not familiar with the issue you're seeing, but the existing and new code
> > are looking for 3 int()s separated by periods. If your recipes have the 
> > string
> > "4.9-rcX" then I'm guessing there might still be an issue since the third
> > int() will be "-rcX" in your case. If this is true, you'll need to take a 
> > look
> > at where "int(min_ver[2])" is used further down in that bbclass file.
>
> I agreed this is not the best implementation of this. We should only get

agree*

> the version using a regex that would get X.Y.Z-R with an optional Z and
> R.
>
> --
> Andrei Gherzan
--
Andrei Gherzan


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] linux-raspberrypi-base.bbclass: allow -rt kernels

[Andrei Gherzan]

On Mon, Nov 28, 2016 at 08:37:09PM -0500, Trevor Woerner wrote:
> On Mon 2016-11-28 @ 03:16:11 PM, Khem Raj wrote:
> >
> > > On Nov 28, 2016, at 11:07 AM, Trevor Woerner  wrote:
> > >
> > > If the PREEMPT_RT patch is applied, the kernel version becomes, say,
> > > 4.4.32-rt43 (instead of 4.4.32). This confuses the version handling code 
> > > in
> > > this class. Update how the version string is processed so that trailing 
> > > rt-
> > > strings are properly handled, in addition to handling the existing cases.
> > >
> >
> > This probably will solve the issue I see with 4.9-rcX recipes that are in 
> > my tree on kraj/master
>
> I'm not familiar with the issue you're seeing, but the existing and new code
> are looking for 3 int()s separated by periods. If your recipes have the string
> "4.9-rcX" then I'm guessing there might still be an issue since the third
> int() will be "-rcX" in your case. If this is true, you'll need to take a look
> at where "int(min_ver[2])" is used further down in that bbclass file.

I agreed this is not the best implementation of this. We should only get
the version using a regex that would get X.Y.Z-R with an optional Z and
R.

--
Andrei Gherzan


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ***SPAM*** Re: [meta-raspberrypi][PATCH] gstreamer1.0-plugins-bad: Don't hard wire use of userland

[Herve Jourdain]

Hi Gary,

Could you try a local to your layer gstreamer1.0-plugins-bad_%.bbappend,
that would contain:
PACKAGECONFIG_remove_rpi = " dispmanx"
And see if it solves your problem?

I've never built for "vc-graphics-hardfp", as I'm not sure if there are
benefits in using it over either using the userland or vc4, so I'm not sure
whether it can work without dispmanx, nor why it would not compile with
dispmanx enabled.
But if this works, then we might need to consider to add an additional case
for not enabling dispmanx.

Cheers,
Herve

-Original Message-
From: Gary Thomas [mailto:g...@mlbassoc.com] 
Sent: mardi 6 décembre 2016 16:58
To: Andrei Gherzan 
Cc: Herve Jourdain ; yocto@yoctoproject.org
Subject: ***SPAM*** Re: [yocto] [meta-raspberrypi][PATCH]
gstreamer1.0-plugins-bad: Don't hard wire use of userland

On 2016-12-06 16:48, Andrei Gherzan wrote:
> On Tue, Dec 06, 2016 at 04:02:20PM +0100, Gary Thomas wrote:
>> On 2016-12-06 13:45, Herve Jourdain wrote:
>>> Hi Gary,
>>>
>>> But dispmanx is really only provided by userland, it does not exist 
>>> in other flavors of egl/libgles.
>>> Actually, dispmanx should not be selected in PACKAGECONFIG if 
>>> userland is not in use for EGL/GLES.
>>
>> Fine, but I'm looking for a solution where I can choose to use 
>> vc-graphics-hardfp so X11 works again and I can also have gst-player 
>> which depends on gstreamer-1.0-bad
>>
>> Any ideas?
>>
>
> Disabling dispamanx is not working?

How might I do that?  It's not clear from [at least] that recipe.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world


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

Re: [yocto] [meta-raspberrypi][PATCH v5] u-boot: Simplify boot script

[Andrei Gherzan]

On Wed, Nov 30, 2016 at 09:02:39PM +, Paul Barker wrote:
> From: Jonathan Liu 
>
> A patch is backported to check if the firmware loaded a device tree blob
> into memory and set the fdt_addr variable if it is found. The U-Boot
> script will then read the command line arguments generated by the
> firmware from the device tree and boot the kernel with the command
> line arguments and the loaded device tree.
>
> This allows things like MAC address, board revision and serial number
> to be correctly configured and options in config.txt to be used.
>
> An additional patch is backported and further changes are made to support
> this.
>
> Signed-off-by: Jonathan Liu 
> Signed-off-by: Paul Barker 
> ---
> Changes in v5:
>  - Backport an additional patch and make further changes to support u-boot
>v2016.03

Merged to master. Thank you.
--
Andrei Gherzan


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ***SPAM*** Re: [meta-raspberrypi] Current master broken

[Andrei Gherzan]

On Tue, Dec 06, 2016 at 07:04:31PM +0100, Herve Jourdain wrote:
> Hi Andrei,
>
> But I believe that the core of the problem is not necessarily the patch in
> oe-core to detect the kernel version itself, but like Khem mentioned the
> fact that a "well known" SRCREV is only valid for a brief period of time
> under the RPI tree "constant" rebasing we've been experiencing lately.
> So basically, the SRCREV that is used is not corresponding to what it used
> to be, if it's still there in the tree, and the oe-core detects that - the
> SRCREV thought it was one version of the kernel, and it just happened that
> it corresponds to a different codebase with a different linux version.
> Killing the error reporting by a patch will probably not prevent the
> mismatch happening behind the scene.
> So like Khem mentioned, either we find a way to "prevent" the rebasing at
> the source, or we need to track down every version we want to support, and
> update SRCREV and corresponding kernel version for those.

Got it now. What do you mean by "track down every version we want"?
--
Andrei Gherzan


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] gstreamer1.0-plugins-bad: Don't hard wire use of userland

[Andrei Gherzan]

On Tue, Dec 06, 2016 at 04:57:42PM +0100, Gary Thomas wrote:
> On 2016-12-06 16:48, Andrei Gherzan wrote:
> > On Tue, Dec 06, 2016 at 04:02:20PM +0100, Gary Thomas wrote:
> > > On 2016-12-06 13:45, Herve Jourdain wrote:
> > > > Hi Gary,
> > > >
> > > > But dispmanx is really only provided by userland, it does not exist in 
> > > > other
> > > > flavors of egl/libgles.
> > > > Actually, dispmanx should not be selected in PACKAGECONFIG if userland 
> > > > is
> > > > not in use for EGL/GLES.
> > >
> > > Fine, but I'm looking for a solution where I can choose to use 
> > > vc-graphics-hardfp
> > > so X11 works again and I can also have gst-player which depends on 
> > > gstreamer-1.0-bad
> > >
> > > Any ideas?
> > >
> >
> > Disabling dispamanx is not working?
>
> How might I do that?  It's not clear from [at least] that recipe.
>
> --
> 
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> 

Uh. I see the append now. I'm thinking on how we can fix this...

--
Andrei Gherzan


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ***SPAM*** Re: [meta-raspberrypi] Current master broken

[Herve Jourdain]

Hi Andrei,

But I believe that the core of the problem is not necessarily the patch in
oe-core to detect the kernel version itself, but like Khem mentioned the
fact that a "well known" SRCREV is only valid for a brief period of time
under the RPI tree "constant" rebasing we've been experiencing lately.
So basically, the SRCREV that is used is not corresponding to what it used
to be, if it's still there in the tree, and the oe-core detects that - the
SRCREV thought it was one version of the kernel, and it just happened that
it corresponds to a different codebase with a different linux version.
Killing the error reporting by a patch will probably not prevent the
mismatch happening behind the scene.
So like Khem mentioned, either we find a way to "prevent" the rebasing at
the source, or we need to track down every version we want to support, and
update SRCREV and corresponding kernel version for those.

Cheers,
Herve

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
On Behalf Of Andrei Gherzan
Sent: mardi 6 décembre 2016 16:29
To: Khem Raj 
Cc: yocto@yoctoproject.org; Gary Thomas 
Subject: ***SPAM*** Re: [yocto] [meta-raspberrypi] Current master broken

On Mon, Dec 5, 2016 at 4:50 PM, Khem Raj  wrote:
> On Sun, Dec 4, 2016 at 10:03 PM, Gary Thomas  wrote:
>> On 2016-12-05 01:54, Andrei Gherzan wrote:
>>>
>>> Hi Gary,
>>>
>>>
>>> On Sat, Dec 3, 2016 at 2:16 PM, Paul Barker 
wrote:

 On Sat, 3 Dec 2016 08:33:40 +0100
 Gary Thomas  wrote:

> I'm currently unable to build for the RaspberryPi-3 using the 
> master
> branch:
>
> Build Configuration:
> BB_VERSION= "1.32.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "universal"
> TARGET_SYS= "arm-amltd-linux-gnueabi"
> MACHINE   = "raspberrypi3"
> DISTRO= "amltd"
> DISTRO_VERSION= "2.2+snapshot-20161202"
> TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4
> callconvention-hard cortexa7"
> TARGET_FPU= "hard"
> meta  = "master:9e63f81c78e284c9b325fe04a1b59e61c7ad8a1a"
> meta-amltd= "master:074120ab3a82cea0ac50d4e9eec89130a860a4fa"
> meta-raspberrypi  = "master:44d41bf3e94c4c8fe5ad5a3650572c8d17ef36c9"
>
> Initialising tasks: 100%
> |#| Time:
> 0:00:00
> Checking sstate mirror object availability: 100%
> |#| Time: 0:00:00
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> ERROR: linux-raspberrypi-1_4.4.28+gitAUTOINC+5afda48c34-r0
> do_kernel_metadata: Function failed: do_kernel_metadata (log file 
> is located at
>
> /build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/l
> inux-raspberrypi/1_4.4.28+gitAUTOINC+5afda48c34-r0/temp/log.do_ker
> nel_metadata.5647)
> ERROR: Logfile of failure stored in:
>
> /build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/l
> inux-raspberrypi/1_4.4.28+gitAUTOINC+5afda48c34-r0/temp/log.do_ker
> nel_metadata.5647
> Log data follows:
> | DEBUG: Executing shell function do_kernel_metadata
> | [ERROR]: processing of file /tmp/tmp.bXPr8PVPz3 failed
> |
>
/build/rpi3_2016-09-13/tmp/sysroots/x86_64-linux/usr/bin/scc-cmds/patch.cmd:
> line 29: : No such file or directory
> |
> | Context around the error is:
> |
> | #
> | prefix
> /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/lin
> ux-raspberrypi/
> | kconf non-hardware
> /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/lin
> ux-raspberrypi/defconfig
> | prefix
> /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/lin
> ux-raspberrypi-4.4/
> | patch
>
"/local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspbe
rrypi-4.4/0001-fix-dtbo-rules.patch"
> | # run time: 0 seconds
> | # processed files:
> | # _cfg
> /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/lin
> ux-raspberrypi/defconfig
> | # _cfg
> /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/lin
> ux-raspberrypi-4.4/0001-fix-dtbo-rules.patch
> |
> | See pre-processed file /tmp/tmp.bXPr8PVPz3 for more details # # 
> | scc v0.8 # processed: Fri Dec  2 04:12:25 CET 2016 # # This is a 
> | scc output file, do not edit #
> | [ERROR]: processing of file /tmp/tmp.eTLAT789Q2 failed # 
> | _reloc_dir
> /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux
> | # _reloc_dir
> /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux
> |
>
/build/rpi3_2016-09-13/tmp/sysroots/x86_64-linux/usr/bin/scc-cmds/patch.cmd:
> line 29: : No such file or directory
> |
> | Context around the error is:
> |
> | #
>

[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, Dec. 6, 2016 8:00 AM US Pacific Time

[Jolley, Stephen K]

Attendees: Armin, Joshua, Stephano, Manju, Saul, Sona, Mark, Randy, Stephen, 
Ross, Richard,



Agenda:



* Opens collection - 5 min (Stephen)

* Yocto Project status - 5 min (Stephen/team)

*YP 2.2 shipped in early November.

*YP 2.1.2 shipped in late November.

*YP 2.0.3 is getting ready to QA.

*YP 2.3 M1 should build early next week.

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.3_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.3_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.3_Features

* Opens - 10 min

*   Ross - Discussed memo on mailing list about EOL of Build appliance.  
See: 
http://lists.openembedded.org/pipermail/openembedded-architecture/2016-December/000345.html

*Mark - Discussed LX-Setup: https://github.com/Wind-River/wr-lx-setup 
and 
http://lists.openembedded.org/pipermail/openembedded-architecture/2016-November/000310.html

*Sona - Discussed the CVE check tool proposal.  It was suggested it get 
rolled into the Recipe Reporting System.  A bugzilla bug to set this up will be 
done by Sona.

* Team Sharing - 10 min

*Richard - Proof of Concept proposal for Recipe Specific SYSROOT is on 
the mailing list.  Please review.


Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:(503) 712-0534
*Cell:   (208) 244-4460
* Email:stephen.k.jol...@intel.com

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

Re: [yocto] [meta-raspberrypi][PATCH] linux-raspberrypi_4.8.bb: upgrade to 4.8.11

[Andrei Gherzan]

On Mon, Nov 28, 2016 at 11:46:38AM -0500, Trevor Woerner wrote:
> The rpi-4.8.y branch of git://github.com/raspberrypi/linux.git was rebased,
> losing any previous commit hashes. This latest update doesn't include the
> raspberry pi patches for 4.8.6, but the upstream patches are included starting
> with 4.8.11.
>
> Signed-off-by: Trevor Woerner 
> ---
>  recipes-kernel/linux/linux-raspberrypi_4.8.bb | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/recipes-kernel/linux/linux-raspberrypi_4.8.bb 
> b/recipes-kernel/linux/linux-raspberrypi_4.8.bb
> index 4664249..504fb6a 100644
> --- a/recipes-kernel/linux/linux-raspberrypi_4.8.bb
> +++ b/recipes-kernel/linux/linux-raspberrypi_4.8.bb
> @@ -1,8 +1,8 @@
>  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
>
> -LINUX_VERSION ?= "4.8.6"
> +LINUX_VERSION ?= "4.8.11"
>
> -SRCREV = "6abac13566786086cd912d87e4f1a922e2a391b2"
> +SRCREV = "429efdba18a1201043eacc15c42f989253fbd68b"
>  SRC_URI = 
> "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.8.y \
>  "
>  require linux-raspberrypi.inc

I updated this patch to 4.8.12 as this was not working already, and
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] firmware: Update to 20161125

[Andrei Gherzan]

On Mon, Dec 05, 2016 at 10:00:27PM +1100, Jonathan Liu wrote:
> Signed-off-by: Jonathan Liu 
> ---
>  recipes-bsp/common/firmware.inc | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/recipes-bsp/common/firmware.inc b/recipes-bsp/common/firmware.inc
> index 8862f58..1961b48 100644
> --- a/recipes-bsp/common/firmware.inc
> +++ b/recipes-bsp/common/firmware.inc
> @@ -1,10 +1,10 @@
> -RPIFW_DATE ?= "20161020"
> +RPIFW_DATE ?= "20161125"
>  RPIFW_SRC_URI ?= 
> "https://github.com/raspberrypi/firmware/archive/1.${RPIFW_DATE}.tar.gz";
>  RPIFW_S ?= "${WORKDIR}/firmware-1.${RPIFW_DATE}"
>
>  SRC_URI = "${RPIFW_SRC_URI}"
> -SRC_URI[md5sum] = "d3c388c114af4c672dd3ee0ed8e984d3"
> -SRC_URI[sha256sum] = 
> "1c7c49d58800aab2dd1b5ff59a1e297934f9ea6f47ebdf0a3f90632561dc690b"
> +SRC_URI[md5sum] = "a9281d2869e2d7673a83d41bacfa66c2"
> +SRC_URI[sha256sum] = 
> "744e050630621c70991c91e0ee8663dc2f579e743583ca762b13b00bc75859bc"
>
>  PV = "${RPIFW_DATE}"
>
Merged to master. Thanks.

--
Andrei Gherzan


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] gstreamer1.0-plugins-bad: Don't hard wire use of userland

[Gary Thomas]

On 2016-12-06 16:48, Andrei Gherzan wrote:

On Tue, Dec 06, 2016 at 04:02:20PM +0100, Gary Thomas wrote:

On 2016-12-06 13:45, Herve Jourdain wrote:

Hi Gary,

But dispmanx is really only provided by userland, it does not exist in other
flavors of egl/libgles.
Actually, dispmanx should not be selected in PACKAGECONFIG if userland is
not in use for EGL/GLES.


Fine, but I'm looking for a solution where I can choose to use 
vc-graphics-hardfp
so X11 works again and I can also have gst-player which depends on 
gstreamer-1.0-bad

Any ideas?



Disabling dispamanx is not working?


How might I do that?  It's not clear from [at least] that recipe.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] [meta-raspberrypi][PATCH] gstreamer1.0-plugins-bad: Don't hard wire use of userland

[Andrei Gherzan]

On Tue, Dec 06, 2016 at 04:02:20PM +0100, Gary Thomas wrote:
> On 2016-12-06 13:45, Herve Jourdain wrote:
> > Hi Gary,
> >
> > But dispmanx is really only provided by userland, it does not exist in other
> > flavors of egl/libgles.
> > Actually, dispmanx should not be selected in PACKAGECONFIG if userland is
> > not in use for EGL/GLES.
>
> Fine, but I'm looking for a solution where I can choose to use 
> vc-graphics-hardfp
> so X11 works again and I can also have gst-player which depends on 
> gstreamer-1.0-bad
>
> Any ideas?
>

Disabling dispamanx is not working?
--
Andrei Gherzan


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] linux-raspberrypi_4.4.bb: upgrade to 4.4.35

[Andrei Gherzan]

On Tue, Nov 29, 2016 at 11:04:59AM -0500, Trevor Woerner wrote:
> Signed-off-by: Trevor Woerner 
> ---
>  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 19e8552..35a72d7 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.28"
> +LINUX_VERSION ?= "4.4.35"
>
> -SRCREV = "5afda48c3408e15742d4569459a4ff668e2857f7"
> +SRCREV = "5d765c8b5782de7ed49f623c107f1b395429b560"
>  SRC_URI = 
> "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.4.y \
> file://0001-fix-dtbo-rules.patch \
>  "
> --
> 2.10.2
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Merged to master. Thanks.

--
Andrei Gherzan


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] linux-raspberrypi_4.4.bb: upgrade to 4.4.32

[Andrei Gherzan]

On Mon, Nov 28, 2016 at 10:03:24PM -0500, Trevor Woerner wrote:
> On Mon 2016-11-28 @ 05:52:38 PM, Khem Raj wrote:
> >
> > > On Nov 28, 2016, at 5:42 PM, Trevor Woerner  wrote:
> > >
> > > On Mon 2016-11-28 @ 03:21:50 PM, Khem Raj wrote:
> > >> its at 4.4.35 now see
> > >> https://github.com/kraj/meta-raspberrypi/commits/kraj/master 
> > >> 
> > >
> > > True. But there's no -rt patch for 4.4.35:
> > > https://www.kernel.org/pub/linux/kernel/projects/rt/4.4/
> > >
> > > The latest 4.4.y -rt patch is 4.4.32.
> > >
> > > Since I'm working on a separate recipe for 4.4.32-rt43 I guess I could 
> > > just
> > > base it on 4.4.32 and let the non-rt-mainline advance to 4.4.35 :-)
> >
> > does it not apply cleanly on 4.4.35
>
> As luck would have it, it does!
> (minus one hunk from Makefile for something that had already been added)
>
> Tomorrow I'll do a boot test and submit the patch (unless the boot test fails,
> or someone else beats me to it)

It does apply on .35 too (with some very minor changes). So, I will
merge the other update patch. Thanks guys!

--
Andrei Gherzan


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] Current master broken

[Andrei Gherzan]

On Mon, Dec 5, 2016 at 4:50 PM, Khem Raj  wrote:
> On Sun, Dec 4, 2016 at 10:03 PM, Gary Thomas  wrote:
>> On 2016-12-05 01:54, Andrei Gherzan wrote:
>>>
>>> Hi Gary,
>>>
>>>
>>> On Sat, Dec 3, 2016 at 2:16 PM, Paul Barker  wrote:

 On Sat, 3 Dec 2016 08:33:40 +0100
 Gary Thomas  wrote:

> I'm currently unable to build for the RaspberryPi-3 using the master
> branch:
>
> Build Configuration:
> BB_VERSION= "1.32.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "universal"
> TARGET_SYS= "arm-amltd-linux-gnueabi"
> MACHINE   = "raspberrypi3"
> DISTRO= "amltd"
> DISTRO_VERSION= "2.2+snapshot-20161202"
> TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4
> callconvention-hard cortexa7"
> TARGET_FPU= "hard"
> meta  = "master:9e63f81c78e284c9b325fe04a1b59e61c7ad8a1a"
> meta-amltd= "master:074120ab3a82cea0ac50d4e9eec89130a860a4fa"
> meta-raspberrypi  = "master:44d41bf3e94c4c8fe5ad5a3650572c8d17ef36c9"
>
> Initialising tasks: 100%
> |#| Time:
> 0:00:00
> Checking sstate mirror object availability: 100%
> |#| Time: 0:00:00
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> ERROR: linux-raspberrypi-1_4.4.28+gitAUTOINC+5afda48c34-r0
> do_kernel_metadata: Function failed: do_kernel_metadata (log
> file is located at
>
> /build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspberrypi/1_4.4.28+gitAUTOINC+5afda48c34-r0/temp/log.do_kernel_metadata.5647)
> ERROR: Logfile of failure stored in:
>
> /build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspberrypi/1_4.4.28+gitAUTOINC+5afda48c34-r0/temp/log.do_kernel_metadata.5647
> Log data follows:
> | DEBUG: Executing shell function do_kernel_metadata
> | [ERROR]: processing of file /tmp/tmp.bXPr8PVPz3 failed
> |
> /build/rpi3_2016-09-13/tmp/sysroots/x86_64-linux/usr/bin/scc-cmds/patch.cmd:
> line 29: : No such file or directory
> |
> | Context around the error is:
> |
> | #
> | prefix
> /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/
> | kconf non-hardware
> /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig
> | prefix
> /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/
> | patch
> "/local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch"
> | # run time: 0 seconds
> | # processed files:
> | # _cfg
> /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig
> | # _cfg
> /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch
> |
> | See pre-processed file /tmp/tmp.bXPr8PVPz3 for more details
> | #
> | # scc v0.8
> | # processed: Fri Dec  2 04:12:25 CET 2016
> | #
> | # This is a scc output file, do not edit
> | #
> | [ERROR]: processing of file /tmp/tmp.eTLAT789Q2 failed
> | # _reloc_dir
> /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux
> | # _reloc_dir
> /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux
> |
> /build/rpi3_2016-09-13/tmp/sysroots/x86_64-linux/usr/bin/scc-cmds/patch.cmd:
> line 29: : No such file or directory
> |
> | Context around the error is:
> |
> | #
> | prefix
> /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/
> | kconf non-hardware
> /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig
> | prefix
> /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/
> | patch
> "/local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch"
> | # run time: 1 seconds
> | # processed files:
> | # _cfg
> /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig
> | # _cfg
> /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch
> |
> | See pre-processed file /tmp/tmp.eTLAT789Q2 for more details
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_kernel_metadata (log file is located at
>
> /build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspberrypi/1_4.4.28+gitAUTOINC+5afda48c34-r0/temp/log.do_kernel_metadata.5647)
> ERROR: Task
> (/local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberry

Re: [yocto] [meta-raspberrypi][PATCH] gstreamer1.0-plugins-bad: Don't hard wire use of userland

[Gary Thomas]

On 2016-12-06 13:45, Herve Jourdain wrote:

Hi Gary,

But dispmanx is really only provided by userland, it does not exist in other
flavors of egl/libgles.
Actually, dispmanx should not be selected in PACKAGECONFIG if userland is
not in use for EGL/GLES.


Fine, but I'm looking for a solution where I can choose to use 
vc-graphics-hardfp
so X11 works again and I can also have gst-player which depends on 
gstreamer-1.0-bad

Any ideas?


-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
On Behalf Of Gary Thomas
Sent: mardi 6 décembre 2016 10:34
To: yocto@yoctoproject.org
Cc: Gary Thomas 
Subject: [yocto] [meta-raspberrypi][PATCH] gstreamer1.0-plugins-bad: Don't
hard wire use of userland

Selection of the libgl packages should be by virtual/XXX.  Using 'userland'
directly can lead to build conflicts and make the system unbuildable.

Signed-off-by: Gary Thomas 
---
 recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git
a/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
b/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
index 7292f90..432869d 100644
--- a/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
+++ b/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
@@ -9,4 +9,4 @@ PACKAGECONFIG_GL_rpi = "egl gles2"

 PACKAGECONFIG_append_rpi = " hls libmms faad"

-PACKAGECONFIG[dispmanx] = "--enable-dispmanx,--disable-dispmanx,userland"
+PACKAGECONFIG[dispmanx] = "--enable-dispmanx,--disable-dispmanx,virtual/egl
virtual/libgles2"




--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] cve-checker tool

[Sona Sarmadi]

Another qustion:

We don't have recipes for libcurl, I guess both curl and libcurl CVEs are 
patched in the curl recipes, right?
I think curl uses libcurl, and libcurl is built when building curl. 

Those CVEs which are listed in the nvd.xml file under "cpe:/a:haxx:libcurl: are 
not detected and reported by cve-check tool.

//Sona 

-Original Message-
From: Sona Sarmadi 
Sent: den 6 december 2016 15:28
To: Mariano Lopez ; mariano.lo...@intel.com; 
yocto@yoctoproject.org
Subject: RE: [yocto] cve-checker tool

Hi Mariano, all,

> If there is a version affected by a CVE it will look for a patch that 
> solves that particular CVE using the the metadata in the patch format.
> For example, the current bind version is affected by CVE-2016-1285, 
> but there is patch for that, so the cve-check class will find this and 
> will generate a log file saying the vulnerability has been addressed.

It seems that this tool does not detect all CVEs, e.g. bind has some CVE 
patches but it is not reported, I tried all options below nothing is reported 
(no cve.log file):
bitbake -c cve_check bind
bitbake -k -c cve_check universe
bitbake -k -c cve_check world

There are some CVEs in bind (reported in nvd.xml file for our version 
cpe:/a:isc:bind:9.10.3"/> ) but cve.check-tool does not report them ex: 
(CVE-2016-2776). Do you know why?


CVEs are reported for the following packages using e.g. "bitbake -k -c 
cve_check universe"
or  "bitbake -c cve_check perl"
 
tmp/work/i586-poky-linux/perl/5.22.1-r0/cve/cve.log
tmp/work/i586-poky-linux/foomatic-filters/4.0.17-r1/cve/cve.log
tmp/work/i586-poky-linux/flex/2.6.0-r0/cve/cve.log
tmp/work/i586-poky-linux/glibc/2.24-r0/cve/cve.log
tmp/work/i586-poky-linux/unzip/1_6.0-r5/cve/cve.log
tmp/work/i586-poky-linux/expat/2.2.0-r0/cve/cve.log
tmp/work/i586-poky-linux/gnutls/3.5.3-r0/cve/cve.log
tmp/work/i586-poky-linux/glibc-initial/2.24-r0/cve/cve.log
tmp/work/i586-poky-linux/libxml2/2.9.4-r0/cve/cve.log
tmp/work/i586-poky-linux/bzip2/1.0.6-r5/cve/cve.log

We have more recipes which have CVE patches but they are not reported. 
I have analyzed these; some of these CVEs are still marked as reserved on Mitre 
 and are not present in the nvd.xml files (although they are public (e.g. 
Busybox: 
https://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2147).

I don't understand why for instance bind CVEs are not detected and reported by 
cve-check tool?
Is it because of cpe:/a:isc:bind? It looks for isc?

morty/poky/meta$ find . -name *CVE-201*.patch 
./recipes-connectivity/ppp/ppp/fix-CVE-2015-3310.patch

./recipes-connectivity/bind/bind/CVE-2016-2776.patch ?
./recipes-connectivity/bind/bind/CVE-2016-1286_2.patch
./recipes-connectivity/bind/bind/CVE-2016-1285.patch
./recipes-connectivity/bind/bind/CVE-2016-1286_1.patch
./recipes-connectivity/bind/bind/CVE-2016-2088.patch
./recipes-connectivity/bind/bind/CVE-2016-2775.patch

./recipes-extended/unzip/unzip/CVE-2015-7696.patch
./recipes-extended/unzip/unzip/06-unzip60-alt-iconv-utf8_CVE-2015-1315.patch
./recipes-extended/unzip/unzip/CVE-2015-7697.patch
./recipes-extended/xinetd/xinetd/xinetd-CVE-2013-4342.patch
./recipes-extended/cpio/cpio-2.12/0001-Fix-CVE-2015-1197.patch
./recipes-extended/cracklib/cracklib/0001-Apply-patch-to-fix-CVE-2016-6318.patch
./recipes-extended/bzip2/bzip2-1.0.6/CVE-2016-3189.patch
./recipes-extended/grep/grep-2.5.1a/grep-CVE-2012-5667.patch
./recipes-extended/foomatic/foomatic-filters-4.0.17/CVE-2015-8327.patch
./recipes-extended/foomatic/foomatic-filters-4.0.17/CVE-2015-8560.patch
./recipes-multimedia/libtiff/files/CVE-2016-3945.patch
./recipes-multimedia/libtiff/files/CVE-2016-3623.patch
./recipes-multimedia/libtiff/files/CVE-2016-5323.patch
./recipes-multimedia/libtiff/files/CVE-2016-5321.patch
./recipes-multimedia/libtiff/files/CVE-2016-3991.patch
./recipes-multimedia/libtiff/files/CVE-2016-3622.patch
./recipes-multimedia/libtiff/files/CVE-2015-8781.patch
./recipes-multimedia/libtiff/files/CVE-2015-8784.patch
./recipes-multimedia/libtiff/files/CVE-2016-3186.patch
./recipes-multimedia/libtiff/files/CVE-2016-3990.patch
./recipes-multimedia/libtiff/files/CVE-2015-8665_8683.patch
./recipes-core/systemd/systemd/CVE-2016-7795.patch
./recipes-core/busybox/busybox/CVE-2016-2147_2.patch  <<< Reserved on Mitre: 
https://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2147
./recipes-core/busybox/busybox/CVE-2016-2147.patch
./recipes-core/busybox/busybox/CVE-2016-2148.patch <<< 
https://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2148
./recipes-devtools/elfutils/elfutils-0.148/elf_begin.c-CVE-2014-9447-fix.patch
./recipes-devtools/python/python3/CVE-2016-5636.patch
./recipes-devtools/python/python3/python3-fix-CVE-2016-1000110.patch
./recipes-devtools/python/python/CVE-2016-5636.patch
./recipes-devtools/python/python/python-fix-CVE-2016-1000110.patch
./recipes-devtools/qemu/qemu/0002-fix-CVE-2016-7423.patch
./recipes-devtools/qemu/qemu/0003-fix-CVE-2016-7908.patch
./recipes-devtools/perl/perl/perl-fix-CVE-20

Re: [yocto] cve-checker tool

[Sona Sarmadi]

Hi Mariano, all,

> If there is a version affected by a CVE it will look for a patch that solves
> that particular CVE using the the metadata in the patch format.
> For example, the current bind version is affected by CVE-2016-1285, but
> there is patch for that, so the cve-check class will find this and will
> generate a log file saying the vulnerability has been addressed.

It seems that this tool does not detect all CVEs, e.g. bind has some CVE patches
but it is not reported, I tried all options below nothing is reported (no 
cve.log file):
bitbake -c cve_check bind 
bitbake -k -c cve_check universe
bitbake -k -c cve_check world

There are some CVEs in bind (reported in nvd.xml file for our version 
cpe:/a:isc:bind:9.10.3"/> )
but cve.check-tool does not report them ex: (CVE-2016-2776). Do you know why?


CVEs are reported for the following packages using e.g. "bitbake -k -c 
cve_check universe"
or  "bitbake -c cve_check perl"
 
tmp/work/i586-poky-linux/perl/5.22.1-r0/cve/cve.log
tmp/work/i586-poky-linux/foomatic-filters/4.0.17-r1/cve/cve.log
tmp/work/i586-poky-linux/flex/2.6.0-r0/cve/cve.log
tmp/work/i586-poky-linux/glibc/2.24-r0/cve/cve.log
tmp/work/i586-poky-linux/unzip/1_6.0-r5/cve/cve.log
tmp/work/i586-poky-linux/expat/2.2.0-r0/cve/cve.log
tmp/work/i586-poky-linux/gnutls/3.5.3-r0/cve/cve.log
tmp/work/i586-poky-linux/glibc-initial/2.24-r0/cve/cve.log
tmp/work/i586-poky-linux/libxml2/2.9.4-r0/cve/cve.log
tmp/work/i586-poky-linux/bzip2/1.0.6-r5/cve/cve.log

We have more recipes which have CVE patches but they are not reported. 
I have analyzed these; some of these CVEs are still marked as reserved on Mitre
 and are not present in the nvd.xml files (although they are public (e.g. 
Busybox: 
https://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2147).

I don't understand why for instance bind CVEs are not detected and reported by 
cve-check tool?
Is it because of cpe:/a:isc:bind? It looks for isc?

morty/poky/meta$ find . -name *CVE-201*.patch
./recipes-connectivity/ppp/ppp/fix-CVE-2015-3310.patch

./recipes-connectivity/bind/bind/CVE-2016-2776.patch ?
./recipes-connectivity/bind/bind/CVE-2016-1286_2.patch
./recipes-connectivity/bind/bind/CVE-2016-1285.patch
./recipes-connectivity/bind/bind/CVE-2016-1286_1.patch
./recipes-connectivity/bind/bind/CVE-2016-2088.patch
./recipes-connectivity/bind/bind/CVE-2016-2775.patch

./recipes-extended/unzip/unzip/CVE-2015-7696.patch
./recipes-extended/unzip/unzip/06-unzip60-alt-iconv-utf8_CVE-2015-1315.patch
./recipes-extended/unzip/unzip/CVE-2015-7697.patch
./recipes-extended/xinetd/xinetd/xinetd-CVE-2013-4342.patch
./recipes-extended/cpio/cpio-2.12/0001-Fix-CVE-2015-1197.patch
./recipes-extended/cracklib/cracklib/0001-Apply-patch-to-fix-CVE-2016-6318.patch
./recipes-extended/bzip2/bzip2-1.0.6/CVE-2016-3189.patch
./recipes-extended/grep/grep-2.5.1a/grep-CVE-2012-5667.patch
./recipes-extended/foomatic/foomatic-filters-4.0.17/CVE-2015-8327.patch
./recipes-extended/foomatic/foomatic-filters-4.0.17/CVE-2015-8560.patch
./recipes-multimedia/libtiff/files/CVE-2016-3945.patch
./recipes-multimedia/libtiff/files/CVE-2016-3623.patch
./recipes-multimedia/libtiff/files/CVE-2016-5323.patch
./recipes-multimedia/libtiff/files/CVE-2016-5321.patch
./recipes-multimedia/libtiff/files/CVE-2016-3991.patch
./recipes-multimedia/libtiff/files/CVE-2016-3622.patch
./recipes-multimedia/libtiff/files/CVE-2015-8781.patch
./recipes-multimedia/libtiff/files/CVE-2015-8784.patch
./recipes-multimedia/libtiff/files/CVE-2016-3186.patch
./recipes-multimedia/libtiff/files/CVE-2016-3990.patch
./recipes-multimedia/libtiff/files/CVE-2015-8665_8683.patch
./recipes-core/systemd/systemd/CVE-2016-7795.patch
./recipes-core/busybox/busybox/CVE-2016-2147_2.patch  <<< Reserved on Mitre: 
https://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2147
./recipes-core/busybox/busybox/CVE-2016-2147.patch
./recipes-core/busybox/busybox/CVE-2016-2148.patch <<< 
https://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2148
./recipes-devtools/elfutils/elfutils-0.148/elf_begin.c-CVE-2014-9447-fix.patch
./recipes-devtools/python/python3/CVE-2016-5636.patch
./recipes-devtools/python/python3/python3-fix-CVE-2016-1000110.patch
./recipes-devtools/python/python/CVE-2016-5636.patch
./recipes-devtools/python/python/python-fix-CVE-2016-1000110.patch
./recipes-devtools/qemu/qemu/0002-fix-CVE-2016-7423.patch
./recipes-devtools/qemu/qemu/0003-fix-CVE-2016-7908.patch
./recipes-devtools/perl/perl/perl-fix-CVE-2015-8607.patch
./recipes-devtools/perl/perl/perl-fix-CVE-2016-2381.patch
./recipes-devtools/perl/perl/perl-fix-CVE-2016-1238.patch
./recipes-devtools/perl/perl/perl-fix-CVE-2016-6185.patch
./recipes-devtools/gcc/gcc-6.2/CVE-2016-4490.patch
./recipes-devtools/flex/flex/CVE-2016-6354.patch
./recipes-bsp/grub/files/0001-Fix-CVE-2015-8370-Grub2-user-pass-vulnerability.patch
./recipes-support/nettle/nettle-2.7.1/CVE-2015-8804.patch
./recipes-support/nettle/nettle-2.7.1/CVE-2015-8803_8805.patch
./recipes-support/gnutls/gnutls/CVE

Re: [yocto] ***SPAM*** [meta-raspberrypi] Qt EGLFS frozen on VC4

[Herve Jourdain]

Hi Gerhard,

 

Could you please provide a bit more information, like the kernel you’re
building against, the kind of features you’re using in QT, if you’re using
GStreamer as well, if you’re playing video, versions of the
meta-raspberrypi/yocto/openembedded layers, etc…

I’m not sure I can help, but without additional information it would be
second-guessing at best.

 

Cheers,

Herve

 

From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
On Behalf Of Gerhard de Clercq
Sent: mardi 6 décembre 2016 15:18
To: Yocto list discussion 
Subject: ***SPAM*** [yocto] [meta-raspberrypi] Qt EGLFS frozen on VC4

 

When I build Qt5 for my RPi 3 so that it uses EGLFS on VC4  (all using
Yocto) then everything seems to go well initially and I can even get a
program to launch but it then seems to render only one frame and then stay
there. There is no response to user input and applications that are supposed
to have constant animations do not change. It is also not possible to
terminate the application with ^c.

 

I'm not even sure where to ask for support because I have no idea if this is
a problem with Qt, VC4 or Yocto. Does anyone here have a clue of what might
be wrong?

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

[yocto] [meta-raspberrypi] Qt EGLFS frozen on VC4

[Gerhard de Clercq]

When I build Qt5 for my RPi 3 so that it uses EGLFS on VC4  (all using Yocto) 
then everything seems to go well initially and I can even get a program to 
launch but it then seems to render only one frame and then stay there. There is 
no response to user input and applications that are supposed to have constant 
animations do not change. It is also not possible to terminate the application 
with ^c.


I'm not even sure where to ask for support because I have no idea if this is a 
problem with Qt, VC4 or Yocto. Does anyone here have a clue of what might be 
wrong?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] update mechanisms

[Lopez, Mariano]

On 12/6/2016 3:45 AM, Patrick Ohly wrote:

On Tue, 2016-12-06 at 10:01 +0100, Stefano Babic wrote:

Hi Patrick,

On 30/11/2016 15:59, Patrick Ohly wrote:

I've started a Wiki page
https://wiki.yoctoproject.org/wiki/System_Update - rudimentary at the
moment, but might as well be mentioned already now.

I have seen Mariano added an entry for SWUpdate, too, thanks  - I would
like to edit for better explanation on some parts. Should I try to edit
directly the page or is it better to discuss it here ?


It will be interesting to have your input directly, I tried to fill the 
table with my experience with SWUpdate but I think you could give a 
better insight of this. Thanks for joining the effort.



Use your own judgment. If its uncontroversial, the feel free to edit the
page directly, otherwise let's discuss it here.

If feel that putting information directly into the table is too limiting
(it should be brief), then feel free to start a complete section about
SWUpdate.

I'll do the same for swupd. Editing the sections should be possible
without conflicts, we just have to be more careful about editing the
table concurrently.



I agree with you, that we need to have a section per project, the table 
is too limiting.


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

Re: [yocto] [meta-raspberrypi][PATCH] gstreamer1.0-plugins-bad: Don't hard wire use of userland

[Herve Jourdain]

Hi Gary,

But dispmanx is really only provided by userland, it does not exist in other
flavors of egl/libgles.
Actually, dispmanx should not be selected in PACKAGECONFIG if userland is
not in use for EGL/GLES.

Cheers,

Herve

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
On Behalf Of Gary Thomas
Sent: mardi 6 décembre 2016 10:34
To: yocto@yoctoproject.org
Cc: Gary Thomas 
Subject: [yocto] [meta-raspberrypi][PATCH] gstreamer1.0-plugins-bad: Don't
hard wire use of userland

Selection of the libgl packages should be by virtual/XXX.  Using 'userland'
directly can lead to build conflicts and make the system unbuildable.

Signed-off-by: Gary Thomas 
---
 recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git
a/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
b/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
index 7292f90..432869d 100644
--- a/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
+++ b/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
@@ -9,4 +9,4 @@ PACKAGECONFIG_GL_rpi = "egl gles2"
 
 PACKAGECONFIG_append_rpi = " hls libmms faad"
 
-PACKAGECONFIG[dispmanx] = "--enable-dispmanx,--disable-dispmanx,userland"
+PACKAGECONFIG[dispmanx] = "--enable-dispmanx,--disable-dispmanx,virtual/egl
virtual/libgles2"
-- 
2.7.4

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

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

Re: [yocto] update mechanisms

[Patrick Ohly]

On Tue, 2016-12-06 at 10:01 +0100, Stefano Babic wrote:
> Hi Patrick,
> 
> On 30/11/2016 15:59, Patrick Ohly wrote:
> > I've started a Wiki page
> > https://wiki.yoctoproject.org/wiki/System_Update - rudimentary at the
> > moment, but might as well be mentioned already now.
> 
> I have seen Mariano added an entry for SWUpdate, too, thanks  - I would
> like to edit for better explanation on some parts. Should I try to edit
> directly the page or is it better to discuss it here ?

Use your own judgment. If its uncontroversial, the feel free to edit the
page directly, otherwise let's discuss it here.

If feel that putting information directly into the table is too limiting
(it should be brief), then feel free to start a complete section about
SWUpdate. 

I'll do the same for swupd. Editing the sections should be possible
without conflicts, we just have to be more careful about editing the
table concurrently.

-- 
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] [meta-raspberrypi][PATCH] gstreamer1.0-plugins-bad: Don't hard wire use of userland

[Gary Thomas]

Selection of the libgl packages should be by virtual/XXX.  Using 'userland'
directly can lead to build conflicts and make the system unbuildable.

Signed-off-by: Gary Thomas 
---
 recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend 
b/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
index 7292f90..432869d 100644
--- a/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
+++ b/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
@@ -9,4 +9,4 @@ PACKAGECONFIG_GL_rpi = "egl gles2"
 
 PACKAGECONFIG_append_rpi = " hls libmms faad"
 
-PACKAGECONFIG[dispmanx] = "--enable-dispmanx,--disable-dispmanx,userland"
+PACKAGECONFIG[dispmanx] = "--enable-dispmanx,--disable-dispmanx,virtual/egl 
virtual/libgles2"
-- 
2.7.4

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

Re: [yocto] update mechanisms

[Stefano Babic]

Hi Patrick,

On 30/11/2016 15:59, Patrick Ohly wrote:
> On Wed, 2016-11-30 at 14:31 +, André Draszik wrote:
>> On Wed, 2016-11-30 at 12:04 +0100, Patrick Ohly wrote:
>>> On Mon, 2016-11-21 at 12:03 +, André Draszik wrote:
 This allows us to completely remove the build time
 depenency on libcheck when not needed, reducing
 overall build time, and in addition tests can be
 converted into a PACKAGECONFIG to enable them if
 needed.
>>>
>>> +1
>>>
>>> Sorry for the delay, I had to check with Joshua first who's going to
>>> merge your patches. I'm currently working on a major update of
>>> meta-swupd (see https://github.com/ostroproject/ostro-os/pull/198) and
>>> if there's enough interest for using it as part of Yocto, might continue
>>> maintaining it.
>>
>> Thanks Patrick. Are you saying you would otherwise abandon meta-swupd
>> completely, or have it be a part of ostro-os only?
> 
> That's undecided. We are currently trying to figure out which update
> mechanism is a good fit for Yocto. Depending on the outcome of that and
> available resources, we may or may not have the time to support
> something.
> 
> I've started a Wiki page
> https://wiki.yoctoproject.org/wiki/System_Update - rudimentary at the
> moment, but might as well be mentioned already now.

I have seen Mariano added an entry for SWUpdate, too, thanks  - I would
like to edit for better explanation on some parts. Should I try to edit
directly the page or is it better to discuss it here ?

Regards,
Stefano

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto