[dora] x264: Update SRCREV to match commit in upstream git repo

[dora] x264: Update SRCREV to match commit in upstream git repo

[Patrick Doyle]

It seems that 585324fee380109acd9986388f857f413a60b896 is no
longer there in git and it has been rewritten to
ffc3ad4945da69f3caa2b40e4eed715a9a8d9526

Change-Id: I9ffe8bd9bcef0d2dc5e6f6d3a6e4317bada8f4be
(From OE-Core rev: b193c7f251542aa76cb5a4d6dcb71d15b27005eb)

(From OE-Core rev: f2b20b169a462cf4c6e6f341b76add8a0f4d6e3f)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 meta/recipes-multimedia/x264/x264_git.bb |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/x264/x264_git.bb
b/meta/recipes-multimedia/x264/x264_git.bb
index 406df30..e40290f 100644
--- a/meta/recipes-multimedia/x264/x264_git.bb
+++ b/meta/recipes-multimedia/x264/x264_git.bb
@@ -11,7 +11,7 @@ SRC_URI = "git://git.videolan.org/x264.git \
            file://don-t-default-to-cortex-a9-with-neon.patch \
            "

-SRCREV = "585324fee380109acd9986388f857f413a60b896"
+SRCREV = "ffc3ad4945da69f3caa2b40e4eed715a9a8d9526"

 PV = "r2265+git${SRCPV}"

-- 
1.7.9.5

Re: [dora] x264: Update SRCREV to match commit in upstream git repo

[Paul Eggleton]

Hi Patrick,

On Tuesday 17 June 2014 09:36:05 Patrick Doyle wrote:
> It seems that 585324fee380109acd9986388f857f413a60b896 is no
> longer there in git and it has been rewritten to
> ffc3ad4945da69f3caa2b40e4eed715a9a8d9526

FYI I sent a similar patch for dora to the OE-Core list a week ago; hopefully 
it should be merged soon.

(Robert: I think my CC of the patch to you at the time bounced, not sure what 
happened.)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [dora] x264: Update SRCREV to match commit in upstream git repo

[Patrick Doyle]

Thanks Paul,
I hope I didn't step on any toes with this.  I'm still confused about
what parts of the project are "Yocto" and what parts are "OE".

Do you have any guesses as to when this might show up in the official
dora branch?

