Re: [OE-core] [PATCH] linux-yocto-custom: Use SRCREV_machine
On Sat, Mar 15, 2014 at 12:42 AM, Darren Hart wrote:
> On 3/14/14, 20:51, "Bruce Ashfield" wrote:
>
>>On Fri, Mar 14, 2014 at 5:15 PM, Darren Hart
>>wrote:
>>> The Yocto kernel tools look for SRCREV_machine in do_validate_branches,
>>> if it's empty, it just returns and silently continues. This likely needs
>>> at least a warning. However, this recipe should be using SRCREV_machine,
>>> and not just SRCREV.
>
> Saul had a recipe using Linus' git tree and an old rev in master. It
> worked in 1.3, but not in 1.5. He found that without setting
> SRCREV_machine specifically, the wrong SRCREV would be checked out, and
> the subsequent patches would fail to apply. Saul can provide specifics.
> Happy to have this wait until we've spelled it out correctly.
ok, that sounds plausible.
he change looks fine to me, since every other kernel user of the kernel-yocto
machine_meta SRCREV has machine properly specified, this one should
as well ..regardless of what was happening.
So consider this Acked-by: Bruce Ashfield
Bruce
>
> --
> Darren
>
>>
>>I can't think of anything that breaks with this .. but my spidey
>>senses are tingling.
>>
>>This log should tell us what actually broke in the end ? What failed
>>to build / work
>>or otherwise explode ?
>>
>>Bruce
>>
>>>
>>> Signed-off-by: Darren Hart
>>> Reported-by: Saul Wold
>>> Cc: Bruce Ashfield
>>> ---
>>> .../recipes-kernel/linux/linux-yocto-custom.bb |2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
>>>b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
>>> index 4115d2f..42162f3 100644
>>> --- a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
>>> +++ b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
>>> @@ -54,7 +54,7 @@ LINUX_VERSION_EXTENSION ?= "-custom"
>>> # Override SRCREV to point to a different commit in a bbappend file to
>>> # build a different release of the Linux kernel.
>>> # tag: v3.4 76e10d158efb6d4516018846f60c2ab5501900bc
>>> -SRCREV="76e10d158efb6d4516018846f60c2ab5501900bc"
>>> +SRCREV_machine="76e10d158efb6d4516018846f60c2ab5501900bc"
>>>
>>> PR = "r1"
>>> PV = "${LINUX_VERSION}+git${SRCPV}"
>>> --
>>> 1.7.9.5
>>>
>>> --
>>> ___
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>>
>>
>>--
>>"Thou shalt not follow the NULL pointer, for chaos and madness await
>>thee at its end"
>>
>
>
>
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] linux-yocto-custom: Use SRCREV_machine
On 3/14/14, 20:51, "Bruce Ashfield" wrote:
>On Fri, Mar 14, 2014 at 5:15 PM, Darren Hart
>wrote:
>> The Yocto kernel tools look for SRCREV_machine in do_validate_branches,
>> if it's empty, it just returns and silently continues. This likely needs
>> at least a warning. However, this recipe should be using SRCREV_machine,
>> and not just SRCREV.
Saul had a recipe using Linus' git tree and an old rev in master. It
worked in 1.3, but not in 1.5. He found that without setting
SRCREV_machine specifically, the wrong SRCREV would be checked out, and
the subsequent patches would fail to apply. Saul can provide specifics.
Happy to have this wait until we've spelled it out correctly.
--
Darren
>
>I can't think of anything that breaks with this .. but my spidey
>senses are tingling.
>
>This log should tell us what actually broke in the end ? What failed
>to build / work
>or otherwise explode ?
>
>Bruce
>
>>
>> Signed-off-by: Darren Hart
>> Reported-by: Saul Wold
>> Cc: Bruce Ashfield
>> ---
>> .../recipes-kernel/linux/linux-yocto-custom.bb |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
>>b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
>> index 4115d2f..42162f3 100644
>> --- a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
>> +++ b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
>> @@ -54,7 +54,7 @@ LINUX_VERSION_EXTENSION ?= "-custom"
>> # Override SRCREV to point to a different commit in a bbappend file to
>> # build a different release of the Linux kernel.
>> # tag: v3.4 76e10d158efb6d4516018846f60c2ab5501900bc
>> -SRCREV="76e10d158efb6d4516018846f60c2ab5501900bc"
>> +SRCREV_machine="76e10d158efb6d4516018846f60c2ab5501900bc"
>>
>> PR = "r1"
>> PV = "${LINUX_VERSION}+git${SRCPV}"
>> --
>> 1.7.9.5
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
>--
>"Thou shalt not follow the NULL pointer, for chaos and madness await
>thee at its end"
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] linux-yocto-custom: Use SRCREV_machine
On Fri, Mar 14, 2014 at 5:15 PM, Darren Hart wrote:
> The Yocto kernel tools look for SRCREV_machine in do_validate_branches,
> if it's empty, it just returns and silently continues. This likely needs
> at least a warning. However, this recipe should be using SRCREV_machine,
> and not just SRCREV.
I can't think of anything that breaks with this .. but my spidey
senses are tingling.
This log should tell us what actually broke in the end ? What failed
to build / work
or otherwise explode ?
Bruce
>
> Signed-off-by: Darren Hart
> Reported-by: Saul Wold
> Cc: Bruce Ashfield
> ---
> .../recipes-kernel/linux/linux-yocto-custom.bb |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
> b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
> index 4115d2f..42162f3 100644
> --- a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
> +++ b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
> @@ -54,7 +54,7 @@ LINUX_VERSION_EXTENSION ?= "-custom"
> # Override SRCREV to point to a different commit in a bbappend file to
> # build a different release of the Linux kernel.
> # tag: v3.4 76e10d158efb6d4516018846f60c2ab5501900bc
> -SRCREV="76e10d158efb6d4516018846f60c2ab5501900bc"
> +SRCREV_machine="76e10d158efb6d4516018846f60c2ab5501900bc"
>
> PR = "r1"
> PV = "${LINUX_VERSION}+git${SRCPV}"
> --
> 1.7.9.5
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] lib/oe: turn oe into a namespace package
This will let folks extend the oe package with modules from other layers. Given openembedded consists of more than just oe-core, I think this makes sense, and adds some useful flexibility. Signed-off-by: Christopher Larson --- meta/lib/oe/__init__.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/lib/oe/__init__.py b/meta/lib/oe/__init__.py index e69de29..3ad9513 100644 --- a/meta/lib/oe/__init__.py +++ b/meta/lib/oe/__init__.py @@ -0,0 +1,2 @@ +from pkgutil import extend_path +__path__ = extend_path(__path__, __name__) -- 1.8.3.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] linux-yocto-custom: Use SRCREV_machine
The Yocto kernel tools look for SRCREV_machine in do_validate_branches,
if it's empty, it just returns and silently continues. This likely needs
at least a warning. However, this recipe should be using SRCREV_machine,
and not just SRCREV.
Signed-off-by: Darren Hart
Reported-by: Saul Wold
Cc: Bruce Ashfield
---
.../recipes-kernel/linux/linux-yocto-custom.bb |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
index 4115d2f..42162f3 100644
--- a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
+++ b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
@@ -54,7 +54,7 @@ LINUX_VERSION_EXTENSION ?= "-custom"
# Override SRCREV to point to a different commit in a bbappend file to
# build a different release of the Linux kernel.
# tag: v3.4 76e10d158efb6d4516018846f60c2ab5501900bc
-SRCREV="76e10d158efb6d4516018846f60c2ab5501900bc"
+SRCREV_machine="76e10d158efb6d4516018846f60c2ab5501900bc"
PR = "r1"
PV = "${LINUX_VERSION}+git${SRCPV}"
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [dylan] Backport request
On 14 March 2014 19:16, Khem Raj wrote: > On Fri, Mar 14, 2014 at 12:13 PM, Chris Larson wrote: >> You'll be amazed how many headaches you can save having the host environment >> be a known quantity :) > > absolutely > I cant agree more. > -Khem I used to do this with a separate build VM but after a hardware re-arrange I don't have the spare machine anymore. I've never used containers before but I've read plenty about them. Just setup Ubuntu Server 12.04 in a container and I'm going to see if I can get the builds running in this. I still think the backport of the fix for eglibc-2.17 with make version > 4.0 is worth doing, but this route gives me a more stable build environment anyway. Cheers for the advice! -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [dylan] Backport request
On Fri, Mar 14, 2014 at 12:13 PM, Chris Larson wrote: > You'll be amazed how many headaches you can save having the host environment > be a known quantity :) absolutely I cant agree more. -Khem -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [dylan] Backport request
On Fri, Mar 14, 2014 at 12:11 PM, Jack Mitchell wrote: > > > On 14/03/2014 18:57, Saul Wold wrote: >> >> On 03/14/2014 11:34 AM, Paul Barker wrote: >>> >>> I'm stuck using Dylan for a project as I need a 3.2 series kernel. >>> Building on my current development machine I ran into two failures: >>> >>> eglibc-initial, do_configure: Make 4.0 isn't recognised >>> >>> This can be fixed by backporting >>> a678243d6e4add90c1e9459da42de34d3724db5d (already in Dora). >>> >>> linux-yocto_3.2: do_patch: Unsupported version of git (1.9.0) >>> >>> I fixed this by removing git-native from ASSUME_PROVIDED in >>> meta/conf/bitbake.conf so that git-native-1.8.1.4 was built and used. >>> That isn't something we should commit in Dylan but may be useful for >>> others to know the solution if they run into the same problem. >>> >> Can't you use the buildtools tarball? It includes the right version of >> make and git. > > > Indeed, this is what I do on my ArchLinux machines when something is too > new; it's just a simple sourcing of an environment file before the build and > you're good to go. build system underneath might still inject bugs into your cross build even though you got it building. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [dylan] Backport request
On Fri, Mar 14, 2014 at 12:11 PM, Paul Barker wrote: > >> I use containers. systemd-nspawn goes long way > > > > > > Yeah, containers (systemd-nspawn, docker) or even a chroot can be > > invaluable. schroot on a debian machine works quite well too for > something > > as simple as builds. I end up aliasing bb and bitbake to transparently > run > > in the chroot at all times. > > It's time I learnt how to use these newfangled containers then... You'll be amazed how many headaches you can save having the host environment be a known quantity :) -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [dylan] Backport request
On 14 March 2014 19:06, Chris Larson wrote: > > On Fri, Mar 14, 2014 at 11:46 AM, Khem Raj wrote: >> >> On Fri, Mar 14, 2014 at 11:44 AM, Paul Barker >> wrote: >> > On 14 March 2014 18:37, Khem Raj wrote: >> >> On Fri, Mar 14, 2014 at 11:34 AM, Paul Barker >> >> wrote: >> >>> I'm stuck using Dylan for a project as I need a 3.2 series kernel. >> >>> Building on my current development machine I ran into two failures: >> >>> >> >>> eglibc-initial, do_configure: Make 4.0 isn't recognised >> >>> >> >>> This can be fixed by backporting >> >>> a678243d6e4add90c1e9459da42de34d3724db5d (already in Dora). >> >>> >> >>> linux-yocto_3.2: do_patch: Unsupported version of git (1.9.0) >> >>> >> >>> I fixed this by removing git-native from ASSUME_PROVIDED in >> >>> meta/conf/bitbake.conf so that git-native-1.8.1.4 was built and used. >> >>> That isn't something we should commit in Dylan but may be useful for >> >>> others to know the solution if they run into the same problem. >> >> >> >> I think if you also lock your build machine OS along with yocto >> >> release, it is less painful. >> > >> > It is definitely less painful. I'm lacking the spare hardware though >> > and I want to avoid building inside a VM if I can as I'll be limited >> > on how much RAM I can allocate to it and I think the performance will >> > take a hit. Thankfully this project isn't far off end-of-life now. >> >> I use containers. systemd-nspawn goes long way > > > Yeah, containers (systemd-nspawn, docker) or even a chroot can be > invaluable. schroot on a debian machine works quite well too for something > as simple as builds. I end up aliasing bb and bitbake to transparently run > in the chroot at all times. It's time I learnt how to use these newfangled containers then... -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [dylan] Backport request
On 14/03/2014 18:57, Saul Wold wrote: On 03/14/2014 11:34 AM, Paul Barker wrote: I'm stuck using Dylan for a project as I need a 3.2 series kernel. Building on my current development machine I ran into two failures: eglibc-initial, do_configure: Make 4.0 isn't recognised This can be fixed by backporting a678243d6e4add90c1e9459da42de34d3724db5d (already in Dora). linux-yocto_3.2: do_patch: Unsupported version of git (1.9.0) I fixed this by removing git-native from ASSUME_PROVIDED in meta/conf/bitbake.conf so that git-native-1.8.1.4 was built and used. That isn't something we should commit in Dylan but may be useful for others to know the solution if they run into the same problem. Can't you use the buildtools tarball? It includes the right version of make and git. Indeed, this is what I do on my ArchLinux machines when something is too new; it's just a simple sourcing of an environment file before the build and you're good to go. Cheers, Sau! Thanks, -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [dylan] Backport request
On Fri, Mar 14, 2014 at 11:46 AM, Khem Raj wrote: > On Fri, Mar 14, 2014 at 11:44 AM, Paul Barker > wrote: > > On 14 March 2014 18:37, Khem Raj wrote: > >> On Fri, Mar 14, 2014 at 11:34 AM, Paul Barker > wrote: > >>> I'm stuck using Dylan for a project as I need a 3.2 series kernel. > >>> Building on my current development machine I ran into two failures: > >>> > >>> eglibc-initial, do_configure: Make 4.0 isn't recognised > >>> > >>> This can be fixed by backporting > >>> a678243d6e4add90c1e9459da42de34d3724db5d (already in Dora). > >>> > >>> linux-yocto_3.2: do_patch: Unsupported version of git (1.9.0) > >>> > >>> I fixed this by removing git-native from ASSUME_PROVIDED in > >>> meta/conf/bitbake.conf so that git-native-1.8.1.4 was built and used. > >>> That isn't something we should commit in Dylan but may be useful for > >>> others to know the solution if they run into the same problem. > >> > >> I think if you also lock your build machine OS along with yocto > >> release, it is less painful. > > > > It is definitely less painful. I'm lacking the spare hardware though > > and I want to avoid building inside a VM if I can as I'll be limited > > on how much RAM I can allocate to it and I think the performance will > > take a hit. Thankfully this project isn't far off end-of-life now. > > I use containers. systemd-nspawn goes long way Yeah, containers (systemd-nspawn, docker) or even a chroot can be invaluable. schroot on a debian machine works quite well too for something as simple as builds. I end up aliasing bb and bitbake to transparently run in the chroot at all times. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [dylan] Backport request
On 03/14/2014 11:34 AM, Paul Barker wrote: I'm stuck using Dylan for a project as I need a 3.2 series kernel. Building on my current development machine I ran into two failures: eglibc-initial, do_configure: Make 4.0 isn't recognised This can be fixed by backporting a678243d6e4add90c1e9459da42de34d3724db5d (already in Dora). linux-yocto_3.2: do_patch: Unsupported version of git (1.9.0) I fixed this by removing git-native from ASSUME_PROVIDED in meta/conf/bitbake.conf so that git-native-1.8.1.4 was built and used. That isn't something we should commit in Dylan but may be useful for others to know the solution if they run into the same problem. Can't you use the buildtools tarball? It includes the right version of make and git. Sau! Thanks, -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [dylan] Backport request
On Fri, Mar 14, 2014 at 11:44 AM, Paul Barker wrote: > On 14 March 2014 18:37, Khem Raj wrote: >> On Fri, Mar 14, 2014 at 11:34 AM, Paul Barker wrote: >>> I'm stuck using Dylan for a project as I need a 3.2 series kernel. >>> Building on my current development machine I ran into two failures: >>> >>> eglibc-initial, do_configure: Make 4.0 isn't recognised >>> >>> This can be fixed by backporting >>> a678243d6e4add90c1e9459da42de34d3724db5d (already in Dora). >>> >>> linux-yocto_3.2: do_patch: Unsupported version of git (1.9.0) >>> >>> I fixed this by removing git-native from ASSUME_PROVIDED in >>> meta/conf/bitbake.conf so that git-native-1.8.1.4 was built and used. >>> That isn't something we should commit in Dylan but may be useful for >>> others to know the solution if they run into the same problem. >> >> I think if you also lock your build machine OS along with yocto >> release, it is less painful. > > It is definitely less painful. I'm lacking the spare hardware though > and I want to avoid building inside a VM if I can as I'll be limited > on how much RAM I can allocate to it and I think the performance will > take a hit. Thankfully this project isn't far off end-of-life now. I use containers. systemd-nspawn goes long way -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [dylan] Backport request
On 14 March 2014 18:37, Khem Raj wrote: > On Fri, Mar 14, 2014 at 11:34 AM, Paul Barker wrote: >> I'm stuck using Dylan for a project as I need a 3.2 series kernel. >> Building on my current development machine I ran into two failures: >> >> eglibc-initial, do_configure: Make 4.0 isn't recognised >> >> This can be fixed by backporting >> a678243d6e4add90c1e9459da42de34d3724db5d (already in Dora). >> >> linux-yocto_3.2: do_patch: Unsupported version of git (1.9.0) >> >> I fixed this by removing git-native from ASSUME_PROVIDED in >> meta/conf/bitbake.conf so that git-native-1.8.1.4 was built and used. >> That isn't something we should commit in Dylan but may be useful for >> others to know the solution if they run into the same problem. > > I think if you also lock your build machine OS along with yocto > release, it is less painful. It is definitely less painful. I'm lacking the spare hardware though and I want to avoid building inside a VM if I can as I'll be limited on how much RAM I can allocate to it and I think the performance will take a hit. Thankfully this project isn't far off end-of-life now. -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [dylan] Backport request
On Fri, Mar 14, 2014 at 11:34 AM, Paul Barker wrote: > I'm stuck using Dylan for a project as I need a 3.2 series kernel. > Building on my current development machine I ran into two failures: > > eglibc-initial, do_configure: Make 4.0 isn't recognised > > This can be fixed by backporting > a678243d6e4add90c1e9459da42de34d3724db5d (already in Dora). > > linux-yocto_3.2: do_patch: Unsupported version of git (1.9.0) > > I fixed this by removing git-native from ASSUME_PROVIDED in > meta/conf/bitbake.conf so that git-native-1.8.1.4 was built and used. > That isn't something we should commit in Dylan but may be useful for > others to know the solution if they run into the same problem. I think if you also lock your build machine OS along with yocto release, it is less painful. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [dylan] Backport request
I'm stuck using Dylan for a project as I need a 3.2 series kernel. Building on my current development machine I ran into two failures: eglibc-initial, do_configure: Make 4.0 isn't recognised This can be fixed by backporting a678243d6e4add90c1e9459da42de34d3724db5d (already in Dora). linux-yocto_3.2: do_patch: Unsupported version of git (1.9.0) I fixed this by removing git-native from ASSUME_PROVIDED in meta/conf/bitbake.conf so that git-native-1.8.1.4 was built and used. That isn't something we should commit in Dylan but may be useful for others to know the solution if they run into the same problem. Thanks, -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [WIP][PATCH] report-error: Allow to upload reports automatically
* useful when distro wants to collect build statistics from
all users/developers without any manual interaction from them
Signed-off-by: Martin Jansa
---
meta/classes/report-error.bbclass| 85 +++-
meta/conf/local.conf.sample.extended | 20 +
2 files changed, 103 insertions(+), 2 deletions(-)
diff --git a/meta/classes/report-error.bbclass
b/meta/classes/report-error.bbclass
index 479b38d..0a53a60 100644
--- a/meta/classes/report-error.bbclass
+++ b/meta/classes/report-error.bbclass
@@ -7,6 +7,12 @@
# Licensed under the MIT license, see COPYING.MIT for details
ERR_REPORT_DIR ?= "${LOG_DIR}/error-report"
+ERR_REPORT_PORT ?= "80"
+
+ERR_REPORT_UPLOAD_FAILURES[type] = "boolean"
+ERR_REPORT_UPLOAD_FAILURES ?= "0"
+ERR_REPORT_UPLOAD_ALL[type] = "boolean"
+ERR_REPORT_UPLOAD_ALL ?= "0"
def errorreport_getdata(e):
logpath = e.data.getVar('ERR_REPORT_DIR', True)
@@ -24,6 +30,77 @@ def errorreport_savedata(e, newdata, file):
json.dump(newdata, f, indent=4, sort_keys=True)
return datafile
+# from scripts/send-error-report to automate report submissions
+def errorreport_senddata(e, json_file):
+import httplib, urllib, os, sys, json, subprocess
+
+if os.path.isfile(json_file):
+username = e.data.getVar('ERR_REPORT_USERNAME', True)
+email = e.data.getVar('ERR_REPORT_EMAIL', True)
+server = e.data.getVar('ERR_REPORT_SERVER', True)
+port = e.data.getVar('ERR_REPORT_PORT', True)
+
+if not username or email:
+# try to read them from git config
+username = subprocess.check_output(['git', 'config', '--get',
'user.name']).strip()
+email = subprocess.check_output(['git', 'config', '--get',
'user.email']).strip()
+
+if not username or not server:
+home = os.path.expanduser("~")
+userfile = os.path.join(home, ".oe-send-error")
+if os.path.isfile(userfile):
+with open(userfile) as g:
+username = g.readline()
+email = g.readline()
+else:
+print("Please enter your name and your email (optionally),
they'll be saved in the file you send.")
+username = raw_input("Name: ")
+email = raw_input("E-mail (not required): ")
+server = raw_input("Server: ")
+port = raw_input("Port: ")
+if len(username) > 0 and len(username) < 50:
+with open(userfile, "w") as g:
+g.write(username + "\n")
+g.write(email + "\n")
+g.write(server + "\n")
+g.write(port + "\n")
+else:
+print("Invalid inputs, try again.")
+return
+
+bb.note("Uploading the report to %s:%s" % (server, port))
+
+with open(json_file) as f:
+data = f.read()
+
+try:
+jsondata = json.loads(data)
+jsondata['username'] = username.strip()
+jsondata['email'] = email.strip()
+data = json.dumps(jsondata, indent=4, sort_keys=True)
+except:
+print("Invalid json data")
+return
+
+try:
+params = urllib.urlencode({'data': data})
+headers = {"Content-type": "application/json"}
+conn = httplib.HTTPConnection(server, port)
+conn.request("POST", "/ClientPost/", params, headers)
+response = conn.getresponse()
+print response.status, response.reason
+res = response.read()
+if response.status == 200:
+print res
+else:
+print("There was a problem submiting your data")
+conn.close()
+except:
+print("Server connection failed")
+
+else:
+print("No data file found.")
+
python errorreport_handler () {
import json
@@ -55,11 +132,15 @@ python errorreport_handler () {
elif isinstance(e, bb.event.BuildCompleted):
jsondata = json.loads(errorreport_getdata(e))
+upload_failures =
oe.data.typed_value('ERR_REPORT_UPLOAD_FAILURES', e.data)
+upload_all = oe.data.typed_value('ERR_REPORT_UPLOAD_ALL', e.data)
failures = jsondata['failures']
-if(len(failures) > 0):
+if len(failures) > 0 or upload_all:
filename = "error_report_" + e.data.getVar("BUILDNAME")+".txt"
datafile = errorreport_savedata(e, jsondata, filename)
-bb.note("The errors of this build are stored in: %s. You can
send the errors to an upstream server by running: send-error-report %s
[server]" % (datafile, datafile))
+bb.note("The report of this build are stored in: %s." %
(datafile))
+if upload_all or (len(failures) > 0 and upload_failures):
+
[OE-core] [PATCH] make: add 'inherit pkgconfig'
Bitbaking make-native generates syntax error during
configure: 'PKG_PROG_PKG_CONFIG: command not found'.
Add 'inherit pkgconfig' to solve this issue.
Signed-off-by: Valentin Popa
---
meta/recipes-devtools/make/make.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/make/make.inc
b/meta/recipes-devtools/make/make.inc
index 2e90eca..4036345 100644
--- a/meta/recipes-devtools/make/make.inc
+++ b/meta/recipes-devtools/make/make.inc
@@ -7,4 +7,4 @@ SECTION = "devel"
SRC_URI = "${GNU_MIRROR}/make/make-${PV}.tar.bz2"
-inherit autotools gettext
+inherit autotools gettext pkgconfig
--
1.8.3.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/6 V3] refactor the archiver*.bbclass
On 03/14/2014 01:45 AM, Burton, Ross wrote: On 11 March 2014 17:08, Robert Yang wrote: Robert Yang (6): classes/archive*.bbclass: remove archive-*-source.bbclass archiver.bbclass: refactor it package_rpm.bbclass: archive the source to srpm package archiver.bbclass: move a few code to copyleft_compliance.bbclass local.conf.sample.extended: update for the archiver patch.bbclass: do_patch: unset TMPDIR from environment This series appears to work for me and doesn't cause rebuilds (after removing the patch change, as that obviously does). Can anyone else who actively uses the archiver verify that it still works for them? Thank you very much for the testing and suggestions, I've updated it a little: * Remove the [PATCH 6/6] which is used for unset the TMPDIR, we can fix it in another thread as bug 5968 describes since it doesn't affect the archiver. * Modified the do_ar_configured a little and tested the "bitbake core-image-sato world meta-toolchain", it worked well. Here is the repo: (the same repo as before) git://git.openembedded.org/openembedded-core-contrib rbt/archiver_v3 http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/archiver_v3 Robert Yang (5): classes/archive*.bbclass: remove archive-*-source.bbclass archiver.bbclass: refactor it package_rpm.bbclass: archive the source to srpm package archiver.bbclass: move a few code to copyleft_compliance.bbclass local.conf.sample.extended: update for the archiver // Robert Cheers, Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Why to make branch info is mandatory for non-master commit with latest bitbake
Hi Richard, sorry to jump in so late, but I just realized that this "small" change has some impact also on our ELDK recipies, so I would really like to understand where the change comes from and why we couple a persistent specification (commit ID) with a transient specification (branch name). With all my previous git experience, this looks at least somewhat strange. > On Mon, 2013-12-23 at 06:41 +, > zhenhua@freescale.com wrote: >> Previously the branch name doesn't need to be defined when a >> non-master branch commit is referred in recipe, this has been changed >> in latest bitbake. >> >> Is this an intentional change? May I know the reason of the change >> if it is intentional? > > It was intentional and was triggered by this change: > > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=f19546e02d3318ee69fd0c34e21aa97b74c987ec > > which is a sanity test added to fix certain failure cases where a given > revision wasn't on a specified branch. > > The bug was nasty since the fetcher was hitting the network in cases it > shouldn't have been when a branch wasn't specified. I looked at the provided link but I'm not certain that I understand the problem nor the fix for it. As far as I can make out, the "failure mode" was likely a specified commit ID that was not available in the local downloads. As a consequence, the fetcher then hit the network and tried to find this (locally not existing) version in the upstream repository. So very likely, the "failure" was that a network access happened at all, correct? So the "failure" is much more a "we don't want network access at all under certain circumstances". If this is correct, then I see how the fix prevents this by effectively limiting the selectable commit IDs to the _existing_ commits in one branch. But doesn't that prevent me from specifying a commit-id in an upstream branch "later" then what I have available locally in that old branch state? I.e. should we rather find a way to say "no downloads are allowed at all" rather than adding this workaround? Of course we can fix all our recipies, but I'd really like to understand why we are doing this. Thanks! Detlev -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libsdl: add missing libglu dependency for openGL
From: Koen Kooi
Configure checks for glu.h to determine if openGL is available.
Signed-off-by: Koen Kooi
---
meta/recipes-graphics/libsdl/libsdl_1.2.15.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
b/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
index dd2c540..e19c388 100644
--- a/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
+++ b/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
@@ -13,7 +13,7 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=27818cd7fd83877a8e3ef82b82798ef4"
PROVIDES = "virtual/libsdl"
DEPENDS = "${@base_contains('DISTRO_FEATURES', 'directfb', 'directfb', '', d)}
\
- ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl', '',
d)} \
+ ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl
libglu', '', d)} \
${@base_contains('DISTRO_FEATURES', 'x11', 'virtual/libx11 libxext
libxrandr libxrender', '', d)} \
tslib"
DEPENDS_class-nativesdk = "${@base_contains('DISTRO_FEATURES', 'x11',
'virtual/nativesdk-libx11 nativesdk-libxrandr nativesdk-libxrender
nativesdk-libxext', '', d)}"
--
1.8.4.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH_V2] mips64-linux: set ac_cv_sizeof_ssize_t
Set ac_cv_sizeof_ssize_t for mips64;
mips-common will not overwrite it.
"ssize_t is a posix define which is architecture specific whose value
is signed size_t, glibc/uclibc for mips64/n64 linux platform defines
it to be equivalent of 'long' and long here is 8bytes because
mips64/n64 follows LP64 model. In OpenEmbedded our default ABI for
mips64 platforms is N64, having said that autoconf decides to poke at
the platform for finding these kind of sizes which fails when you are
doing cross compiling hence we have to cache it." - Khem Raj
[YOCTO #5935]
Signed-off-by: Valentin Popa
---
meta/site/mips64-linux | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/site/mips64-linux b/meta/site/mips64-linux
index 4449c96..ed0fbbe 100644
--- a/meta/site/mips64-linux
+++ b/meta/site/mips64-linux
@@ -35,6 +35,7 @@ glib_cv_use_pid_surrogate=${glib_cv_use_pid_surrogate=yes}
ac_cv_alignof_guint32=4
ac_cv_alignof_guint64=8
ac_cv_alignof_unsigned_long=8
+ac_cv_sizeof_ssize_t=8
# libpcap
ac_cv_linux_vers=${ac_cv_linux_vers=2}
--
1.8.3.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/6] package_rpm.bbclass: archive the source to srpm package
On 14 March 2014 02:14, Robert Yang wrote: > I'd like to remove the sources in the first thought, but that would > cause a problem: if we only re-run the do_package_write_rpm, for example, > when the FILES is changed, then the sources are gone, and we would get > nothing in the .src.rpm. I thing that keep both the .src.rpm and.tar.gz > is not a big problem, so I changed the usage to: Good argument, fair enough. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Set ac_cv_sizeof_ssize_t
On 03/14/2014 12:10 PM, Khem Raj wrote:
On Fri, Mar 14, 2014 at 12:40 AM, Saul Wold wrote:
On 03/13/2014 04:28 AM, Valentin Popa wrote:
Set ac_cv_sizeof_ssize_t for mips64;
mips-common will not overwrite it.
This really needed a little more about "why" this change is needed.
ssize_t is a posix define which is architecture specific whose value
is signed size_t, glibc/uclibc for mips64/n64 linux platform defines
it to be equivalent of 'long' and long here is 8bytes because
mips64/n64 follows LP64 model. In OpenEmbedded our default ABI for
mips64 platforms is N64, having said that autoconf decides to poke at
the platform for finding these kind of sizes which fails when you are
doing cross compiling hence we have to cache it.
Thanks for the explanation Khem!
Sau!
[YOCTO #5935]
Signed-off-by: Valentin Popa
---
meta/site/mips64-linux | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/site/mips64-linux b/meta/site/mips64-linux
index 4449c96..ed0fbbe 100644
--- a/meta/site/mips64-linux
+++ b/meta/site/mips64-linux
@@ -35,6 +35,7 @@
glib_cv_use_pid_surrogate=${glib_cv_use_pid_surrogate=yes}
ac_cv_alignof_guint32=4
ac_cv_alignof_guint64=8
ac_cv_alignof_unsigned_long=8
+ac_cv_sizeof_ssize_t=8
# libpcap
ac_cv_linux_vers=${ac_cv_linux_vers=2}
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] OpenEmbedded Developers meeting after ELC May 2-3
Please read: http://openembedded.org/wiki/OEDAM We'd like to get a good idea of the number of people attending. If you are waiting for approvals to travel, you could add yourself as tentative so we have some idea of total attendance for planning. If you are having trouble adding yourself on the wiki, send the info to me and I can add it for you. Thanks, Philip -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 6/6] patch.bbclass: do_patch: unset TMPDIR from environment
On 03/14/2014 12:54 AM, Burton, Ross wrote:
On 13 March 2014 16:46, Burton, Ross wrote:
On 11 March 2014 17:08, Robert Yang wrote:
We need unset it after we use it, otherwise it would affect the env
after we run "bb.build.exec_func('do_patch', d)", and will cause
unexpected errors.
This assignment has been there since October 2012, so what are the
problems that this causes?
So what bothers me about this (and the original patch) is that TMPDIR
has special meaning to bitbake and the conflict with patch's temporary
directory is unfortunate. Maybe a better solution is to change
meta/lib/oe/patch.py to set TMPDIR when invoking patch so the changed
TMPDIR is constrained to the patch process and nothing else.
Hi Ross,
The problem is that:
1) do_patch set "TMPDIR" in env, it would remove the directory but didn't
unset the "TMPDIR".
2) autoconf will use the "TMPDIR" from the env:
autoconf/Autom4te/General.pm: my $TMPDIR = $ENV{'TMPDIR'} || '/tmp';
And if the dir doesn't exist, there would be errors.
I had met this problem because I used the do_patch and do_configure
in one task:
bb.build.exec_func('do_patch', d)
bb.build.exec_func('do_configure', d)
I had split them into 2 tasks, so the "TMPDIR" doesn't affact the
archiver.bbclass any more.
I've tried to set the TMPDIR in meta/lib/oe/patch.py, but met more
problems, the PATCHTOOL = "patch" doesn't work (Seems only on
OpenSuse 12.2), I've filed a bug for it:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5968
I think that we can fix it in another thread since it doesn't affect
the archiver.bbclass, as we have talked, we may drop the
PATCHTOOL = "patch"
// Robert
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] dbus: fix a hard dependency about dbus-ptest
On Friday 14 March 2014 17:14:27 Chong Lu wrote:
> On 03/13/2014 06:01 PM, Paul Eggleton wrote:
> > On Thursday 13 March 2014 17:54:03 Chong Lu wrote:
> >> On 03/06/2014 06:04 PM, Burton, Ross wrote:
> >>> On 6 March 2014 08:06, Chong Lu wrote:
> +PACKAGES += "dbus-ptest"
> +ALLOW_EMPTY_${PN}-ptest = "1"
> +RDEPENDS_${PN}-ptest = "${@base_contains('IMAGE_FEATURES',
> 'ptest-pkgs',
> 'dbus-test-ptest', 'dbus-test', d)}"
> >>>
> >>> Clearly I wasn't thinking clearly last week. You can't check
> >>> IMAGE_FEATURES in a non-image recipe so this isn't a good solution.
> >>
> >> Do you have any suggestion about this issue?
> >> If we don't check IMAGE_FEATURES, I have no way to resolve this problem
> >> that only build but not install ptest. I'm very confused.
> >
> > This should check DISTRO_FEATURES, not IMAGE_FEATURES. Assuming ptest is
> > in
> > DISTRO_FEATURES, even if ptest is not in IMAGE_FEATURES it doesn't matter
> > if the dependency between dbus-ptest and dbus-ptest-ptest exists because
> > dbus- ptest itself shouldn't be in the image, so dbus-ptest-ptest
> > shouldn't be pulled in either. Does that make sense?
> >
> > Cheers,
> > Paul
>
> Hi Paul,
>
> Thanks for your reply!
> But I still have a question.
>
> I try to following way:
>
> # git diff
> diff --git a/meta/recipes-core/dbus/dbus-ptest_1.6.18.bb
> b/meta/recipes-core/dbus/dbus-ptest_1.6.18.bb
> index bc260de..50dfe54 100644
> --- a/meta/recipes-core/dbus/dbus-ptest_1.6.18.bb
> +++ b/meta/recipes-core/dbus/dbus-ptest_1.6.18.bb
> @@ -9,6 +9,7 @@ DEPENDS = "python-pygobject dbus dbus-glib"
>
> RDEPENDS_${PN} += "make"
> RDEPENDS_${PN}-dev = ""
> +ALLOW_EMPTY_${PN} = "1"
>
> SRC_URI = "http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \
> file://tmpdir.patch \
> diff --git a/meta/recipes-core/dbus/dbus.inc
> b/meta/recipes-core/dbus/dbus.inc
> index 677ff78..ba7f3cb 100644
> --- a/meta/recipes-core/dbus/dbus.inc
> +++ b/meta/recipes-core/dbus/dbus.inc
> @@ -6,7 +6,7 @@ LICENSE = "AFL-2 | GPLv2+"
> LIC_FILES_CHKSUM = "file://COPYING;md5=10dded3b58148f3f1fd804b26354af3e \
> file://dbus/dbus.h;beginline=6;endline=20;md5=7755c9d7abccd5dbd25a6a974538bb
> 3c" DEPENDS = "expat virtual/libintl"
> -RDEPENDS_dbus = "${@base_contains('DISTRO_FEATURES', 'ptest',
> 'dbus-ptest-ptest', '', d)}"
> +RDEPENDS_dbus = "dbus-ptest"
The line above is the problem. You *cannot* do this or dbus-ptest (and
therefore dbus-ptest-ptest) will always be installed whether you want it or
not. You need to remove this line.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Set ac_cv_sizeof_ssize_t
On Fri, Mar 14, 2014 at 12:40 AM, Saul Wold wrote:
> On 03/13/2014 04:28 AM, Valentin Popa wrote:
>>
>> Set ac_cv_sizeof_ssize_t for mips64;
>> mips-common will not overwrite it.
>>
>
> This really needed a little more about "why" this change is needed.
>
ssize_t is a posix define which is architecture specific whose value
is signed size_t, glibc/uclibc for mips64/n64 linux platform defines
it to be equivalent of 'long' and long here is 8bytes because
mips64/n64 follows LP64 model. In OpenEmbedded our default ABI for
mips64 platforms is N64, having said that autoconf decides to poke at
the platform for finding these kind of sizes which fails when you are
doing cross compiling hence we have to cache it.
> Sau!
>
>
>> [YOCTO #5935]
>>
>> Signed-off-by: Valentin Popa
>> ---
>> meta/site/mips64-linux | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/meta/site/mips64-linux b/meta/site/mips64-linux
>> index 4449c96..ed0fbbe 100644
>> --- a/meta/site/mips64-linux
>> +++ b/meta/site/mips64-linux
>> @@ -35,6 +35,7 @@
>> glib_cv_use_pid_surrogate=${glib_cv_use_pid_surrogate=yes}
>> ac_cv_alignof_guint32=4
>> ac_cv_alignof_guint64=8
>> ac_cv_alignof_unsigned_long=8
>> +ac_cv_sizeof_ssize_t=8
>>
>> # libpcap
>> ac_cv_linux_vers=${ac_cv_linux_vers=2}
>>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] dbus: fix a hard dependency about dbus-ptest
On 03/13/2014 06:01 PM, Paul Eggleton wrote:
On Thursday 13 March 2014 17:54:03 Chong Lu wrote:
On 03/06/2014 06:04 PM, Burton, Ross wrote:
On 6 March 2014 08:06, Chong Lu wrote:
+PACKAGES += "dbus-ptest"
+ALLOW_EMPTY_${PN}-ptest = "1"
+RDEPENDS_${PN}-ptest = "${@base_contains('IMAGE_FEATURES', 'ptest-pkgs',
'dbus-test-ptest', 'dbus-test', d)}"
Clearly I wasn't thinking clearly last week. You can't check
IMAGE_FEATURES in a non-image recipe so this isn't a good solution.
Do you have any suggestion about this issue?
If we don't check IMAGE_FEATURES, I have no way to resolve this problem
that only build but not install ptest. I'm very confused.
This should check DISTRO_FEATURES, not IMAGE_FEATURES. Assuming ptest is in
DISTRO_FEATURES, even if ptest is not in IMAGE_FEATURES it doesn't matter if
the dependency between dbus-ptest and dbus-ptest-ptest exists because dbus-
ptest itself shouldn't be in the image, so dbus-ptest-ptest shouldn't be
pulled in either. Does that make sense?
Cheers,
Paul
Hi Paul,
Thanks for your reply!
But I still have a question.
I try to following way:
# git diff
diff --git a/meta/recipes-core/dbus/dbus-ptest_1.6.18.bb
b/meta/recipes-core/dbus/dbus-ptest_1.6.18.bb
index bc260de..50dfe54 100644
--- a/meta/recipes-core/dbus/dbus-ptest_1.6.18.bb
+++ b/meta/recipes-core/dbus/dbus-ptest_1.6.18.bb
@@ -9,6 +9,7 @@ DEPENDS = "python-pygobject dbus dbus-glib"
RDEPENDS_${PN} += "make"
RDEPENDS_${PN}-dev = ""
+ALLOW_EMPTY_${PN} = "1"
SRC_URI = "http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \
file://tmpdir.patch \
diff --git a/meta/recipes-core/dbus/dbus.inc
b/meta/recipes-core/dbus/dbus.inc
index 677ff78..ba7f3cb 100644
--- a/meta/recipes-core/dbus/dbus.inc
+++ b/meta/recipes-core/dbus/dbus.inc
@@ -6,7 +6,7 @@ LICENSE = "AFL-2 | GPLv2+"
LIC_FILES_CHKSUM = "file://COPYING;md5=10dded3b58148f3f1fd804b26354af3e \
file://dbus/dbus.h;beginline=6;endline=20;md5=7755c9d7abccd5dbd25a6a974538bb3c"
DEPENDS = "expat virtual/libintl"
-RDEPENDS_dbus = "${@base_contains('DISTRO_FEATURES', 'ptest',
'dbus-ptest-ptest', '', d)}"
+RDEPENDS_dbus = "dbus-ptest"
RDEPENDS_dbus_class-native = ""
RDEPENDS_dbus_class-nativesdk = ""
In local.conf, I set following thing:
+EXTRA_IMAGE_FEATURES += "ptest-pkgs"
+CORE_IMAGE_EXTRA_INSTALL += "dbus"
Then, I run "bitbake core-image-minimal" command.
Finally, I start target through runqemu.
But dbus ptest is not installed.
I alway try to many ways to fix this issue, but the result is not
satisfactory.
I think the point of this defect is the following question:
If we only want to build dbus-ptest (generate dbus-ptest-ptest-***.rpm),
but not install it. How to resolve it?
Best Regards
Chong
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Set ac_cv_sizeof_ssize_t
On 2014-03-14 01:40, Saul Wold wrote:
> On 03/13/2014 04:28 AM, Valentin Popa wrote:
>> Set ac_cv_sizeof_ssize_t for mips64;
>> mips-common will not overwrite it.
>>
>
> This really needed a little more about "why" this change is needed.
Also, the email subject is missing the 'mips64-linux: ' prefix which is the
preferred form.
>> [YOCTO #5935]
>>
>> Signed-off-by: Valentin Popa
>> ---
>> meta/site/mips64-linux | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/meta/site/mips64-linux b/meta/site/mips64-linux
>> index 4449c96..ed0fbbe 100644
>> --- a/meta/site/mips64-linux
>> +++ b/meta/site/mips64-linux
>> @@ -35,6 +35,7 @@ glib_cv_use_pid_surrogate=${glib_cv_use_pid_surrogate=yes}
>> ac_cv_alignof_guint32=4
>> ac_cv_alignof_guint64=8
>> ac_cv_alignof_unsigned_long=8
>> +ac_cv_sizeof_ssize_t=8
>>
>> # libpcap
>> ac_cv_linux_vers=${ac_cv_linux_vers=2}
>>
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] systemd 208: move stray /usr/lib/systemd/* into /lib/systemd
Op 14 mrt. 2014, om 02:41 heeft Richard Purdie
het volgende geschreven:
> On Thu, 2014-03-13 at 10:09 +0100, Koen Kooi wrote:
>> Op 21 jan. 2014, om 14:02 heeft Koen Kooi het
>> volgende geschreven:
>>
>>> On 01/21/2014 02:01 PM, Martin Jansa wrote:
On Tue, Jan 21, 2014 at 12:01:21PM +0100, Koen Kooi wrote:
> From: Koen Kooi
>
> Apps testing for systemd config get confused when both /usr/lib/systemd
> and /lib/systemd exist. This fixes (among other things) dracut systemd
> detections.
>
> Signed-off-by: Koen Kooi
> ---
> meta/recipes-core/systemd/systemd_208.bb | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/meta/recipes-core/systemd/systemd_208.bb
> b/meta/recipes-core/systemd/systemd_208.bb
> index 6590235..710624c 100644
> --- a/meta/recipes-core/systemd/systemd_208.bb
> +++ b/meta/recipes-core/systemd/systemd_208.bb
> @@ -113,6 +113,12 @@ do_install() {
>
> # Delete journal README, as log can be symlinked inside volatile.
> rm -f ${D}/${localstatedir}/log/README
> +
> + # fix up libdir confusion
> + if [ -d ${D}${libdir}/systemd ] ; then
> + cp -a ${D}${libdir}/systemd/* ${D}${systemd_unitdir}
> + rm -rf ${D}${libdir}/systemd
> + fi
It's not your fault, but the indentation looks inconsistent with rest of
do_install()
>>>
>>> And I did especially pay attention to use tabs after all the meta-oe
>>> patches I did :)
>>
>> Ping
>
> This kind of patch sets off all the alarm bells. Why? It becomes
> impossible to know which recipes this is fixing
It's fixing the systemd_208.bb recipe to address runtime issues with systemd
itself (ignored files in the wrong dir) and issues with runtime rootlibdir
detection by e.g. dracut. I'm working on a patch for dracut to check for
systemd binaries instead of 'if [ -d /usr/lib/systemd/systemd ]', but I suspect
there are a lot more scripts out there with similar (broken) logic.
> and whether there are
> other underlying issues.
The underlying issue is that upstream doesn't really care for rootlibdir !=
/usr/lib, which means bugs like this happen :(
> Once added it would be near impossible to
> remove or improve upon.
>
> I'd much rather we fix recipes to put files into the correct location
> and thrown errors if they put files somewhere incorrect.
>
> I appreciate its tempting to hack around it but I'm not keen...
Systemd 211 should have a partial fix for this, but you still need patching for
the case where rootlibdir != /usr/lib
regards,
Koen
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Set ac_cv_sizeof_ssize_t
On 03/13/2014 04:28 AM, Valentin Popa wrote:
Set ac_cv_sizeof_ssize_t for mips64;
mips-common will not overwrite it.
This really needed a little more about "why" this change is needed.
Sau!
[YOCTO #5935]
Signed-off-by: Valentin Popa
---
meta/site/mips64-linux | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/site/mips64-linux b/meta/site/mips64-linux
index 4449c96..ed0fbbe 100644
--- a/meta/site/mips64-linux
+++ b/meta/site/mips64-linux
@@ -35,6 +35,7 @@ glib_cv_use_pid_surrogate=${glib_cv_use_pid_surrogate=yes}
ac_cv_alignof_guint32=4
ac_cv_alignof_guint64=8
ac_cv_alignof_unsigned_long=8
+ac_cv_sizeof_ssize_t=8
# libpcap
ac_cv_linux_vers=${ac_cv_linux_vers=2}
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
