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
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 shou
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.
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
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: Bru
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 aft
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@li
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:
>>
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
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 D
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
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.
> >>> Buil
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
a678243d6e4add90c1e9459da42d
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:
>>
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
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
> a678243
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_
* 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
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/reci
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
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
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/
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 m
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 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 p
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
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 a
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_
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 archit
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_FEATURE
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: ' pre
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 +0
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 i
33 matches
Mail list logo