I am asking because we have a development flow here (I'm still not
sure I'm 100% happy with it, but it's what we've got), where we mirror
the poky repository, check out from that mirror very occasionally, and
generate a complete-from-scratch even more occasionally.
Unfortunately, we have a situation right now where, if somebody were
to do that (say, hypothetically speaking, a new person joins the
team), we can't generate a complete build from scratch.  I could apply
my patch to our local mirror, and thus break the mirror.  Or I could
create a local clone of the mirror and reference our local clone.  Or
…

If this will show up in dora in a matter of hours to a day or so, I'm
going to stop thinking about this.  If it is anticipated that it will
take longer, then I'll come up with a solution.

I'm not trying to complain nor advocate that this patch get applied
faster than would be normal, I'm just trying to plan my day :-)

--wpd


On Tue, Jun 17, 2014 at 11:07 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> Hi Patrick,
>
> On Tuesday 17 June 2014 09:36:05 Patrick Doyle wrote:
>> It seems that 585324fee380109acd9986388f857f413a60b896 is no
>> longer there in git and it has been rewritten to
>> ffc3ad4945da69f3caa2b40e4eed715a9a8d9526
>
> FYI I sent a similar patch for dora to the OE-Core list a week ago; hopefully
> it should be merged soon.
>
> (Robert: I think my CC of the patch to you at the time bounced, not sure what
> happened.)
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre

Re: [dora] x264: Update SRCREV to match commit in upstream git repo

[Robert Yang]

On 06/17/2014 11:31 PM, Patrick Doyle wrote:
> Thanks Paul,
> I hope I didn't step on any toes with this.  I'm still confused about
> what parts of the project are "Yocto" and what parts are "OE".

The oe-core is a part of yocto project, which is the meta layer in
poky.

>
> Do you have any guesses as to when this might show up in the official
> dora branch?

I've resend it oe-core, and will ping RP sooner.


@Paul,
I'm sorry, seems that I missed your email, but I still can't find it
when I searched again.

// Robert

>
> I am asking because we have a development flow here (I'm still not
> sure I'm 100% happy with it, but it's what we've got), where we mirror
> the poky repository, check out from that mirror very occasionally, and
> generate a complete-from-scratch even more occasionally.
> Unfortunately, we have a situation right now where, if somebody were
> to do that (say, hypothetically speaking, a new person joins the
> team), we can't generate a complete build from scratch.  I could apply
> my patch to our local mirror, and thus break the mirror.  Or I could
> create a local clone of the mirror and reference our local clone.  Or
> …
>
> If this will show up in dora in a matter of hours to a day or so, I'm
> going to stop thinking about this.  If it is anticipated that it will
> take longer, then I'll come up with a solution.
>
> I'm not trying to complain nor advocate that this patch get applied
> faster than would be normal, I'm just trying to plan my day :-)
>
> --wpd
>
>
> On Tue, Jun 17, 2014 at 11:07 AM, Paul Eggleton
> <paul.eggleton@linux.intel.com> wrote:
>> Hi Patrick,
>>
>> On Tuesday 17 June 2014 09:36:05 Patrick Doyle wrote:
>>> It seems that 585324fee380109acd9986388f857f413a60b896 is no
>>> longer there in git and it has been rewritten to
>>> ffc3ad4945da69f3caa2b40e4eed715a9a8d9526
>>
>> FYI I sent a similar patch for dora to the OE-Core list a week ago; hopefully
>> it should be merged soon.
>>
>> (Robert: I think my CC of the patch to you at the time bounced, not sure what
>> happened.)
>>
>> Cheers,
>> Paul
>>
>> --
>>
>> Paul Eggleton
>> Intel Open Source Technology Centre
>
>

Re: [dora] x264: Update SRCREV to match commit in upstream git repo

[Paul Eggleton]

On Tuesday 17 June 2014 23:56:58 Robert Yang wrote:
> > Do you have any guesses as to when this might show up in the official
> > dora branch?
> 
> I've resend it oe-core, and will ping RP sooner.

Thanks.

> 
> @Paul,
> I'm sorry, seems that I missed your email, but I still can't find it
> when I searched again.

No problem - I think it was some kind of transmission problem between my email 
system and yours since I received a delivery failure response; looks like it 
has now been fixed :)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [dora] x264: Update SRCREV to match commit in upstream git repo

[Paul Eggleton]

On Tuesday 17 June 2014 11:31:52 Patrick Doyle wrote:
> Thanks Paul,
> I hope I didn't step on any toes with this.  

No, not at all; I just wanted to let you know we are working on the issue.

> I'm still confused about what parts of the project are "Yocto" and 
> what parts are "OE".

Right, I know it's not as clear as it could be sometimes. At least for 
patches, FYI we did put some "where to send patches" information in the README 
file within the Poky repository. (We're certainly open to suggestions on making 
the process easier, be it from a documentation, tooling or process angle.)
 
> Do you have any guesses as to when this might show up in the official
> dora branch?

So Robert is the dora branch maintainer and he's replied separately; it should 
be fairly quick now that he's aware of it.

> I am asking because we have a development flow here (I'm still not
> sure I'm 100% happy with it, but it's what we've got), where we mirror
> the poky repository, check out from that mirror very occasionally, and
> generate a complete-from-scratch even more occasionally.
> Unfortunately, we have a situation right now where, if somebody were
> to do that (say, hypothetically speaking, a new person joins the
> team), we can't generate a complete build from scratch.  I could apply
> my patch to our local mirror, and thus break the mirror.  Or I could
> create a local clone of the mirror and reference our local clone.  Or
> …
> 
> If this will show up in dora in a matter of hours to a day or so, I'm
> going to stop thinking about this.  If it is anticipated that it will
> take longer, then I'll come up with a solution.
> 
> I'm not trying to complain nor advocate that this patch get applied
> faster than would be normal, I'm just trying to plan my day :-)

No problem - in this particular instance with x264 it was a bit of an 
unfortunate trifecta where the upstream project does not provide release 
tarballs so we build directly from their git repository; they recently decided 
to rewrite their git history without telling anyone, and we didn't notice 
immediately because we don't build it on our autobuilder regularly (since it 
has LICENSE_FLAGS set). Even when we did know about it though, it's fair to 
say we have been a little slow to correct for it; hopefully we can get this 
patch in soon and then it'll be taken care of, at least for the x264 recipes 
in master, daisy and dora.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [dora] x264: Update SRCREV to match commit in upstream git repo

[Patrick Doyle]

On Tue, Jun 17, 2014 at 12:46 PM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> No problem - in this particular instance with x264 it was a bit of an
> unfortunate trifecta where the upstream project does not provide release
> tarballs so we build directly from their git repository; they recently decided
> to rewrite their git history without telling anyone, and we didn't notice
> immediately because we don't build it on our autobuilder regularly (since it
> has LICENSE_FLAGS set). Even when we did know about it though, it's fair to
> say we have been a little slow to correct for it; hopefully we can get this
> patch in soon and then it'll be taken care of, at least for the x264 recipes
> in master, daisy and dora.
>
In this particular instance, it was even more difficult as I just
learned that we don't have a mechanism for keeping our local dora
repository in sync with the Yocto repository.  Fortunately, I know how
to fix that :-)

