On Wed, 13 Feb 2013 00:21:53 +
Richard Purdie wrote:
> +# DEFAULTTUNE can change TARGET_ARCH override so expand this now
> before update_data
> +newtune = e.data.getVar("DEFAULTTUNE_" + "virtclass-multilib-" +
> variant)
I was going to ask whether this wants a ", True", but it occurs
On Tue, Feb 12, 2013 at 2:53 PM, Richard Purdie
wrote:
> On Tue, 2013-02-12 at 16:03 -0600, Jason Wessel wrote:
>> On 02/12/2013 03:39 PM, Richard Purdie wrote:
>> > On Tue, 2013-02-12 at 13:36 -0600, Jason Wessel wrote:
>> >> If you never use sstate and always build everything from scratch you
>>
On 2/12/13 6:21 PM, Richard Purdie wrote:
Please add:
[ YOCTO #3874 ]
to the commit message. (The problem is complex enough, that the bugzilla entry
is helpful in understanding why this is needed.)
There were problems where a SRC_URI with:
SRC_URI_append_powerpc = " xxx"
SRC_URI_append_p
There were problems where a SRC_URI with:
SRC_URI_append_powerpc = " xxx"
SRC_URI_append_powerpc64 = " xxx2"
would end up with *both* xxx and xxx2 being added when using a multilib
which is clearly incorrect and undesirable.
The issue is that OVERRIDES has virtclass-multilib- added to it,
th
Double alignment is 8 bytes on x32 but it is defaulting to 4 currently.
This leads to various issues and fontconfig fails to build due to the
mismatch triggering assert failures.
Signed-off-by: Richard Purdie
diff --git a/meta/site/x32-linux b/meta/site/x32-linux
index 7ce6551..36ee68b 100644
--
On Wed, 2013-02-13 at 00:55 +0100, Andreas Müller wrote:
> On Tue, Feb 12, 2013 at 10:24 PM, Richard Purdie
> wrote:
> > On Tue, 2013-02-12 at 09:42 -0800, Khem Raj wrote:
> >> systemd always uses /lib and /usr/lib to store unit files
> >> so using libdir and base_libdir is incorrect. It will work
On Tue, Feb 12, 2013 at 10:24 PM, Richard Purdie
wrote:
> On Tue, 2013-02-12 at 09:42 -0800, Khem Raj wrote:
>> systemd always uses /lib and /usr/lib to store unit files
>> so using libdir and base_libdir is incorrect. It will work
>> where libdir is usr/lib and base_libdir is /lib but wont work
>
On Tue, 2013-02-12 at 16:03 -0600, Jason Wessel wrote:
> On 02/12/2013 03:39 PM, Richard Purdie wrote:
> > On Tue, 2013-02-12 at 13:36 -0600, Jason Wessel wrote:
> >> If you never use sstate and always build everything from scratch you
> >> will never see this problem. However, if you use sstate a
The pseudo 1.4.2 linkat() implementation had a broken edge case
in which you could end up with chroot paths being doubled when
using plain link() calls instead of linkat() calls.
Signed-off-by: Peter Seebach
---
.../pseudo/{pseudo_1.4.3.bb => pseudo_1.4.4.bb}|4 ++--
meta/recipes-devtool
So, about two days AFTER pseudo 1.4.3 goes in, I finally hit the fairly
obvious bug in the link/linkat() changes. Summary: In general, if parameter
names end in 'path' pseudo tries to do automatic path fixups for them.
This doesn't work well for the *at() functions, because they can need
magic done
On Tue, Feb 12, 2013 at 1:06 PM, Burton, Ross wrote:
>
> Yes, throwing an error/warning does make sense, as the alternative
> would be files mysteriously disappearing. Can you send a patch for
> that?
I have something for test.
___
Openembedded-core m
The DEBIAN_NAMES feature renames some of the libc packages to
"libc6*" names --but only some. A previous patch added the -dbg
package. However, this doesn't cover other packages (such as
the -doc package), and it didn't take multilibs into account.
Signed-off-by: Peter Seebach
---
meta/classes/l
DEBIAN_NAMES ought to work for multilibs, and it ought to handle all
the libc packages, not just the base, -dev, and -dbg packages.
I do have one concern about this: The last three lines of the function,
setting up PROVIDE for libc-dbg... I do not know whether we still need
or want those. The com
On 02/12/2013 03:39 PM, Richard Purdie wrote:
> On Tue, 2013-02-12 at 13:36 -0600, Jason Wessel wrote:
>> If you never use sstate and always build everything from scratch you
>> will never see this problem. However, if you use sstate and build
>> directories that last a long time eventually you ca
On 12 February 2013 21:53, Eric Bénard wrote:
> if you have a how-to to get Qt/E 4.x working with evdev, please send it
> before removing tslib so that we can test it on several boards which
> are actually running with Qt/E+tslib.
Totally, not regressing badly is a prerequisite.
Ross
__
Hi Ross,
Le Tue, 12 Feb 2013 21:36:16 +,
"Burton, Ross" a écrit :
> On 12 February 2013 21:22, Martin Jansa wrote:
> > Yes, xf86-input-tslib works
> > http://git.openembedded.org/meta-openembedded/commit/?id=506d5f781f5ee93e3c9b8ca51a7fb65f40d4a8b8
>
> [ surprised face ]
>
> You totally s
link() calls inside a chroot tend to fail. Conveniently, nearly
everyone uses linkat() so this doesn't affect most builds, but we found
a test case where it was really easy to trigger.
Symptom: RPM installs saying somehing like:
pseudo: Fatal: Tried to stat
'/home/seebs/pseudo/r/home/seebs/pseudo
On 2/12/13 3:39 PM, Richard Purdie wrote:
On Tue, 2013-02-12 at 13:36 -0600, Jason Wessel wrote:
If you never use sstate and always build everything from scratch you
will never see this problem. However, if you use sstate and build
directories that last a long time eventually you can end up wit
On Tue, Feb 12, 2013 at 7:36 PM, Burton, Ross wrote:
> On 12 February 2013 21:22, Martin Jansa wrote:
>> Yes, xf86-input-tslib works
>> http://git.openembedded.org/meta-openembedded/commit/?id=506d5f781f5ee93e3c9b8ca51a7fb65f40d4a8b8
>
> [ surprised face ]
>
> You totally should push those tarbal
On Tue, 2013-02-12 at 13:36 -0600, Jason Wessel wrote:
> If you never use sstate and always build everything from scratch you
> will never see this problem. However, if you use sstate and build
> directories that last a long time eventually you can end up with the
> scenario where libtool gets a h
On 12 February 2013 21:22, Martin Jansa wrote:
> Yes, xf86-input-tslib works
> http://git.openembedded.org/meta-openembedded/commit/?id=506d5f781f5ee93e3c9b8ca51a7fb65f40d4a8b8
[ surprised face ]
You totally should push those tarballs to a git repo on fd.o,
pengutronix has clearly abandoned it.
On Tue, 2013-02-12 at 09:42 -0800, Khem Raj wrote:
> systemd always uses /lib and /usr/lib to store unit files
> so using libdir and base_libdir is incorrect. It will work
> where libdir is usr/lib and base_libdir is /lib but wont work
> when say its /lib64
>
> Additionally introduce the install a
On Tue, Feb 12, 2013 at 08:51:25PM +, Burton, Ross wrote:
> On 12 February 2013 16:43, Otavio Salvador wrote:
> >> Qt Embedded as we build it is currently configured to use tslib, as is
> >> SDL. If the alternative (evdev?) is supported they could presumably be
> >> switched over though. I don
On 12 February 2013 17:35, Khem Raj wrote:
> Thinking about it from different perspective, I agree that probably
> adding an extra package is not right and having unitfiles as part of
> package proper is fine. but we should definitely have a check where if
> SYSTEMD_PACKAGES dont exist in PACKAGES
On 12 February 2013 17:42, Khem Raj wrote:
> systemd always uses /lib and /usr/lib to store unit files
> so using libdir and base_libdir is incorrect. It will work
> where libdir is usr/lib and base_libdir is /lib but wont work
> when say its /lib64
That's interesting, wasn't aware of that. Why
On 12 February 2013 16:43, Otavio Salvador wrote:
>> Qt Embedded as we build it is currently configured to use tslib, as is
>> SDL. If the alternative (evdev?) is supported they could presumably be
>> switched over though. I don't know how practical that is however.
>
> Yes Qt Embedded uses it; no
W dniu 12.02.2013 20:51, Martin Jansa pisze:
> xserver-common is similar to formfactor, a bit more flexible but a
> lot worse to maintain for new MACHINES
IIRC xserver-common allows to set all MACHINE related variables in
/etc/default/something file. I added that years ago when merged
xserver-com
This seems to be an incomplete patch and will not patch anything in
OE-Core directly, maybe you really mean to patch the Squashfs-tools recipe.
Sau!
On 02/12/2013 08:31 AM, Pete Kolcsar wrote:
--- a/squashfs_fs.h 2011-02-11 17:49:24.0 +0200
+++ b/squashfs_fs.h 2013-02-12 15:
--- a/squashfs_fs.h 2011-02-11 17:49:24.0 +0200
+++ b/squashfs_fs.h 2013-02-12 15:53:04.360256607 +0200
@@ -36,9 +36,9 @@
/* default size of data blocks */
#define SQUASHFS_FILE_SIZE 131072
-#define SQUASHFS_FILE_LOG 17
#define SQUASHFS_FILE_MAX_SIZE
On 2/12/13 1:32 PM, Chris Larson wrote:
On Tue, Feb 12, 2013 at 12:19 PM, Martin Jansa mailto:martin.ja...@gmail.com>> wrote:
> * meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.4.bbappend
> * meta-oe/recipes-qt/qt4/qt4-embedded_4.8.4.bbappend
> These two add MySQL and PostgreSQL support
On Tue, Feb 12, 2013 at 07:32:33PM +, Paul Eggleton wrote:
> On Tuesday 12 February 2013 20:19:02 Martin Jansa wrote:
> > On Mon, Feb 11, 2013 at 05:09:01PM +, Paul Eggleton wrote:
> > > * tslib: OE-Core has the 1.0 release version, meta-oe has a git recipe
> > > that is ahead of 1.0; the O
If you never use sstate and always build everything from scratch you
will never see this problem. However, if you use sstate and build
directories that last a long time eventually you can end up with the
scenario where libtool gets a hard coded path in it for sed, and sed
may not exist. The reaso
On Tue, Feb 12, 2013 at 12:19 PM, Martin Jansa wrote:
> > * meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.4.bbappend
> > * meta-oe/recipes-qt/qt4/qt4-embedded_4.8.4.bbappend
> > These two add MySQL and PostgreSQL support to Qt and Qt/Embedded. I see
> this
> > as a distro policy decision; these should m
On Tuesday 12 February 2013 20:19:02 Martin Jansa wrote:
> On Mon, Feb 11, 2013 at 05:09:01PM +, Paul Eggleton wrote:
> > * tslib: OE-Core has the 1.0 release version, meta-oe has a git recipe
> > that is ahead of 1.0; the OE-Core version has two patches not in the
> > meta-oe version but that
On Tue, Feb 12, 2013 at 5:19 PM, Martin Jansa wrote:
> On Mon, Feb 11, 2013 at 05:09:01PM +, Paul Eggleton wrote:
>> Hi all,
>>
>> I'd like to make an attempt to remove all appends and overlayed recipes from
>> the meta-oe layer. As I've said previously, I don't believe meta-oe - as a
>> colle
On Mon, Feb 11, 2013 at 05:09:01PM +, Paul Eggleton wrote:
> Hi all,
>
> I'd like to make an attempt to remove all appends and overlayed recipes from
> the meta-oe layer. As I've said previously, I don't believe meta-oe - as a
> collection of very useful additional recipes that many wish to
systemd always uses /lib and /usr/lib to store unit files
so using libdir and base_libdir is incorrect. It will work
where libdir is usr/lib and base_libdir is /lib but wont work
when say its /lib64
Additionally introduce the install append from meta-oe
lot of recipe appends in meta-systemd depend
On Tue, Feb 12, 2013 at 1:08 AM, Ross Burton wrote:
> On Tuesday, 12 February 2013 at 08:22, Khem Raj wrote:
>> If someone defines SYSTEMD_PACKAGES to be different
>> then ${PN} then we need to make sure that they get
>> added to PACKAGES variable
>
> The only case it won't already be in PACKAGES
Signed-off-by: Ross Burton
---
meta/recipes-gnome/gtkhtml2/gtkhtml2_svn.bb | 38 ---
1 file changed, 38 deletions(-)
delete mode 100644 meta/recipes-gnome/gtkhtml2/gtkhtml2_svn.bb
diff --git a/meta/recipes-gnome/gtkhtml2/gtkhtml2_svn.bb
b/meta/recipes-gnome/gtkhtml2/g
The gtkhtml2 version of Web is even older than the webkitgtk port, remove it.
Signed-off-by: Ross Burton
---
meta/recipes-sato/web/web/fix_makefile.patch| 20 -
meta/recipes-sato/web/web/owl-window-menu.patch | 98 ---
meta/recipes-sato/web/web_git.bb
On Tue, Feb 12, 2013 at 11:19 AM, Phil Blundell wrote:
> On Tue, 2013-02-12 at 17:14 +, McClintock Matthew-B29882 wrote:
>> We really need COMPATIBLE_ARCH here...
>
> Why can't you use COMPATIBLE_HOST?
Yes, that's what it's called ;)
-M
___
Openem
On Tue, 2013-02-12 at 17:14 +, McClintock Matthew-B29882 wrote:
> We really need COMPATIBLE_ARCH here...
Why can't you use COMPATIBLE_HOST?
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/
On Thu, Feb 7, 2013 at 4:43 PM, Saul Wold wrote:
> On 02/07/2013 06:33 AM, Martin Jansa wrote:
>>
>> Signed-off-by: Martin Jansa
>> ---
>> meta/recipes-kernel/libpfm/libpfm4_4.3.0.bb | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/meta/recipes-kernel/libpfm/libpfm4_4.3.0.bb
>> b
W dniu 12.02.2013 17:30, Richard Purdie pisze:
> On Tue, 2013-02-12 at 15:25 +0100, Marcin Juszkiewicz wrote:
>> | Collected errors:
>> | * satisfy_dependencies_for: Cannot satisfy the following dependencies for
>> packagegroup-core-standalone-hhvm-sdk-target:
>> | *eglibc-thread-db *
>>
>>
On Tuesday 12 February 2013 14:44:58 Otavio Salvador wrote:
> On Tue, Feb 12, 2013 at 1:50 PM, Ross Burton wrote:
> > On Tuesday, 12 February 2013 at 10:24, Burton, Ross wrote:
> >> > * meta-oe/recipes-extended/polkit/polkit_0.104.bbappend
> >> > Another bbappend apparently for systemd support. Ag
On Tue, Feb 12, 2013 at 10:32 AM, Richard Purdie
wrote:
> On Tue, 2013-02-12 at 09:06 -0500, Bruce Ashfield wrote:
>> On Tue, Feb 12, 2013 at 8:21 AM, Richard Purdie
>> wrote:
>> > On Tue, 2013-02-05 at 11:29 -0500, Bruce Ashfield wrote:
>> >> On Tue, Feb 5, 2013 at 1:42 AM, ChenQi wrote:
>> >>
* Ross Burton [130212 16:07]:
> On Tuesday, 12 February 2013 at 15:01, Anders Darander wrote:
> > > Or is there another use-case I'm missing?
> > Well, there is always the possibillity that the install is split into
> > multiple packages, with binaries also in some sub-packages. I can't
> > reca
On Tue, Feb 12, 2013 at 1:50 PM, Ross Burton wrote:
> On Tuesday, 12 February 2013 at 10:24, Burton, Ross wrote:
>> > * meta-oe/recipes-extended/polkit/polkit_0.104.bbappend
>> > Another bbappend apparently for systemd support. Again, this should have
>> > been
>> > moved to meta-systemd; do we n
On Tue, Feb 12, 2013 at 8:38 AM, Paul Eggleton
wrote:
> On Tuesday 12 February 2013 10:24:50 Burton, Ross wrote:
>> > * tslib: OE-Core has the 1.0 release version, meta-oe has a git recipe
>> > that is ahead of 1.0; the OE-Core version has two patches not in the
>> > meta-oe version but that both
On Tue, 2013-02-12 at 15:25 +0100, Marcin Juszkiewicz wrote:
> | Collected errors:
> | * satisfy_dependencies_for: Cannot satisfy the following dependencies for
> packagegroup-core-standalone-hhvm-sdk-target:
> | *eglibc-thread-db *
>
> eglibc-thread-db is listed in LIBC_DEPENDENCIES and us
This is needed if the GTKIMMODULES_PACKAGES is changed later, in
do_populate_packages for example. This way, we don't have to add another
dumb asignment in the recipe inheriting this.
[YOCTO #3853]
Signed-off-by: Laurentiu Palcu
---
meta/classes/gtk-immodules-cache.bbclass |2 ++
1 file cha
In order to have the proper postinst/postrm scriptlets generated for
gtk+ immodules packages, use the already existing class.
[YOCTO #3853]
Signed-off-by: Laurentiu Palcu
---
meta/recipes-gnome/gtk+/gtk+.inc|8 +---
meta/recipes-gnome/gtk+/gtk+3_3.4.4.bb | 12 ++--
me
[YOCTO #3582]
Signed-off-by: Laurentiu Palcu
---
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.26.5.bb | 48 ++--
1 file changed, 3 insertions(+), 45 deletions(-)
diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.26.5.bb
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.26.5.bb
Also, fix the GDK_PIXBUF_QUERYLOADERS path.
[YOCTO #3582]
Signed-off-by: Laurentiu Palcu
---
meta/recipes-gnome/librsvg/librsvg_2.32.1.bb | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/meta/recipes-gnome/librsvg/librsvg_2.32.1.bb
b/meta/recipes-gno
gsettings.bbclass offers just that.
[YOCTO #3854]
Signed-off-by: Laurentiu Palcu
---
meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb
b/meta/recipes-gnome/gnome/
All packages exporting pixbuf loaders should inherit this class in order
to generate the correct postinst/postrm scriptlets.
[YOCTO #3852]
Signed-off-by: Laurentiu Palcu
---
meta/classes/pixbufcache.bbclass | 50 ++
1 file changed, 50 insertions(+)
create
Since the intercept fall-back procedure will change the package
installation status, do the checking after ROOTFS_POSTPROCESS_COMMAND
ends.
Signed-off-by: Laurentiu Palcu
---
meta/classes/rootfs_deb.bbclass | 14 +++---
meta/classes/rootfs_ipk.bbclass | 13 ++---
meta/classes
"Link" the package to the postinstall hook by running the
postinst_intercept script.
Signed-off-by: Laurentiu Palcu
---
meta/classes/fontcache.bbclass | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/meta/classes/fontcache.bbclass b/meta/classes/fontcac
Since the hook has been made a standalone script, use postinst_intercept
script in order to "link" the package to the hook.
Signed-off-by: Laurentiu Palcu
---
meta/classes/gtk-icon-cache.bbclass | 39 ---
1 file changed, 9 insertions(+), 30 deletions(-)
diff --
Hi all,
This patchset adds the fall-back solution to intercept hooks. That is, if
intercept hooks fail than the postinstalls will run on target, at first boot.
This way we will avoid unwanted situations when the intercept hooks fail and
the build cannot complete. The previous solution had some iss
The scripts/postinst-intercepts will contain all postinstall hooks that
we need to run after all packages have been installed.
If one wants to install such a postinst hook, all it needs to do is put
the hook in this directory and, from the package postinstall scriptlet,
call:
postinst_inte
If an intercept script fails, it would be helpful to fall-back to
running the postinstall on target's first boot. In order to achieve
that, the postinstalls that install a host intercept hook will have to
return 1, so that the postinstall is marked as unpacked only. If the
intercept hook fails, the
On Tuesday, 12 February 2013 at 10:24, Burton, Ross wrote:
> > * meta-oe/recipes-extended/polkit/polkit_0.104.bbappend
> > Another bbappend apparently for systemd support. Again, this should have
> > been
> > moved to meta-systemd; do we now need to merge it into OE-Core?
>
>
> Yes, half of it h
On Tue, 2013-02-12 at 09:06 -0500, Bruce Ashfield wrote:
> On Tue, Feb 12, 2013 at 8:21 AM, Richard Purdie
> wrote:
> > On Tue, 2013-02-05 at 11:29 -0500, Bruce Ashfield wrote:
> >> On Tue, Feb 5, 2013 at 1:42 AM, ChenQi wrote:
> >> On 02/02/2013 03:08 AM, Bruce Ashfield wrote:
> >>
On Tuesday, 12 February 2013 at 15:01, Anders Darander wrote:
> > Or is there another use-case I'm missing?
>
> Well, there is always the possibillity that the install is split into
> multiple packages, with binaries also in some sub-packages. I can't
> recall right now if we have such packages, w
* Ross Burton [130212 10:09]:
> On Tuesday, 12 February 2013 at 08:22, Khem Raj wrote:
> > If someone defines SYSTEMD_PACKAGES to be different
> > then ${PN} then we need to make sure that they get
> > added to PACKAGES variable
> The only case it won't already be in PACKAGES is if you're creati
| Collected errors:
| * satisfy_dependencies_for: Cannot satisfy the following dependencies for
packagegroup-core-standalone-hhvm-sdk-target:
| *eglibc-thread-db *
eglibc-thread-db is listed in LIBC_DEPENDENCIES and used by SDK. Package
ends as "libthread-db1" and provides glibc-thread-db.
On Tue, Feb 12, 2013 at 8:21 AM, Richard Purdie
wrote:
> On Tue, 2013-02-05 at 11:29 -0500, Bruce Ashfield wrote:
>> On Tue, Feb 5, 2013 at 1:42 AM, ChenQi wrote:
>> On 02/02/2013 03:08 AM, Bruce Ashfield wrote:
>> > On Fri, Feb 1, 2013 at 1:56 PM, Saul Wold
>> > wrote:
>
On Tuesday 12 February 2013 13:10:05 Richard Purdie wrote:
> On Tue, 2013-02-12 at 09:24 +, Paul Eggleton wrote:
> > On Monday 11 February 2013 22:35:47 Richard Purdie wrote:
> > > On Mon, 2013-02-11 at 17:09 +, Paul Eggleton wrote:
> > > > *
> > > > meta-oe/recipes-qt/packagegroups/package
On Tue, 2013-02-05 at 11:29 -0500, Bruce Ashfield wrote:
> On Tue, Feb 5, 2013 at 1:42 AM, ChenQi wrote:
> On 02/02/2013 03:08 AM, Bruce Ashfield wrote:
> > On Fri, Feb 1, 2013 at 1:56 PM, Saul Wold
> > wrote:
> > On 02/01/2013 06:18 AM, Bruce Ashfield wrot
On Tue, 2013-02-12 at 09:24 +, Paul Eggleton wrote:
> On Monday 11 February 2013 22:35:47 Richard Purdie wrote:
> > On Mon, 2013-02-11 at 17:09 +, Paul Eggleton wrote:
> > > *
> > > meta-oe/recipes-qt/packagegroups/packagegroup-qte-toolchain-target.bbappe
> > > nd This is adding qwt to the
New in v3 are all the fixes recommended by Laurentiu Palcu
* Fix sudo exec problem
* Preserve padding in the .interp section
---
Now that I have had to debug the SDK relocator on multiple occasions
I figure it might be nice to get the patches upstreamed. This last
time through fixing the pyt
After having to debug the SDK installer a few times in
addition to the relocation code the following patch was created
to improve the capabilities around debugging the SDK installer.
1) Add a verbose mode -D which set a set -x to see what
the SDK installer is doing.
2) Add a mode -S to save th
Avoid the chicken / egg problem of an SDK that provides a working
python but requires that version of python to extract itself. The
RHEL 5.x systems and some other enterprise Linux systems ship with
python 2.4.x as the default python. We need to at least be able to
extract work executables even i
There are two cases of corruption that the relocate_sdk.py was not correctly
dealing with.
1) SDK Extras should be left alone
Extra external binaries included in an SDK that were linked against the
host's version of /usr/lib/ld-so.so should not get a relocation applied.
In the case that w
On 02/12/2013 04:24 AM, Laurentiu Palcu wrote:
>
> On 02/12/2013 12:19 PM, Jason Wessel wrote:
>> For what ever reason I never received the original mails, else I absolutely
>> would have responded. This is the first response I have received from the
>> oe-core list in months in fact.
> I believ
On Tuesday 12 February 2013 10:24:50 Burton, Ross wrote:
> > * tslib: OE-Core has the 1.0 release version, meta-oe has a git recipe
> > that is ahead of 1.0; the OE-Core version has two patches not in the
> > meta-oe version but that both have been merged upstream in the git
> > revision being used
On Tue, Feb 12, 2013 at 12:20 PM, Michael Halstead wrote:
>
> On 02/11/2013 06:57 AM, Andrei Gherzan wrote:
>
>
>
>
> On Mon, Feb 11, 2013 at 4:43 PM, Paul Eggleton <
> paul.eggle...@linux.intel.com> wrote:
>
>> On Monday 11 February 2013 16:01:10 Andrei Gherzan wrote:
>> > On Mon, Feb 11, 2013
On Tuesday 12 February 2013 02:20:29 Michael Halstead wrote:
> On 02/11/2013 06:57 AM, Andrei Gherzan wrote:
> > On Mon, Feb 11, 2013 at 4:43 PM, Paul Eggleton
> > mailto:paul.eggle...@linux.intel.com>>
> >
> > wrote:
> > On Monday 11 February 2013 16:01:10 Andrei Gherzan wrote:
> > > On M
On 11 February 2013 17:09, Paul Eggleton wrote:
> I'd like to make an attempt to remove all appends and overlayed recipes from
> the meta-oe layer. As I've said previously, I don't believe meta-oe - as a
> collection of very useful additional recipes that many wish to be able to use
> on top of th
On 02/12/2013 12:19 PM, Jason Wessel wrote:
> For what ever reason I never received the original mails, else I absolutely
> would have responded. This is the first response I have received from the
> oe-core list in months in fact.
I believe you... It happened to me too not to receive replies
On 02/11/2013 06:57 AM, Andrei Gherzan wrote:
>
>
>
> On Mon, Feb 11, 2013 at 4:43 PM, Paul Eggleton
> mailto:paul.eggle...@linux.intel.com>>
> wrote:
>
> On Monday 11 February 2013 16:01:10 Andrei Gherzan wrote:
> > On Mon, Feb 11, 2013 at 3:10 PM, Sarbu, Florin-Ionut (Florin) <
> > f
On 02/12/2013 02:09 AM, Laurentiu Palcu wrote:
>
>
> On 02/12/2013 01:22 AM, Jason Wessel wrote:
>> Now that I have had to debug the SDK relocator on multiple occasions
>> I figure it might be nice to get the patches upstreamed.
> But, before that, did you see my comments on the previous patchset?
On Monday 11 February 2013 22:35:47 Richard Purdie wrote:
> On Mon, 2013-02-11 at 17:09 +, Paul Eggleton wrote:
> > *
> > meta-oe/recipes-qt/packagegroups/packagegroup-qte-toolchain-target.bbappe
> > nd This is adding qwt to the qte toolchain. As far as I am concerned this
> > is a distro polic
On Mon, Feb 11, 2013 at 09:46:31PM -0800, Saul Wold wrote:
>On 02/05/2013 07:55 AM, Bernhard Reutner-Fischer wrote:
>>ifupdown stores its ifstate into CONFIG_IFIPDOWN_IFSTATE_PATH.
>>Fixes:
>>ifup: can't open '/var/run/ifstate': No such file or directory
>>
>>Signed-off-by: Bernhard Reutner-Fischer
On Tuesday, 12 February 2013 at 08:22, Khem Raj wrote:
> If someone defines SYSTEMD_PACKAGES to be different
> then ${PN} then we need to make sure that they get
> added to PACKAGES variable
The only case it won't already be in PACKAGES is if you're creating a package
which contains just the serv
* Otavio Salvador [130211 18:50]:
> On Mon, Feb 11, 2013 at 3:09 PM, Paul Eggleton
> wrote:
> ...
> > * meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.4.bbappend
> > * meta-oe/recipes-qt/qt4/qt4-embedded_4.8.4.bbappend
> > These two add MySQL and PostgreSQL support to Qt and Qt/Embedded. I see this
> >
If someone defines SYSTEMD_PACKAGES to be different
then ${PN} then we need to make sure that they get
added to PACKAGES variable
Signed-off-by: Khem Raj
---
meta/classes/systemd.bbclass |7 +++
1 file changed, 7 insertions(+)
diff --git a/meta/classes/systemd.bbclass b/meta/classes/sys
On 02/11/2013 07:46 PM, Saul Wold wrote:
qhat kind of testing have you done with this update, since qemu is
core to our BSPs I want to make sure we have tested it well.
I have tested core-image-sato on all qemu archs.
Cheers,
Constantin
Thanks
Sau!
On 02/11/2013 05:01 AM, Constantin M
On 02/12/2013 08:04 AM, Saul Wold wrote:
> Laurentiu Palcu (6):
> Add pixbufcache class
> gdk-pixbuf: use the new pixbufcache class
> librsvg: use the new pixbufcache class
> gtk-immodules-cache: add weak asignment for GTKIMMODULES_PACKAGES
> gtk+: use gtk-immodules-cache class
> gnom
On 02/12/2013 01:22 AM, Jason Wessel wrote:
> Now that I have had to debug the SDK relocator on multiple occasions
> I figure it might be nice to get the patches upstreamed.
But, before that, did you see my comments on the previous patchset? It
looks like they went unnoticed as they were not addr
91 matches
Mail list logo
