On Mon, Jan 28, 2013 at 9:00 AM, Otavio Salvador
wrote:
> On Mon, Jan 28, 2013 at 12:24 PM, Vakul Garg wrote:
>> U-boot patches portal devices for adding new properties in portal nodes.
>> T4 devices such as T4240 have large number of portals. This requires extra
>> space in device tree blob. The
From: Ian Reinhart Geiser
* By default enable only swrast. This needs to
be here or for some reason qemuarm tries to
detect the intel dri libraries and fails.
* For x86 and x86-64 clear out the field so mesa
enabled all of the modules.
builds properly with qemux86 qemuarm and qemux8
On 01/30/2013 04:19 PM, Saul Wold wrote:
> On 01/30/2013 04:03 PM, Darren Hart wrote:
>> On 01/30/2013 03:05 PM, Saul Wold wrote:
>>> This patch will allow recipes that provide kernel modules to package
>>> the module or modules in specific packages. That list is contained in
>>> MODULE_PACKAGES,
On 01/30/2013 04:03 PM, Darren Hart wrote:
On 01/30/2013 03:05 PM, Saul Wold wrote:
This patch will allow recipes that provide kernel modules to package
the module or modules in specific packages. That list is contained in
MODULE_PACKAGES, this defaults to to preserve the current behavior.
s/
On 01/30/2013 03:05 PM, Saul Wold wrote:
> This patch will allow recipes that provide kernel modules to package
> the module or modules in specific packages. That list is contained in
> MODULE_PACKAGES, this defaults to to preserve the current behavior.
s/to to preserve/to preserving/
> The pack
This fixes:
WARNING: QA Issue: dhcp: Files/directories were installed but not shipped
/etc/dhcpd.conf.example
/etc/dhclient.conf.example
Signed-off-by: Saul Wold
---
meta/recipes-connectivity/dhcp/dhcp.inc | 4 ++--
meta/recipes-connectivity/dhcp/dhcp_4.2.5.bb | 2 +-
2 files changed, 3
This patch will allow recipes that provide kernel modules to package
the module or modules in specific packages. That list is contained in
MODULE_PACKAGES, this defaults to to preserve the current behavior.
The package can also define MODULE_FILES to specify files.
[YOCTO #3803]
Signed-off-by: S
On Wed, 30 Jan 2013, Chris Larson wrote:
> On Wed, Jan 30, 2013 at 1:37 PM, Robert P. J. Day
> wrote:
> On Wed, 30 Jan 2013, Chris Larson wrote:
>
> > It's worth bringing up the SRCREV_POLICY variable, which lets you
> > control how bitbake handles caching of srcrevs. By defaul
On Wed, Jan 30, 2013 at 03:37:45PM -0500, Robert P. J. Day wrote:
> On Wed, 30 Jan 2013, Chris Larson wrote:
>
> > It's worth bringing up the SRCREV_POLICY variable, which lets you
> > control how bitbake handles caching of srcrevs. By default, it
> > figures it needs to get the mapping every time
On Wed, Jan 30, 2013 at 1:49 PM, Harvey Chapman wrote:
> On Jan 30, 2013, at 3:34 PM, Chris Larson wrote:
>
> On Wed, Jan 30, 2013 at 1:34 PM, Chris Larson wrote:
>
>>
>> It's worth bringing up the SRCREV_POLICY variable, which lets you control
>> how bitbake handles caching of srcrevs. By defau
On Wed, 30 Jan 2013, Harvey Chapman wrote:
> So, should BB_NO_NETWORK=1 automatically set BB_SRCREV_POLICY=cache
> because the former implies the latter?
how would that have any useful effect? by the time you set
BB_NO_NETWORK=1, you better have all those SRCREVs cached already.
rday
--
==
On Jan 30, 2013, at 3:34 PM, Chris Larson wrote:
> On Wed, Jan 30, 2013 at 1:34 PM, Chris Larson wrote:
>
> It's worth bringing up the SRCREV_POLICY variable, which lets you control how
> bitbake handles caching of srcrevs. By default, it figures it needs to get
> the mapping every time (valu
On Wed, Jan 30, 2013 at 1:37 PM, Robert P. J. Day wrote:
> On Wed, 30 Jan 2013, Chris Larson wrote:
>
> > It's worth bringing up the SRCREV_POLICY variable, which lets you
> > control how bitbake handles caching of srcrevs. By default, it
> > figures it needs to get the mapping every time (value =
On Wed, 30 Jan 2013, Chris Larson wrote:
> It's worth bringing up the SRCREV_POLICY variable, which lets you
> control how bitbake handles caching of srcrevs. By default, it
> figures it needs to get the mapping every time (value == clear, or
> unset), which can make sense in certain cases. But yo
On Wed, Jan 30, 2013 at 1:34 PM, Chris Larson wrote:
>
> On Wed, Jan 30, 2013 at 1:27 PM, Robert P. J. Day
> wrote:
>
>> On Tue, 29 Jan 2013, Martin Jansa wrote:
>>
>> ... snip ...
>>
>> > It would be better to change SRCREV to hash corresponding to that
>> > tag and move tag only to comment abo
On Wed, Jan 30, 2013 at 1:27 PM, Robert P. J. Day wrote:
> On Tue, 29 Jan 2013, Martin Jansa wrote:
>
> ... snip ...
>
> > It would be better to change SRCREV to hash corresponding to that
> > tag and move tag only to comment above SRCREV. Such patch could be
> > applied in upstream...
>
> which
On Tue, 29 Jan 2013, Martin Jansa wrote:
... snip ...
> It would be better to change SRCREV to hash corresponding to that
> tag and move tag only to comment above SRCREV. Such patch could be
> applied in upstream...
which brings up a larger issue ... what is the *preferred* way of
doing this i
How can I generate multiple systemd service packages for single recipe?
I'm building connman with VPN support and I want to have
connman-systemd and connman-vpn-systemd packages.
I'm using following syntax for connman recipe but no
"connman-vpn-systemd" is generated:
SYSTEMD_PACKAGES += "${PN}-sy
Looks ok to me.
On Wed, Jan 30, 2013 at 8:26 AM, Bogdan Marinescu
wrote:
> Before modifying RTLDLIST in ldd, make sure that it doesn't already
> contain the right path, thus avoiding duplicate entries in RTLDLIST.
>
> [YOCTO #2655]
>
> Signed-off-by: Bogdan Marinescu
> ---
> meta/recipes-core/e
On 01/30/2013 02:13 AM, Enrico Scholz wrote:
Saul Wold writes:
This change ensures that the ls /etc/rpm-postinsts runs in the target
at first boot time, rather than at the creation time of the script on
the host.
...
-for i in `ls /etc/rpm-postinsts/`; do
+for i in \`ls /etc/rpm-postinsts/\`;
On 30 January 2013 16:38, Ian Geiser wrote:
> No, I was just extending what was there so I have no real preference. I will
> need to check if it impacts non-x86 builds. I do not think it will be a
> problem, since most non-x86 systems have their own GL implementations. I
> think it will just
> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Wednesday, January 30, 2013 10:16 AM
> To: Ian Geiser
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] mesa-dri: add extra dri drivers
>
> On 30 January 2013 13:26, wrote:
> >
On 01/29/2013 08:43 PM, Saul Wold wrote:
On 01/29/2013 11:28 AM, Phil Staub wrote:
The io_syscallX wrappers in syscall-mips.h discard error return status
by overwriting the value returned in v0 from the system call with -1.
Modify this behavior by returning the negative of the return value on
e
Before modifying RTLDLIST in ldd, make sure that it doesn't already
contain the right path, thus avoiding duplicate entries in RTLDLIST.
[YOCTO #2655]
Signed-off-by: Bogdan Marinescu
---
meta/recipes-core/eglibc/eglibc_2.17.bb |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
d
On 29 January 2013 11:57, Otavio Salvador wrote:
> There're some processors which provide binary blobs for DRI and GPU
> support which need to be build in BSP; to avoid some dirt and ugly
> hacks in BSP we ought to be flexible.
>
> We splitted the glx and dri PACKAGECONFIG options and added a
> vi
Andrei,
There is almost ALWAYS something worth putting in the comment message.
In this case, please include your latest testing comment in your commit
message and resend with my Acked by.
On 01/28/2013 04:27 AM, Andrei Dinu wrote:
> Signed-off-by: Andrei Dinu
Acked-by: Darren Hart
Thanks,
Signed-off-by: Andrei Dinu
---
.../icu/{icu_50.1.1.bb => icu_50.1.2.bb} |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
rename meta/recipes-support/icu/{icu_50.1.1.bb => icu_50.1.2.bb} (55%)
diff --git a/meta/recipes-support/icu/icu_50.1.1.bb
b/meta/recipes-support/icu
On 30 January 2013 13:26, wrote:
> On x86 the ATI and NVidia drm drivers are valid to build.
> Currently there are _append_x86 and _append_x64 lines that
> explicitly add i915 and i965. For consistency I think that
> the ATI and NVidia drm driver should be added. In classic
> these were tunable
> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Wednesday, January 30, 2013 9:53 AM
> To: Ian Geiser
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 17/17] directfb: Explictly disable mesa
>
> On 30 January 2013 14:43, Ian Gei
On 30 January 2013 14:43, Ian Geiser wrote:
>> Without this, directfb might build with mesa enabled if present.
>>
> Is it possible to make this tunable? We use directfb with the mesa dri
> drivers for opengl. Maybe enable it only if the distro features contains
> opengl?
I was just saying to
On Wed, 2013-01-30 at 09:43 -0500, Ian Geiser wrote:
> > -Original Message-
> > From: openembedded-core-boun...@lists.openembedded.org
> > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> > Richard Purdie
> > Sent: Wednesday, January 30, 2013 9:01 AM
> > To: openembe
- removed the usage of the patches already contained in the new version
- adapted patch remove.ldconfig.call.patch so that it applies on new version
Signed-off-by: Andrei Dinu
---
.../acinclude.m4 |0
.../fallocate.patch|
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Richard Purdie
> Sent: Wednesday, January 30, 2013 9:01 AM
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 17/1
From: Cristian Iorga
Removed the following tools:
- all related to hdsp (required gtk+ and fltk-config)
- ld10k1, qlo10k1 (required QT)
- hdajackretask
Fixed the automake issue for cross-compilation
Signed-off-by: Cristian Iorga
Signed-off-by: Saul Wold
---
.../{alsa-tools-1.0.25 => alsa-too
Currently we do a signficant amount of tree traversal in many different places
which in inefficient. We can assume that the files don't change and cache the
file list which gives an efficiency improvement which this patch does using
a global variable.
Signed-off-by: Richard Purdie
---
meta/class
The following patch series contains a number of packaging improvements along
with a couple of bugfixes (one multilib, one directfb).
The following changes since commit cf05c4578c99c0cb885cf2706f7f2b39b100aeb8:
module.bbclass: Don't add pkg_postinst/pkg_prerm to all packages in recipe
(2013-01
The splitfile and splitfile2 function names are confusing and the comments
are also misleading, hard to understand or plain incorrect. This tries to
improve things.
Signed-off-by: Richard Purdie
---
meta/classes/package.bbclass | 21 +
1 file changed, 9 insertions(+), 12 de
Improve package_fixsymlinks so we don't handle RDEPENDS for every single package
in PACKAGES.
Signed-off-by: Richard Purdie
---
meta/classes/package.bbclass | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/meta/classes/package.bbclass b/meta/classes/pack
If we don't do this, stale files can build up, particularly with the PR
server.
Signed-off-by: Richard Purdie
---
meta/classes/package_deb.bbclass |1 +
meta/classes/package_ipk.bbclass |1 +
meta/classes/package_rpm.bbclass |1 +
3 files changed, 3 insertions(+)
diff --git a/meta/c
The symlink handling code doesn't need to being part of populate_packages
and is logically separate so split it out into a separate function,
package_fixsymlinks.
Signed-off-by: Richard Purdie
---
meta/classes/package.bbclass | 17 -
1 file changed, 12 insertions(+), 5 deletion
Currently the kernel module handling consists of several special cases
and has its own path walking. This refactors the code to handle them in
a more standardised way which is also a bit more efficient.
Signed-off-by: Richard Purdie
---
meta/classes/package.bbclass | 37 ---
There is no real point in adjusting overrides and creating a copy of the
datastore,
just to access a single variable. We can do this just as easily with a slightly
more complicated getVar call. This improves performance.
Signed-off-by: Richard Purdie
---
meta/classes/package.bbclass | 11 +---
We only use the PKG variable in emit_pkgdata so we might as well move the
fallback code there, allowing restructuring of other parts of the metadata.
Signed-off-by: Richard Purdie
---
meta/classes/package.bbclass | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/m
Move package_rename_hook call into PACKAGEFUNCS and also move
package_get_auto_pr
to a more appropriate execution point, grouping package metadata handling
functions together.
Signed-off-by: Richard Purdie
---
meta/classes/package.bbclass |6 +++---
1 file changed, 3 insertions(+), 3 deleti
There is no need to check FILES in each loop iteration, we can just check it
once
at the start when we read the variable.
Signed-off-by: Richard Purdie
---
meta/classes/package.bbclass |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/classes/package.bbclass b/me
We may as well expand the RDEPENDS when reading and writing as this function
does.
if we don't do this, we could accidentally duplicate data and it also turns out
to be much less efficient.
Signed-off-by: Richard Purdie
---
meta/classes/package.bbclass |2 +-
1 file changed, 1 insertion(+),
On a trace I was a bit puzzled why getVar was making 180 calls to len(d).
This is an expensive operation that should be very rarely called and
certainly not by getVar. In perl's do_package it was resulting in
~1.5 million function calls from those 180 cases.
Ultimately this typo was why. Lets fix
The same log message gets output multiple times in the log which look
confusing and is rather pointless. Move the log message to the correct
level.
Signed-off-by: Richard Purdie
---
meta/classes/sstate.bbclass |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/ss
The mkdir function iterates over strings with many different operations,
even if ultimately the target already exists. This adds a check to the start
of the function so we don't waste time when the target already exists.
Signed-off-by: Richard Purdie
---
meta/classes/package.bbclass |2 ++
1
Signed-off-by: Richard Purdie
---
meta/conf/multilib.conf |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/multilib.conf b/meta/conf/multilib.conf
index 97b53ec..f86cff0 100644
--- a/meta/conf/multilib.conf
+++ b/meta/conf/multilib.conf
@@ -1,5 +1,5 @@
-baselib =
Without this, directfb might build with mesa enabled if present.
Signed-off-by: Richard Purdie
---
meta/recipes-graphics/directfb/directfb.inc |1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-graphics/directfb/directfb.inc
b/meta/recipes-graphics/directfb/directfb.inc
index c
From: Ian Reinhart Geiser
On x86 the ATI and NVidia drm drivers are valid to build.
Currently there are _append_x86 and _append_x64 lines that
explicitly add i915 and i965. For consistency I think that
the ATI and NVidia drm driver should be added. In classic
these were tunable via the machine c
On Tue, 2013-01-29 at 04:41 -0500, Robert P. J. Day wrote:
> back in november, i whined thusly:
>
> http://lists.linuxtogo.org/pipermail/openembedded-core/2012-November/031997.html
>
> is this the *intended* behaviour? since it seems that if i do a
> "bitbake -c fetchall", i should expect that
- changed the archive extension because it changed
on the repository.
Signed-off-by: Andrei Dinu
---
.../{pax-utils_0.2.2.bb => pax-utils_0.6.bb} |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
rename meta/recipes-devtools/pax-utils/{pax-utils_0.2.2.bb =>
pax-utils_0.6.
Sending this as an RFC, since I believe that alot of this work can be
automated, or at least semi-automated. Perhaps I'm way out of line here,
please let me know if there are any existing tools in this area.
Ponder this:
1. Write you top level python recipe.
2. Instantiate tool X(?bitbake?), insta
Saul Wold writes:
> This change ensures that the ls /etc/rpm-postinsts runs in the target
> at first boot time, rather than at the creation time of the script on
> the host.
> ...
> -for i in `ls /etc/rpm-postinsts/`; do
> +for i in \`ls /etc/rpm-postinsts/\`; do
> i=/etc/rpm-postinsts/$i
>
Hi Darren,
I created an atom-pc hddimg and loaded it into qemu. The image booted
with no errors. So everything seems to work fine. Thanks for the help!
Andrei
On 01/29/2013 06:46 PM, Darren Hart wrote:
On 01/29/2013 01:49 AM, Andrei Dinu wrote:
Hello,
Hi Andrei,
No, i performed only mini
57 matches
Mail list logo