> Cheers,
> Paul
Thanks for your help, and for your commitment to Open Source Software.

--wpd

How to copy recipe and have different target names

[Brian Smucker]

Hello,

I would like to have yocto generate two copies of busybox, one 
statically-linked and one dynamically linked. So I try to make a copy of 
the busybox recipe and give it a new name like busybox-s_xxxxx.bb

But my knowlege of yocto comes up short and I get lots of errors.

Is there a way to do this cleanly?  Or should I be trying to do a 
different approach?

Thanks,

Brian

Re: How to copy recipe and have different target names

[Andrea Adami]

On Tue, Jun 17, 2014 at 5:41 PM, Brian Smucker <bds@bsmucker.eu.org> wrote:
> Hello,
>
> I would like to have yocto generate two copies of busybox, one
> statically-linked and one dynamically linked. So I try to make a copy of the
> busybox recipe and give it a new name like busybox-s_xxxxx.bb
>
> But my knowlege of yocto comes up short and I get lots of errors.
>
> Is there a way to do this cleanly?  Or should I be trying to do a different
> approach?
>
> Thanks,
>
> Brian
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Brian,

I don't think there is an 'official' way to do that.
For a similar purpose (buidling static binaries against klibc) I have
developed two solutions, both using a custom class:

1) for easy-to-adapt recipes, BBCLASSEXTEND +  the custom class
http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-bsp/kexecboot/kexecboot_0.6.bb

2) for the stubborn cases, create a copy of the recipe and may need to
adjust some vars (S, FILESPATH or better FILESEXTRAPATHS, ...)
see  i.e.
http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-devtools/mtd/ubi-utils-klibc_1.5.0.bb
http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-kernel/kexec/kexec-tools-klibc_2.0.2.bb

I guess busybox belongs to the heavy ones...

Cheers

Andrea

Re: How to copy recipe and have different target names

[Brian Smucker]

Andrea,

Thanks for your reply.

In my case, the difference in the two recipes is quite minimal: a 
different defconfig and a modified busybox.inc.

Generating the altered recipe is not my question.

My question is, now that I have two overlayed recipes for busybox, the 
standard and the custom, how can I build them both as separate targets?

Thanks,

Brian

On 6/17/2014 9:31 AM, Andrea Adami wrote:
> On Tue, Jun 17, 2014 at 5:41 PM, Brian Smucker <bds@bsmucker.eu.org> wrote:
>> Hello,
>>
>> I would like to have yocto generate two copies of busybox, one
>> statically-linked and one dynamically linked. So I try to make a copy of the
>> busybox recipe and give it a new name like busybox-s_xxxxx.bb
>>
>> But my knowlege of yocto comes up short and I get lots of errors.
>>
>> Is there a way to do this cleanly?  Or should I be trying to do a different
>> approach?
>>
>> Thanks,
>>
>> Brian
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
> Brian,
>
> I don't think there is an 'official' way to do that.
> For a similar purpose (buidling static binaries against klibc) I have
> developed two solutions, both using a custom class:
>
> 1) for easy-to-adapt recipes, BBCLASSEXTEND +  the custom class
> http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-bsp/kexecboot/kexecboot_0.6.bb
>
> 2) for the stubborn cases, create a copy of the recipe and may need to
> adjust some vars (S, FILESPATH or better FILESEXTRAPATHS, ...)
> see  i.e.
> http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-devtools/mtd/ubi-utils-klibc_1.5.0.bb
> http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-kernel/kexec/kexec-tools-klibc_2.0.2.bb
>
> I guess busybox belongs to the heavy ones...
>
> Cheers
>
> Andrea

Re: How to copy recipe and have different target names

[Brian Smucker]

Hi Andrea and all,

So I am using your suggestion to make another variant of busybox: 
busybox-static, and I add the static.bblcass file.

So when I try to do bitbake busybox-static, it ends up unpacking to 
busybox-static-1.20.2-r2/busybox-1.20.2 (which does not correspond to 
the S variable).
And it errors out when it attempts to patch to 
busybox-static-1.20.2-r2/busybox-static-1.20.2 (the S variable path).

