On 07/08/2013 12:35 PM, Saul Wold wrote:
> On 07/08/2013 12:10 AM, jackie.hu...@windriver.com wrote:
>> From: Jackie Huang
>>
>> udev requires blkid, but this wasn't explicit. Note that the
>> dependency is on util-linux specifically, the one from e2fsprogs
>> won't work.
>>
> Doesn't udev use an
On 12/05/2012 09:52 PM, Andy Ross wrote:
On 12/05/2012 09:00 PM, Saul Wold wrote:
This patch is still having problems, see the Autobuilder recently build (link
below). This is on MUT with the updated binutils, I am not sure if that is
part of the problem or not, but binutils was working
On 12/05/2012 09:00 PM, Saul Wold wrote:
This patch is still having problems, see the Autobuilder recently build (link
below). This is on MUT with the updated binutils, I am not sure if that is
part of the problem or not, but binutils was working before.
Ah, fun fun. It's not binutils. Som
On 12/03/2012 10:47 AM, Saul Wold wrote:
I think this needs to be rebased since some other patches have been applied,
please verify and rebase against master.
It applies cleanly for me on top of what seems to be the current oe-core HEAD:
commit 24b954253dd1aa626835352c4dc8d085a19aae35
Author:
xed:
From 9796edb4e5a7a9a7c2d6d51fc68ea1ffa2b4d9ea Mon Sep 17 00:00:00 2001
From: Andy Ross
Date: Thu, 29 Nov 2012 11:08:47 -0800
Subject: [PATCH] base/license.bbclass: handle multiple INCOMPATIBLE_LICENSEs
Allow INCOMPATIBLE_LICENSE to be a whitespace-separated list of
incompatible license strings and/or glob patte
On 11/28/2012 03:14 PM, Flanagan, Elizabeth wrote:
This patch needs a rebase and a minor bit of whitespace work. I've
done some work to make it apply to the current master head and tested
it out and it does improve the utility of INCOMPATIBLE_LICENSE quite a
bit.
Hm... AFAICT the content of the
On 11/01/2012 11:02 AM, Andy Ross wrote:
We hit a problem trying to exclude L/GPLv3 recipes where
INCOMPATIBLE_LICENSE could only match exactly one license. The older
wildcard syntax had been broken by a more recent SPDX change
(specifying a string without a SPDXLICENSEMAP entry could crash
cause of a bug in return_spdx()
which would die with a runtime error when there was no SPDXLICENSEMAP
entry for the string.
Signed-off-by: Andy Ross
---
meta/classes/base.bbclass| 67 ++
meta/classes/license.bb
We hit a problem trying to exclude L/GPLv3 recipes where
INCOMPATIBLE_LICENSE could only match exactly one license. The older
wildcard syntax had been broken by a more recent SPDX change
(specifying a string without a SPDXLICENSEMAP entry could crash), so
"*GPLv3" wouldn't work.
This fixes that,
o be wrong/stale. AFAICT update-rc.d and
update-alternatives work fine with each other, though there is an
ordering constraint (alternatives must be specified last, so it
"wraps" update-rc.d). This version builds and works both with and
without busybox.
Signed-off-by: Andy Ross
---
m
Allow recipes that require busybox.inc to specificy custom defconfig
files and binary names such that multiple busybox configurations may
coexist.
Signed-off-by: Andy Ross
---
meta/recipes-core/busybox/busybox.inc | 92 +++--
meta/recipes-core/busybox
e needless busybox applets.
Signed-off-by: Andy Ross
---
.../busybox/busybox-oe-min-1.20.2/defconfig-oe-min | 992 +
meta/recipes-core/busybox/busybox-oe-min_1.20.2.bb | 35 +
2 files changed, 1027 insertions(+)
create mode 100644
meta/recipes-core/busybox/busybox-oe-min-1.20.2
We've been attempting to build an image that is busybox-free.
Unfortunately there are a handful of busybox applets which are used in
existing functionality (mostly various initscripts) and for which
oe-core has no packaged replacements:
+ /usr/bin/run-parts - part of upstream debianutils, unpackag
On 09/18/2012 03:25 PM, Saul Wold wrote:
How much bigger does this make the busybox image?
These binaries are manually stripped and not prelinked, but probably
close enough:
-rwxr-xr-x. 1 andy andy 557312 Sep 18 15:30 busybox-r0
-rwxr-xr-x. 1 andy andy 561696 Sep 18 15:30 busybox-r1
So 4k or
uot;/dev/root" instead of the proper $DEVNAME string exposed by udev.
So we must also test the root filesystem device number vs. the
$MAJOR/$MINOR udev tells us.
Signed-off-by: Andy Ross
---
meta/recipes-core/udev/udev-extraconf/mount.sh | 8 ++--
meta/recipes-core/udev/udev-extraconf_1.
When you boot an image with a kernel-mounted root filesystem
(e.g. "root=/dev/sda1" or the like), the root filesystem also appears
as a read-write filesystem under /media. The fix has two parts:
2. Modify the mount.sh hook to test the root filesystem device number
instead of the name (which won't
: Andy Ross
---
meta/recipes-core/busybox/busybox-1.20.2/defconfig | 4 ++--
.../busybox/busybox-1.20.2/stat-usr-bin.patch | 21 +
meta/recipes-core/busybox/busybox_1.20.2.bb | 5 +++--
3 files changed, 26 insertions(+), 4 deletions(-)
create mode 100644 meta
On 08/24/2012 09:19 AM, Richard Purdie wrote:
I'd love to have a better fix for this. I suspect its taking the path
from some "gcc -print-" call which returns/usr/lib/../lib on x86_64
so we could try and normalise it at source...
Yeah, but that sounds like whack-a-mole to me. It's just too
On 08/24/2012 07:12 AM, Richard Purdie wrote:
This avoids problems with libstdc++ having bad rpaths (/usr/lib/../.lib)
in its .la file. See the patch for more information.
Heh, I was just sitting down having discovered the same thing. Isn't
the root cause at least partially that gcc is using a
point to host directories.
[YOCTO #2965]
Signed-off-by: Andy Ross
---
meta/recipes-devtools/binutils/binutils-2.22.inc | 3 +-
.../binutils/binutils/rpath-sysroot.patch | 38 ++
2 files changed, 40 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes
Current RPATH work:
Patch 1 just updates the libtool work to use the built-in
normalization function instead of sed, as requested.
Patch 2 is to binutils ld, to fix the underlying host pollution issue:
the -rpath argument was not sysroot aware, so setting
"/usr/lib/../lib" as an RPATH would add t
Use the built-in normalization function instead of the sed hack.
Signed-off-by: Andy Ross
---
meta/recipes-devtools/libtool/libtool-2.4.2.inc| 2 +-
.../libtool/libtool/norm-rpath.patch | 22 --
2 files changed, 9 insertions(+), 15 deletions(-)
diff --git
In toolchain edge cases it's possible for the RPATH of a library to be
set to something like "/usr/lib/../lib". This should be detected as
"/usr/lib" and generate a warning.
Signed-off-by: Andy Ross
---
meta/classes/insane.bbclass | 5 -
1 file changed, 4 insertion
On 08/19/2012 03:06 AM, Richard Purdie wrote:
On Fri, 2012-08-17 at 08:53 -0700, Andy Ross wrote:
++libdir_norm=`echo $libdir \
++ | sed 's/\/\+\.\(\/\+\|$\)/\//g' \
++ | sed 's/[^\/]\+\/\+\.\.\(\/\+\|$\)//g' \
++
Libtool may be passed link paths of the form "/usr/lib/../lib", which fool
its detection code into thinking it should be included as an RPATH in
the generated binary. Normalize before comparision.
Signed-off-by: Andy Ross
---
meta/recipes-devtools/libtool/libtool-2.4.2.i
In toolchain edge cases it's possible for the RPATH of a library to be
set to something like "/usr/lib/../lib". This should be detected as
"/usr/lib" and generate a warning.
Signed-off-by: Andy Ross
---
meta/classes/insane.bbclass | 6 +-
1 file changed, 5
Results from chasing the RPATH pollution I was seeing:
I don't have a fix for the underlying linker issue, but that is
captured here:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2965
Patch 1 is the warning fix from earlier, which is still a fix to the
existing logic and should be applied
On 08/17/2012 03:28 AM, Richard Purdie wrote:
I suspect you need to look somewhere around:
http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-devtools/libtool/libtool/fix-rpath.patch
Indeed. Found that yesterday and am currently testing a fix.
Should be inbound within the hour.
Andy
On 08/16/2012 01:39 AM, Phil Blundell wrote:
If these RPATHs are causing host pollution then that sounds like there
is another bug elsewhere. They ought to be resolved relative to the
sysroot during link edit.
Indeed, this is turning out to be a deeper issue than I wanted it to
be. What seems
In toolchain edge cases it's possible for the RPATH of a library to be
set to something like "/usr/lib/../lib". This should be detected as
"/usr/lib" and generate a warning. Also clarify the warning text to
indicate potential link-time pollution from the host libraries.
Chris Larson wrote:
> Please just use os.path.normpath() rather than reinventing the wheel here.
Learn something new every day. Fixed.
Andy
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin
We hit some oddball cases where libraries were being built with RPATHs
referencing host directores and causing version skew in builds. There
is a warning case to detect that already, but it was being fooled by
".." terms in the path strings. This just adds a normalize step to
the path comparison
In toolchain edge cases it's possible for the RPATH of a library to be
set to something like "/usr/lib/../lib". This should be detected as
"/usr/lib" and generate a warning. Also clarify the warning text to
indicate potential link-time pollution from the host libraries.
On 08/15/2012 12:38 AM, Koen Kooi wrote:
> MIssing PR bump
Oops, fixed.
Andy
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
The task-core-lsb-runtime-add subpackage includes eglibc-pic as an
RDEPEND. That's incorrect, eglibc-pic is nothing but 22MB of static
libraries and should never appear as a runtime dependency.
Signed-off-by: Andy Ross
---
meta/recipes-extended/tasks/task-core-lsb.bb | 3 +--
1 file chang
On 08/15/2012 06:51 AM, Richard Purdie wrote:
Are files in that package required in order to pass LSB tests?
I'm fine with removing it if it isn't required but I would like that
confirmation before we merge this.
I can't speak to the test suites, but these files are eglibc-specific, so
it's ha
The task-core-lsb-runtime-add subpackage includes eglibc-pic as an
RDEPEND. That's incorrect, eglibc-pic is nothing but 22MB of static
libraries and should never appear as a runtime dependency.
Signed-off-by: Andy Ross
---
meta/recipes-extended/tasks/task-core-lsb.bb | 1 -
1 file chang
ned-off-by: Andy Ross
---
meta/recipes-core/udev/udev/mount.sh | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-core/udev/udev/mount.sh
b/meta/recipes-core/udev/udev/mount.sh
index c13b8bb..61d14a3 100644
--- a/meta/recipes-core/udev/udev/mount.sh
root before calling setuid).
Signed-off-by: Andy Ross
---
meta/recipes-core/dbus/dbus-1.4.20/dbus-1.init | 11 +++
meta/recipes-core/dbus/dbus-1.5.12/dbus-1.init | 11 +++
2 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/meta/recipes-core/dbus/dbus-1.4.20/dbus-1.init
iputils drops a /bin/arping with a runtime linkage against libsysfs in
/usr. Port Fedora 17 iputils-20071127-infiniband.patch, which inlines
access previously done by libsysfs.
Signed-off-by: Andy Ross
---
.../files/arping-break-libsysfs-dependency.patch | 296 +
meta
40 matches
Mail list logo