What am I missing?

Thanks,

Brian



On 6/17/2014 9:31 AM, Andrea Adami wrote:
> On Tue, Jun 17, 2014 at 5:41 PM, Brian Smucker <bds@bsmucker.eu.org> wrote:
>> Hello,
>>
>> I would like to have yocto generate two copies of busybox, one
>> statically-linked and one dynamically linked. So I try to make a copy of the
>> busybox recipe and give it a new name like busybox-s_xxxxx.bb
>>
>> But my knowlege of yocto comes up short and I get lots of errors.
>>
>> Is there a way to do this cleanly?  Or should I be trying to do a different
>> approach?
>>
>> Thanks,
>>
>> Brian
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
> Brian,
>
> I don't think there is an 'official' way to do that.
> For a similar purpose (buidling static binaries against klibc) I have
> developed two solutions, both using a custom class:
>
> 1) for easy-to-adapt recipes, BBCLASSEXTEND +  the custom class
> http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-bsp/kexecboot/kexecboot_0.6.bb
>
> 2) for the stubborn cases, create a copy of the recipe and may need to
> adjust some vars (S, FILESPATH or better FILESEXTRAPATHS, ...)
> see  i.e.
> http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-devtools/mtd/ubi-utils-klibc_1.5.0.bb
> http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-kernel/kexec/kexec-tools-klibc_2.0.2.bb
>
> I guess busybox belongs to the heavy ones...
>
> Cheers
>
> Andrea

Re: How to copy recipe and have different target names

[Andrea Adami]

On Tue, Jun 17, 2014 at 10:11 PM, Brian Smucker <bds@bsmucker.eu.org> wrote:
> Hi Andrea and all,
>
> So I am using your suggestion to make another variant of busybox:
> busybox-static, and I add the static.bblcass file.
>
> So when I try to do bitbake busybox-static, it ends up unpacking to
> busybox-static-1.20.2-r2/busybox-1.20.2 (which does not correspond to the S
> variable).
> And it errors out when it attempts to patch to
> busybox-static-1.20.2-r2/busybox-static-1.20.2 (the S variable path).
>
> What am I missing?
>

Hi,
sorry but I couldn't do a build-test yet so take my observations with
a grain of salt.
As I prevously hinted there are cases like this requiring some vars
adjustements because you have changed the BPN and PN (base/package
name).

In your -static recipe you could try to redefine

S = "${WORKDIR}/busybox-${PV}

Neverthless, busybox recipe is a special one because it is used
instead of a lot of single utilities.
This implies there are special cares to take to avoid conflicts with
busybox when a recipe is providing the same stuff.

AFAIS packaging should work because the recipe is using ${PN} so
you'll get distinct packages but check the manual about U_A (update
alternatives) and provider conflicts.

You have chosen one of the most complicate recipes to play with ;)

Cheers

Andrea
>
> Thanks,
>
> Brian
>
>
>
> On 6/17/2014 9:31 AM, Andrea Adami wrote:
>>
>> On Tue, Jun 17, 2014 at 5:41 PM, Brian Smucker <bds@bsmucker.eu.org>
>> wrote:
>>>
>>> Hello,
>>>
>>> I would like to have yocto generate two copies of busybox, one
>>> statically-linked and one dynamically linked. So I try to make a copy of
>>> the
>>> busybox recipe and give it a new name like busybox-s_xxxxx.bb
>>>
>>> But my knowlege of yocto comes up short and I get lots of errors.
>>>
>>> Is there a way to do this cleanly?  Or should I be trying to do a
>>> different
>>> approach?
>>>
>>> Thanks,
>>>
>>> Brian
>>> --
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>> Brian,
>>
>> I don't think there is an 'official' way to do that.
>> For a similar purpose (buidling static binaries against klibc) I have
>> developed two solutions, both using a custom class:
>>
>> 1) for easy-to-adapt recipes, BBCLASSEXTEND +  the custom class
>>
>> http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-bsp/kexecboot/kexecboot_0.6.bb
>>
>> 2) for the stubborn cases, create a copy of the recipe and may need to
>> adjust some vars (S, FILESPATH or better FILESEXTRAPATHS, ...)
>> see  i.e.
>>
>> http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-devtools/mtd/ubi-utils-klibc_1.5.0.bb
>>
>> http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-kernel/kexec/kexec-tools-klibc_2.0.2.bb
>>
>> I guess busybox belongs to the heavy ones...
>>
>> Cheers
>>
>> Andrea
>
>