Re: [OE-core] Error running QEMU with oe-core / angstrom console-image, hwclock: can't open '/dev/misc/rtc' : No such file or directory
Hi, well I never thought this would work out, but after adding -o rw to the -append parameters the system started and the login prompt appeared. So this problem is solved, for completenes I append my used command line to start qemu: qemu-system-arm -M versatilepb -m 128 -kernel /var/oe-core/tmp-eglibc/deploy/images/qemuarm/zImage-qemuarm.bin -hda /var/oe-core/tmp-eglibc/deploy/images/qemuarm/console-image-qemuarm.ext2 -append root=/dev/sda -o rw -- Regards Samuel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libc-package bbclass: fix binary localedata dependency code
Op 2 aug. 2011, om 17:01 heeft Phil Blundell het volgende geschreven:
It does look a bit weird. That code was introduced in 561d8754,
ostensibly as a merger of the eglibc and glibc equivalents. But, the
original code from glibc-package.bbclass did:
def output_locale_binary_rdepends(name, pkgname, locale, encoding):
m = re.match((.*)\.(.*), name)
if m:
glibc_name = %s.%s % (m.group(1),
m.group(2).lower().replace(-,))
else:
glibc_name = name
bb.data.setVar('RDEPENDS_%s' % pkgname,
legitimize_package_name('glibc-binary-localedata-%s' % glibc_name), d)
... i.e. it was using the . separator both for splitting and joining,
which seems reasonable. But somehow when it showed up in
libc-package.bbclass it had gotten transmogrified so that it split on
_ but joined with . as you showed below. That seems bogus to me.
There is something funky going on if you use cross-localedef instead of
on-target localedef and it looks like this is one of the reasons. I can respin
the patch in different split formats if people want. But most of all I'd like
to know what is going on :)
regards,
Koen
p.
On Tue, 2011-08-02 at 16:55 +0200, Koen Kooi wrote:
The bug I was seeing was caused by something else, but I'd still like
feedback on this patch to find out why the dot vs dash difference exists
Op 2 aug. 2011, om 16:47 heeft Koen Kooi het volgende geschreven:
When using binary locales rootfs generation fails with:
| Unknown package 'locale-base-en-us'.
| Collected errors:
| * opkg_install_cmd: Cannot install package locale-base-en-us.
This is due to:
$ dpkg-deb -I ipk/armv7a/locale-base-en-us_2.12-r16_armv7a.ipk | grep
Depends
Depends: eglibc-binary-localedata-en.us
Note the '.' seperator
$ ls ipk/armv7a/ | grep binary-localedata-en | grep us
eglibc-binary-localedata-en-us_2.12-r16_armv7a.ipk
Note the '-' seperator vs the '.' in the locale-base packages.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
meta/classes/libc-package.bbclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/libc-package.bbclass
b/meta/classes/libc-package.bbclass
index de57230..67d08c0 100644
--- a/meta/classes/libc-package.bbclass
+++ b/meta/classes/libc-package.bbclass
@@ -243,7 +243,7 @@ python package_do_split_gconvs () {
def output_locale_binary_rdepends(name, pkgname, locale, encoding):
m = re.match((.*)_(.*), name)
if m:
- libc_name = %s.%s % (m.group(1),
m.group(2).lower().replace(-,))
+ libc_name = %s-%s % (m.group(1),
m.group(2).lower().replace(-,))
else:
libc_name = name
bb.data.setVar('RDEPENDS_%s' % pkgname,
legitimize_package_name('%s-binary-localedata-%s' \
--
1.6.6.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Error running QEMU with oe-core / angstrom console-image, hwclock: can't open '/dev/misc/rtc' : No such file or directory
Op 3 aug. 2011, om 08:18 heeft Samuel Stirtzel het volgende geschreven: Hi, well I never thought this would work out, but after adding -o rw to the -append parameters the system started and the login prompt appeared. So this problem is solved, for completenes I append my used command line to start qemu: qemu-system-arm -M versatilepb -m 128 -kernel /var/oe-core/tmp-eglibc/deploy/images/qemuarm/zImage-qemuarm.bin -hda /var/oe-core/tmp-eglibc/deploy/images/qemuarm/console-image-qemuarm.ext2 -append root=/dev/sda -o rw FWIW, this is what I use: qemu-system-arm -M versatilepb -m 256M -kernel zImage --append 'root=/dev/sda rw console=tty0 raid=noautodetect' Angstrom-efl-nodm-image-eglibc-ipk-v2011.07-core-qemuarm.rootfs.ext3 Since I'm on OSX I build qemu myself and don't use the wrapper scripts. regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libc-package bbclass: fix binary localedata dependency code
On Wed, 2011-08-03 at 08:19 +0200, Koen Kooi wrote:
Op 2 aug. 2011, om 17:01 heeft Phil Blundell het volgende geschreven:
It does look a bit weird. That code was introduced in 561d8754,
ostensibly as a merger of the eglibc and glibc equivalents. But, the
original code from glibc-package.bbclass did:
def output_locale_binary_rdepends(name, pkgname, locale, encoding):
m = re.match((.*)\.(.*), name)
if m:
glibc_name = %s.%s % (m.group(1),
m.group(2).lower().replace(-,))
else:
glibc_name = name
bb.data.setVar('RDEPENDS_%s' % pkgname,
legitimize_package_name('glibc-binary-localedata-%s' % glibc_name), d)
... i.e. it was using the . separator both for splitting and joining,
which seems reasonable. But somehow when it showed up in
libc-package.bbclass it had gotten transmogrified so that it split on
_ but joined with . as you showed below. That seems bogus to me.
There is something funky going on if you use cross-localedef instead of
on-target localedef and it looks like this is one of the reasons. I can
respin the patch in different split formats if people want. But most of all
I'd like to know what is going on :)
Well, the original purpose of that code (when it split on dots) was to
squash hyphens in encoding names. That is, it transforms en-US.utf-8
to en-US.utf8, on the grounds that the dash isn't significant there
and might be confusing with all the other dashes that go on in the
package name.
I don't know why cross-localdef would be doing anything different to the
on-target one. Can you expand on what exactly is the funky behaviour
you see?
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libc-package bbclass: fix binary localedata dependency code
Op 3 aug. 2011, om 08:39 heeft Phil Blundell het volgende geschreven:
On Wed, 2011-08-03 at 08:19 +0200, Koen Kooi wrote:
Op 2 aug. 2011, om 17:01 heeft Phil Blundell het volgende geschreven:
It does look a bit weird. That code was introduced in 561d8754,
ostensibly as a merger of the eglibc and glibc equivalents. But, the
original code from glibc-package.bbclass did:
def output_locale_binary_rdepends(name, pkgname, locale, encoding):
m = re.match((.*)\.(.*), name)
if m:
glibc_name = %s.%s % (m.group(1),
m.group(2).lower().replace(-,))
else:
glibc_name = name
bb.data.setVar('RDEPENDS_%s' % pkgname,
legitimize_package_name('glibc-binary-localedata-%s' % glibc_name), d)
... i.e. it was using the . separator both for splitting and joining,
which seems reasonable. But somehow when it showed up in
libc-package.bbclass it had gotten transmogrified so that it split on
_ but joined with . as you showed below. That seems bogus to me.
There is something funky going on if you use cross-localedef instead of
on-target localedef and it looks like this is one of the reasons. I can
respin the patch in different split formats if people want. But most of all
I'd like to know what is going on :)
Well, the original purpose of that code (when it split on dots) was to
squash hyphens in encoding names. That is, it transforms en-US.utf-8
to en-US.utf8, on the grounds that the dash isn't significant there
and might be confusing with all the other dashes that go on in the
package name.
I don't know why cross-localdef would be doing anything different to the
on-target one. Can you expand on what exactly is the funky behaviour
you see?
If you look at e.g.
http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/testlab/commit/?h=yoctoid=0fb50099
-locale_base_en_us - eglibc_localedata_en_us;
-locale_base_en_us - localedef;
-locale_base_en_us - eglibc_charmap_utf_8;
-localedef - libc6;
+locale_base_en_us - eglibc_binary_localedata_en_us;
That shows that locale-base-foo drops some deps like the charmap when switching
to binary locales. There's other breakage in that build clouding the diff, so I
copied the relevant lines above.
regards,
Koen
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libc-package bbclass: fix binary localedata dependency code
On Wed, 2011-08-03 at 09:03 +0200, Koen Kooi wrote: If you look at e.g. http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/testlab/commit/?h=yoctoid=0fb50099 -locale_base_en_us - eglibc_localedata_en_us; -locale_base_en_us - localedef; -locale_base_en_us - eglibc_charmap_utf_8; -localedef - libc6; +locale_base_en_us - eglibc_binary_localedata_en_us; That shows that locale-base-foo drops some deps like the charmap when switching to binary locales. There's other breakage in that build clouding the diff, so I copied the relevant lines above. I think that's expected. IIRC, the charmap files are inputs to localedef and the relevant bits from them are fully captured in the binary archive output. So, if you're using a pregenerated binary locale, you don't need the charmap (or localedata, which is also a source file) at run time. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] xinput-calibrator: Add 0.7.5 as new recipe
Richard Purdie wrote: On Tue, 2011-07-26 at 14:53 +0200, Koen Kooi wrote: This one looks suspicously like the one in meta-oe. Apart from that, is it really needed in oe-core? Given that the xcalibrate extension has been removed from the xserver I think we're going to either need to migrate the tools like xtscal or adopt other tools. Certainly OE-Core should have a consistent story for touchscreens... RP, There is another recipe pointercal-xinput that provides script for calibration based on xinput_calibrator's output. So moving xinput, xinput_calibrator and pointercal-xinput from meta-oe to oe-core make a consistent story? If no objection, I'll do this... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2] eglibc: fix build for armv4 machines
eglibc builds for arm-eabi unconditionally enables the libc-do-syscall.S
file, which contains thumb assembly. It's unused in arm-eabi-nothumb case,
so just ifdef the actual code.
V2: use the patch from oe.dev.
The patch is submitted to sourceware bugzilla by Khem Raj back in October
of 2010, but the status is still UNCONFIRMED and the patch isn't commited.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
Cc: Khem Raj raj.k...@gmail.com
---
.../eglibc-2.12/armv4-eabi-compile-fix.patch | 25
.../eglibc-2.13/armv4-eabi-compile-fix.patch | 25
meta/recipes-core/eglibc/eglibc_2.12.bb|3 +-
meta/recipes-core/eglibc/eglibc_2.13.bb|3 +-
4 files changed, 54 insertions(+), 2 deletions(-)
create mode 100644
meta/recipes-core/eglibc/eglibc-2.12/armv4-eabi-compile-fix.patch
create mode 100644
meta/recipes-core/eglibc/eglibc-2.13/armv4-eabi-compile-fix.patch
diff --git a/meta/recipes-core/eglibc/eglibc-2.12/armv4-eabi-compile-fix.patch
b/meta/recipes-core/eglibc/eglibc-2.12/armv4-eabi-compile-fix.patch
new file mode 100644
index 000..c2407ee
--- /dev/null
+++ b/meta/recipes-core/eglibc/eglibc-2.12/armv4-eabi-compile-fix.patch
@@ -0,0 +1,25 @@
+Source: http://sourceware.org/bugzilla/show_bug.cgi?id=12097
+Upstream-Status: Submitted
+
+The patch should be merged into glibc-ports
+
+-Khem
+Index: libc/ports/sysdeps/unix/sysv/linux/arm/eabi/libc-do-syscall.S
+===
+--- libc.orig/ports/sysdeps/unix/sysv/linux/arm/eabi/libc-do-syscall.S
libc/ports/sysdeps/unix/sysv/linux/arm/eabi/libc-do-syscall.S
+@@ -16,6 +16,8 @@
+Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+02111-1307 USA. */
+
++#if defined(__thumb__)
++
+ #include sysdep.h
+
+ /* Out-of-line syscall stub. We expect the system call number in ip
+@@ -41,3 +43,5 @@ ENTRY (__libc_do_syscall)
+ pop {r7, pc}
+ .fnend
+ END (__libc_do_syscall)
++
++#endif /* __thumb__ */
diff --git a/meta/recipes-core/eglibc/eglibc-2.13/armv4-eabi-compile-fix.patch
b/meta/recipes-core/eglibc/eglibc-2.13/armv4-eabi-compile-fix.patch
new file mode 100644
index 000..c2407ee
--- /dev/null
+++ b/meta/recipes-core/eglibc/eglibc-2.13/armv4-eabi-compile-fix.patch
@@ -0,0 +1,25 @@
+Source: http://sourceware.org/bugzilla/show_bug.cgi?id=12097
+Upstream-Status: Submitted
+
+The patch should be merged into glibc-ports
+
+-Khem
+Index: libc/ports/sysdeps/unix/sysv/linux/arm/eabi/libc-do-syscall.S
+===
+--- libc.orig/ports/sysdeps/unix/sysv/linux/arm/eabi/libc-do-syscall.S
libc/ports/sysdeps/unix/sysv/linux/arm/eabi/libc-do-syscall.S
+@@ -16,6 +16,8 @@
+Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+02111-1307 USA. */
+
++#if defined(__thumb__)
++
+ #include sysdep.h
+
+ /* Out-of-line syscall stub. We expect the system call number in ip
+@@ -41,3 +43,5 @@ ENTRY (__libc_do_syscall)
+ pop {r7, pc}
+ .fnend
+ END (__libc_do_syscall)
++
++#endif /* __thumb__ */
diff --git a/meta/recipes-core/eglibc/eglibc_2.12.bb
b/meta/recipes-core/eglibc/eglibc_2.12.bb
index 1ada892..ce16bd6 100644
--- a/meta/recipes-core/eglibc/eglibc_2.12.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.12.bb
@@ -1,7 +1,7 @@
require eglibc.inc
DEPENDS += gperf-native
-PR = r20
+PR = r21
SRCREV = 14158
@@ -11,6 +11,7 @@ SRC_URI =
svn://www.eglibc.org/svn/branches/;module=${EGLIBC_BRANCH};proto=http
file://IO-acquire-lock-fix.patch \
file://shorten-build-commands.patch \
file://mips-rld-map-check.patch \
+ file://armv4-eabi-compile-fix.patch \
file://etc/ld.so.conf \
file://generate-supported.mk \
diff --git a/meta/recipes-core/eglibc/eglibc_2.13.bb
b/meta/recipes-core/eglibc/eglibc_2.13.bb
index 41fe7c7..ddca50f 100644
--- a/meta/recipes-core/eglibc/eglibc_2.13.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.13.bb
@@ -3,7 +3,7 @@ require eglibc.inc
SRCREV = 14157
DEPENDS += gperf-native
-PR = r9
+PR = r10
PR_append = +svnr${SRCPV}
EGLIBC_BRANCH=eglibc-2_13
@@ -13,6 +13,7 @@ SRC_URI =
svn://www.eglibc.org/svn/branches/;module=${EGLIBC_BRANCH};proto=http
file://shorten-build-commands.patch \
file://mips-rld-map-check.patch \
file://stack-protector-test.patch \
+ file://armv4-eabi-compile-fix.patch \
file://etc/ld.so.conf \
file://generate-supported.mk \
file://glibc_bug_fix_12454.patch \
--
1.7.2.3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 5/5] update-alternatives: Add alternatives as a runtime provide
On Tue, 2011-08-02 at 09:49 -0500, Mark Hatle wrote:
On 8/2/11 8:46 AM, Phil Blundell wrote:
On Mon, 2011-08-01 at 19:17 -0500, Mark Hatle wrote:
The following allows RPM to generate the SDK image, however without it
we get a failure because the system has nothing that provides /bin/sh.
Unfortunately the patch causes failures with ipk and deb packages because
they can not have filenames within their RPROVIDES. I'm looking for some
type of a resolution to the issue, the only thing I can think of is to
add a way to manually add a FILERPROVIDE for the items. This will require
changes to the way FILERPROVIDE is currently generated... but I'm not sure
how we can automatically generate the FILERPROVIDE values without the use
of
python...
Any suggestions?
It's never really been the intent that update-alternatives should put
the name of the link being provided into RPROVIDES. If you want to
solve the specific problem with /bin/sh then just adding RPROVIDES_${PN}
+= virtual-bourne-shell or something to bash and busybox is probably
the easiest way of doing that.
I wouldn't be entirely opposed to the concept of what you're proposing
here, though. Something like:
RPROVIDES_${PN} += ${@' '.join(map(lambda x:
legitimize_package_name(virtual-path- + x), filter(lambda x: x != '',
[ d.getVar('ALTERNATIVE_LINK', True) or '' ] +
(d.getVar('ALTERNATIVE_LINKS', True) or '').split(}
might be what you want, perhaps. I'm not sure that the resulting
virtual names will be very pretty though.
Hmm.. Coming from the RPM world, the virtual-path- because we can't just
provide a file in the system seems a bit wonky to me. But it should be able
to work. For RPM at least, we'd want a reversing function to turn virtual
paths
back into real paths.
If I have time today, I'll try to implement a proof of concept and see if I
can
get it to work reasonably well.
Just to be clear for Phil's benefit, RPM natively supports file based
dependencies, so a dependency of /bin/sh is automatically fulfilled by
a package which contains /bin/sh. Some dependencies such as the
shebang in scripts are automatically added to packages and resolved by
rpm.
I did chase down this bug a bit and it seems that if you bitbake
meta-toolchain-game you hit an error about /bin/sh being missing but if
you bitbake busybox; bitbake meta-toolchain-gmae it will work. This is
due to busybox shipping a /bin/sh.
The question is therefore how to handle this on the deb/ipk side and
ensure we get consistency between the behaviours of the different
backends. I thought with the rpm filedeps code in do_package, we were
adding things like /bin/sh dependencies to the other package formats but
now I'm not so sure.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] help with gcc-configure-common bug
On Tue, 2011-08-02 at 10:36 -0500, Kumar Gala wrote:
On Aug 1, 2011, at 1:58 PM, Kumar Gala wrote:
I'm trying to track down a bug related the following in
gcc-configure-common.inc. I know there is one bug in the sed line, but
when I fix that I run into a second issue. I'm trying to understand what
we think the following two lines are trying to attempt:
SYSTEMLIBS_DIR=`dirname ${SYSTEMLIBS}`
[ $SYSTEMLIBS_DIR = / ] SYSTEMLIBS_DIR=
any ideas?
From the commit log we expect something like:
#define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR/ld-linux-x86-64.so.2
and we define SYSTEMLIBS_DIR in defaults.h.
so its seems if SYSTEMLIBS = 'lib', that we end up with:
#define SYSTEMLIBS
and thus becomes:
GLIBC_DYNAMIC_LINKER64 ld-linux-x86-64.so.2
which ends up being wrong.
- k
do_configure_prepend () {
# Change the default dynamic linker path, only useful for SDK,
other's value
# are not changed according to the SYSTEMLIBS_DIR
sed -i ${S}/gcc/config/*/linux*.h -e \
's#\(GLIBC_DYNAMIC_LINKER[^ ]*\)\( */lib.*\)#\1
SYSTEMLIBS_DIR\2#'
SYSTEMLIBS_DIR=`dirname ${SYSTEMLIBS}`
[ $SYSTEMLIBS_DIR = / ] SYSTEMLIBS_DIR=
# teach gcc to find correct target includedir when checking libc ssp
support
mkdir -p ${B}/gcc
echo NATIVE_SYSTEM_HEADER_DIR = ${SYSTEMHEADERS} ${B}/gcc/t-oe
cat ${S}/gcc/defaults.h | grep -v \#endif.*GCC_DEFAULTS_H
${B}/gcc/defaults.h.new
cat ${B}/gcc/defaults.h.new _EOF
#ifndef STANDARD_INCLUDE_DIR
#define STANDARD_INCLUDE_DIR ${SYSTEMHEADERS}
#endif
#ifndef STANDARD_STARTFILE_PREFIX_1
#define STANDARD_STARTFILE_PREFIX_1 ${SYSTEMLIBS}
#endif
#ifndef STANDARD_STARTFILE_PREFIX_2
#define STANDARD_STARTFILE_PREFIX_2 ${SYSTEMLIBS1}
#endif
#define SYSTEMLIBS_DIR $SYSTEMLIBS_DIR
#endif /* ! GCC_DEFAULTS_H */
_EOF
mv ${B}/gcc/defaults.h.new ${B}/gcc/defaults.h
}
Would really love if anyone knows what is suppose to be going on with
SYSTEMLIBS_DIR to chime in here.
Ah, I can help here :)
We only have one gcc source checkout with the shared work directory.
Each multilib (or sdk build) needs to customise SYSTEMLIBS depending on
its configuration. This is why its being done in the defaults.h file in
${B} instead of files in ${S}.
We likely should do the substitutions in ${S} at unpack time to make
this clearer.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] help with gcc-configure-common bug
On Aug 3, 2011, at 7:25 AM, Richard Purdie wrote:
On Tue, 2011-08-02 at 10:36 -0500, Kumar Gala wrote:
On Aug 1, 2011, at 1:58 PM, Kumar Gala wrote:
I'm trying to track down a bug related the following in
gcc-configure-common.inc. I know there is one bug in the sed line, but
when I fix that I run into a second issue. I'm trying to understand what
we think the following two lines are trying to attempt:
SYSTEMLIBS_DIR=`dirname ${SYSTEMLIBS}`
[ $SYSTEMLIBS_DIR = / ] SYSTEMLIBS_DIR=
any ideas?
From the commit log we expect something like:
#define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR/ld-linux-x86-64.so.2
and we define SYSTEMLIBS_DIR in defaults.h.
so its seems if SYSTEMLIBS = 'lib', that we end up with:
#define SYSTEMLIBS
and thus becomes:
GLIBC_DYNAMIC_LINKER64 ld-linux-x86-64.so.2
which ends up being wrong.
- k
do_configure_prepend () {
# Change the default dynamic linker path, only useful for SDK,
other's value
# are not changed according to the SYSTEMLIBS_DIR
sed -i ${S}/gcc/config/*/linux*.h -e \
's#\(GLIBC_DYNAMIC_LINKER[^ ]*\)\( */lib.*\)#\1
SYSTEMLIBS_DIR\2#'
SYSTEMLIBS_DIR=`dirname ${SYSTEMLIBS}`
[ $SYSTEMLIBS_DIR = / ] SYSTEMLIBS_DIR=
# teach gcc to find correct target includedir when checking libc ssp
support
mkdir -p ${B}/gcc
echo NATIVE_SYSTEM_HEADER_DIR = ${SYSTEMHEADERS} ${B}/gcc/t-oe
cat ${S}/gcc/defaults.h | grep -v \#endif.*GCC_DEFAULTS_H
${B}/gcc/defaults.h.new
cat ${B}/gcc/defaults.h.new _EOF
#ifndef STANDARD_INCLUDE_DIR
#define STANDARD_INCLUDE_DIR ${SYSTEMHEADERS}
#endif
#ifndef STANDARD_STARTFILE_PREFIX_1
#define STANDARD_STARTFILE_PREFIX_1 ${SYSTEMLIBS}
#endif
#ifndef STANDARD_STARTFILE_PREFIX_2
#define STANDARD_STARTFILE_PREFIX_2 ${SYSTEMLIBS1}
#endif
#define SYSTEMLIBS_DIR $SYSTEMLIBS_DIR
#endif /* ! GCC_DEFAULTS_H */
_EOF
mv ${B}/gcc/defaults.h.new ${B}/gcc/defaults.h
}
Would really love if anyone knows what is suppose to be going on with
SYSTEMLIBS_DIR to chime in here.
Ah, I can help here :)
We only have one gcc source checkout with the shared work directory.
Each multilib (or sdk build) needs to customise SYSTEMLIBS depending on
its configuration. This is why its being done in the defaults.h file in
${B} instead of files in ${S}.
We likely should do the substitutions in ${S} at unpack time to make
this clearer.
Cheers,
Richard
Post some patches to address this, so take a look.
- k
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] oe-init-build-env, scripts/oe-buildenv-internal: add error detecting for $BDIR
On 08/02/2011 11:46 PM, Cui, Dexuan wrote:
Darren Hart wrote on 2011-08-03:
On 08/02/2011 04:43 AM, Richard Purdie wrote:
On Tue, 2011-08-02 at 14:08 +0800, Dexuan Cui wrote:
[YOCTO #671]
For a patch to address a relatively benign bug I thought the
standard procedure would be for it to await feedback for more than
5 hours. I
I agree. :-)
was hoping to have an opportunity to review this fix as I was
working with the team in root causing the bug.
+ if [ -z $BDIR ]; then + if expr $1 : '.*/$' /dev/null; then
echo 2 Error: please + remove any trailing / in the argument.
This portion of the patch is really not necessary. There is no
meaningful difference between the path with or without the
trailing slash, a much simpler and less noisy solution would be to
simply strip the trailing slash from the user input before doing
the rest of the input validation.
Hi Darren, thanks for the suggestion! I considered the idea too,
however, if we use the idea, it looks not that simple to gracefully
and concisely handle the case if a user (by accident or by prank)
passes / as $1 here, i.e., readlink -f would fail. So I didn't do
that.
Hi Dexuan,
I had not considered that case, good catch. I can't think of a valid use
case for BDIR=/. Not only are write permissions unlikely, but the
build would conflict with /tmp as well.
if [ $BDIR == / ]; then
echo ERROR: / is not supported as a build directory.
exit 1
fi
BDIR=${BDIR%/}
I would be happy with something like the above (untested). It seems a
lot more clear and direct to me.
In any case, I don't see any reason to bail out and ask the user to
remove a trailing slash. We should just do this and move on. There is no
semantic difference from the user's perspective, and the blame is to be
placed on readlink, not the user.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] oe-init-build-env, scripts/oe-buildenv-internal: add error detecting for $BDIR
On Wednesday 03 August 2011 14:50:45 Darren Hart wrote:
if [ $BDIR == / ]; then
echo ERROR: / is not supported as a build directory.
exit 1
fi
BDIR=${BDIR%/}
Works fine here - the only thing I'd suggest is use = instead of == as I
think == is a bashism (at least dash doesn't like it - not that we support
dash but we at least want the user to get past the setup script so they can
get a proper error from sanity.bbclass).
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] oe-init-build-env, scripts/oe-buildenv-internal: add error detecting for $BDIR
On Wed, 2011-08-03 at 15:01 +0100, Paul Eggleton wrote:
On Wednesday 03 August 2011 14:50:45 Darren Hart wrote:
if [ $BDIR == / ]; then
echo ERROR: / is not supported as a build directory.
exit 1
fi
BDIR=${BDIR%/}
Works fine here - the only thing I'd suggest is use = instead of == as I
think == is a bashism
Yeah, it is.
not that we support dash but we at least want the user to get past the
setup script so they can get a proper error from sanity.bbclass).
Has anybody ever tried to quantify how much work would be involved in
making OE work within the constraints of POSIX sh (i.e. work with dash)?
It does seem fairly obnoxious/embarrassing that you're obliged to
make /bin/sh be bash on a systemwide basis; I can't think offhand of any
other piece of software I use that has this kind of requirement.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] oe-init-build-env, scripts/oe-buildenv-internal: add error detecting for $BDIR
On Wednesday 03 August 2011 15:11:07 Phil Blundell wrote: Has anybody ever tried to quantify how much work would be involved in making OE work within the constraints of POSIX sh (i.e. work with dash)? It does seem fairly obnoxious/embarrassing that you're obliged to make /bin/sh be bash on a systemwide basis; I can't think offhand of any other piece of software I use that has this kind of requirement. Would that not entail fixing everything we build that contains shell scripts with bashisms that claim #!/bin/sh? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] oe-init-build-env, scripts/oe-buildenv-internal: add error detecting for $BDIR
On Wed, 2011-08-03 at 15:21 +0100, Paul Eggleton wrote:
On Wednesday 03 August 2011 15:11:07 Phil Blundell wrote:
Has anybody ever tried to quantify how much work would be involved in
making OE work within the constraints of POSIX sh (i.e. work with dash)?
It does seem fairly obnoxious/embarrassing that you're obliged to
make /bin/sh be bash on a systemwide basis; I can't think offhand of any
other piece of software I use that has this kind of requirement.
Would that not entail fixing everything we build that contains shell scripts
with bashisms that claim #!/bin/sh?
Yes, but anything that builds on current Ubuntu (etc) will presumably be
OK in that respect, and any shell scripts which are installed on the
target ought to be getting fixed anyway since bash is unlikely to be
available there. If you assume that those two groups of things are
going to have to be solved anyway (by someone) then it isn't obvious to
me that the remaining problem set will be all that large.
If it were to become a real issue then one could write a class which
searched for shell scripts inside ${S} and reprocessed them to use
#!/bin/bash, or alternatively write an LD_PRELOAD sort of shim to detect
such scripts at exec() time and redirect them to bash rather than sh.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] prelink issue with ppc64?
On 8/3/11 12:35 AM, Kumar Gala wrote: If prelink gets a chance to properly run I get a rootfs that does: /sbin/init: relocation error: /lib64/libc.so.6: symbol _rtld_global_ro, version GLIBC_PRIVATE not defined in file ld64.so.1 with link time reference if 'baselib' is set to /lib we get: /local/home/galak/git/poky/build-p5020/tmp/sysroots/x86_64-linux/usr/sbin/prelink: /sbin/init.sysvinit: Using /lib/ld64.so.1, not /lib64/ld64.so.1 as dynamic linker if 'baselib' is set to /lib64 we get: Assigned virtual address space slots for libraries: /lib64/ld64.so.1 0080f491-0080f49473d0 /lib64/libc.so.6 0080f495-0080f4afe090 /lib64/libdl.so.2 0080f4b1-0080f4b23520 /lib64/libcrypt.so.1 0080f4b1-0080f4b57708 /lib64/libutil.so.1 0080f4b1-0080f4b234a0 Would prelink /lib64/ld-2.13.so Would prelink /lib64/libc-2.13.so Not sure what prelink is doing but it seems to breaking things. Any ideas? --- I'm also concerned that we use /etc/prelink.conf when invoking prelink. Prelinker is being run within the rootfs, so the /etc/prelink.conf being used is the one inside of the image -- NOT the system version. I would suspect that the cross-prelinker rtld emulation is likely setup for the LSB style library paths and may be causing some of the problems. I'd suggest simply disabling prelink and getting everything to work first.. once it does we can work through any prelinker issues. (Prelink on PPC64 hasn't been tested within the oe-core environment.. so it could very well have issues beyond the ld.so path.) --Mark - k ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 5/5] update-alternatives: Add alternatives as a runtime provide
On 8/3/11 7:20 AM, Richard Purdie wrote:
On Tue, 2011-08-02 at 09:49 -0500, Mark Hatle wrote:
On 8/2/11 8:46 AM, Phil Blundell wrote:
On Mon, 2011-08-01 at 19:17 -0500, Mark Hatle wrote:
The following allows RPM to generate the SDK image, however without it
we get a failure because the system has nothing that provides /bin/sh.
Unfortunately the patch causes failures with ipk and deb packages because
they can not have filenames within their RPROVIDES. I'm looking for some
type of a resolution to the issue, the only thing I can think of is to
add a way to manually add a FILERPROVIDE for the items. This will require
changes to the way FILERPROVIDE is currently generated... but I'm not sure
how we can automatically generate the FILERPROVIDE values without the use
of
python...
Any suggestions?
It's never really been the intent that update-alternatives should put
the name of the link being provided into RPROVIDES. If you want to
solve the specific problem with /bin/sh then just adding RPROVIDES_${PN}
+= virtual-bourne-shell or something to bash and busybox is probably
the easiest way of doing that.
I wouldn't be entirely opposed to the concept of what you're proposing
here, though. Something like:
RPROVIDES_${PN} += ${@' '.join(map(lambda x:
legitimize_package_name(virtual-path- + x), filter(lambda x: x != '',
[ d.getVar('ALTERNATIVE_LINK', True) or '' ] +
(d.getVar('ALTERNATIVE_LINKS', True) or '').split(}
might be what you want, perhaps. I'm not sure that the resulting
virtual names will be very pretty though.
Hmm.. Coming from the RPM world, the virtual-path- because we can't just
provide a file in the system seems a bit wonky to me. But it should be
able
to work. For RPM at least, we'd want a reversing function to turn virtual
paths
back into real paths.
If I have time today, I'll try to implement a proof of concept and see if I
can
get it to work reasonably well.
Just to be clear for Phil's benefit, RPM natively supports file based
dependencies, so a dependency of /bin/sh is automatically fulfilled by
a package which contains /bin/sh. Some dependencies such as the
shebang in scripts are automatically added to packages and resolved by
rpm.
I did chase down this bug a bit and it seems that if you bitbake
meta-toolchain-game you hit an error about /bin/sh being missing but if
you bitbake busybox; bitbake meta-toolchain-gmae it will work. This is
due to busybox shipping a /bin/sh.
The question is therefore how to handle this on the deb/ipk side and
ensure we get consistency between the behaviours of the different
backends. I thought with the rpm filedeps code in do_package, we were
adding things like /bin/sh dependencies to the other package formats but
now I'm not so sure.
Due to deb/ipk not handling file based dependencies, they are filtered out on
the creation of the deb/ipk packages. The original intention was to use them,
but it wasn't possible at the time. Simply adding a ton of file-based
dependencies seemed like a huge mistake as well. (We'd have to add virtual
provides for all of the virtual requirements)
We could certainly select a few specific requirements and scan for and use those
to catch obvious issues, such as perl, sh, bash, env/python... but it's still
only a partial solution to the real issue.
--Mark
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Error running QEMU with oe-core / angstrom console-image, hwclock: can't open '/dev/misc/rtc' : No such file or directory
On 08/02/2011 11:18 PM, Samuel Stirtzel wrote: Hi, well I never thought this would work out, but after adding -o rw to the -append parameters the system started and the login prompt appeared. So this problem is solved, for completenes I append my used command line to start qemu: qemu-system-arm -M versatilepb -m 128 -kernel /var/oe-core/tmp-eglibc/deploy/images/qemuarm/zImage-qemuarm.bin -hda /var/oe-core/tmp-eglibc/deploy/images/qemuarm/console-image-qemuarm.ext2 -append root=/dev/sda -o rw There is a smart script in scripts/ dir that you could use something like this runqemu /var/oe-core/tmp-eglibc/deploy/images/qemuarm/zImage-qemuarm.bin /var/oe-core/tmp-eglibc/deploy/images/qemuarm/console-image-qemuarm.ext2 and it will setup everything (even networking) for you make sure that its run in shell where you have sourced setup environment of either oe-core or angstrom Hope that helps -Khem ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] prelink issue with ppc64?
On Aug 3, 2011, at 9:37 AM, Mark Hatle wrote: On 8/3/11 12:35 AM, Kumar Gala wrote: If prelink gets a chance to properly run I get a rootfs that does: /sbin/init: relocation error: /lib64/libc.so.6: symbol _rtld_global_ro, version GLIBC_PRIVATE not defined in file ld64.so.1 with link time reference if 'baselib' is set to /lib we get: /local/home/galak/git/poky/build-p5020/tmp/sysroots/x86_64-linux/usr/sbin/prelink: /sbin/init.sysvinit: Using /lib/ld64.so.1, not /lib64/ld64.so.1 as dynamic linker if 'baselib' is set to /lib64 we get: Assigned virtual address space slots for libraries: /lib64/ld64.so.1 0080f491-0080f49473d0 /lib64/libc.so.6 0080f495-0080f4afe090 /lib64/libdl.so.2 0080f4b1-0080f4b23520 /lib64/libcrypt.so.1 0080f4b1-0080f4b57708 /lib64/libutil.so.1 0080f4b1-0080f4b234a0 Would prelink /lib64/ld-2.13.so Would prelink /lib64/libc-2.13.so Not sure what prelink is doing but it seems to breaking things. Any ideas? --- I'm also concerned that we use /etc/prelink.conf when invoking prelink. Prelinker is being run within the rootfs, so the /etc/prelink.conf being used is the one inside of the image -- NOT the system version. Is this because of psuedo or something else? I would suspect that the cross-prelinker rtld emulation is likely setup for the LSB style library paths and may be causing some of the problems. I'd suggest simply disabling prelink and getting everything to work first.. once it does we can work through any prelinker issues. (Prelink on PPC64 hasn't been tested within the oe-core environment.. so it could very well have issues beyond the ld.so path.) Everything else is working, so prelink is what fails for me (at least for a simple minimal) build. any suggestions on how to try and debug further, who might be more familiar with prelink and what its doing? When I ran readelf -a on ld-2.13.so after prelink was getting weird results, not sure if thats normal or not. - k ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] xinput-calibrator: Add 0.7.5 as new recipe
On 08/03/2011 12:53 AM, Zhai, Edwin wrote: Richard Purdie wrote: On Tue, 2011-07-26 at 14:53 +0200, Koen Kooi wrote: This one looks suspicously like the one in meta-oe. Apart from that, is it really needed in oe-core? Given that the xcalibrate extension has been removed from the xserver I think we're going to either need to migrate the tools like xtscal or adopt other tools. Certainly OE-Core should have a consistent story for touchscreens... RP, There is another recipe pointercal-xinput that provides script for calibration based on xinput_calibrator's output. So moving xinput, xinput_calibrator and pointercal-xinput from meta-oe to oe-core make a consistent story? If no objection, I'll do this... yes please. I have not been able to caliberate screen using xinput-calibrator. I would try anything that will get me going. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] redundant RPATH warning?
On Wed, 2011-08-03 at 10:00 -0500, Kumar Gala wrote:
What causes warnings like the following:
WARNING: QA Issue: gthumb:
/work/ppce5500-poky-linux/gthumb-2.12.3-r1/packages-split/gthumb/usr/lib64/gthumb/extensions/libexport_tools.so
contains probably-redundant RPATH /usr/lib64
Pretty much what it says. That DSO contains an RPATH record pointing to
a directory which (in insane.bbclass's view) the dynamic linker would
have searched anyway without being told to. In most cases this means
that the RPATH isn't serving any useful purpose and is just wasting time
and space.
Obviously insane.bbclass is not infallible though. In particular, there
is no portable way to find out what paths ld.so will actually search on
its own initiative, so insane.bbclass assumes that the list consists of
${base_libdir} and ${libdir}. If that assumption isn't valid in your
particular configuration then you will get spurious warnings.
Is this something we should by trying to clean up?
Ideally, yes. I think libtool is the main offender in this respect and,
if it could be fixed somehow, the majority of those warnings would
probably go away.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] prelink issue with ppc64?
On 8/3/11 9:53 AM, Kumar Gala wrote: On Aug 3, 2011, at 9:37 AM, Mark Hatle wrote: On 8/3/11 12:35 AM, Kumar Gala wrote: If prelink gets a chance to properly run I get a rootfs that does: /sbin/init: relocation error: /lib64/libc.so.6: symbol _rtld_global_ro, version GLIBC_PRIVATE not defined in file ld64.so.1 with link time reference if 'baselib' is set to /lib we get: /local/home/galak/git/poky/build-p5020/tmp/sysroots/x86_64-linux/usr/sbin/prelink: /sbin/init.sysvinit: Using /lib/ld64.so.1, not /lib64/ld64.so.1 as dynamic linker if 'baselib' is set to /lib64 we get: Assigned virtual address space slots for libraries: /lib64/ld64.so.1 0080f491-0080f49473d0 /lib64/libc.so.6 0080f495-0080f4afe090 /lib64/libdl.so.2 0080f4b1-0080f4b23520 /lib64/libcrypt.so.1 0080f4b1-0080f4b57708 /lib64/libutil.so.1 0080f4b1-0080f4b234a0 Would prelink /lib64/ld-2.13.so Would prelink /lib64/libc-2.13.so Not sure what prelink is doing but it seems to breaking things. Any ideas? --- I'm also concerned that we use /etc/prelink.conf when invoking prelink. Prelinker is being run within the rootfs, so the /etc/prelink.conf being used is the one inside of the image -- NOT the system version. Is this because of psuedo or something else? In the cross prelinker, we pass in the --root=image. This instructs the cross-prelinker to prefix image to most paths. I would suspect that the cross-prelinker rtld emulation is likely setup for the LSB style library paths and may be causing some of the problems. You can run the cross-prelinker's rtld emulation by running the prelink-rtld program located in build/tmp-eglibc/work/x86_64-linux/usr/sbin/prelink-rtld Passing --root=path will setup the sysroot path for reference, adding in --target-paths will allow you to pass further arguments as referenced on the sysroot. So prelink-rtld --root=/foo/bar/build/sysroot/image --target-paths /sbin/init Should give you back an ldd like syntax within the sysroot, for /sbin/init. (without --target-paths, you need to specify the full path to the /sbin/init.. this is useful when running the rtld against items outside of the image.) I'd suggest simply disabling prelink and getting everything to work first.. once it does we can work through any prelinker issues. (Prelink on PPC64 hasn't been tested within the oe-core environment.. so it could very well have issues beyond the ld.so path.) Everything else is working, so prelink is what fails for me (at least for a simple minimal) build. any suggestions on how to try and debug further, who might be more familiar with prelink and what its doing? When I ran readelf -a on ld-2.13.so after prelink was getting weird results, not sure if thats normal or not. I'm the prelink maintainer for Yocto, however I know more about the way the cross-prelinker functionality works then how the ELF specific prelink functions work. I've been relying on the upstream prelink project to manage the individual architecture/ABI prelink standards. My suggestion is to disable cross-prelinking, and revert to the upstream prelink project -- run the binary on the target and see if it fails in the same way. If it does, then we know it's a deeper problem then the cross prelink integration. You can pull down the git repository: git://git.yoctoproject.org/prelink-cross.git The master branch is identical to the upstream SVN branch. The cross_prelink branch is the current state of integration. --Mark - k ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] redundant RPATH warning?
On 8/3/11 10:00 AM, Kumar Gala wrote: What causes warnings like the following: WARNING: QA Issue: gthumb: /work/ppce5500-poky-linux/gthumb-2.12.3-r1/packages-split/gthumb/usr/lib64/gthumb/extensions/libexport_tools.so contains probably-redundant RPATH /usr/lib64 Something passing in rpath /usr/lib64 during linking.. likely libtool Is this something we should by trying to clean up? It doesn't have to be cleaned up, but it's a really good idea to find and fix the problems. I believe that the standard libtool in oe-core avoids passing rpaths of standard system prefixes.. so it's likely the gthumb Makefiles themselves that are doing this. (Unless of course libtool has a bug) --Mark - k ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] xinput-calibrator: Add 0.7.5 as new recipe
Op 3 aug. 2011, om 17:00 heeft Khem Raj het volgende geschreven: On 08/03/2011 12:53 AM, Zhai, Edwin wrote: Richard Purdie wrote: On Tue, 2011-07-26 at 14:53 +0200, Koen Kooi wrote: This one looks suspicously like the one in meta-oe. Apart from that, is it really needed in oe-core? Given that the xcalibrate extension has been removed from the xserver I think we're going to either need to migrate the tools like xtscal or adopt other tools. Certainly OE-Core should have a consistent story for touchscreens... RP, There is another recipe pointercal-xinput that provides script for calibration based on xinput_calibrator's output. So moving xinput, xinput_calibrator and pointercal-xinput from meta-oe to oe-core make a consistent story? If no objection, I'll do this... yes please. I have not been able to caliberate screen using xinput-calibrator. I would try anything that will get me going. I've only used it under X and if you use xf86-input-evdev it just works. The most recent system I tried was an ipaq hx4700 with kernel 3.0. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libzypp: Correctly handle - in package architecture names
If package architectures contain - characters this needs to be mapped
to something else in (_) since its illegal in C variable names.
[YOCTO #1313 partially]
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-extended/libzypp/libzypp_git.bb
b/meta/recipes-extended/libzypp/libzypp_git.bb
index 6e8fe16..bb36a90 100644
--- a/meta/recipes-extended/libzypp/libzypp_git.bb
+++ b/meta/recipes-extended/libzypp/libzypp_git.bb
@@ -54,7 +54,7 @@ do_archgen () {
echo
zypp/poky-arch.h
echo #ifndef POKY_ARCH_H
zypp/poky-arch.h
echo #define POKY_ARCH_H 1
zypp/poky-arch.h
- echo #define Arch_machine Arch_${MACHINE_ARCH}
zypp/poky-arch.h
+ echo #define Arch_machine Arch_${MACHINE_ARCH} | tr - _
zypp/poky-arch.h
echo #endif /* POKY_ARCH_H */
zypp/poky-arch.h
echo
zypp/poky-arch.h
if [ ${AVOID_CONSTRUCTOR} != true ]; then
@@ -65,7 +65,7 @@ do_archgen () {
all | any | noarch)
continue;;
esac
- echo DEF_BUILTIN( ${each_arch} );
zypp/poky-arch.h
+ echo DEF_BUILTIN( ${each_arch} ); | tr - _
zypp/poky-arch.h
done
echo #endif /* DEF_BUILTIN */
zypp/poky-arch.h
echo
zypp/poky-arch.h
@@ -77,7 +77,7 @@ do_archgen () {
all | any | noarch)
continue;;
esac
- echo extern const Arch Arch_${each_arch};
zypp/poky-arch.h
+ echo extern const Arch Arch_${each_arch}; | tr - _
zypp/poky-arch.h
done
echo #endif /* POKY_EXTERN_PROTO */
zypp/poky-arch.h
echo
zypp/poky-arch.h
@@ -89,9 +89,11 @@ do_archgen () {
continue;;
esac
if [ ${AVOID_CONSTRUCTOR} != true ]; then
- echo const Arch Arch_${each_arch} (_${each_arch});
zypp/poky-arch.h
+ echo -n const Arch Arch_${each_arch} | tr - _
zypp/poky-arch.h
+ echo (_${each_arch});
zypp/poky-arch.h
else
- echo const Arch Arch_${each_arch} ( IdString (
\${each_arch}\ ) ); zypp/poky-arch.h
+ echo -n const Arch Arch_${each_arch} | tr - _
zypp/poky-arch.h
+ echo ( IdString ( \${each_arch}\ ) );
zypp/poky-arch.h
fi
done
echo #endif /* POKY_PROTO */
zypp/poky-arch.h
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] autotools.bbclass: Fix m4 file race
If something removes .m4 files from the aclocal directory whilst aclocal is
running it gets upset. To avoid this we need to take a copy of the aclocal
directory and build against this instead.
[YOCTO #861]
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
index e5c13ae..8f65b70 100644
--- a/meta/classes/autotools.bbclass
+++ b/meta/classes/autotools.bbclass
@@ -111,8 +111,13 @@ autotools_do_configure() {
if [ -d ${STAGING_DATADIR_NATIVE}/aclocal-$AUTOV ]; then
acpaths=$acpaths
-I${STAGING_DATADIR_NATIVE}/aclocal-$AUTOV
fi
+ # The aclocal directory could get modified by other
processes
+ # uninstalling data from the sysroot. See Yocto #861
for details.
+ # We avoid this by taking a copy here and then files
cannot disappear.
if [ -d ${STAGING_DATADIR}/aclocal ]; then
- acpaths=$acpaths -I ${STAGING_DATADIR}/aclocal
+ mkdir -p ${B}/aclocal-copy/
+ cp ${STAGING_DATADIR}/aclocal/*
${B}/aclocal-copy/
+ acpaths=$acpaths -I ${B}/aclocal-copy/
fi
# autoreconf is too shy to overwrite aclocal.m4 if it
doesn't look
# like it was auto-generated. Work around this by
blowing it away
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libnss-mdns: dont use hard coded /lib path
As libdir might not be /lib (could be /lib64) use ${libdir} instead of
hard coded /lib in configure options set in EXTRA_OECONF.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
.../libnss-mdns/libnss-mdns_0.10.bb|4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb
b/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb
index f5df005..00f2c56 100644
--- a/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb
+++ b/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
file://LICENSE;md5=2d5025d4aa3495befef8f17206a5b0a1
DEPENDS = avahi
RDEPENDS_${PN} = avahi-daemon
-PR = r2
+PR = r3
SRC_URI = http://0pointer.de/lennart/projects/nss-mdns/nss-mdns-${PV}.tar.gz;
@@ -21,7 +21,7 @@ inherit autotools
LEAD_SONAME = libnss_mdns.so
DEBIANNAME_${PN} = libnss-mdns
-EXTRA_OECONF = --libdir=/lib --disable-lynx --enable-avahi
+EXTRA_OECONF = --libdir=${libdir} --disable-lynx --enable-avahi
# TODO: pattern based configuration update
pkg_postinst_${PN} () {
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] bitbake.conf/qemux86-64: Automate TRANSLATED_TARGET_ARCH
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index ac5d1f3..6f0b42c 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -728,7 +728,7 @@ TARGET_ARCH[unexport] = 1
DISTRO[unexport] = 1
# Used by canadian-cross to handle string conversions on TARGET_ARCH where
needed
-TRANSLATED_TARGET_ARCH ??= ${TARGET_ARCH}
+TRANSLATED_TARGET_ARCH ??= ${@d.getVar('TARGET_ARCH', True).replace(_,
-)}
# Setup our default hash policy
BB_SIGNATURE_HANDLER ?= basic
diff --git a/meta/conf/machine/qemux86-64.conf
b/meta/conf/machine/qemux86-64.conf
index 46d7d12..18a7513 100644
--- a/meta/conf/machine/qemux86-64.conf
+++ b/meta/conf/machine/qemux86-64.conf
@@ -2,9 +2,6 @@
#@NAME: common_pc
#@DESCRIPTION: Machine configuration for running a common x86
-TARGET_ARCH = x86_64
-TRANSLATED_TARGET_ARCH = x86-64
-
PREFERRED_PROVIDER_virtual/libgl = mesa-dri
PREFERRED_PROVIDER_virtual/libx11 ?= libx11-trim
PREFERRED_PROVIDER_virtual/xserver ?= xserver-xf86-dri-lite
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libnss-mdns: dont use hard coded /lib path
On Wed, 2011-08-03 at 10:15 -0500, Kumar Gala wrote:
As libdir might not be /lib (could be /lib64) use ${libdir} instead of
hard coded /lib in configure options set in EXTRA_OECONF.
Do you mean ${libdir} or ${base_libdir} ?
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
.../libnss-mdns/libnss-mdns_0.10.bb|4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb
b/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb
index f5df005..00f2c56 100644
--- a/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb
+++ b/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
file://LICENSE;md5=2d5025d4aa3495befef8f17206a5b0a1
DEPENDS = avahi
RDEPENDS_${PN} = avahi-daemon
-PR = r2
+PR = r3
SRC_URI =
http://0pointer.de/lennart/projects/nss-mdns/nss-mdns-${PV}.tar.gz;
@@ -21,7 +21,7 @@ inherit autotools
LEAD_SONAME = libnss_mdns.so
DEBIANNAME_${PN} = libnss-mdns
-EXTRA_OECONF = --libdir=/lib --disable-lynx --enable-avahi
+EXTRA_OECONF = --libdir=${libdir} --disable-lynx --enable-avahi
# TODO: pattern based configuration update
pkg_postinst_${PN} () {
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libnss-mdns: dont use hard coded /lib path
On Wed, 2011-08-03 at 10:15 -0500, Kumar Gala wrote:
-EXTRA_OECONF = --libdir=/lib --disable-lynx --enable-avahi
+EXTRA_OECONF = --libdir=${libdir} --disable-lynx --enable-avahi
Really? ${libdir} is /usr/lib in most configurations. If you wanted
this to be a no-op for most folks then ${base_libdir} is probably the
variable you need.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/7][PULL] Multilib: various fixes
Hi Richard,
This pull request contains several multilib fixes, especially for rpm side.
Please help to review and pull.
Current status for rpm sato is, most of the error dependency issues have been
solved except one error while do_rootfs:
error: Failed dependencies:
/bin/sh is needed by dbus-1.4.12-r0.x86_64
/bin/sh is needed by psplash-0.0+svnr424-r6.x86_64
/bin/sh is needed by portmap-6.0-r7.x86_64
/bin/sh is needed by dropbear-0.52-r3.x86_64
...
I am looking into that currently. Any suggestion would be appreciated.
Thanks,
Dongxiao
The following changes since commit 07864a16baf18046b726ec72b688594a91c6e4b4:
local.conf.sample: Fix TUNENAME reference (should be DEFAULTTUNE) (2011-08-02
14:40:54 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib dxu4/ml
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dxu4/ml
Dongxiao Xu (7):
eglibc-locale: Specially handle FILES_eglibc-gconv for multilib
libxml-simple-perl: Use BBCLASSEXTEND insteand of *-native recipe
openjade-native: Change RDEPENDS of sgml-common-native
multilib: Use BPN instead of PN for style like lib${PN}
multilib: remove MULTILIB_PACKAGE_ARCHS variable
package_rpm: fix strip_multilib function
package_rpm: Fix package rename issue in multilib case
meta/classes/libc-package.bbclass |2 +-
meta/classes/package_rpm.bbclass | 31 +++-
meta/classes/populate_sdk_rpm.bbclass |3 --
meta/classes/rootfs_rpm.bbclass|3 --
meta/recipes-core/eglibc/eglibc-locale.inc |5 ++-
.../openjade/openjade-native_1.3.2.bb |2 +-
.../perl/libxml-simple-perl-native_2.18.bb |7
.../perl/libxml-simple-perl_2.18.bb|2 +
meta/recipes-devtools/python/python_2.6.6.bb |4 +-
meta/recipes-extended/augeas/augeas.inc| 12
meta/recipes-extended/gamin/gamin_0.1.10.bb|8 ++--
meta/recipes-support/attr/ea-acl.inc |2 +-
meta/recipes-support/sqlite/sqlite3.inc|6 ++--
13 files changed, 35 insertions(+), 52 deletions(-)
delete mode 100644 meta/recipes-devtools/perl/libxml-simple-perl-native_2.18.bb
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/7] libxml-simple-perl: Use BBCLASSEXTEND insteand of *-native recipe
It's not appropriate to require xxx.bb in xxx-native.bb, causing that
xxx-native depends on target recipe.
Use BBCLASSEXTEND to solve this issue.
Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
.../perl/libxml-simple-perl-native_2.18.bb |7 ---
.../perl/libxml-simple-perl_2.18.bb|2 ++
2 files changed, 2 insertions(+), 7 deletions(-)
delete mode 100644 meta/recipes-devtools/perl/libxml-simple-perl-native_2.18.bb
diff --git a/meta/recipes-devtools/perl/libxml-simple-perl-native_2.18.bb
b/meta/recipes-devtools/perl/libxml-simple-perl-native_2.18.bb
deleted file mode 100644
index 3877d0b..000
--- a/meta/recipes-devtools/perl/libxml-simple-perl-native_2.18.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-SECTION = libs
-
-inherit native
-
-require libxml-simple-perl_${PV}.bb
-
-DEPENDS += libxml-parser-perl-native
diff --git a/meta/recipes-devtools/perl/libxml-simple-perl_2.18.bb
b/meta/recipes-devtools/perl/libxml-simple-perl_2.18.bb
index 3a50d7f..f2abf9d 100644
--- a/meta/recipes-devtools/perl/libxml-simple-perl_2.18.bb
+++ b/meta/recipes-devtools/perl/libxml-simple-perl_2.18.bb
@@ -14,3 +14,5 @@ S = ${WORKDIR}/XML-Simple-${PV}
EXTRA_PERLFLAGS = -I
${STAGING_LIBDIR_NATIVE}/perl-native/perl/${@get_perl_version(d)}
inherit cpan
+
+BBCLASSEXTEND = native
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/7] eglibc-locale: Specially handle FILES_eglibc-gconv for multilib
In multilib support, it iterate values in PACKAGES and then extend name
for variables like FILES_xxx, SUMMARY_xxx, etc.
However eglibc-gconv is dynamically put in PACKAGES by
package_do_split_gconv function. Therefore the name will not be
extended automatically.
Specially handle the FILES variable for eglibc-gconv to fix the issue
of missing lib32-eglibc-gconv issue in doing multilib do_rootfs.
Also when set PACKAGES, add the MLPREFIX.
Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
meta/classes/libc-package.bbclass |2 +-
meta/recipes-core/eglibc/eglibc-locale.inc |5 -
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/classes/libc-package.bbclass
b/meta/classes/libc-package.bbclass
index de57230..0d5ce20 100644
--- a/meta/classes/libc-package.bbclass
+++ b/meta/classes/libc-package.bbclass
@@ -191,7 +191,7 @@ python package_do_split_gconvs () {
do_split_packages(d, locales_dir, file_regex='(.*)',
output_pattern=bpn+'-localedata-%s', \
description='locale definition for %s', hook=calc_locale_deps,
extra_depends='')
- bb.data.setVar('PACKAGES', bb.data.getVar('PACKAGES', d) + ' ' + bpn +
'-gconv', d)
+ bb.data.setVar('PACKAGES', bb.data.getVar('PACKAGES', d) + ' ' +
bb.data.getVar('MLPREFIX', d) + bpn + '-gconv', d)
use_bin = bb.data.getVar(GLIBC_INTERNAL_USE_BINARY_LOCALE, d, 1)
diff --git a/meta/recipes-core/eglibc/eglibc-locale.inc
b/meta/recipes-core/eglibc/eglibc-locale.inc
index b496ce6..ca3940d 100644
--- a/meta/recipes-core/eglibc/eglibc-locale.inc
+++ b/meta/recipes-core/eglibc/eglibc-locale.inc
@@ -41,7 +41,10 @@ PACKAGES_DYNAMIC = locale-base-* \
DESCRIPTION_localedef = eglibc: compile locale definition files
-FILES_eglibc-gconv = ${libdir}/gconv/*
+# eglibc-gconv is dynamically added into PACKAGES, thus
+# FILES_eglibc-gconv will not be automatically extended in multilib.
+# Explicitly add ${MLPREFIX} for FILES_eglibc-gconv.
+FILES_${MLPREFIX}eglibc-gconv = ${libdir}/gconv/*
FILES_${PN}-dbg += ${libdir}/gconv/.debug/*
FILES_localedef${PKGSUFFIX} = ${bindir}/localedef
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 7/7] package_rpm: Fix package rename issue in multilib case
do_package task will write information into pkgdata and
do_package_write_rpm will read them out. Take lib32-dates as an example,
one of its RDEPENDS is li32-gtk+, and PKG_lib32-gtk+ = libgtk-2.0,
these info is stored at:
tmp/pkgdata/x86_64-pokymllib32-linux/runtime/lib32-dates.
Function mapping_rename_hook in do_package_write_rpm is to handle
those renamed packages. However before it executes, translate_vers
has stripped the multilib prefix out, making it failed to find PKG_gtk+
value in pkgdata.
This commit moves the strip_multilib out of translate_vers and call it
after mapping_rename_hook.
CC: Mark Hatle mark.ha...@windriver.com
Signed-off-by: Dongxiao Xu dongxiao...@intel.com
Signed-off-by: Lianhao Lu lianhao...@intel.com
---
meta/classes/package_rpm.bbclass | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index a29ce9d..4a2d667 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -362,7 +362,7 @@ python write_specfile () {
pv = subd['PKGV']
reppv = pv.replace('-',
'+')
ver = ver.replace(pv,
reppv)
- newdeps_dict[strip_multilib(dep, d)] = ver
+ newdeps_dict[dep] = ver
depends = bb.utils.join_deps(newdeps_dict)
bb.data.setVar(varname, depends.strip(), d)
@@ -484,12 +484,12 @@ python write_specfile () {
# Map the dependencies into their final form
bb.build.exec_func(mapping_rename_hook, localdata)
- splitrdepends= bb.data.getVar('RDEPENDS', localdata, True)
or
- splitrrecommends = bb.data.getVar('RRECOMMENDS', localdata,
True) or
- splitrsuggests = bb.data.getVar('RSUGGESTS', localdata, True)
or
- splitrprovides = bb.data.getVar('RPROVIDES', localdata, True)
or
- splitrreplaces = bb.data.getVar('RREPLACES', localdata, True)
or
- splitrconflicts = bb.data.getVar('RCONFLICTS', localdata,
True) or
+ splitrdepends= strip_multilib(bb.data.getVar('RDEPENDS',
localdata, True), d) or
+ splitrrecommends = strip_multilib(bb.data.getVar('RRECOMMENDS',
localdata, True), d) or
+ splitrsuggests = strip_multilib(bb.data.getVar('RSUGGESTS',
localdata, True), d) or
+ splitrprovides = strip_multilib(bb.data.getVar('RPROVIDES',
localdata, True), d) or
+ splitrreplaces = strip_multilib(bb.data.getVar('RREPLACES',
localdata, True), d) or
+ splitrconflicts = strip_multilib(bb.data.getVar('RCONFLICTS',
localdata, True), d) or
splitrobsoletes = []
# Gather special src/first package data
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/7] openjade-native: Change RDEPENDS of sgml-common-native
openjade-native should RDEPENDS on sgml-common-native but not
sgml-common
Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
.../openjade/openjade-native_1.3.2.bb |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-devtools/openjade/openjade-native_1.3.2.bb
b/meta/recipes-devtools/openjade/openjade-native_1.3.2.bb
index c71f22a..6cc6bb5 100644
--- a/meta/recipes-devtools/openjade/openjade-native_1.3.2.bb
+++ b/meta/recipes-devtools/openjade/openjade-native_1.3.2.bb
@@ -10,7 +10,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=641ff1e4511f0a87044ad42f87cb1045
PR = r4
DEPENDS = opensp-native sgml-common-native
-RDEPENDS_${PN} = sgml-common
+RDEPENDS_${PN} = sgml-common-native
SRC_URI = ${SOURCEFORGE_MIRROR}/openjade/openjade-${PV}.tar.gz \
file://makefile.patch \
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/7] multilib: remove MULTILIB_PACKAGE_ARCHS variable
multilib package and normal package shares the same architecture deploy
folder, thus we do not need the ${MULTILIB_PACKAGE_ARCHS}.
CC: Mark Hatle mark.ha...@windriver.com
Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
meta/classes/package_rpm.bbclass | 13 ++---
meta/classes/populate_sdk_rpm.bbclass |3 ---
meta/classes/rootfs_rpm.bbclass |3 ---
3 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index abedc68..9d0eeba 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -27,8 +27,7 @@ package_update_index_rpm () {
# Update target packages
base_archs=${PACKAGE_ARCHS}
- ml_archs=${MULTILIB_PACKAGE_ARCHS}
- package_update_index_rpm_common ${RPMCONF_TARGET_BASE} base_archs
ml_archs
+ package_update_index_rpm_common ${RPMCONF_TARGET_BASE} base_archs
# Update SDK packages
base_archs=${SDK_PACKAGE_ARCHS}
@@ -76,7 +75,7 @@ package_update_index_rpm_common () {
#
package_generate_rpm_conf () {
# Update target packages
- package_generate_rpm_conf_common ${RPMCONF_TARGET_BASE} base_archs
ml_archs
+ package_generate_rpm_conf_common ${RPMCONF_TARGET_BASE} base_archs
# Update SDK packages
package_generate_rpm_conf_common ${RPMCONF_HOST_BASE} base_archs
@@ -203,10 +202,6 @@ package_install_internal_rpm () {
archvar=base_archs
ml_pkg=$(echo ${pkg} | sed
s,^${MLPREFIX}\(.*\),\1,)
- if [ ${ml_pkg} != ${pkg} ]; then
- archvar=ml_archs
- fi
-
pkg_name=$(resolve_package_rpm
${confbase}-${archvar}.conf ${ml_pkg})
if [ -z $pkg_name ]; then
echo Unable to find package $pkg
($ml_pkg)!
@@ -223,10 +218,6 @@ package_install_internal_rpm () {
archvar=base_archs
ml_pkg=$(echo ${pkg} | sed s,^${MLPREFIX}\(.*\),\1,)
- if [ ${ml_pkg} != ${pkg} ]; then
- archvar=ml_archs
- fi
-
pkg_name=$(resolve_package_rpm
${confbase}-${archvar}.conf ${ml_pkg})
if [ -z $pkg_name ]; then
echo Unable to find package $pkg ($ml_pkg)!
diff --git a/meta/classes/populate_sdk_rpm.bbclass
b/meta/classes/populate_sdk_rpm.bbclass
index 5fb0234..f33e4a9 100644
--- a/meta/classes/populate_sdk_rpm.bbclass
+++ b/meta/classes/populate_sdk_rpm.bbclass
@@ -115,7 +115,6 @@ EOF
}
python () {
-ml_package_archs =
multilibs = d.getVar('MULTILIBS', True) or
for ext in multilibs.split():
eext = ext.split(':')
@@ -125,8 +124,6 @@ python () {
localdata.setVar(OVERRIDES, overrides)
# TEMP: OVERRIDES isn't working right
localdata.setVar(DEFAULTTUNE,
localdata.getVar(DEFAULTTUNE_virtclass-multilib- + eext[1], False) or )
-ml_package_archs += localdata.getVar(PACKAGE_ARCHS, True) or
#bb.note(ML_PACKAGE_ARCHS %s %s %s % (eext[1],
localdata.getVar(PACKAGE_ARCHS, True) or (none), overrides))
-bb.data.setVar('MULTILIB_PACKAGE_ARCHS', ml_package_archs, d)
}
diff --git a/meta/classes/rootfs_rpm.bbclass b/meta/classes/rootfs_rpm.bbclass
index 7c06064..c188d27 100644
--- a/meta/classes/rootfs_rpm.bbclass
+++ b/meta/classes/rootfs_rpm.bbclass
@@ -209,7 +209,6 @@ python () {
bb.data.setVar('RPM_PREPROCESS_COMMANDS', '', d)
bb.data.setVar('RPM_POSTPROCESS_COMMANDS', '', d)
-ml_package_archs =
multilibs = d.getVar('MULTILIBS', True) or
for ext in multilibs.split():
eext = ext.split(':')
@@ -219,7 +218,5 @@ python () {
localdata.setVar(OVERRIDES, overrides)
# TEMP: OVERRIDES isn't working right
localdata.setVar(DEFAULTTUNE,
localdata.getVar(DEFAULTTUNE_virtclass-multilib- + eext[1], False) or )
-ml_package_archs += localdata.getVar(PACKAGE_ARCHS, True) or
#bb.note(ML_PACKAGE_ARCHS %s %s %s % (eext[1],
localdata.getVar(PACKAGE_ARCHS, True) or (none), overrides))
-bb.data.setVar('MULTILIB_PACKAGE_ARCHS', ml_package_archs, d)
}
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/7] multilib: Use BPN instead of PN for style like lib${PN}
When supporting multilib, ${PN} will be extended with MLPREFIX. However
if a package name contains ${PN} with styles like lib${PN}, such
extension will cause error. Use BPN in this case.
Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
meta/recipes-devtools/python/python_2.6.6.bb |4 ++--
meta/recipes-extended/augeas/augeas.inc | 12 ++--
meta/recipes-extended/gamin/gamin_0.1.10.bb |8
meta/recipes-support/attr/ea-acl.inc |2 +-
meta/recipes-support/sqlite/sqlite3.inc |6 +++---
5 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/meta/recipes-devtools/python/python_2.6.6.bb
b/meta/recipes-devtools/python/python_2.6.6.bb
index f71440a..c9c1a13 100644
--- a/meta/recipes-devtools/python/python_2.6.6.bb
+++ b/meta/recipes-devtools/python/python_2.6.6.bb
@@ -116,8 +116,8 @@ FILES_${PN}-core +=
${libdir}/python${PYTHON_MAJMIN}/sitecustomize.py
FILES_${PN}-core += ${bindir}/2to3
# package libpython2
-PACKAGES =+ lib${PN}2
-FILES_lib${PN}2 = ${libdir}/libpython*.so.*
+PACKAGES =+ lib${BPN}2
+FILES_lib${BPN}2 = ${libdir}/libpython*.so.*
# additional stuff -dev
diff --git a/meta/recipes-extended/augeas/augeas.inc
b/meta/recipes-extended/augeas/augeas.inc
index 619cd20..0c6d534 100644
--- a/meta/recipes-extended/augeas/augeas.inc
+++ b/meta/recipes-extended/augeas/augeas.inc
@@ -11,15 +11,15 @@ DEPENDS = readline
inherit autotools
-PACKAGES =+ ${PN}-lenses lib${PN} lib${PN}-dev lib${PN}-dbg
+PACKAGES =+ ${PN}-lenses lib${BPN} lib${BPN}-dev lib${BPN}-dbg
FILES_${PN}-lenses = ${datadir}/augeas/lenses
-FILES_lib${PN} = ${libdir}/*.so.*
-FILES_lib${PN}-dev = ${libdir}/*.so ${libdir}/*.a ${libdir}/*.la
${includedir} ${libdir}/pkgconfig
-FILES_lib${PN}-dbg = ${libdir}/.debug
+FILES_lib${BPN} = ${libdir}/*.so.*
+FILES_lib${BPN}-dev = ${libdir}/*.so ${libdir}/*.a ${libdir}/*.la
${includedir} ${libdir}/pkgconfig
+FILES_lib${BPN}-dbg = ${libdir}/.debug
-RDEPENDS_lib${PN} += ${PN}-lenses
-RRECOMMENDS_lib${PN} += ${PN}
+RDEPENDS_lib${BPN} += ${PN}-lenses
+RRECOMMENDS_lib${BPN} += ${PN}
LEAD_SONAME = libaugeas.so
diff --git a/meta/recipes-extended/gamin/gamin_0.1.10.bb
b/meta/recipes-extended/gamin/gamin_0.1.10.bb
index 81b27c0..080a325 100644
--- a/meta/recipes-extended/gamin/gamin_0.1.10.bb
+++ b/meta/recipes-extended/gamin/gamin_0.1.10.bb
@@ -20,14 +20,14 @@ inherit autotools pkgconfig
EXTRA_OECONF = --without-python
-PACKAGES += lib${PN} lib${PN}-dev
+PACKAGES += lib${BPN} lib${BPN}-dev
FILES_${PN} = ${libexecdir}
FILES_${PN}-dbg += ${libexecdir}/.debug
-FILES_lib${PN} = ${libdir}/lib*.so.*
-FILES_lib${PN}-dev = ${includedir} ${libdir}/pkgconfig ${libdir}/lib*.la \
+FILES_lib${BPN} = ${libdir}/lib*.so.*
+FILES_lib${BPN}-dev = ${includedir} ${libdir}/pkgconfig ${libdir}/lib*.la \
${libdir}/lib*.a ${libdir}/lib*.so
-RDEPENDS_lib${PN} = ${PN}
+RDEPENDS_lib${BPN} = ${PN}
LEAD_SONAME = libgamin-1.so
diff --git a/meta/recipes-support/attr/ea-acl.inc
b/meta/recipes-support/attr/ea-acl.inc
index 9af5960..4e79421 100644
--- a/meta/recipes-support/attr/ea-acl.inc
+++ b/meta/recipes-support/attr/ea-acl.inc
@@ -16,7 +16,7 @@ do_install () {
oe_runmake install install-lib install-dev DIST_ROOT=${D}
}
-PACKAGES =+ lib${PN} lib${PN}-dev lib${PN}-doc
+PACKAGES =+ lib${BPN} lib${BPN}-dev lib${BPN}-doc
FILES_lib${PN} = ${base_libdir}/lib*.so.*
diff --git a/meta/recipes-support/sqlite/sqlite3.inc
b/meta/recipes-support/sqlite/sqlite3.inc
index a5d122d..c96c6a6 100644
--- a/meta/recipes-support/sqlite/sqlite3.inc
+++ b/meta/recipes-support/sqlite/sqlite3.inc
@@ -17,12 +17,12 @@ export config_TARGET_LINK = ${CCLD}
export config_TARGET_CFLAGS = ${CFLAGS}
export config_TARGET_LFLAGS = ${LDFLAGS}
-PACKAGES = lib${PN} lib${PN}-dev lib${PN}-doc ${PN} ${PN}-dbg
+PACKAGES = lib${BPN} lib${BPN}-dev lib${BPN}-doc ${PN} ${PN}-dbg
FILES_${PN} = ${bindir}/*
FILES_lib${PN} = ${libdir}/*.so.*
FILES_lib${PN}-dev = ${libdir}/*.a ${libdir}/*.la ${libdir}/*.so \
${libdir}/pkgconfig ${includedir}
-FILES_lib${PN}-doc = ${docdir} ${mandir} ${infodir}
-AUTO_LIBNAME_PKGS = lib${PN}
+FILES_lib${BPN}-doc = ${docdir} ${mandir} ${infodir}
+AUTO_LIBNAME_PKGS = lib${BPN}
BBCLASSEXTEND = native nativesdk
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 6/7] package_rpm: fix strip_multilib function
The previous logic could only strip MLPREFIX from the first element in
an array, take an example, strip_multilib the [lib32-a lib32-b lib32-c]
will result in [a lib32-b lib32-c]. This commit change it to strip all
elements' multilib prefix.
CC: Mark Hatle mark.ha...@windriver.com
Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
meta/classes/package_rpm.bbclass |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index 9d0eeba..a29ce9d 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -326,7 +326,7 @@ python write_specfile () {
for ext in multilibs.split():
eext = ext.split(':')
if len(eext) 1 and eext[0] == 'multilib' and name and
name.find(eext[1] + '-') == 0:
- name = (eext[1] + '-').join(name.split(eext[1]
+ '-', 1)[1:])
+ name = .join(name.split(eext[1] + '-')[1:])
return name
# ml = bb.data.getVar(MLPREFIX, d, True)
@@ -720,7 +720,7 @@ python do_package_rpm () {
def strip_multilib(name, d):
ml = bb.data.getVar(MLPREFIX, d, True)
if ml and name and len(ml) != 0 and name.find(ml) == 0:
- return ml.join(name.split(ml, 1)[1:])
+ return .join(name.split(ml)[1:])
return name
workdir = bb.data.getVar('WORKDIR', d, True)
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libproxy: utilize base_libdir when configured
Pass $base_libdir through when we configure to support a location other
than /lib.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
meta/recipes-support/libproxy/libproxy_0.4.6.bb |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-support/libproxy/libproxy_0.4.6.bb
b/meta/recipes-support/libproxy/libproxy_0.4.6.bb
index b24e8ba..8d9a332 100644
--- a/meta/recipes-support/libproxy/libproxy_0.4.6.bb
+++ b/meta/recipes-support/libproxy/libproxy_0.4.6.bb
@@ -14,12 +14,12 @@ SRC_URI =
http://libproxy.googlecode.com/files/libproxy-${PV}.tar.gz;
SRC_URI[md5sum] = 199c6b120baf1f7258a55f38d5ec74f5
SRC_URI[sha256sum] =
9ad912e63b1efca98fb442240a2bc7302e6021c1d0b1b9363327729f29462f30
-PR = r1
+PR = r2
inherit cmake pkgconfig
EXTRA_OECMAKE = -DWITH_WEBKIT=no -DWITH_GNOME=yes -DWITH_KDE4=no \
- -DWITH_PYTHON=no -DWITH_PERL=no -DWITH_MOZJS=no -DWITH_NM=no
+ -DWITH_PYTHON=no -DWITH_PERL=no -DWITH_MOZJS=no -DWITH_NM=no
-DLIB_INSTALL_DIR=${base_libdir}
FILES_${PN}-dbg += ${libdir}/libproxy/${PV}/plugins/.debug/
${libdir}/libproxy/${PV}/modules/.debug/
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] libnss-mdns: dont use hard coded /lib path
As libdir might not be /lib (could be /lib64) use ${base_libdir} instead of
hard coded /lib in configure options set in EXTRA_OECONF.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
* Use $base_libdir per feedback
.../libnss-mdns/libnss-mdns_0.10.bb|4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb
b/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb
index f5df005..5f614f8 100644
--- a/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb
+++ b/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
file://LICENSE;md5=2d5025d4aa3495befef8f17206a5b0a1
DEPENDS = avahi
RDEPENDS_${PN} = avahi-daemon
-PR = r2
+PR = r3
SRC_URI = http://0pointer.de/lennart/projects/nss-mdns/nss-mdns-${PV}.tar.gz;
@@ -21,7 +21,7 @@ inherit autotools
LEAD_SONAME = libnss_mdns.so
DEBIANNAME_${PN} = libnss-mdns
-EXTRA_OECONF = --libdir=/lib --disable-lynx --enable-avahi
+EXTRA_OECONF = --libdir=${base_libdir} --disable-lynx --enable-avahi
# TODO: pattern based configuration update
pkg_postinst_${PN} () {
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/7][PULL] Multilib: various fixes
On 8/3/11 10:19 AM, Dongxiao Xu wrote:
Hi Richard,
This pull request contains several multilib fixes, especially for rpm side.
Please help to review and pull.
Current status for rpm sato is, most of the error dependency issues have been
solved except one error while do_rootfs:
error: Failed dependencies:
/bin/sh is needed by dbus-1.4.12-r0.x86_64
/bin/sh is needed by psplash-0.0+svnr424-r6.x86_64
/bin/sh is needed by portmap-6.0-r7.x86_64
/bin/sh is needed by dropbear-0.52-r3.x86_64
...
I am looking into that currently. Any suggestion would be appreciated.
The issue is due to nothing providing /bin/sh currently. /bin/sh is provide via
the alternatives mechanism, we need a way to use this mechanism to tell RPM the
required component is available. (A discussion is already going on within the
oe-core mailing list, topic is [PATCH 5/5] update-alternatives: Add
alternatives as a runtime provide.
Thanks,
Dongxiao
The following changes since commit 07864a16baf18046b726ec72b688594a91c6e4b4:
local.conf.sample: Fix TUNENAME reference (should be DEFAULTTUNE)
(2011-08-02 14:40:54 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib dxu4/ml
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dxu4/ml
Dongxiao Xu (7):
eglibc-locale: Specially handle FILES_eglibc-gconv for multilib
libxml-simple-perl: Use BBCLASSEXTEND insteand of *-native recipe
openjade-native: Change RDEPENDS of sgml-common-native
multilib: Use BPN instead of PN for style like lib${PN}
multilib: remove MULTILIB_PACKAGE_ARCHS variable
package_rpm: fix strip_multilib function
package_rpm: Fix package rename issue in multilib case
meta/classes/libc-package.bbclass |2 +-
meta/classes/package_rpm.bbclass | 31
+++-
meta/classes/populate_sdk_rpm.bbclass |3 --
meta/classes/rootfs_rpm.bbclass|3 --
meta/recipes-core/eglibc/eglibc-locale.inc |5 ++-
.../openjade/openjade-native_1.3.2.bb |2 +-
.../perl/libxml-simple-perl-native_2.18.bb |7
.../perl/libxml-simple-perl_2.18.bb|2 +
meta/recipes-devtools/python/python_2.6.6.bb |4 +-
meta/recipes-extended/augeas/augeas.inc| 12
meta/recipes-extended/gamin/gamin_0.1.10.bb|8 ++--
meta/recipes-support/attr/ea-acl.inc |2 +-
meta/recipes-support/sqlite/sqlite3.inc|6 ++--
13 files changed, 35 insertions(+), 52 deletions(-)
delete mode 100644
meta/recipes-devtools/perl/libxml-simple-perl-native_2.18.bb
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 5/7] multilib: remove MULTILIB_PACKAGE_ARCHS variable
On 8/3/11 10:19 AM, Dongxiao Xu wrote:
multilib package and normal package shares the same architecture deploy
folder, thus we do not need the ${MULTILIB_PACKAGE_ARCHS}.
This is incorrect behavior, at least for RPM. The folder should have the
pkgarch specific to the tuning used to generate the multilib. (Behavior may be
correct for deb/ipk.)
(If RPM sees two packages with the same .arch, it assumes that it's an upgrade
operation. If the .arch is different then it goes into the multilib mode and
will be able to install both packages together, assuming the conflict resolution
results in a working -- non-conflicting -- install solution.)
--Mark
CC: Mark Hatle mark.ha...@windriver.com
Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
meta/classes/package_rpm.bbclass | 13 ++---
meta/classes/populate_sdk_rpm.bbclass |3 ---
meta/classes/rootfs_rpm.bbclass |3 ---
3 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/meta/classes/package_rpm.bbclass
b/meta/classes/package_rpm.bbclass
index abedc68..9d0eeba 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -27,8 +27,7 @@ package_update_index_rpm () {
# Update target packages
base_archs=${PACKAGE_ARCHS}
- ml_archs=${MULTILIB_PACKAGE_ARCHS}
- package_update_index_rpm_common ${RPMCONF_TARGET_BASE} base_archs
ml_archs
+ package_update_index_rpm_common ${RPMCONF_TARGET_BASE} base_archs
# Update SDK packages
base_archs=${SDK_PACKAGE_ARCHS}
@@ -76,7 +75,7 @@ package_update_index_rpm_common () {
#
package_generate_rpm_conf () {
# Update target packages
- package_generate_rpm_conf_common ${RPMCONF_TARGET_BASE} base_archs
ml_archs
+ package_generate_rpm_conf_common ${RPMCONF_TARGET_BASE} base_archs
# Update SDK packages
package_generate_rpm_conf_common ${RPMCONF_HOST_BASE} base_archs
@@ -203,10 +202,6 @@ package_install_internal_rpm () {
archvar=base_archs
ml_pkg=$(echo ${pkg} | sed
s,^${MLPREFIX}\(.*\),\1,)
- if [ ${ml_pkg} != ${pkg} ]; then
- archvar=ml_archs
- fi
-
pkg_name=$(resolve_package_rpm
${confbase}-${archvar}.conf ${ml_pkg})
if [ -z $pkg_name ]; then
echo Unable to find package $pkg
($ml_pkg)!
@@ -223,10 +218,6 @@ package_install_internal_rpm () {
archvar=base_archs
ml_pkg=$(echo ${pkg} | sed s,^${MLPREFIX}\(.*\),\1,)
- if [ ${ml_pkg} != ${pkg} ]; then
- archvar=ml_archs
- fi
-
pkg_name=$(resolve_package_rpm
${confbase}-${archvar}.conf ${ml_pkg})
if [ -z $pkg_name ]; then
echo Unable to find package $pkg ($ml_pkg)!
diff --git a/meta/classes/populate_sdk_rpm.bbclass
b/meta/classes/populate_sdk_rpm.bbclass
index 5fb0234..f33e4a9 100644
--- a/meta/classes/populate_sdk_rpm.bbclass
+++ b/meta/classes/populate_sdk_rpm.bbclass
@@ -115,7 +115,6 @@ EOF
}
python () {
-ml_package_archs =
multilibs = d.getVar('MULTILIBS', True) or
for ext in multilibs.split():
eext = ext.split(':')
@@ -125,8 +124,6 @@ python () {
localdata.setVar(OVERRIDES, overrides)
# TEMP: OVERRIDES isn't working right
localdata.setVar(DEFAULTTUNE,
localdata.getVar(DEFAULTTUNE_virtclass-multilib- + eext[1], False) or )
-ml_package_archs += localdata.getVar(PACKAGE_ARCHS, True) or
#bb.note(ML_PACKAGE_ARCHS %s %s %s % (eext[1],
localdata.getVar(PACKAGE_ARCHS, True) or (none), overrides))
-bb.data.setVar('MULTILIB_PACKAGE_ARCHS', ml_package_archs, d)
}
diff --git a/meta/classes/rootfs_rpm.bbclass b/meta/classes/rootfs_rpm.bbclass
index 7c06064..c188d27 100644
--- a/meta/classes/rootfs_rpm.bbclass
+++ b/meta/classes/rootfs_rpm.bbclass
@@ -209,7 +209,6 @@ python () {
bb.data.setVar('RPM_PREPROCESS_COMMANDS', '', d)
bb.data.setVar('RPM_POSTPROCESS_COMMANDS', '', d)
-ml_package_archs =
multilibs = d.getVar('MULTILIBS', True) or
for ext in multilibs.split():
eext = ext.split(':')
@@ -219,7 +218,5 @@ python () {
localdata.setVar(OVERRIDES, overrides)
# TEMP: OVERRIDES isn't working right
localdata.setVar(DEFAULTTUNE,
localdata.getVar(DEFAULTTUNE_virtclass-multilib- + eext[1], False) or )
-ml_package_archs += localdata.getVar(PACKAGE_ARCHS, True) or
#bb.note(ML_PACKAGE_ARCHS %s %s %s % (eext[1],
localdata.getVar(PACKAGE_ARCHS, True) or (none), overrides))
-bb.data.setVar('MULTILIB_PACKAGE_ARCHS',
Re: [OE-core] [PATCH 6/7] package_rpm: fix strip_multilib function
On 8/3/11 10:19 AM, Dongxiao Xu wrote:
The previous logic could only strip MLPREFIX from the first element in
an array, take an example, strip_multilib the [lib32-a lib32-b lib32-c]
will result in [a lib32-b lib32-c]. This commit change it to strip all
elements' multilib prefix.
CC: Mark Hatle mark.ha...@windriver.com
Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
meta/classes/package_rpm.bbclass |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/package_rpm.bbclass
b/meta/classes/package_rpm.bbclass
index 9d0eeba..a29ce9d 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -326,7 +326,7 @@ python write_specfile () {
for ext in multilibs.split():
eext = ext.split(':')
if len(eext) 1 and eext[0] == 'multilib' and name and
name.find(eext[1] + '-') == 0:
- name = (eext[1] + '-').join(name.split(eext[1]
+ '-', 1)[1:])
+ name = .join(name.split(eext[1] + '-')[1:])
This looks incorrect to me, with the .join, it's going to join multiple
elements with a whitespace between them. The original code was written to work
on one item at a time within the list of multilibs.
How well has this been tested? Since I don't have all of the context this very
well might be correct within the current scope of the multilib implementation.
return name
#ml = bb.data.getVar(MLPREFIX, d, True)
@@ -720,7 +720,7 @@ python do_package_rpm () {
def strip_multilib(name, d):
ml = bb.data.getVar(MLPREFIX, d, True)
if ml and name and len(ml) != 0 and name.find(ml) == 0:
- return ml.join(name.split(ml, 1)[1:])
+ return .join(name.split(ml)[1:])
return name
workdir = bb.data.getVar('WORKDIR', d, True)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 5/5] update-alternatives: Add alternatives as a runtime provide
On Wed, 2011-08-03 at 09:41 -0500, Mark Hatle wrote:
On 8/3/11 7:20 AM, Richard Purdie wrote:
On Tue, 2011-08-02 at 09:49 -0500, Mark Hatle wrote:
On 8/2/11 8:46 AM, Phil Blundell wrote:
On Mon, 2011-08-01 at 19:17 -0500, Mark Hatle wrote:
The following allows RPM to generate the SDK image, however without it
we get a failure because the system has nothing that provides /bin/sh.
Unfortunately the patch causes failures with ipk and deb packages because
they can not have filenames within their RPROVIDES. I'm looking for some
type of a resolution to the issue, the only thing I can think of is to
add a way to manually add a FILERPROVIDE for the items. This will
require
changes to the way FILERPROVIDE is currently generated... but I'm not
sure
how we can automatically generate the FILERPROVIDE values without the
use of
python...
Any suggestions?
It's never really been the intent that update-alternatives should put
the name of the link being provided into RPROVIDES. If you want to
solve the specific problem with /bin/sh then just adding RPROVIDES_${PN}
+= virtual-bourne-shell or something to bash and busybox is probably
the easiest way of doing that.
I wouldn't be entirely opposed to the concept of what you're proposing
here, though. Something like:
RPROVIDES_${PN} += ${@' '.join(map(lambda x:
legitimize_package_name(virtual-path- + x), filter(lambda x: x != '',
[ d.getVar('ALTERNATIVE_LINK', True) or '' ] +
(d.getVar('ALTERNATIVE_LINKS', True) or '').split(}
might be what you want, perhaps. I'm not sure that the resulting
virtual names will be very pretty though.
Hmm.. Coming from the RPM world, the virtual-path- because we can't just
provide a file in the system seems a bit wonky to me. But it should be
able
to work. For RPM at least, we'd want a reversing function to turn virtual
paths
back into real paths.
If I have time today, I'll try to implement a proof of concept and see if
I can
get it to work reasonably well.
Just to be clear for Phil's benefit, RPM natively supports file based
dependencies, so a dependency of /bin/sh is automatically fulfilled by
a package which contains /bin/sh. Some dependencies such as the
shebang in scripts are automatically added to packages and resolved by
rpm.
I did chase down this bug a bit and it seems that if you bitbake
meta-toolchain-game you hit an error about /bin/sh being missing but if
you bitbake busybox; bitbake meta-toolchain-gmae it will work. This is
due to busybox shipping a /bin/sh.
The question is therefore how to handle this on the deb/ipk side and
ensure we get consistency between the behaviours of the different
backends. I thought with the rpm filedeps code in do_package, we were
adding things like /bin/sh dependencies to the other package formats but
now I'm not so sure.
Due to deb/ipk not handling file based dependencies, they are filtered out on
the creation of the deb/ipk packages. The original intention was to use them,
but it wasn't possible at the time. Simply adding a ton of file-based
dependencies seemed like a huge mistake as well. (We'd have to add virtual
provides for all of the virtual requirements)
We could certainly select a few specific requirements and scan for and use
those
to catch obvious issues, such as perl, sh, bash, env/python... but it's still
only a partial solution to the real issue.
Short term I'm tempted to buy us some time and do this (rpm specific):
package_rpm: Ensure alternatives links are reflected in rpm package dependencies
Currently, if a file is provided as an alternative link within the package, rpm
doesn't see the dependency. This works out badly for dependencies such as
/bin/sh
which scripts might require.
Since rpm detects and adds these dependencies we do need to ensure the
dependency
information in the packages is correct. This patch does so for the rpm backend
ensuring internal consistency whilst the approach for addressing this problem in
the other package backends is considered.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index abedc68..c44fdcc 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -501,6 +501,10 @@ python write_specfile () {
splitrconflicts = bb.data.getVar('RCONFLICTS', localdata,
True) or
splitrobsoletes = []
+ # For now we need to manually supplement RPROVIDES with any
update-alternatives links
+ if pkg == d.getVar(PN, True):
+ splitrprovides = splitrprovides +
(d.getVar('ALTERNATIVE_LINK', True) or '') + (d.getVar('ALTERNATIVE_LINKS',
True) or '')
+
# Gather special src/first package data
if srcname == splitname:
srcrdepends=
[OE-core] [PATCH] tcl: Fix packaging of platform independent files
Tcl's doesn't utilize ${baselib} for platform independent files but
defines it as follows:
TCL_LIBRARY = $(prefix)/lib/tcl$(VERSION)
Match that so if ${baselib} is not just /lib things work properly.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
meta/recipes-devtools/tcltk/tcl_8.5.9.bb |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/tcltk/tcl_8.5.9.bb
b/meta/recipes-devtools/tcltk/tcl_8.5.9.bb
index 12e2bd0..2eabb4d 100644
--- a/meta/recipes-devtools/tcltk/tcl_8.5.9.bb
+++ b/meta/recipes-devtools/tcltk/tcl_8.5.9.bb
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM =
file://../license.terms;md5=a47a9be26d03f925fc1fbd2784f27e11
file://../win/license.terms;md5=a47a9be26d03f925fc1fbd2784f27e11 \
-PR = r0
+PR = r1
BASE_SRC_URI = ${SOURCEFORGE_MIRROR}/tcl/tcl${PV}-src.tar.gz \
file://tcl-add-soname.patch
@@ -59,7 +59,7 @@ do_install() {
PACKAGES =+ ${PN}-lib
FILES_${PN}-lib = ${libdir}/libtcl8.5.so*
-FILES_${PN} += ${libdir}/tcl8.5
+FILES_${PN} += ${prefix}/lib/tcl8.5
FILES_${PN}-dev += ${libdir}/tclConfig.sh
BBCLASSEXTEND = native
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gcc: Fix setting of GLIBC_DYNAMIC_LINKER
From: Kumar Gala ga...@kernel.crashing.org
The sed regex in do_configure_prepend was producing the following result:
#define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR /lib64/ld-linux-x86-64.so.2
instead of removing the leading /lib or /lib64.
Now we have it do:
#define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR ld-linux-x86-64.so.2
Additionally, with the regex fixed the manipulation of SYSTEMLIBS_DIR
needs to be removed.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
Signed-off-by: Khem Raj raj.k...@gmail.com
---
meta/recipes-devtools/gcc/gcc-4.6.inc |2 +-
meta/recipes-devtools/gcc/gcc-configure-common.inc | 12
meta/recipes-devtools/gcc/gcc_4.5.1.bb |2 +-
meta/recipes-devtools/gcc/gcc_csl-arm-2008q1.bb|2 +-
4 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc
b/meta/recipes-devtools/gcc/gcc-4.6.inc
index 6956677..7d8170c 100644
--- a/meta/recipes-devtools/gcc/gcc-4.6.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
@@ -1,6 +1,6 @@
require gcc-common.inc
-PR = r2
+PR = r3
# Third digit in PV should be incremented after a minor release
# happens from this branch on gcc e.g. currently its 4.6.0
diff --git a/meta/recipes-devtools/gcc/gcc-configure-common.inc
b/meta/recipes-devtools/gcc/gcc-configure-common.inc
index 9f5ba33..869d1b6 100644
--- a/meta/recipes-devtools/gcc/gcc-configure-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-configure-common.inc
@@ -64,11 +64,15 @@ SYSTEMLIBS1 = ${target_libdir}/
do_configure_prepend () {
# Change the default dynamic linker path, only useful for SDK, other's
value
# are not changed according to the SYSTEMLIBS_DIR
+ #
+ # We want something like the following:
+ # #define GLIBC_DYNAMIC_LINKER64 /lib64/ld-linux-x86-64.so.2
+ # becomes
+ # #define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR
ld-linux-x86-64.so.2
+ #
sed -i ${S}/gcc/config/*/linux*.h -e \
- 's#\(GLIBC_DYNAMIC_LINKER[^ ]*\)\( */lib.*\)#\1
SYSTEMLIBS_DIR\2#'
+ 's#\(GLIBC_DYNAMIC_LINKER[^ ]*\) \( */lib.*\)/\(.*\)#\1
SYSTEMLIBS_DIR \3#'
- SYSTEMLIBS_DIR=`dirname ${SYSTEMLIBS}`
- [ $SYSTEMLIBS_DIR = / ] SYSTEMLIBS_DIR=
# teach gcc to find correct target includedir when checking libc ssp
support
mkdir -p ${B}/gcc
echo NATIVE_SYSTEM_HEADER_DIR = ${SYSTEMHEADERS} ${B}/gcc/t-oe
@@ -83,7 +87,7 @@ do_configure_prepend () {
#ifndef STANDARD_STARTFILE_PREFIX_2
#define STANDARD_STARTFILE_PREFIX_2 ${SYSTEMLIBS1}
#endif
-#define SYSTEMLIBS_DIR $SYSTEMLIBS_DIR
+#define SYSTEMLIBS_DIR ${SYSTEMLIBS}
#endif /* ! GCC_DEFAULTS_H */
_EOF
mv ${B}/gcc/defaults.h.new ${B}/gcc/defaults.h
diff --git a/meta/recipes-devtools/gcc/gcc_4.5.1.bb
b/meta/recipes-devtools/gcc/gcc_4.5.1.bb
index 12e42c4..f036cb1 100644
--- a/meta/recipes-devtools/gcc/gcc_4.5.1.bb
+++ b/meta/recipes-devtools/gcc/gcc_4.5.1.bb
@@ -1,4 +1,4 @@
-PR = r7
+PR = r8
require gcc-${PV}.inc
require gcc-configure-target.inc
require gcc-package-target.inc
diff --git a/meta/recipes-devtools/gcc/gcc_csl-arm-2008q1.bb
b/meta/recipes-devtools/gcc/gcc_csl-arm-2008q1.bb
index 2df12ef..9fd2b0a 100644
--- a/meta/recipes-devtools/gcc/gcc_csl-arm-2008q1.bb
+++ b/meta/recipes-devtools/gcc/gcc_csl-arm-2008q1.bb
@@ -1,4 +1,4 @@
-PR = r4
+PR = r5
require gcc-${PV}.inc
require gcc-configure-target.inc
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] help with gcc-configure-common bug
On 08/03/2011 05:50 AM, Kumar Gala wrote:
Ah, I can help here:)
We only have one gcc source checkout with the shared work directory.
Each multilib (or sdk build) needs to customise SYSTEMLIBS depending on
its configuration. This is why its being done in the defaults.h file in
${B} instead of files in ${S}.
We likely should do the substitutions in ${S} at unpack time to make
this clearer.
Cheers,
Richard
Post some patches to address this, so take a look.
I have reposted the same patch after testing. I can now boot x86_64 qemu
and all other qemu sato-images build fine too. Here is the reposted patch.
http://patches.openembedded.org/patch/9131/
Thanks
-Khem
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 5/5] update-alternatives: Add alternatives as a runtime provide
On 8/3/11 10:40 AM, Richard Purdie wrote:
On Wed, 2011-08-03 at 09:41 -0500, Mark Hatle wrote:
On 8/3/11 7:20 AM, Richard Purdie wrote:
On Tue, 2011-08-02 at 09:49 -0500, Mark Hatle wrote:
On 8/2/11 8:46 AM, Phil Blundell wrote:
On Mon, 2011-08-01 at 19:17 -0500, Mark Hatle wrote:
The following allows RPM to generate the SDK image, however without it
we get a failure because the system has nothing that provides /bin/sh.
Unfortunately the patch causes failures with ipk and deb packages because
they can not have filenames within their RPROVIDES. I'm looking for some
type of a resolution to the issue, the only thing I can think of is to
add a way to manually add a FILERPROVIDE for the items. This will
require
changes to the way FILERPROVIDE is currently generated... but I'm not
sure
how we can automatically generate the FILERPROVIDE values without the
use of
python...
Any suggestions?
It's never really been the intent that update-alternatives should put
the name of the link being provided into RPROVIDES. If you want to
solve the specific problem with /bin/sh then just adding RPROVIDES_${PN}
+= virtual-bourne-shell or something to bash and busybox is probably
the easiest way of doing that.
I wouldn't be entirely opposed to the concept of what you're proposing
here, though. Something like:
RPROVIDES_${PN} += ${@' '.join(map(lambda x:
legitimize_package_name(virtual-path- + x), filter(lambda x: x != '',
[ d.getVar('ALTERNATIVE_LINK', True) or '' ] +
(d.getVar('ALTERNATIVE_LINKS', True) or '').split(}
might be what you want, perhaps. I'm not sure that the resulting
virtual names will be very pretty though.
Hmm.. Coming from the RPM world, the virtual-path- because we can't just
provide a file in the system seems a bit wonky to me. But it should be
able
to work. For RPM at least, we'd want a reversing function to turn virtual
paths
back into real paths.
If I have time today, I'll try to implement a proof of concept and see if
I can
get it to work reasonably well.
Just to be clear for Phil's benefit, RPM natively supports file based
dependencies, so a dependency of /bin/sh is automatically fulfilled by
a package which contains /bin/sh. Some dependencies such as the
shebang in scripts are automatically added to packages and resolved by
rpm.
I did chase down this bug a bit and it seems that if you bitbake
meta-toolchain-game you hit an error about /bin/sh being missing but if
you bitbake busybox; bitbake meta-toolchain-gmae it will work. This is
due to busybox shipping a /bin/sh.
The question is therefore how to handle this on the deb/ipk side and
ensure we get consistency between the behaviours of the different
backends. I thought with the rpm filedeps code in do_package, we were
adding things like /bin/sh dependencies to the other package formats but
now I'm not so sure.
Due to deb/ipk not handling file based dependencies, they are filtered out on
the creation of the deb/ipk packages. The original intention was to use
them,
but it wasn't possible at the time. Simply adding a ton of file-based
dependencies seemed like a huge mistake as well. (We'd have to add virtual
provides for all of the virtual requirements)
We could certainly select a few specific requirements and scan for and use
those
to catch obvious issues, such as perl, sh, bash, env/python... but it's still
only a partial solution to the real issue.
Short term I'm tempted to buy us some time and do this (rpm specific):
package_rpm: Ensure alternatives links are reflected in rpm package
dependencies
Currently, if a file is provided as an alternative link within the package,
rpm
doesn't see the dependency. This works out badly for dependencies such as
/bin/sh
which scripts might require.
Since rpm detects and adds these dependencies we do need to ensure the
dependency
information in the packages is correct. This patch does so for the rpm backend
ensuring internal consistency whilst the approach for addressing this problem
in
the other package backends is considered.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/classes/package_rpm.bbclass
b/meta/classes/package_rpm.bbclass
index abedc68..c44fdcc 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -501,6 +501,10 @@ python write_specfile () {
splitrconflicts = bb.data.getVar('RCONFLICTS', localdata,
True) or
splitrobsoletes = []
+ # For now we need to manually supplement RPROVIDES with any
update-alternatives links
+ if pkg == d.getVar(PN, True):
+ splitrprovides = splitrprovides +
(d.getVar('ALTERNATIVE_LINK', True) or '') + (d.getVar('ALTERNATIVE_LINKS',
True) or '')
+
Will the + add a space in this case, otherwise we need additional spaces
added.
But this is a good solution to the issue. It's RPM
Re: [OE-core] [PATCH 5/5] update-alternatives: Add alternatives as a runtime provide
On Wed, 2011-08-03 at 11:03 -0500, Mark Hatle wrote:
On 8/3/11 10:40 AM, Richard Purdie wrote:
On Wed, 2011-08-03 at 09:41 -0500, Mark Hatle wrote:
On 8/3/11 7:20 AM, Richard Purdie wrote:
On Tue, 2011-08-02 at 09:49 -0500, Mark Hatle wrote:
On 8/2/11 8:46 AM, Phil Blundell wrote:
On Mon, 2011-08-01 at 19:17 -0500, Mark Hatle wrote:
The following allows RPM to generate the SDK image, however without it
we get a failure because the system has nothing that provides /bin/sh.
Unfortunately the patch causes failures with ipk and deb packages
because
they can not have filenames within their RPROVIDES. I'm looking for
some
type of a resolution to the issue, the only thing I can think of is to
add a way to manually add a FILERPROVIDE for the items. This will
require
changes to the way FILERPROVIDE is currently generated... but I'm not
sure
how we can automatically generate the FILERPROVIDE values without the
use of
python...
Any suggestions?
It's never really been the intent that update-alternatives should put
the name of the link being provided into RPROVIDES. If you want to
solve the specific problem with /bin/sh then just adding RPROVIDES_${PN}
+= virtual-bourne-shell or something to bash and busybox is probably
the easiest way of doing that.
I wouldn't be entirely opposed to the concept of what you're proposing
here, though. Something like:
RPROVIDES_${PN} += ${@' '.join(map(lambda x:
legitimize_package_name(virtual-path- + x), filter(lambda x: x != '',
[ d.getVar('ALTERNATIVE_LINK', True) or '' ] +
(d.getVar('ALTERNATIVE_LINKS', True) or '').split(}
might be what you want, perhaps. I'm not sure that the resulting
virtual names will be very pretty though.
Hmm.. Coming from the RPM world, the virtual-path- because we can't just
provide a file in the system seems a bit wonky to me. But it should
be able
to work. For RPM at least, we'd want a reversing function to turn
virtual paths
back into real paths.
If I have time today, I'll try to implement a proof of concept and see
if I can
get it to work reasonably well.
Just to be clear for Phil's benefit, RPM natively supports file based
dependencies, so a dependency of /bin/sh is automatically fulfilled by
a package which contains /bin/sh. Some dependencies such as the
shebang in scripts are automatically added to packages and resolved by
rpm.
I did chase down this bug a bit and it seems that if you bitbake
meta-toolchain-game you hit an error about /bin/sh being missing but if
you bitbake busybox; bitbake meta-toolchain-gmae it will work. This is
due to busybox shipping a /bin/sh.
The question is therefore how to handle this on the deb/ipk side and
ensure we get consistency between the behaviours of the different
backends. I thought with the rpm filedeps code in do_package, we were
adding things like /bin/sh dependencies to the other package formats but
now I'm not so sure.
Due to deb/ipk not handling file based dependencies, they are filtered out
on
the creation of the deb/ipk packages. The original intention was to use
them,
but it wasn't possible at the time. Simply adding a ton of file-based
dependencies seemed like a huge mistake as well. (We'd have to add virtual
provides for all of the virtual requirements)
We could certainly select a few specific requirements and scan for and use
those
to catch obvious issues, such as perl, sh, bash, env/python... but it's
still
only a partial solution to the real issue.
Short term I'm tempted to buy us some time and do this (rpm specific):
package_rpm: Ensure alternatives links are reflected in rpm package
dependencies
Currently, if a file is provided as an alternative link within the package,
rpm
doesn't see the dependency. This works out badly for dependencies such as
/bin/sh
which scripts might require.
Since rpm detects and adds these dependencies we do need to ensure the
dependency
information in the packages is correct. This patch does so for the rpm
backend
ensuring internal consistency whilst the approach for addressing this
problem in
the other package backends is considered.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/classes/package_rpm.bbclass
b/meta/classes/package_rpm.bbclass
index abedc68..c44fdcc 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -501,6 +501,10 @@ python write_specfile () {
splitrconflicts = bb.data.getVar('RCONFLICTS', localdata,
True) or
splitrobsoletes = []
+ # For now we need to manually supplement RPROVIDES with any
update-alternatives links
+ if pkg == d.getVar(PN, True):
+ splitrprovides = splitrprovides +
(d.getVar('ALTERNATIVE_LINK', True) or '') +
Re: [OE-core] [PATCH v2] gcc: Fix setting of GLIBC_DYNAMIC_LINKER
On Tue, 2011-08-02 at 17:33 -0500, Kumar Gala wrote: The sed regex in do_configure_prepend was producing the following result: #define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR /lib64/ld-linux-x86-64.so.2 instead of removing the leading /lib or /lib64. Now we have it do: #define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR ld-linux-x86-64.so.2 Additionally, with the regex fixed the manipulation of SYSTEMLIBS_DIR needs to be removed. Signed-off-by: Kumar Gala ga...@kernel.crashing.org Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Update intltool to set perl shebang correctly for installed tools
Several installed scripts set the perl shebang that is too long
which can cause failures on certian older bash versions.
Signed-off-by: Matthew McClintock m...@freescale.com
---
meta/recipes-devtools/intltool/intltool.inc |2 +-
meta/recipes-devtools/intltool/intltool_0.40.6.bb |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/intltool/intltool.inc
b/meta/recipes-devtools/intltool/intltool.inc
index c934654..d8917ad 100644
--- a/meta/recipes-devtools/intltool/intltool.inc
+++ b/meta/recipes-devtools/intltool/intltool.inc
@@ -12,5 +12,5 @@ RRECOMMENDS_${PN} = perl-modules
inherit autotools pkgconfig perlnative
-export PERL_virtclass-native = /usr/bin/env perl
+export PERL = /usr/bin/env perl
BBCLASSEXTEND = native
diff --git a/meta/recipes-devtools/intltool/intltool_0.40.6.bb
b/meta/recipes-devtools/intltool/intltool_0.40.6.bb
index c7938e5..8b52cf8 100644
--- a/meta/recipes-devtools/intltool/intltool_0.40.6.bb
+++ b/meta/recipes-devtools/intltool/intltool_0.40.6.bb
@@ -1,7 +1,7 @@
require intltool.inc
LICENSE=GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f
-PR = r3
+PR = r4
SRC_URI_append = file://intltool-nowarn-0.40.0.patch
--
1.7.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] libnss-mdns: dont use hard coded /lib path
On Wed, 2011-08-03 at 10:28 -0500, Kumar Gala wrote:
As libdir might not be /lib (could be /lib64) use ${base_libdir} instead of
hard coded /lib in configure options set in EXTRA_OECONF.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
* Use $base_libdir per feedback
Merged to master, thanks.
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] automake: Fix issue with tar configure failing with large UID/GIDs
On Tue, 2011-08-02 at 16:20 -0500, Kumar Gala wrote: Add a fixup for trying to create ustar archives when the users UID or GID is larger than the format allows. Signed-off-by: Tom Rini tom_r...@mentor.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- * Removed patch=1 * Fixed a few whitespace issues meta/recipes-devtools/automake/automake.inc|2 +- .../prefer-cpio-over-pax-for-ustar-archives.patch | 41 meta/recipes-devtools/automake/automake_1.11.1.bb |3 +- 3 files changed, 44 insertions(+), 2 deletions(-) create mode 100644 meta/recipes-devtools/automake/automake/prefer-cpio-over-pax-for-ustar-archives.patch Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] tune/arch-powerpc64: keep insync with arch-powerpc.inc
On Tue, 2011-08-02 at 16:00 -0500, Kumar Gala wrote:
On Aug 2, 2011, at 3:39 PM, Richard Purdie wrote:
On Tue, 2011-08-02 at 14:18 -0500, Kumar Gala wrote:
* Add DEFAULTTUNE setting
* Sync TUNE_PKGARCH with:
commit 20f285728219c1efcc23d8e861902c212893c68d
Author: Richard Purdie richard.pur...@linuxfoundation.org
Date: Tue Aug 2 12:40:06 2011 +0100
tune/ppc: Fix various TUNE_PKGARCH issues
Quick question, are all ppc64 cores ppc32 capable or not?
Cheers,
Richard
yes
Should we make the 64 bit include file automatically include the 32 bit
one then?
That would take care of the
+PPCPKGARCH = ${TUNE_ARCH}
+TUNE_PKGARCH ?= ${PPCPKGARCH}
part but we probably should set the DEFAULTTUNE still...
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] [PATCH] Update intltool to set perl shebang correctly for installed tools
On 2011-08-03 10:33, Matthew McClintock wrote:
Several installed scripts set the perl shebang that is too long
which can cause failures on certian older bash versions.
How does the change below correspond to this comment? It's not
clear [at least to me] how changing that environment variable
affects shebang constructs. Can you give a more thorough explanation?
Signed-off-by: Matthew McClintockm...@freescale.com
---
meta/recipes-devtools/intltool/intltool.inc |2 +-
meta/recipes-devtools/intltool/intltool_0.40.6.bb |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/intltool/intltool.inc
b/meta/recipes-devtools/intltool/intltool.inc
index c934654..d8917ad 100644
--- a/meta/recipes-devtools/intltool/intltool.inc
+++ b/meta/recipes-devtools/intltool/intltool.inc
@@ -12,5 +12,5 @@ RRECOMMENDS_${PN} = perl-modules
inherit autotools pkgconfig perlnative
-export PERL_virtclass-native = /usr/bin/env perl
+export PERL = /usr/bin/env perl
BBCLASSEXTEND = native
diff --git a/meta/recipes-devtools/intltool/intltool_0.40.6.bb
b/meta/recipes-devtools/intltool/intltool_0.40.6.bb
index c7938e5..8b52cf8 100644
--- a/meta/recipes-devtools/intltool/intltool_0.40.6.bb
+++ b/meta/recipes-devtools/intltool/intltool_0.40.6.bb
@@ -1,7 +1,7 @@
require intltool.inc
LICENSE=GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f
-PR = r3
+PR = r4
SRC_URI_append = file://intltool-nowarn-0.40.0.patch
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] image-mklibs.bbclass: Add powerpc64 arch support
On Wed, 2011-08-03 at 00:27 -0500, Kumar Gala wrote:
powerp64 dynamic loader is 'ld64.so.1'.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
* Use correct name of ppc64 dynamic loader
* user ${baselib} so if we are /lib or /lib64 things work
meta/classes/image-mklibs.bbclass |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/meta/classes/image-mklibs.bbclass
b/meta/classes/image-mklibs.bbclass
index 9f5a4ea..83f609c 100644
--- a/meta/classes/image-mklibs.bbclass
+++ b/meta/classes/image-mklibs.bbclass
@@ -19,6 +19,9 @@ mklibs_optimize_image_doit() {
powerpc | mips | microblaze )
dynamic_loader=/lib/ld.so.1
;;
+ powerpc64)
+ dynamic_loader=/${baselib}/ld64.so.1
+ ;;
x86_64)
dynamic_loader=/lib/ld-linux-x86-64.so.2
;;
Can we use ${base_libdir} there please?
${baselib} is really intended only for use to build the other
expressions.
We should probably use ${base_libdir} elsewhere in this file too. I also
suspect prelinking of a multilib image may need work :/.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] tune/arch-powerpc64: keep insync with arch-powerpc.inc
On Aug 3, 2011, at 11:49 AM, Richard Purdie wrote:
On Tue, 2011-08-02 at 16:00 -0500, Kumar Gala wrote:
On Aug 2, 2011, at 3:39 PM, Richard Purdie wrote:
On Tue, 2011-08-02 at 14:18 -0500, Kumar Gala wrote:
* Add DEFAULTTUNE setting
* Sync TUNE_PKGARCH with:
commit 20f285728219c1efcc23d8e861902c212893c68d
Author: Richard Purdie richard.pur...@linuxfoundation.org
Date: Tue Aug 2 12:40:06 2011 +0100
tune/ppc: Fix various TUNE_PKGARCH issues
Quick question, are all ppc64 cores ppc32 capable or not?
Cheers,
Richard
yes
Should we make the 64 bit include file automatically include the 32 bit
one then?
That would take care of the
+PPCPKGARCH = ${TUNE_ARCH}
+TUNE_PKGARCH ?= ${PPCPKGARCH}
part but we probably should set the DEFAULTTUNE still...
Not a bad idea, I'll look at doing that.
- k
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] tune/arch-powerpc: Use fpu-soft to set PPCPKGSFX_FPU
On Wed, 2011-08-03 at 00:28 -0500, Kumar Gala wrote:
Its more likely that we explicitly set soft-floating point support for a
given target than hard. So use 'fpu-soft' in TUNE_FEATURES rather than
'fpu-hard' to determine setting 'nf' (no-float) in PPCPKGSFX_FPU.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
* Removed setting of 'fpu-hard' from the tune files that it set
meta/conf/machine/include/powerpc/arch-powerpc.inc |2 +-
meta/conf/machine/include/tune-ppc603e.inc |2 +-
meta/conf/machine/include/tune-ppce500mc.inc |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc
b/meta/conf/machine/include/powerpc/arch-powerpc.inc
index da1a1d6..c073f18 100644
--- a/meta/conf/machine/include/powerpc/arch-powerpc.inc
+++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc
@@ -18,7 +18,7 @@ TARGET_FPU .= ${@bb.utils.contains(TUNE_FEATURES,
fpu-soft, soft, , d)}
ABIEXTENSION = ${@['','spe'][d.getVar('TARGET_FPU', True) in ['ppc-efd',
'ppc-efs']]}
-PPCPKGSFX_FPU = ${@bb.utils.contains(TUNE_FEATURES, fpu-hard , ,
-nf, d)}
+PPCPKGSFX_FPU = ${@bb.utils.contains(TUNE_FEATURES, fpu-soft, -nf,
, d)}
PPCPKGARCH = ${TUNE_ARCH}${PPCPKGSFX_FPU}
TUNE_PKGARCH ?= ${PPCPKGARCH}
diff --git a/meta/conf/machine/include/tune-ppc603e.inc
b/meta/conf/machine/include/tune-ppc603e.inc
I've remembered the issue here. Further up in that file we have:
TUNEVALID[fpu-hard] = Use hardware FPU.
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, fpu-hard,
-mhard-float, , d)}
TUNEVALID[fpu-soft] = Use software FPU.
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, fpu-soft,
-msoft-float, , d)}
further up in the file and there are optionally other float models
which some processors seemed to need to use. This meant you had to
specify which fpu option you wanted explicitly.
I'm open to better ways of handling this.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] scripts/oe-buildenv-internal: Add SOCKS5_{USER, PASSWD} to BB_ENV_EXTRAWHITE
On Jul 28, 2011, at 8:10 AM, Kumar Gala wrote: If a SOCKS5 gateway is needed for a proxy access like git it might also require authentication to the proxy via a password and username. Adding SOCKS5_USER SOCKS5_PASSWD to BB_ENV_EXTRAWHITE allow for automation of the authentication request to occur when something like a git fetch is going through the proxy. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- * Fixes issue with a git fetch request failing to get pass a firewall scripts/oe-buildenv-internal |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal index c13fc40..b223292 100755 --- a/scripts/oe-buildenv-internal +++ b/scripts/oe-buildenv-internal @@ -55,4 +55,4 @@ unset BITBAKEDIR export BUILDDIR export PATH -export BB_ENV_EXTRAWHITE=MACHINE DISTRO TCMODE TCLIBC http_proxy ftp_proxy https_proxy all_proxy ALL_PROXY no_proxy SSH_AGENT_PID SSH_AUTH_SOCK BB_SRCREV_POLICY SDKMACHINE BB_NUMBER_THREADS PARALLEL_MAKE GIT_PROXY_COMMAND +export BB_ENV_EXTRAWHITE=MACHINE DISTRO TCMODE TCLIBC http_proxy ftp_proxy https_proxy all_proxy ALL_PROXY no_proxy SSH_AGENT_PID SSH_AUTH_SOCK BB_SRCREV_POLICY SDKMACHINE BB_NUMBER_THREADS PARALLEL_MAKE GIT_PROXY_COMMAND SOCKS5_PASSWD SOCSK5_USER -- 1.7.3.4 Ping on this patch - k ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/7][PULL] Multilib: various fixes
On Wed, 2011-08-03 at 23:19 +0800, Dongxiao Xu wrote:
Hi Richard,
This pull request contains several multilib fixes, especially for rpm side.
Please help to review and pull.
Current status for rpm sato is, most of the error dependency issues have been
solved except one error while do_rootfs:
error: Failed dependencies:
/bin/sh is needed by dbus-1.4.12-r0.x86_64
/bin/sh is needed by psplash-0.0+svnr424-r6.x86_64
/bin/sh is needed by portmap-6.0-r7.x86_64
/bin/sh is needed by dropbear-0.52-r3.x86_64
...
I am looking into that currently. Any suggestion would be appreciated.
There should be a fix merged for that issue now :)
The following changes since commit 07864a16baf18046b726ec72b688594a91c6e4b4:
local.conf.sample: Fix TUNENAME reference (should be DEFAULTTUNE)
(2011-08-02 14:40:54 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib dxu4/ml
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dxu4/ml
Dongxiao Xu (7):
eglibc-locale: Specially handle FILES_eglibc-gconv for multilib
libxml-simple-perl: Use BBCLASSEXTEND insteand of *-native recipe
openjade-native: Change RDEPENDS of sgml-common-native
multilib: Use BPN instead of PN for style like lib${PN}
I've merged these.
multilib: remove MULTILIB_PACKAGE_ARCHS variable
package_rpm: fix strip_multilib function
package_rpm: Fix package rename issue in multilib case
These look like they need more discussion with Mark.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] tcl: Fix packaging of platform independent files
On Wed, 2011-08-03 at 10:43 -0500, Kumar Gala wrote:
Tcl's doesn't utilize ${baselib} for platform independent files but
defines it as follows:
TCL_LIBRARY = $(prefix)/lib/tcl$(VERSION)
Match that so if ${baselib} is not just /lib things work properly.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
meta/recipes-devtools/tcltk/tcl_8.5.9.bb |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Merged to master, thanks.
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] scripts/oe-buildenv-internal: Add SOCKS5_{USER, PASSWD} to BB_ENV_EXTRAWHITE
On 08/03/2011 10:00 AM, Kumar Gala wrote: On Jul 28, 2011, at 8:10 AM, Kumar Gala wrote: If a SOCKS5 gateway is needed for a proxy access like git it might also require authentication to the proxy via a password and username. Adding SOCKS5_USER SOCKS5_PASSWD to BB_ENV_EXTRAWHITE allow for automation of the authentication request to occur when something like a git fetch is going through the proxy. Signed-off-by: Kumar Galaga...@kernel.crashing.org --- * Fixes issue with a git fetch request failing to get pass a firewall scripts/oe-buildenv-internal |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal index c13fc40..b223292 100755 --- a/scripts/oe-buildenv-internal +++ b/scripts/oe-buildenv-internal @@ -55,4 +55,4 @@ unset BITBAKEDIR export BUILDDIR export PATH -export BB_ENV_EXTRAWHITE=MACHINE DISTRO TCMODE TCLIBC http_proxy ftp_proxy https_proxy all_proxy ALL_PROXY no_proxy SSH_AGENT_PID SSH_AUTH_SOCK BB_SRCREV_POLICY SDKMACHINE BB_NUMBER_THREADS PARALLEL_MAKE GIT_PROXY_COMMAND +export BB_ENV_EXTRAWHITE=MACHINE DISTRO TCMODE TCLIBC http_proxy ftp_proxy https_proxy all_proxy ALL_PROXY no_proxy SSH_AGENT_PID SSH_AUTH_SOCK BB_SRCREV_POLICY SDKMACHINE BB_NUMBER_THREADS PARALLEL_MAKE GIT_PROXY_COMMAND SOCKS5_PASSWD SOCSK5_USER -- 1.7.3.4 Ping on this patch Kumar, I think you were asked to modify this patch so that the additinal SOCKS5_* do not get into sstate, Paul Eggleton provided the BB_HASHSPACE_WHITELIST info. Please update this patch Thanks Sau! - k ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libproxy: utilize base_libdir when configured
On 08/03/2011 08:26 AM, Kumar Gala wrote:
Pass $base_libdir through when we configure to support a location other
than /lib.
Signed-off-by: Kumar Galaga...@kernel.crashing.org
---
meta/recipes-support/libproxy/libproxy_0.4.6.bb |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-support/libproxy/libproxy_0.4.6.bb
b/meta/recipes-support/libproxy/libproxy_0.4.6.bb
index b24e8ba..8d9a332 100644
--- a/meta/recipes-support/libproxy/libproxy_0.4.6.bb
+++ b/meta/recipes-support/libproxy/libproxy_0.4.6.bb
@@ -14,12 +14,12 @@ SRC_URI =
http://libproxy.googlecode.com/files/libproxy-${PV}.tar.gz;
SRC_URI[md5sum] = 199c6b120baf1f7258a55f38d5ec74f5
SRC_URI[sha256sum] =
9ad912e63b1efca98fb442240a2bc7302e6021c1d0b1b9363327729f29462f30
-PR = r1
+PR = r2
inherit cmake pkgconfig
EXTRA_OECMAKE = -DWITH_WEBKIT=no -DWITH_GNOME=yes -DWITH_KDE4=no \
- -DWITH_PYTHON=no -DWITH_PERL=no -DWITH_MOZJS=no -DWITH_NM=no
+ -DWITH_PYTHON=no -DWITH_PERL=no -DWITH_MOZJS=no -DWITH_NM=no
-DLIB_INSTALL_DIR=${base_libdir}
Should this be ${base_libdir} as in /lib* or ${libdir} as in /usr/lib*?
I think libproxy should be installed to the ${libdir}
FILES_${PN}-dbg += ${libdir}/libproxy/${PV}/plugins/.debug/
${libdir}/libproxy/${PV}/modules/.debug/
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] systemd-gnome-image do_rootfs failure
On Tue, Aug 2, 2011 at 10:00 PM, Joel A Fernandes agnel.j...@gmail.com wrote: Hi, I now get a build error as below with systemd-gnome-image in do_rootfs, could you take a look? I did a clean rebuild of a few packages like: font-util, mesa-dri and shadow, opkg-cl now doesn't show those errors anymore. Thanks, Joel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] tcl: Fix packaging of platform independent files
On Wed, Aug 3, 2011 at 8:43 AM, Kumar Gala ga...@kernel.crashing.org wrote:
Tcl's doesn't utilize ${baselib} for platform independent files but
defines it as follows:
TCL_LIBRARY Â Â Â Â Â Â = $(prefix)/lib/tcl$(VERSION)
Match that so if ${baselib} is not just /lib things work properly.
hmm may be fixing tcl to honour --libdir=dir to generate TCL_LIBRARY
from configure would be a nice solution
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
 meta/recipes-devtools/tcltk/tcl_8.5.9.bb |   4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/tcltk/tcl_8.5.9.bb
b/meta/recipes-devtools/tcltk/tcl_8.5.9.bb
index 12e2bd0..2eabb4d 100644
--- a/meta/recipes-devtools/tcltk/tcl_8.5.9.bb
+++ b/meta/recipes-devtools/tcltk/tcl_8.5.9.bb
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM =
file://../license.terms;md5=a47a9be26d03f925fc1fbd2784f27e11
  file://../win/license.terms;md5=a47a9be26d03f925fc1fbd2784f27e11 \
 Â
-PR = r0
+PR = r1
 BASE_SRC_URI = ${SOURCEFORGE_MIRROR}/tcl/tcl${PV}-src.tar.gz \
        file://tcl-add-soname.patch
@@ -59,7 +59,7 @@ do_install() {
 PACKAGES =+ ${PN}-lib
 FILES_${PN}-lib = ${libdir}/libtcl8.5.so*
-FILES_${PN} += ${libdir}/tcl8.5
+FILES_${PN} += ${prefix}/lib/tcl8.5
 FILES_${PN}-dev += ${libdir}/tclConfig.sh
 BBCLASSEXTEND = native
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] scripts/oe-buildenv-internal: Add SOCKS5_{USER, PASSWD} to BB_ENV_EXTRAWHITE
On Aug 3, 2011, at 12:30 PM, Saul Wold wrote: On 08/03/2011 10:00 AM, Kumar Gala wrote: On Jul 28, 2011, at 8:10 AM, Kumar Gala wrote: If a SOCKS5 gateway is needed for a proxy access like git it might also require authentication to the proxy via a password and username. Adding SOCKS5_USER SOCKS5_PASSWD to BB_ENV_EXTRAWHITE allow for automation of the authentication request to occur when something like a git fetch is going through the proxy. Signed-off-by: Kumar Galaga...@kernel.crashing.org --- * Fixes issue with a git fetch request failing to get pass a firewall scripts/oe-buildenv-internal |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal index c13fc40..b223292 100755 --- a/scripts/oe-buildenv-internal +++ b/scripts/oe-buildenv-internal @@ -55,4 +55,4 @@ unset BITBAKEDIR export BUILDDIR export PATH -export BB_ENV_EXTRAWHITE=MACHINE DISTRO TCMODE TCLIBC http_proxy ftp_proxy https_proxy all_proxy ALL_PROXY no_proxy SSH_AGENT_PID SSH_AUTH_SOCK BB_SRCREV_POLICY SDKMACHINE BB_NUMBER_THREADS PARALLEL_MAKE GIT_PROXY_COMMAND +export BB_ENV_EXTRAWHITE=MACHINE DISTRO TCMODE TCLIBC http_proxy ftp_proxy https_proxy all_proxy ALL_PROXY no_proxy SSH_AGENT_PID SSH_AUTH_SOCK BB_SRCREV_POLICY SDKMACHINE BB_NUMBER_THREADS PARALLEL_MAKE GIT_PROXY_COMMAND SOCKS5_PASSWD SOCSK5_USER -- 1.7.3.4 Ping on this patch Kumar, I think you were asked to modify this patch so that the additinal SOCKS5_* do not get into sstate, Paul Eggleton provided the BB_HASHSPACE_WHITELIST info. Please update this patch Thanks Sau! From the thread it sounded as if that was NOT needed. As nothing refers to SOCKS5_* we didn't need to add it. Much like how it doesn't have SSH_AGENT_PID or SSH_AUTH_SOCK in it. - k ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] libmusicbrainz: utilize base_libdir when configured
Pass $libdir through when we configure to support a location
other than /lib.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
* Make it libdir instead of base_libdir
.../musicbrainz/libmusicbrainz_3.0.3.bb|4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-multimedia/musicbrainz/libmusicbrainz_3.0.3.bb
b/meta/recipes-multimedia/musicbrainz/libmusicbrainz_3.0.3.bb
index d6fb2f4..6331452 100644
--- a/meta/recipes-multimedia/musicbrainz/libmusicbrainz_3.0.3.bb
+++ b/meta/recipes-multimedia/musicbrainz/libmusicbrainz_3.0.3.bb
@@ -6,7 +6,7 @@ LIC_FILES_CHKSUM =
file://COPYING.txt;md5=fbc093901857fcd118f065f900982c24 \
file://include/musicbrainz3/includes.h;beginline=1;endline=21;md5=9ab2846573f560cea7561da472803a72
DEPENDS = expat neon
-PR = r2
+PR = r3
SRC_URI = http://ftp.musicbrainz.org/pub/musicbrainz/${BPN}-${PV}.tar.gz \
file://fix_build_issue_for_gcc_4.5.0.patch
@@ -15,3 +15,5 @@ SRC_URI[md5sum] = f4824d0a75bdeeef1e45cc88de7bb58a
SRC_URI[sha256sum] =
7fd459a9fd05be9faec60a9a21caa9a1e9fda03147d58d8c7c95f33582a738c5
inherit cmake pkgconfig
+
+EXTRA_OECMAKE = -DLIB_INSTALL_DIR=${libdir}
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] [PATCH] Update intltool to set perl shebang correctly for installed tools
On 2011-08-03 13:52, McClintock Matthew-B29882 wrote:
(Sorry if this get sent twice...)
On Wed, Aug 3, 2011 at 11:44 AM, Gary Thomasg...@mlbassoc.com wrote:
On 2011-08-03 10:33, Matthew McClintock wrote:
Several installed scripts set the perl shebang that is too long
which can cause failures on certian older bash versions.
How does the change below correspond to this comment? It's not
clear [at least to me] how changing that environment variable
affects shebang constructs. Can you give a more thorough explanation?
The scripts intltool-{update,etc} installed in sysroot end up having
*really* long shebangs without this change. On older distros this
causes the intltool scripts to just fail usually during the configure
task. intltools recipe itself will
build and install fine. However, when a package that requires
intltool's is being configured they will all fail withing invoking
intltools.
This much was already clear from your explanation - the what happens and
why it needs fixing part.
What I don't see is the why - why does defining PERL vs PERL_virtclass-native
have this effect?
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] tcl: Fix packaging of platform independent files
On Wed, 2011-08-03 at 10:43 -0500, Kumar Gala wrote:
Tcl's doesn't utilize ${baselib} for platform independent files but
defines it as follows:
TCL_LIBRARY = $(prefix)/lib/tcl$(VERSION)
Match that so if ${baselib} is not just /lib things work properly.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
Even better would be bashing tcl so that it puts its bits in ${datadir}
where they belong. :-) But your patch is fine though.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] [PATCH] Update intltool to set perl shebang correctly for installed tools
[ Removed yocto@ from Cc. Please don't crosspost between oe-core and
yocto. ]
On Wed, 2011-08-03 at 14:01 -0600, Gary Thomas wrote:
On 2011-08-03 13:52, McClintock Matthew-B29882 wrote:
(Sorry if this get sent twice...)
On Wed, Aug 3, 2011 at 11:44 AM, Gary Thomasg...@mlbassoc.com wrote:
On 2011-08-03 10:33, Matthew McClintock wrote:
Several installed scripts set the perl shebang that is too long
which can cause failures on certian older bash versions.
How does the change below correspond to this comment? It's not
clear [at least to me] how changing that environment variable
affects shebang constructs. Can you give a more thorough explanation?
The scripts intltool-{update,etc} installed in sysroot end up having
*really* long shebangs without this change. On older distros this
causes the intltool scripts to just fail usually during the configure
task. intltools recipe itself will
build and install fine. However, when a package that requires
intltool's is being configured they will all fail withing invoking
intltools.
This much was already clear from your explanation - the what happens and
why it needs fixing part.
What I don't see is the why - why does defining PERL vs
PERL_virtclass-native
have this effect?
Agreed, that seems weird and bogus. Surely the scripts which go into
the sysroot (and later get executed on the build host) are going to be
the ones that were built with virtclass-native, in which case this would
be a no-op.
And for scripts that are going to be packaged for installation on the
target, I'm not sure it is safe to assume that env is installed at all
and, even if it is guaranteed to be there, it is certainly not safe to
hardcode /usr/bin as the path to find it. So I'm pretty sure that
this patch is the wrong thing.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] autoconf: Remove patch=1 from SRC_URI
Edit summary field s/produced/produce/
Fix the license related warning
WARNING: autoconf-native: No generic license file exists for:
GPLv2|GPLv3 at /b/openembedded-core/meta/files/common-licenses
WARNING: autoconf-native: There is also no SPDXLICENSEMAP for this
license type: GPLv2|GPLv3 at
/b/openembedded-core/meta/files/common-licenses
Signed-off-by: Khem Raj raj.k...@gmail.com
---
meta/recipes-devtools/autoconf/autoconf.inc |4 ++--
meta/recipes-devtools/autoconf/autoconf_2.68.bb | 19 ++-
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/meta/recipes-devtools/autoconf/autoconf.inc
b/meta/recipes-devtools/autoconf/autoconf.inc
index 47b2b84..08a1b02 100644
--- a/meta/recipes-devtools/autoconf/autoconf.inc
+++ b/meta/recipes-devtools/autoconf/autoconf.inc
@@ -1,4 +1,4 @@
-SUMMARY = A GNU tool that procuded shell scripts to automatically configure
software.
+SUMMARY = A GNU tool that procude shell scripts to automatically configure
software.
DESCRIPTION = Autoconf is an extensible package of M4 macros that produce
shell scripts to automatically \
configure software source code packages. Autoconf creates a configuration
script for a package from a template \
file that lists the operating system features that the package can use, in the
form of M4 macro calls.
@@ -9,6 +9,6 @@ DEPENDS += m4-native
RDEPENDS_${PN} = m4 gnu-config
SRC_URI = ${GNU_MIRROR}/autoconf/autoconf-${PV}.tar.bz2 \
- file://program_prefix.patch;patch=1
+ file://program_prefix.patch
inherit autotools
diff --git a/meta/recipes-devtools/autoconf/autoconf_2.68.bb
b/meta/recipes-devtools/autoconf/autoconf_2.68.bb
index 638e677..3b196a6 100644
--- a/meta/recipes-devtools/autoconf/autoconf_2.68.bb
+++ b/meta/recipes-devtools/autoconf/autoconf_2.68.bb
@@ -6,16 +6,17 @@ PARALLEL_MAKE =
DEPENDS += m4-native
RDEPENDS_${PN} = m4 gnu-config
-LICENSE = GPLv2|GPLv3
+LICENSE = GPLv2 GPLv3
LIC_FILES_CHKSUM = file://COPYING;md5=751419260aa954499f7abaabaa882bbe \
file://COPYINGv3;md5=d32239bcb673463ab874e80d47fae504
-SRC_URI += file://autoreconf-include.patch;patch=1 \
- file://autoreconf-exclude.patch;patch=1 \
- file://autoreconf-foreign.patch;patch=1 \
- file://autoreconf-gnuconfigize.patch;patch=1 \
- file://autoheader-nonfatal-warnings.patch;patch=1 \
- ${@['file://path_prog_fixes.patch;patch=1',
''][bb.data.inherits_class('native', d)]} \
- file://config_site.patch;patch=1
+SRC_URI += file://autoreconf-include.patch \
+ file://autoreconf-exclude.patch \
+ file://autoreconf-foreign.patch \
+ file://autoreconf-gnuconfigize.patch \
+ file://autoheader-nonfatal-warnings.patch \
+ ${@['file://path_prog_fixes.patch',
''][bb.data.inherits_class('native', d)]} \
+file://config_site.patch \
+
SRC_URI[md5sum] = 864d785215aa60d627c91fcb21b05b07
SRC_URI[sha256sum] =
c491fb273fd6d4ca925e26ceed3d177920233c76d542b150ff35e571454332c8
@@ -23,6 +24,6 @@ SRC_URI[sha256sum] =
c491fb273fd6d4ca925e26ceed3d177920233c76d542b150ff35e57145
DEPENDS_virtclass-native = m4-native gnu-config-native
RDEPENDS_${PN}_virtclass-native = m4-native gnu-config-native
-SRC_URI_append_virtclass-native = file://fix_path_xtra.patch;patch=1
+SRC_URI_append_virtclass-native = file://fix_path_xtra.patch
BBCLASSEXTEND = native
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] coreutils: Fix build on uclibc
coreutils has getloadavg.m4 of its own. So we need
to make sure that we remove the portions which look
into hardcoded /usr/local/lib paths. These tests are
only for AIX so we dont lose much
Signed-off-by: Khem Raj raj.k...@gmail.com
---
.../remove-usr-local-lib-from-m4.patch | 31
meta/recipes-core/coreutils/coreutils_8.12.bb |6 ++-
2 files changed, 35 insertions(+), 2 deletions(-)
create mode 100644
meta/recipes-core/coreutils/coreutils-8.12/remove-usr-local-lib-from-m4.patch
diff --git
a/meta/recipes-core/coreutils/coreutils-8.12/remove-usr-local-lib-from-m4.patch
b/meta/recipes-core/coreutils/coreutils-8.12/remove-usr-local-lib-from-m4.patch
new file mode 100644
index 000..aac097a
--- /dev/null
+++
b/meta/recipes-core/coreutils/coreutils-8.12/remove-usr-local-lib-from-m4.patch
@@ -0,0 +1,31 @@
+We have problem using hardcoded directories like /usr/local here
+which will be checked for cross builds. This is a special case which
+is valid for AIX only. We do not have AIX as one of our supported
+build host or target. Therefore we get rid of the hardcoded paths
+and make life easier for cross compilation process.
+
+Signed-off-by: Khem Raj raj.k...@gmail.com
+
+Upstream-Status: Inappropriate [Upstream does care for AIX while we may not]
+
+Index: coreutils-8.12/m4/getloadavg.m4
+===
+--- coreutils-8.12.orig/m4/getloadavg.m4 2011-08-03 14:03:59.982197767
-0700
coreutils-8.12/m4/getloadavg.m42011-08-03 14:04:20.402197763 -0700
+@@ -44,16 +44,6 @@ AC_CHECK_FUNC([getloadavg], [],
+[LIBS=-lutil $LIBS gl_have_func=yes])
+fi
+
+- if test $gl_have_func = no; then
+- # There is a commonly available library for RS/6000 AIX.
+- # Since it is not a standard part of AIX, it might be installed locally.
+- gl_getloadavg_LIBS=$LIBS
+- LIBS=-L/usr/local/lib $LIBS
+- AC_CHECK_LIB([getloadavg], [getloadavg],
+- [LIBS=-lgetloadavg $LIBS gl_have_func=yes],
+- [LIBS=$gl_getloadavg_LIBS])
+- fi
+-
+# Set up the replacement function if necessary.
+if test $gl_have_func = no; then
+ AC_LIBOBJ([getloadavg])
diff --git a/meta/recipes-core/coreutils/coreutils_8.12.bb
b/meta/recipes-core/coreutils/coreutils_8.12.bb
index 00746b9..0004ce7 100644
--- a/meta/recipes-core/coreutils/coreutils_8.12.bb
+++ b/meta/recipes-core/coreutils/coreutils_8.12.bb
@@ -7,13 +7,15 @@ BUGTRACKER = http://debbugs.gnu.org/coreutils;
LICENSE = GPLv3+
LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504\
file://src/ls.c;startline=5;endline=16;md5=e1a509558876db58fb6667ba140137ad
-PR = r2
+PR = r3
DEPENDS = gmp
DEPENDS_virtclass-native =
inherit autotools gettext
-SRC_URI = ${GNU_MIRROR}/coreutils/${BP}.tar.gz
+SRC_URI = ${GNU_MIRROR}/coreutils/${BP}.tar.gz \
+ file://remove-usr-local-lib-from-m4.patch \
+
SRC_URI[md5sum] = fce753a67243d00d75cc86dbcaa6
SRC_URI[sha256sum] =
9e233a62c98a3378a7b0483d2ae3d662dbaf6cd3917d3830d3514665e12a85c8
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] autoconf: Remove code checking for hardcoded /usr/local
This code is only relevant for AIX and causes
problems with OE QA sniffer which detects -L/usr/local/lib
on linker commandline during cross compile and rightly barfs
This only happens when getloadavg() is not found in libc
so we do not reach that code with eglibc but only with uclibc
Signed-off-by: Khem Raj raj.k...@gmail.com
---
.../autoconf/remove-usr-local-lib-from-m4.patch| 29
meta/recipes-devtools/autoconf/autoconf_2.68.bb|3 +-
2 files changed, 31 insertions(+), 1 deletions(-)
create mode 100644
meta/recipes-devtools/autoconf/autoconf/remove-usr-local-lib-from-m4.patch
diff --git
a/meta/recipes-devtools/autoconf/autoconf/remove-usr-local-lib-from-m4.patch
b/meta/recipes-devtools/autoconf/autoconf/remove-usr-local-lib-from-m4.patch
new file mode 100644
index 000..55d2e2f
--- /dev/null
+++ b/meta/recipes-devtools/autoconf/autoconf/remove-usr-local-lib-from-m4.patch
@@ -0,0 +1,29 @@
+We have problem using hardcoded directories like /usr/local here
+which will be checked for cross builds. This is a special case which
+is valid for AIX only. We do not have AIX as one of our supported
+build host or target. Therefore we get rid of the hardcoded paths
+and make life easier for cross compilation process.
+
+Signed-off-by: Khem Raj raj.k...@gmail.com
+
+Upstream-Status: Inappropriate [Upstream does care for AIX while we may not]
+Index: autoconf-2.68/lib/autoconf/functions.m4
+===
+--- autoconf-2.68.orig/lib/autoconf/functions.m4 2010-09-22
14:52:19.0 -0700
autoconf-2.68/lib/autoconf/functions.m42011-08-03 11:57:05.822199513
-0700
+@@ -749,15 +749,6 @@ if test $ac_have_func = no; then
+ [LIBS=-lutil $LIBS ac_have_func=yes ac_cv_func_getloadavg_setgid=yes])
+ fi
+
+-if test $ac_have_func = no; then
+- # There is a commonly available library for RS/6000 AIX.
+- # Since it is not a standard part of AIX, it might be installed locally.
+- ac_getloadavg_LIBS=$LIBS
+- LIBS=-L/usr/local/lib $LIBS
+- AC_CHECK_LIB(getloadavg, getloadavg,
+- [LIBS=-lgetloadavg $LIBS], [LIBS=$ac_getloadavg_LIBS])
+-fi
+-
+ # Make sure it is really in the library, if we think we found it,
+ # otherwise set up the replacement function.
+ AC_CHECK_FUNCS(getloadavg, [],
diff --git a/meta/recipes-devtools/autoconf/autoconf_2.68.bb
b/meta/recipes-devtools/autoconf/autoconf_2.68.bb
index 3b196a6..c6209a3 100644
--- a/meta/recipes-devtools/autoconf/autoconf_2.68.bb
+++ b/meta/recipes-devtools/autoconf/autoconf_2.68.bb
@@ -1,6 +1,6 @@
require autoconf.inc
-PR = r1
+PR = r2
PARALLEL_MAKE =
@@ -16,6 +16,7 @@ SRC_URI += file://autoreconf-include.patch \
file://autoheader-nonfatal-warnings.patch \
${@['file://path_prog_fixes.patch',
''][bb.data.inherits_class('native', d)]} \
file://config_site.patch \
+file://remove-usr-local-lib-from-m4.patch \
SRC_URI[md5sum] = 864d785215aa60d627c91fcb21b05b07
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/9] tcl: Add tcl_cv_api_serial to siteinfo
On 08/01/2011 10:14 AM, Tom Rini wrote: On 07/31/2011 12:16 PM, Tom Rini wrote: On 07/30/2011 05:56 PM, Khem Raj wrote: On Saturday, July 30, 2011 04:42:51 PM Tom Rini wrote: On 07/30/2011 10:33 AM, Khem Raj wrote: On Wednesday, July 27, 2011 03:56:46 PM Tom Rini wrote: This comes from oe.dev which had this set for arm-linux only. Bump PR since this changes how builds happen. if you are clubbing them in right site files then this variable is for deciding what serial API(termios or termio or sgtty) to use its not dependent on libc imo. Where do you think it should go? common-linux? yes k, I'll v2 just this patch, tomorrow. OK, http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=trini/update-siteinfo-round-2-v2 and http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/commit/?h=trini/update-siteinfo-round-2-v2id=d8f714075dcbe37ef21b17639f91a8faeb868bf1 in particular. Due to not paying enough attention, I had pushed only a partial branch to the v2 branch. v3 has everything, really. -- Tom Rini Mentor Graphics Corporation ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 03/33] libfm: depend on intltool-native instead of intltool
From: Martin Jansa martin.ja...@gmail.com Signed-off-by: Martin Jansa martin.ja...@gmail.com --- meta/recipes-support/libfm/libfm_0.1.14.bb |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta/recipes-support/libfm/libfm_0.1.14.bb b/meta/recipes-support/libfm/libfm_0.1.14.bb index 5c7e95c..38f1d73 100644 --- a/meta/recipes-support/libfm/libfm_0.1.14.bb +++ b/meta/recipes-support/libfm/libfm_0.1.14.bb @@ -8,7 +8,7 @@ LIC_FILES_CHKSUM = file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \ file://src/base/fm-config.h;endline=23;md5=ad0fc418c3cf041eea35ddb3daf37f17 SECTION = x11/libs -DEPENDS = gtk+ menu-cache intltool +DEPENDS = gtk+ menu-cache intltool-native PR = r3 -- 1.7.3.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 02/33] polkit: depend on intltool-native instead of intltool
From: Martin Jansa martin.ja...@gmail.com
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/recipes-extended/polkit/polkit_0.101.bb |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-extended/polkit/polkit_0.101.bb
b/meta/recipes-extended/polkit/polkit_0.101.bb
index 56ceca4..06ca595 100644
--- a/meta/recipes-extended/polkit/polkit_0.101.bb
+++ b/meta/recipes-extended/polkit/polkit_0.101.bb
@@ -12,7 +12,7 @@ SRC_URI =
http://hal.freedesktop.org/releases/polkit-${PV}.tar.gz \
PAM_SRC_URI = file://polkit-1_pam.patch
PR = r1
-DEPENDS = libpam expat dbus-glib eggdbus intltool
+DEPENDS = libpam expat dbus-glib eggdbus intltool-native
RDEPENDS_${PN} = libpam
EXTRA_OECONF = --with-authfw=pam --with-os-type=moblin --disable-man-pages
--disable-gtk-doc --disable-introspection
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 01/33] libnewt: update to 0.52.13
From: Kang Kai kai.k...@windriver.com
Update libnewt to 0.52.13, and remove include-without-python.patch
because it has been merged.
Update SRC_URI and add SRC_URI checksum.
Signed-off-by: Kang Kai kai.k...@windriver.com
---
.../newt/files/include-without-python.patch| 73
.../{libnewt_0.52.12.bb = libnewt_0.52.13.bb} | 10 ++-
2 files changed, 6 insertions(+), 77 deletions(-)
delete mode 100644
meta/recipes-extended/newt/files/include-without-python.patch
rename meta/recipes-extended/newt/{libnewt_0.52.12.bb = libnewt_0.52.13.bb}
(80%)
diff --git a/meta/recipes-extended/newt/files/include-without-python.patch
b/meta/recipes-extended/newt/files/include-without-python.patch
deleted file mode 100644
index 263e9de..000
--- a/meta/recipes-extended/newt/files/include-without-python.patch
+++ /dev/null
@@ -1,73 +0,0 @@
-Upstream-Status: Pending
-
-From 3d13769050fac4cc6c904c174edc27e4f03d Mon Sep 17 00:00:00 2001
-From: Otavio Salvador ota...@ossystems.com.br
-Date: Thu, 20 Jan 2011 14:14:51 -0200
-Subject: [PATCH] build: add -without-python
-
-Signed-off-by: Otavio Salvador ota...@ossystems.com.br
- Makefile.in |8
- configure.ac | 10 --
- 2 files changed, 12 insertions(+), 6 deletions(-)
-
-diff --git a/Makefile.in b/Makefile.in
-index e764e61..74e9097 100644
a/Makefile.in
-+++ b/Makefile.in
-@@ -77,7 +77,7 @@ showkey: showkey.o $(LIBNEWT)
- $(CC) -g -o showkey showkey.o $(LIBNEWT) $(LDFLAGS) $(LIBS)
-
- _snackmodule.so: snackmodule.c $(LIBNEWTSH)
-- for ver in $(PYTHONVERS) ; do \
-+ [ -n $(PYTHONVERS) ] for ver in $(PYTHONVERS) ; do \
- mkdir -p $$ver ;\
- PCFLAGS=`$$ver-config --cflags`; \
- PIFLAGS=`$$ver-config --includes`; \
-@@ -85,7 +85,7 @@ _snackmodule.so: snackmodule.c $(LIBNEWTSH)
- PLFLAGS=`$$ver-config --libs`; \
- $(CC) $(CPPFLAGS) $$PIFLAGS $$PCFLAGS -c -o $$ver/snackmodule.o
snackmodule.c ;\
- $(CC) --shared $$PLDFLAGS $$PLFLAGS $(LDFLAGS) -o
$$ver/_snackmodule.so $$ver/snackmodule.o -L. -lnewt $(LIBS);\
-- done
-+ done || :
- touch $@
-
- whiptail: $(NDIALOGOBJS) $(LIBNEWTSH)
-@@ -141,11 +141,11 @@ install-sh: sharedlib $(WHIPTCLSO) _snackmodule.so
- ln -sf $(LIBNEWTSONAME) $(instroot)/$(libdir)/libnewt.so
- ln -sf $(LIBNEWTSH) $(instroot)/$(libdir)/$(LIBNEWTSONAME)
- [ -n $(WHIPTCLSO) ] install -m 755 whiptcl.so
$(instroot)/$(libdir) || :
-- for ver in $(PYTHONVERS) ; do \
-+ [ -n $(PYTHONVERS) ] for ver in $(PYTHONVERS) ; do \
- [ -d $(instroot)/$(libdir)/$$ver/site-packages ] || install -m 755
-d $(instroot)/$(libdir)/$$ver/site-packages ;\
- install -m 755 $$ver/_snackmodule.so
$(instroot)/$(libdir)/$$ver/site-packages ;\
- install -m 644 snack.py $(instroot)/$(libdir)/$$ver/site-packages ;\
-- done
-+ done || :
-
- Makefile: newt.spec
- echo You need to rerun ./configure before continuing
-diff --git a/configure.ac b/configure.ac
-index 7bc381a..dc04352 100644
a/configure.ac
-+++ b/configure.ac
-@@ -54,8 +54,14 @@ fi
- AC_CHECK_HEADERS([popt.h libintl.h])
-
- AC_MSG_CHECKING([for python versions])
--PYTHONVERS=$(echo /usr/include/python*/Python.h | sed s|/usr/include/||g|
sed s|/Python.h||g 2 /dev/null)
--AC_MSG_RESULT([$PYTHONVERS])
-+AC_ARG_WITH([python], [ --without-pythondo not compile python
support])
-+if test x$with_python = xno; then
-+ AC_MSG_RESULT([skipped])
-+ PYTHONVERS=
-+else
-+ PYTHONVERS=$(ls /usr/include/python*/Python.h 2 /dev/null | sed
s|/usr/include/||g| sed s|/Python.h||g 2 /dev/null)
-+ AC_MSG_RESULT([$PYTHONVERS])
-+fi
- AC_SUBST([PYTHONVERS])
-
- AC_ARG_WITH([tcl], [ --without-tcl do not compile whiptcl.so])
---
-1.7.2.3
-
diff --git a/meta/recipes-extended/newt/libnewt_0.52.12.bb
b/meta/recipes-extended/newt/libnewt_0.52.13.bb
similarity index 80%
rename from meta/recipes-extended/newt/libnewt_0.52.12.bb
rename to meta/recipes-extended/newt/libnewt_0.52.13.bb
index e2ad559..38e09a9 100644
--- a/meta/recipes-extended/newt/libnewt_0.52.12.bb
+++ b/meta/recipes-extended/newt/libnewt_0.52.13.bb
@@ -17,16 +17,18 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=55ca817ccb7d5b5b66355690e9abc605
# slang needs to be = 2.2
DEPENDS = slang popt
-PR = r2
+PR = r0
SRCREV = c3c7be75f6ef1adfc2be5f99c1e8ef3f0ab58c38
-SRC_URI = git://git.fedorahosted.org/git/newt;protocol=git \
- file://include-without-python.patch \
+SRC_URI = https://fedorahosted.org/releases/n/e/newt/newt-${PV}.tar.gz \
file://remove_slang_include.patch \
file://fix_SHAREDDIR.patch
-S = ${WORKDIR}/git
+SRC_URI[md5sum] = 77de05b3f58540152a4ae32a1a64e5d0
+SRC_URI[sha256sum] =
01c254b00a3d27e22f13240b6db74df04e721ccec4d1d4fc7b45fee009efc05f
+
+S = ${WORKDIR}/newt-${PV}
EXTRA_OECONF = --without-python --without-tcl
--
[OE-core] [CONSOLIDATED PULL 06/33] bison: Add dependency on flex-native
From: Noor, Ahsan noor_ah...@mentor.com
* This is 0479b70418ef553859029911c57c63a7aaebe299 from OE. flex-native is
needed to build bison. The dependency was being satisfied indirectly but we
need to add it explicitly.
Signed-off-by: Noor, Ahsan noor_ah...@mentor.com
---
meta/recipes-devtools/bison/bison_2.3.bb |4 ++--
meta/recipes-devtools/bison/bison_2.5.bb |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-devtools/bison/bison_2.3.bb
b/meta/recipes-devtools/bison/bison_2.3.bb
index 22f884b..388476b 100644
--- a/meta/recipes-devtools/bison/bison_2.3.bb
+++ b/meta/recipes-devtools/bison/bison_2.3.bb
@@ -7,9 +7,9 @@ HOMEPAGE = http://www.gnu.org/software/bison/;
LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=eb723b61539feef013de476e68b5c50a
SECTION = devel
-DEPENDS = bison-native
+DEPENDS = bison-native flex-native
-PR = r0
+PR = r1
BASE_SRC_URI = ${GNU_MIRROR}/bison/bison-${PV}.tar.gz \
file://bison-2.3_m4.patch
diff --git a/meta/recipes-devtools/bison/bison_2.5.bb
b/meta/recipes-devtools/bison/bison_2.5.bb
index 63f4e76..eb5d87c 100644
--- a/meta/recipes-devtools/bison/bison_2.5.bb
+++ b/meta/recipes-devtools/bison/bison_2.5.bb
@@ -7,9 +7,9 @@ HOMEPAGE = http://www.gnu.org/software/bison/;
LICENSE = GPLv3
LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504
SECTION = devel
-DEPENDS = bison-native
+DEPENDS = bison-native flex-native
-PR = r0
+PR = r1
BASE_SRC_URI = ${GNU_MIRROR}/bison/bison-${PV}.tar.gz \
file://m4.patch \
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 07/33] gtk-icon-cache bbclass: only add runtime dependencies on hicolor-icon-theme when installing icons
From: Koen Kooi k...@dominion.thruhere.net
Tested with gnome-icon-theme and libsoup recipes on angstrom.
Signed-off-by: Koen Kooi k...@openembedded.org
---
meta/classes/gtk-icon-cache.bbclass |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/classes/gtk-icon-cache.bbclass
b/meta/classes/gtk-icon-cache.bbclass
index dcabaf5..d9b5d1b 100644
--- a/meta/classes/gtk-icon-cache.bbclass
+++ b/meta/classes/gtk-icon-cache.bbclass
@@ -1,5 +1,4 @@
FILES_${PN} += ${datadir}/icons/hicolor
-RDEPENDS += hicolor-icon-theme
# This could run on the host as icon cache files are architecture independent,
# but there is no gtk-update-icon-cache built natively.
@@ -34,7 +33,12 @@ python populate_packages_append () {
icon_dir = '%s/%s/%s/icons' % (pkgdest, pkg,
bb.data.getVar('datadir', d, 1))
if not os.path.exists(icon_dir):
continue
-
+
+ bb.note(adding hicolor-icon-theme dependency to %s % pkg)
+ rdepends = bb.data.getVar('RDEPENDS', d, 1)
+ rdepends += hicolor-icon-theme
+ bb.data.setVar('RDEPENDS', rdepends, d)
+
bb.note(adding gtk-icon-cache postinst and postrm scripts to
%s % pkg)
postinst = bb.data.getVar('pkg_postinst_%s' % pkg, d, 1) or
bb.data.getVar('pkg_postinst', d, 1)
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 05/33] aspell: upgrade from 0.60.6 to 0.60.6.1
From: Mei Lei lei@intel.com
Signed-off-by: Mei Lei lei@intel.com
---
.../{aspell_0.60.6.bb = aspell_0.60.6.1.bb} |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
rename meta/recipes-support/aspell/{aspell_0.60.6.bb = aspell_0.60.6.1.bb}
(82%)
diff --git a/meta/recipes-support/aspell/aspell_0.60.6.bb
b/meta/recipes-support/aspell/aspell_0.60.6.1.bb
similarity index 82%
rename from meta/recipes-support/aspell/aspell_0.60.6.bb
rename to meta/recipes-support/aspell/aspell_0.60.6.1.bb
index 455ea35..d773ee3 100644
--- a/meta/recipes-support/aspell/aspell_0.60.6.bb
+++ b/meta/recipes-support/aspell/aspell_0.60.6.1.bb
@@ -1,12 +1,12 @@
SRC_URI = ${GNU_MIRROR}/aspell/aspell-${PV}.tar.gz
-SRC_URI[md5sum] = bc80f0198773d5c05086522be67334eb
-SRC_URI[sha256sum] =
4f5b1520e26cf6bbb1b5ca8a2f9f22948c3ca38ac4c2dd9e02df042fee7c0e36
+SRC_URI[md5sum] = e66a9c9af6a60dc46134fdacf6ce97d7
+SRC_URI[sha256sum] =
f52583a83a63633701c5f71db3dc40aab87b7f76b29723aeb27941eff42df6e1
DESCRIPTION = GNU Aspell spell-checker
SECTION = console/utils
LICENSE=LGPLv2 | LGPLv2.1
LIC_FILES_CHKSUM = file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34
-
+PR = r0
PACKAGES += libaspell libpspell libpspell-dev aspell-utils
FILES_${PN}-dbg += ${libdir}/aspell-0.60/.debu*
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 27/33] site/common-linux: Add ac_cv_file__dev_zero=yes
From: Tom Rini tom_r...@mentor.com
Signed-off-by: Tom Rini tom_r...@mentor.com
---
meta/site/common-linux |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/meta/site/common-linux b/meta/site/common-linux
index 14d671b..e75864d 100644
--- a/meta/site/common-linux
+++ b/meta/site/common-linux
@@ -1,3 +1,6 @@
+# apr
+ac_cv_file__dev_zero=${ac_cv_file__dev_zero=yes}
+
# samba
samba_cv_HAVE_IFACE_AIX=${samba_cv_HAVE_IFACE_AIX=no}
samba_cv_HAVE_IFACE_IFCONF=${samba_cv_HAVE_IFACE_IFCONF=yes}
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 08/33] binutils: Add support for powerpc e5500 core
From: Kumar Gala ga...@kernel.crashing.org
Add powerpc e5500 core support to binutils so its recognized by
assember, etc. The e5500 is a 64-bit core from Freescale utilized in
the P5020 SoC.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
.../binutils/binutils/binutils-powerpc-e5500.patch | 112
meta/recipes-devtools/binutils/binutils_2.21.1.bb |3 +-
2 files changed, 114 insertions(+), 1 deletions(-)
create mode 100644
meta/recipes-devtools/binutils/binutils/binutils-powerpc-e5500.patch
diff --git
a/meta/recipes-devtools/binutils/binutils/binutils-powerpc-e5500.patch
b/meta/recipes-devtools/binutils/binutils/binutils-powerpc-e5500.patch
new file mode 100644
index 000..1de164d
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils/binutils-powerpc-e5500.patch
@@ -0,0 +1,112 @@
+Upstream-Status: Pending
+
+Add support for FSL PowerPC e5500 core.
+
+Signed-off-by: Edmar Wienskoski ed...@freescale.com
+Signed-off-by: Kumar Gala ga...@kernel.crashing.org
+
+Index: binutils-2.21.1/bfd/archures.c
+===
+--- binutils-2.21.1.orig/bfd/archures.c
binutils-2.21.1/bfd/archures.c
+@@ -231,6 +231,7 @@ DESCRIPTION
+ .#define bfd_mach_ppc_e500 500
+ .#define bfd_mach_ppc_e500mc5001
+ .#define bfd_mach_ppc_e500mc64 5005
++.#define bfd_mach_ppc_e5500 5006
+ .#define bfd_mach_ppc_titan 83
+ . bfd_arch_rs6000,{* IBM RS/6000 *}
+ .#define bfd_mach_rs6k6000
+Index: binutils-2.21.1/bfd/bfd-in2.h
+===
+--- binutils-2.21.1.orig/bfd/bfd-in2.h
binutils-2.21.1/bfd/bfd-in2.h
+@@ -1918,6 +1918,7 @@ enum bfd_architecture
+ #define bfd_mach_ppc_e500 500
+ #define bfd_mach_ppc_e500mc5001
+ #define bfd_mach_ppc_e500mc64 5005
++#define bfd_mach_ppc_e5500 5006
+ #define bfd_mach_ppc_titan 83
+ bfd_arch_rs6000,/* IBM RS/6000 */
+ #define bfd_mach_rs6k 6000
+Index: binutils-2.21.1/bfd/cpu-powerpc.c
+===
+--- binutils-2.21.1.orig/bfd/cpu-powerpc.c
binutils-2.21.1/bfd/cpu-powerpc.c
+@@ -352,6 +352,20 @@ const bfd_arch_info_type bfd_powerpc_arc
+ FALSE, /* not the default */
+ powerpc_compatible,
+ bfd_default_scan,
++bfd_powerpc_archs[19]
++ },
++ {
++64, /* 64 bits in a word */
++64, /* 64 bits in an address */
++8, /* 8 bits in a byte */
++bfd_arch_powerpc,
++bfd_mach_ppc_e5500,
++powerpc,
++powerpc:e5500,
++3,
++FALSE, /* not the default */
++powerpc_compatible,
++bfd_default_scan,
+ 0
+ }
+ };
+Index: binutils-2.21.1/gas/config/tc-ppc.c
+===
+--- binutils-2.21.1.orig/gas/config/tc-ppc.c
binutils-2.21.1/gas/config/tc-ppc.c
+@@ -1236,6 +1236,7 @@ PowerPC options:\n\
+ -me500, -me500x2generate code for Motorola e500 core complex\n\
+ -me500mc, generate code for Freescale e500mc core complex\n\
+ -me500mc64, generate code for Freescale e500mc64 core complex\n\
++-me5500,generate code for Freescale e5500 core complex\n\
+ -mspe generate code for Motorola SPE instructions\n\
+ -mtitan generate code for AppliedMicro Titan core complex\n\
+ -mregnames Allow symbolic names for registers\n\
+Index: binutils-2.21.1/gas/doc/as.texinfo
+===
+--- binutils-2.21.1.orig/gas/doc/as.texinfo
binutils-2.21.1/gas/doc/as.texinfo
+@@ -432,7 +432,7 @@ gcc(1), ld(1), and the Info entries for
+[@b{-a32}|@b{-a64}]
+
[@b{-mpwrx}|@b{-mpwr2}|@b{-mpwr}|@b{-m601}|@b{-mppc}|@b{-mppc32}|@b{-m603}|@b{-m604}|@b{-m403}|@b{-m405}|
+
@b{-m440}|@b{-m464}|@b{-m476}|@b{-m7400}|@b{-m7410}|@b{-m7450}|@b{-m7455}|@b{-m750cl}|@b{-mppc64}|
+-
@b{-m620}|@b{-me500}|@b{-e500x2}|@b{-me500mc}|@b{-me500mc64}|@b{-mppc64bridge}|@b{-mbooke}|
++
@b{-m620}|@b{-me500}|@b{-e500x2}|@b{-me500mc}|@b{-me500mc64}|@b{-me5500}|@b{-mppc64bridge}|@b{-mbooke}|
+
@b{-mpower4}|@b{-mpr4}|@b{-mpower5}|@b{-mpwr5}|@b{-mpwr5x}|@b{-mpower6}|@b{-mpwr6}|
+
@b{-mpower7}|@b{-mpw7}|@b{-ma2}|@b{-mcell}|@b{-mspe}|@b{-mtitan}|@b{-me300}|@b{-mcom}]
+[@b{-many}] [@b{-maltivec}|@b{-mvsx}]
+Index: binutils-2.21.1/gas/doc/c-ppc.texi
+===
+--- binutils-2.21.1.orig/gas/doc/c-ppc.texi
binutils-2.21.1/gas/doc/c-ppc.texi
+@@ -85,6 +85,9 @@ Generate code for Freescale e500mc core
+ @item -me500mc64
+ Generate code for Freescale e500mc64 core complex.
+
++@item -me5500
++Generate code for Freescale e5500 core complex.
++
+ @item -mspe
+ Generate code for Motorola SPE instructions.
+
+Index: binutils-2.21.1/opcodes/ppc-dis.c
+===
+---
[OE-core] [CONSOLIDATED PULL 10/33] kernel, cml1.bbclass: Move menuconfig to cml1
From: Noor, Ahsan noor_ah...@mentor.com
* The menuconfig target exists in places other than the kernel that use kernel
style config.
Signed-off-by: Noor, Ahsan noor_ah...@mentor.com
---
meta/classes/cml1.bbclass | 12
meta/classes/kernel.bbclass | 15 ---
2 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/meta/classes/cml1.bbclass b/meta/classes/cml1.bbclass
index 79218b4..a747af5 100644
--- a/meta/classes/cml1.bbclass
+++ b/meta/classes/cml1.bbclass
@@ -6,3 +6,15 @@ cml1_do_configure() {
EXPORT_FUNCTIONS do_configure
addtask configure after do_unpack do_patch before do_compile
+
+do_menuconfig() {
+ export TERMWINDOWTITLE=${PN} Configuration
+ export SHELLCMDS=make menuconfig
+ ${TERMCMDRUN}
+ if [ $? -ne 0 ]; then
+ oefatal '${TERMCMD}' not found. Check TERMCMD variable.
+ fi
+}
+do_menuconfig[nostamp] = 1
+addtask menuconfig after do_configure
+
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 9c492a3..25d2629 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -197,21 +197,6 @@ kernel_do_configure() {
do_configure[depends] += ${INITRAMFS_TASK}
-do_menuconfig() {
-export DISPLAY='${DISPLAY}'
-export DBUS_SESSION_BUS_ADDRESS='${DBUS_SESSION_BUS_ADDRESS}'
-export XAUTHORITY='${XAUTHORITY}'
- export TERMWINDOWTITLE=${PN} Kernel Configuration
- export SHELLCMDS=make menuconfig
- ${TERMCMDRUN}
- if [ $? -ne 0 ]; then
- echo Fatal: '${TERMCMD}' not found. Check TERMCMD variable.
- exit 1
- fi
-}
-do_menuconfig[nostamp] = 1
-addtask menuconfig after do_configure
-
pkg_postinst_kernel () {
cd /${KERNEL_IMAGEDEST}; update-alternatives --install
/${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE} ${KERNEL_IMAGETYPE}
${KERNEL_IMAGETYPE}-${KERNEL_VERSION} ${KERNEL_PRIORITY} || true
}
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 11/33] lighttpd: Upgrade to 1.4.29
From: Zhai Edwin edwin.z...@intel.com
Signed-off-by: Zhai Edwin edwin.z...@intel.com
---
.../{lighttpd_1.4.28.bb = lighttpd_1.4.29.bb} |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
rename meta/recipes-extended/lighttpd/{lighttpd_1.4.28.bb =
lighttpd_1.4.29.bb} (90%)
diff --git a/meta/recipes-extended/lighttpd/lighttpd_1.4.28.bb
b/meta/recipes-extended/lighttpd/lighttpd_1.4.29.bb
similarity index 90%
rename from meta/recipes-extended/lighttpd/lighttpd_1.4.28.bb
rename to meta/recipes-extended/lighttpd/lighttpd_1.4.29.bb
index d43766c..c1d5f81 100644
--- a/meta/recipes-extended/lighttpd/lighttpd_1.4.28.bb
+++ b/meta/recipes-extended/lighttpd/lighttpd_1.4.29.bb
@@ -18,14 +18,14 @@ RDEPENDS_${PN} += \
PR = r0
-SRC_URI =
http://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-${PV}.tar.gz;name=src
\
+SRC_URI =
http://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-${PV}.tar.bz2 \
file://index.html \
file://lighttpd.conf \
file://lighttpd \
-SRC_URI[src.md5sum] = 202d36efc6324adb95a3600d2826ec6a
-SRC_URI[src.sha256sum] =
efd7623f43182723b99c51d57a24158e22a207cd90dca35aaf3b2e3bac115712
+SRC_URI[md5sum] = e6e67b09986cb504db630b5a86b2dd76
+SRC_URI[sha256sum] =
afd8af213e65afb48b397d004696c6620a7ae7f3d4f162ec46a04b9b9dbfd599
EXTRA_OECONF = \
--without-bzip2 \
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 04/33] SRC_URI, S: use BPN instead of PN for multilib case
From: Yu Ke ke...@intel.com
in multilibcase, PN has multilib prefix, so it is not
correct to use PN in SRC_URI and S. instead, we've
dedicately pruned multilib prefix in BPN, so BPN is
the right alternative for PN.
Signed-off-by: Yu Ke k...@intel.com
---
.../farsight/farsight2_0.0.9.bb|2 +-
.../loudmouth/loudmouth_1.4.0.bb |2 +-
.../opensync/libopensync-plugin_0.36.inc |2 +-
.../telepathy/telepathy-farsight_0.0.7.bb |2 +-
.../telepathy/telepathy-gabble_0.7.8.bb|2 +-
.../recipes-connectivity/wbxml/wbxml2_0.9.2.bb |2 +-
.../recipes-gnome/gcalctool/gcalctool_5.7.32.bb|2 +-
.../recipes-gnome/gcalctool/gcalctool_5.8.17.bb|2 +-
.../recipes-gnome/libgtkstylus/libgtkstylus_0.5.bb |2 +-
meta-demoapps/recipes-gnome/wv/wv_1.2.0.bb |2 +-
meta-demoapps/recipes-sato/kf/kf_0.5.4.1.bb|2 +-
.../matchbox-themes-extra_git.bb |2 +-
.../recipes-support/poppler/poppler-data_0.1.bb|2 +-
meta-demoapps/recipes-support/poppler/poppler.inc |2 +-
.../omap3-sgx-modules_1.3.13.1397.bb |4 ++--
meta/recipes-bsp/zaurusd/zaurusd_svn.bb|2 +-
.../galago/galago-daemon_0.5.1.bb |2 +-
.../iproute2/iproute2_2.6.38.bb|2 +-
meta/recipes-connectivity/ofono/ofono_0.50.bb |2 +-
.../telepathy/telepathy-glib_0.14.3.bb |2 +-
.../telepathy/telepathy-idle_0.1.8.bb |2 +-
.../telepathy/telepathy-python_0.15.19.bb |2 +-
meta/recipes-core/dbus-wait/dbus-wait_svn.bb |2 +-
.../glib-networking/glib-networking_2.28.7.bb |2 +-
meta/recipes-devtools/distcc/distcc_2.18.3.bb |2 +-
.../subversion/subversion_1.6.15.bb|2 +-
meta/recipes-extended/blktool/blktool_4-6.bb |2 +-
.../recipes-extended/chkconfig/chkconfig_1.3.52.bb |2 +-
meta/recipes-extended/libidn/libidn_0.6.14.bb |2 +-
meta/recipes-extended/libidn/libidn_1.22.bb|2 +-
meta/recipes-extended/libtirpc/libtirpc_0.2.2.bb |4 ++--
meta/recipes-extended/mktemp/mktemp_1.7.bb |2 +-
meta/recipes-extended/xdg-utils/xdg-utils_1.0.2.bb |2 +-
.../ttf-fonts/liberation-fonts_1.06.bb |2 +-
.../xorg-driver/xf86-driver-common.inc |2 +-
meta/recipes-multimedia/libomxil/libomxil_0.3.3.bb |2 +-
meta/recipes-sato/eds/eds-tools_bzr.bb |2 +-
meta/recipes-sato/gaku/gaku_svn.bb |2 +-
meta/recipes-sato/libical/libical_0.46.bb |2 +-
meta/recipes-sato/libowl/libowl_svn.bb |2 +-
.../recipes-sato/owl-video-widget/libowl-av_svn.bb |2 +-
meta/recipes-sato/puzzles/oh-puzzles_svn.bb|2 +-
meta/recipes-sato/puzzles/puzzles_r9175.bb |2 +-
meta/recipes-sato/screenshot/screenshot_svn.bb |2 +-
meta/recipes-support/apr/apr-util_1.3.10.bb|2 +-
meta/recipes-support/apr/apr_1.4.2.bb |2 +-
meta/recipes-support/liboil/liboil_0.3.17.bb |2 +-
meta/recipes-support/neon/neon_0.29.5.bb |2 +-
48 files changed, 50 insertions(+), 50 deletions(-)
diff --git a/meta-demoapps/recipes-connectivity/farsight/farsight2_0.0.9.bb
b/meta-demoapps/recipes-connectivity/farsight/farsight2_0.0.9.bb
index 483a767..a7bdc97 100644
--- a/meta-demoapps/recipes-connectivity/farsight/farsight2_0.0.9.bb
+++ b/meta-demoapps/recipes-connectivity/farsight/farsight2_0.0.9.bb
@@ -1,6 +1,6 @@
DESCRIPTION = FarSight is an audio/video conferencing framework specifically
designed for Instant Messengers.
HOMEPAGE = http://farsight.sf.net;
-SRC_URI = http://farsight.freedesktop.org/releases/farsight2/${P}.tar.gz;
+SRC_URI =
http://farsight.freedesktop.org/releases/farsight2/${BPN}-${PV}.tar.gz;
LICENSE = GPLv2.1
DEPENDS = libnice glib-2.0 libxml2 zlib dbus gstreamer gst-plugins-base
diff --git a/meta-demoapps/recipes-connectivity/loudmouth/loudmouth_1.4.0.bb
b/meta-demoapps/recipes-connectivity/loudmouth/loudmouth_1.4.0.bb
index e20c417..b6af11d 100644
--- a/meta-demoapps/recipes-connectivity/loudmouth/loudmouth_1.4.0.bb
+++ b/meta-demoapps/recipes-connectivity/loudmouth/loudmouth_1.4.0.bb
@@ -5,6 +5,6 @@ LICENSE = LGPL
DEPENDS = glib-2.0 gnutls libcheck
PR = r2
-SRC_URI = http://ftp.imendio.com/pub/imendio/${PN}/src/${PN}-${PV}.tar.bz2;
+SRC_URI = http://ftp.imendio.com/pub/imendio/${BPN}/src/${BPN}-${PV}.tar.bz2;
inherit autotools pkgconfig
diff --git
a/meta-demoapps/recipes-connectivity/opensync/libopensync-plugin_0.36.inc
b/meta-demoapps/recipes-connectivity/opensync/libopensync-plugin_0.36.inc
index 147fcfb..cde4779 100644
--- a/meta-demoapps/recipes-connectivity/opensync/libopensync-plugin_0.36.inc
+++ b/meta-demoapps/recipes-connectivity/opensync/libopensync-plugin_0.36.inc
@@ -2,7 +2,7 @@ DEPENDS = libopensync (= 0.36)
[OE-core] [CONSOLIDATED PULL 12/33] libsoup-2.4: Upgrade to 2.34.2
From: Zhai Edwin edwin.z...@intel.com
Signed-off-by: Zhai Edwin edwin.z...@intel.com
---
...libsoup-2.4_2.34.1.bb = libsoup-2.4_2.34.2.bb} |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-support/libsoup/{libsoup-2.4_2.34.1.bb =
libsoup-2.4_2.34.2.bb} (76%)
diff --git a/meta/recipes-support/libsoup/libsoup-2.4_2.34.1.bb
b/meta/recipes-support/libsoup/libsoup-2.4_2.34.2.bb
similarity index 76%
rename from meta/recipes-support/libsoup/libsoup-2.4_2.34.1.bb
rename to meta/recipes-support/libsoup/libsoup-2.4_2.34.2.bb
index f9e8de5..57af8f7 100644
--- a/meta/recipes-support/libsoup/libsoup-2.4_2.34.1.bb
+++ b/meta/recipes-support/libsoup/libsoup-2.4_2.34.2.bb
@@ -12,8 +12,8 @@ DEPENDS = glib-2.0 gnutls libxml2 libproxy sqlite3
libgnome-keyring
SRC_URI = ${GNOME_MIRROR}/libsoup/2.34/libsoup-${PV}.tar.bz2
-SRC_URI[md5sum] = 846779d898c11f97b5de28a79ea82254
-SRC_URI[sha256sum] =
a2f846af2c4c08e15eacc9879c8c9be4d85f8105f960f96a9ba3dbabd9ee517b
+SRC_URI[md5sum] = 2454b38681a6e082b613a781a501e721
+SRC_URI[sha256sum] =
1d70edc48c309528635012269733739f9cd22548913125864318a65d1b6f1261
S = ${WORKDIR}/libsoup-${PV}
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 15/33] parted: Upgrade to 3.0
From: Zhai Edwin edwin.z...@intel.com
Signed-off-by: Zhai Edwin edwin.z...@intel.com
---
.../{parted-2.3 = parted-3.0}/no_check.patch |0
.../{parted-2.3 = parted-3.0}/syscalls.patch |0
.../parted/{parted_2.3.bb = parted_3.0.bb}|4 ++--
3 files changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-extended/parted/{parted-2.3 = parted-3.0}/no_check.patch
(100%)
rename meta/recipes-extended/parted/{parted-2.3 = parted-3.0}/syscalls.patch
(100%)
rename meta/recipes-extended/parted/{parted_2.3.bb = parted_3.0.bb} (78%)
diff --git a/meta/recipes-extended/parted/parted-2.3/no_check.patch
b/meta/recipes-extended/parted/parted-3.0/no_check.patch
similarity index 100%
rename from meta/recipes-extended/parted/parted-2.3/no_check.patch
rename to meta/recipes-extended/parted/parted-3.0/no_check.patch
diff --git a/meta/recipes-extended/parted/parted-2.3/syscalls.patch
b/meta/recipes-extended/parted/parted-3.0/syscalls.patch
similarity index 100%
rename from meta/recipes-extended/parted/parted-2.3/syscalls.patch
rename to meta/recipes-extended/parted/parted-3.0/syscalls.patch
diff --git a/meta/recipes-extended/parted/parted_2.3.bb
b/meta/recipes-extended/parted/parted_3.0.bb
similarity index 78%
rename from meta/recipes-extended/parted/parted_2.3.bb
rename to meta/recipes-extended/parted/parted_3.0.bb
index 14c9c25..29daf01 100644
--- a/meta/recipes-extended/parted/parted_2.3.bb
+++ b/meta/recipes-extended/parted/parted_3.0.bb
@@ -10,8 +10,8 @@ SRC_URI = ${GNU_MIRROR}/parted/parted-${PV}.tar.gz \
file://no_check.patch \
file://syscalls.patch
-SRC_URI[md5sum] = 30ceb6df7e8681891e865e2fe5a7903d
-SRC_URI[sha256sum] =
e81fa140805b5cd029ff6dda5cfa94d223e83ac182ebcae94f841d62ce468829
+SRC_URI[md5sum] = a94e84a9b9944715c4453f82ccc639bf
+SRC_URI[sha256sum] =
8886eece015202f6bd5ce8414f4b68838452cef509f2e3389ad56128219837b7
EXTRA_OECONF = --disable-Werror --disable-device-mapper
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 30/33] glibc: Remove unused version
Signed-off-by: Saul Wold s...@linux.intel.com --- meta/conf/distro/include/tcmode-default.inc |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/meta/conf/distro/include/tcmode-default.inc b/meta/conf/distro/include/tcmode-default.inc index dce76db..0d0af38 100644 --- a/meta/conf/distro/include/tcmode-default.inc +++ b/meta/conf/distro/include/tcmode-default.inc @@ -19,7 +19,6 @@ PREFERRED_PROVIDER_virtual/gettext ??= gettext GCCVERSION ?= 4.6% SDKGCCVERSION ?= 4.6% BINUVERSION ?= 2.21.1 -GLIBCVERSION ?= 2.10.1 EGLIBCVERSION ?= 2.13 UCLIBCVERSION ?= 0.9.32 LINUXLIBCVERSION ?= 2.6.37.2 -- 1.7.3.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 14/33] gpgme: Upgrade to 1.3.1
From: Zhai Edwin edwin.z...@intel.com
Signed-off-by: Zhai Edwin edwin.z...@intel.com
---
.../disable_gpgconf_check.patch|0
.../gpgme/{gpgme_1.3.0.bb = gpgme_1.3.1.bb} | 10 +-
2 files changed, 5 insertions(+), 5 deletions(-)
rename meta/recipes-support/gpgme/{gpgme-1.3.0 =
gpgme-1.3.1}/disable_gpgconf_check.patch (100%)
rename meta/recipes-support/gpgme/{gpgme_1.3.0.bb = gpgme_1.3.1.bb} (74%)
diff --git a/meta/recipes-support/gpgme/gpgme-1.3.0/disable_gpgconf_check.patch
b/meta/recipes-support/gpgme/gpgme-1.3.1/disable_gpgconf_check.patch
similarity index 100%
rename from meta/recipes-support/gpgme/gpgme-1.3.0/disable_gpgconf_check.patch
rename to meta/recipes-support/gpgme/gpgme-1.3.1/disable_gpgconf_check.patch
diff --git a/meta/recipes-support/gpgme/gpgme_1.3.0.bb
b/meta/recipes-support/gpgme/gpgme_1.3.1.bb
similarity index 74%
rename from meta/recipes-support/gpgme/gpgme_1.3.0.bb
rename to meta/recipes-support/gpgme/gpgme_1.3.1.bb
index 4c45a44..9ffedba 100644
--- a/meta/recipes-support/gpgme/gpgme_1.3.0.bb
+++ b/meta/recipes-support/gpgme/gpgme_1.3.1.bb
@@ -5,14 +5,14 @@ BUGTRACKER = https://bugs.g10code.com/gnupg/index;
LICENSE = GPLv2+ LGPLv2.1+
LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
file://COPYING.LESSER;md5=bbb461211a33b134d42ed5ee802b37ff
\
-
file://src/gpgme.h;endline=23;md5=2775a99d3dd524c4f848ff1c59093038 \
+
file://src/gpgme.h.in;endline=23;md5=942b47052c0674c6a3b9b9e6127628a4 \
file://src/engine.h;endline=22;md5=e96acfaab1cff82dd8fbefddd2f5c436
SRC_URI = ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-${PV}.tar.bz2 \
- file://disable_gpgconf_check.patch;patch=1;pnum=1
+ file://disable_gpgconf_check.patch
-SRC_URI[md5sum] = 4784e3c6086c9c25e9a1b4d9f7c5aa96
-SRC_URI[sha256sum] =
74e040fcd46061f6b0d8b621a2a2a48100a7ba5c9f69e7cf207259a6e2e3e6a1
+SRC_URI[md5sum] = 90afa8436ce2b2683c001c824bd22601
+SRC_URI[sha256sum] =
15ef27a875ae0d79d7446fd931deda11438e724ffbeac74449ed19cba23df4d4
DEPENDS = libgpg-error libassuan pth
PR = r0
@@ -25,4 +25,4 @@ PACKAGES =+ ${PN}-pth ${PN}-pthread
FILES_${PN}-pth = ${libdir}/libgpgme-pth.so.*
FILES_${PN}-pthread = ${libdir}/libgpgme-pthread.so.*
FILES_${PN} = ${libdir}/libgpgme.so.*
-FILES_${PN}-dev += ${bindir}/gpgme-config
+FILES_${PN}-dev += ${bindir}/gpgme-config
${datadir}/common-lisp/source/gpgme/*
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 19/33] kernel.bbcalss: Added do_savedefconfig task.
From: Noor, Ahsan noor_ah...@mentor.com
* Added do_savedefconfig task to kernel.bbclass.
Signed-off-by: Noor, Ahsan noor_ah...@mentor.com
---
meta/classes/kernel.bbclass |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 25d2629..f2f05b1 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -197,6 +197,12 @@ kernel_do_configure() {
do_configure[depends] += ${INITRAMFS_TASK}
+do_savedefconfig() {
+ oe_runmake savedefconfig
+}
+do_savedefconfig[nostamp] = 1
+addtask savedefconfig after do_configure
+
pkg_postinst_kernel () {
cd /${KERNEL_IMAGEDEST}; update-alternatives --install
/${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE} ${KERNEL_IMAGETYPE}
${KERNEL_IMAGETYPE}-${KERNEL_VERSION} ${KERNEL_PRIORITY} || true
}
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 16/33] apr: Upgrade to 1.4.5
From: Zhai Edwin edwin.z...@intel.com
Remove buildconf_fix.patch as already in upstream.
Signed-off-by: Zhai Edwin edwin.z...@intel.com
Merged with ${BPN} change
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/recipes-support/apr/apr/buildconf_fix.patch | 27
.../apr/{apr_1.4.2.bb = apr_1.4.5.bb} | 13 +
2 files changed, 7 insertions(+), 33 deletions(-)
delete mode 100644 meta/recipes-support/apr/apr/buildconf_fix.patch
rename meta/recipes-support/apr/{apr_1.4.2.bb = apr_1.4.5.bb} (82%)
diff --git a/meta/recipes-support/apr/apr/buildconf_fix.patch
b/meta/recipes-support/apr/apr/buildconf_fix.patch
deleted file mode 100644
index 2c9d62e..000
--- a/meta/recipes-support/apr/apr/buildconf_fix.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-Remove the new libtool detection method to avoid config failure. Poky's libtool
-has different format for aclocaldir, and there is no elegant parsing method,
-so fall back to old detection.
-
-Signed-off-by: Zhai Edwin edwin.z...@intel.com
-
-Upstream-Status: Inappropriate [configuration]
-
-Index: apr-1.4.2/buildconf
-===
apr-1.4.2.orig/buildconf 2009-11-13 06:19:49.0 +0800
-+++ apr-1.4.2/buildconf2010-11-29 14:39:19.0 +0800
-@@ -50,14 +50,6 @@
-
- if [ -f libtool.m4 ]; then
-ltfile=`pwd`/libtool.m4
--elif grep all_pkgmacro_files $libtoolize /dev/null; then
--# libtool 2.x
-- aclocal_dir=`sed -n '/^aclocaldir=/{s/.*=//;p;q;}' $libtoolize`
-- ltfiles=`sed -n '/^all_pkgmacro_files=/{s/.*=//;;s///;p;q;}'
$libtoolize`
-- for f in $ltfiles; do
-- test -f $aclocal_dir/$f cp $aclocal_dir/$f build
-- done
-- ltfile=$aclocal_dir/libtool.m4
- else
-ltfindcmd=`sed -n \/=[^\\\`]/p;/libtool_m4=/{s/.*=/echo /p;q;}\ \
- $libtoolize`
diff --git a/meta/recipes-support/apr/apr_1.4.2.bb
b/meta/recipes-support/apr/apr_1.4.5.bb
similarity index 82%
rename from meta/recipes-support/apr/apr_1.4.2.bb
rename to meta/recipes-support/apr/apr_1.4.5.bb
index 2d5edaa..b65e042 100644
--- a/meta/recipes-support/apr/apr_1.4.2.bb
+++ b/meta/recipes-support/apr/apr_1.4.5.bb
@@ -9,13 +9,12 @@ LIC_FILES_CHKSUM =
file://LICENSE;md5=0c35ff3c4c83b89d2f076e315caac28b \
PR = r1
SRC_URI = ${APACHE_MIRROR}/apr/${BPN}-${PV}.tar.bz2 \
- file://configure_fixes.patch;patch=1 \
- file://cleanup.patch;patch=1 \
- file://configfix.patch;patch=1 \
- file://buildconf_fix.patch;patch=1
+ file://configure_fixes.patch \
+ file://cleanup.patch \
+ file://configfix.patch
-SRC_URI[md5sum] = 4b00e8f70c067893d075577962656b35
-SRC_URI[sha256sum] =
2017ca700694d09d2b0b21dd7c4d195e43a48735aac88526160c6195ee8f5391
+SRC_URI[md5sum] = 8b53f5a5669d0597f2da889a2f576eb6
+SRC_URI[sha256sum] =
38c61cacb39be649411cdab212979c71ce29495549c249c2e9a1b0d12480c93e
inherit autotools lib_package binconfig multilib_header
@@ -26,6 +25,8 @@ do_configure_prepend() {
./buildconf
}
+FILES_${PN}-dev += ${libdir}/apr.exp ${datadir}/build-1/*
+
#for some reason, build/libtool.m4 handled by buildconf still be overwritten
#when autoconf, so handle it again.
do_configure_append() {
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 17/33] apr-util: Upgrade to 1.3.12
From: Zhai Edwin edwin.z...@intel.com
Signed-off-by: Zhai Edwin edwin.z...@intel.com
Merged with ${BPN} change
Signed-off-by: Saul Wold s...@linux.intel.com
---
.../apr/{apr-util_1.3.10.bb = apr-util_1.3.12.bb} | 12
1 files changed, 8 insertions(+), 4 deletions(-)
rename meta/recipes-support/apr/{apr-util_1.3.10.bb = apr-util_1.3.12.bb}
(67%)
diff --git a/meta/recipes-support/apr/apr-util_1.3.10.bb
b/meta/recipes-support/apr/apr-util_1.3.12.bb
similarity index 67%
rename from meta/recipes-support/apr/apr-util_1.3.10.bb
rename to meta/recipes-support/apr/apr-util_1.3.12.bb
index 01595df..6635202 100644
--- a/meta/recipes-support/apr/apr-util_1.3.10.bb
+++ b/meta/recipes-support/apr/apr-util_1.3.12.bb
@@ -10,11 +10,11 @@ LIC_FILES_CHKSUM =
file://LICENSE;md5=519e0a18e03f7c023070568c14b077bb \
PR = r0
SRC_URI = ${APACHE_MIRROR}/apr/${BPN}-${PV}.tar.gz \
- file://configfix.patch;patch=1 \
- file://configure_fixes.patch;patch=1
+ file://configfix.patch \
+ file://configure_fixes.patch
-SRC_URI[md5sum] = 82acd25cf3df8c72eba44eaee8b80c19
-SRC_URI[sha256sum] =
7c37ac40b2351bfc23000fb6b7b54a67e0872255df315c82eb60c821bcef4b23
+SRC_URI[md5sum] = d1977289889592ef998e3f777f68efe4
+SRC_URI[sha256sum] =
815b6fc82950f61050a5e711a7f3c20fd9b6ffcc7a4cacfe9f291fb241210cd8
EXTRA_OECONF = --with-apr=${STAGING_BINDIR_CROSS}/apr-1-config \
--without-odbc \
@@ -33,3 +33,7 @@ do_configure_prepend() {
cp ${STAGING_DATADIR}/apr/apr_rules.mk ${S}/build/rules.mk
}
+FILES_${PN} += ${libdir}/apr-util-1/apr_dbm_gdbm-1.so
+FILES_${PN}-dev += ${libdir}/aprutil.exp ${libdir}/apr-util-1/apr_dbm_gdbm.*
+FILES_${PN}-dbg += ${libdir}/apr-util-1/.debug/*
+
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 18/33] xserver-nodm-init: Fix X start failure on some platform
From: Zhai Edwin edwin.z...@intel.com sudo is used to run rootless X in xserver-nodm, and start to fail with xf86OpenConsole: Cannot open /dev/tty0 error after upgrade to 1.8.1. sudo seems wait for some resource that is unavailable in early phase of booting. This patch swith to su for rootless X starting as a fix. [YOCTO #1211] got fixed Signed-off-by: Zhai Edwin edwin.z...@intel.com --- .../x11-common/xserver-nodm-init/xserver-nodm |6 ++ 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm b/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm index d8c4ba0..3b71983 100755 --- a/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm +++ b/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm @@ -35,10 +35,8 @@ case $1 in chmod g+r /dev/tty[0-3] chmod o+rw /dev/input/* fi - # Using sudo -i here has the nice side effect of making sire - # HOME, USER and other previously problematic variables - # are set correctly - sudo -b -i -u $username /etc/X11/Xserver + # Using su rather than sudo as latest 1.8.1 cause failure [YOCTO #1211] + su -l -c '/etc/X11/Xserver' $username # Wait for the desktop to say its finished loading dbus-wait org.matchbox_project.desktop Loaded ;; -- 1.7.3.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 22/33] tcl: Add tcl_cv_api_serial to siteinfo
From: Tom Rini tom_r...@mentor.com
This comes from oe.dev which had this set for arm-linux only. Bump PR
since this changes how builds happen.
Signed-off-by: Tom Rini tom_r...@mentor.com
---
meta/site/common-glibc |2 ++
meta/site/common-uclibc |3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/meta/site/common-glibc b/meta/site/common-glibc
index 8cfa695..baca5f8 100644
--- a/meta/site/common-glibc
+++ b/meta/site/common-glibc
@@ -69,3 +69,5 @@ gl_cv_func_mbrtowc_null_arg=${gl_cv_func_mbrtowc_null_arg=yes}
gl_cv_func_mbrtowc_retval=${gl_cv_func_mbrtowc_retval=yes}
gl_cv_func_mbrtowc_nul_retval=${gl_cv_func_mbrtowc_nul_retval=yes}
+# TCL
+tcl_cv_api_serial=${tcl_cv_api_serial=termios}
diff --git a/meta/site/common-uclibc b/meta/site/common-uclibc
index 093f60e..002a559 100644
--- a/meta/site/common-uclibc
+++ b/meta/site/common-uclibc
@@ -26,3 +26,6 @@ ac_cv_have_abstract_sockets=${ac_cv_have_abstract_sockets=yes}
# bash
bash_cv_under_sys_siglist=${bash_cv_under_sys_siglist=no}
bash_cv_sys_siglist=${bash_cv_sys_siglist=no}
+
+# TCL
+tcl_cv_api_serial=${tcl_cv_api_serial=termios}
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 21/33] sudo: Drop sudo_cv_uid_t_len from site files
From: Tom Rini tom_r...@mentor.com
We were just setting this to the assumed default. If anything, this
belongs in the libc files if we must set it.
Signed-off-by: Tom Rini tom_r...@mentor.com
---
meta/site/arm-common|3 ---
meta/site/ix86-common |3 ---
meta/site/mips-linux|3 ---
meta/site/mips-linux-uclibc |3 ---
meta/site/mipsel-linux |5 +
meta/site/powerpc32-linux |3 ---
meta/site/sh-common |3 ---
meta/site/x86_64-linux |1 -
8 files changed, 1 insertions(+), 23 deletions(-)
diff --git a/meta/site/arm-common b/meta/site/arm-common
index 04d1164..2129298 100644
--- a/meta/site/arm-common
+++ b/meta/site/arm-common
@@ -191,9 +191,6 @@
ac_cv_have_openpty_ctty_bug=${ac_cv_have_openpty_ctty_bug=yes}
# startup-notification
lf_cv_sane_realloc=yes
-# sudo
-sudo_cv_uid_t_len=${sudo_cv_uid_t_len=10}
-
# xffm
jm_cv_func_working_readdir=yes
diff --git a/meta/site/ix86-common b/meta/site/ix86-common
index 7a7e253..122eb14 100644
--- a/meta/site/ix86-common
+++ b/meta/site/ix86-common
@@ -211,9 +211,6 @@
ac_cv_have_openpty_ctty_bug=${ac_cv_have_openpty_ctty_bug=yes}
# startup-notification
lf_cv_sane_realloc=yes
-# sudo
-sudo_cv_uid_t_len=${sudo_cv_uid_t_len=10}
-
# xffm
jm_cv_func_working_readdir=yes
diff --git a/meta/site/mips-linux b/meta/site/mips-linux
index 807e552..212c3ad 100644
--- a/meta/site/mips-linux
+++ b/meta/site/mips-linux
@@ -76,9 +76,6 @@
samba_cv_HAVE_GETTIMEOFDAY_TZ=${samba_cv_HAVE_GETTIMEOFDAY_TZ=yes}
# vim
ac_cv_sizeof_int=${ac_cv_sizeof_int=4}
-# sudo
-sudo_cv_uid_t_len=${sudo_cv_uid_t_len=10}
-
# intercom
ac_cv_func_fnmatch_works=${ac_cv_func_fnmatch_works=yes}
diff --git a/meta/site/mips-linux-uclibc b/meta/site/mips-linux-uclibc
index 807e552..212c3ad 100644
--- a/meta/site/mips-linux-uclibc
+++ b/meta/site/mips-linux-uclibc
@@ -76,9 +76,6 @@
samba_cv_HAVE_GETTIMEOFDAY_TZ=${samba_cv_HAVE_GETTIMEOFDAY_TZ=yes}
# vim
ac_cv_sizeof_int=${ac_cv_sizeof_int=4}
-# sudo
-sudo_cv_uid_t_len=${sudo_cv_uid_t_len=10}
-
# intercom
ac_cv_func_fnmatch_works=${ac_cv_func_fnmatch_works=yes}
diff --git a/meta/site/mipsel-linux b/meta/site/mipsel-linux
index c59d85f..a9032ac 100644
--- a/meta/site/mipsel-linux
+++ b/meta/site/mipsel-linux
@@ -77,10 +77,7 @@
samba_cv_HAVE_GETTIMEOFDAY_TZ=${samba_cv_HAVE_GETTIMEOFDAY_TZ=yes}
# vim
ac_cv_sizeof_int=${ac_cv_sizeof_int=4}
-# sudo
-sudo_cv_uid_t_len=${sudo_cv_uid_t_len=10}
-
-#intercom
+# intercom
ac_cv_func_fnmatch_works=${ac_cv_func_fnmatch_works=yes}
#lmbench
diff --git a/meta/site/powerpc32-linux b/meta/site/powerpc32-linux
index 46b64eb..8a10111 100644
--- a/meta/site/powerpc32-linux
+++ b/meta/site/powerpc32-linux
@@ -280,9 +280,6 @@ ac_cv_sync_with_stdio_2=${ac_cv_sync_with_stdio_2=yes}
mysql_cv_func_atomic_sub=${mysql_cv_func_atomic_sub=no}
mysql_cv_func_atomic_add=${mysql_cv_func_atomic_add=no}
-# sudo
-sudo_cv_uid_t_len=${sudo_cv_uid_t_len=10}
-
# dpkg
dpkg_cv_va_copy=${ac_cv_va_copy=yes}
dpkg_cv___va_copy=${ac_cv___va_copy=yes}
diff --git a/meta/site/sh-common b/meta/site/sh-common
index 26a612a..63abe57 100644
--- a/meta/site/sh-common
+++ b/meta/site/sh-common
@@ -231,9 +231,6 @@
rsync_cv_HAVE_SECURE_MKSTEMP=${rsync_cv_HAVE_SECURE_MKSTEMP=yes}
rsync_cv_REPLACE_INET_NTOA=${rsync_cv_REPLACE_INET_NTOA=no}
rsync_cv_REPLACE_INET_ATON=${rsync_cv_REPLACE_INET_ATON=no}
-# sudo
-sudo_cv_uid_t_len=${sudo_cv_uid_t_len=10}
-
# ipsec-tools
ac_cv_va_copy=${ac_cv_va_copy=no}
ac_cv_va_val_copy=${ac_cv_va_val_copy=yes}
diff --git a/meta/site/x86_64-linux b/meta/site/x86_64-linux
index 968dedc..91965b9 100644
--- a/meta/site/x86_64-linux
+++ b/meta/site/x86_64-linux
@@ -92,7 +92,6 @@ ac_cv_alignof_CORBA_short=2
ac_cv_alignof_CORBA_struct=1
ac_cv_alignof_CORBA_wchar=2
-sudo_cv_uid_t=${sudo_cv_uid_t_len=10}
lf_cv_sane_realloc=yes
as_cv_unaligned_access=${as_cv_unaligned_access=yes}
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 23/33] Various site files: Drop monotone
From: Tom Rini tom_r...@mentor.com
Not in oe-core nor meta-oe and based on oe.dev, possibly incomplete.
Signed-off-by: Tom Rini tom_r...@mentor.com
---
meta/site/arm-common|3 ---
meta/site/arm-linux |3 ---
meta/site/common-glibc |3 ---
meta/site/ix86-common |3 ---
meta/site/mips-linux|5 -
meta/site/mips-linux-uclibc |5 -
meta/site/mipsel-linux |5 -
meta/site/powerpc32-linux |4
meta/site/sh-common |3 ---
9 files changed, 0 insertions(+), 34 deletions(-)
diff --git a/meta/site/arm-common b/meta/site/arm-common
index 2129298..7317a13 100644
--- a/meta/site/arm-common
+++ b/meta/site/arm-common
@@ -116,9 +116,6 @@ with_broken_putenv=${with_broken_putenv=no}
# links
ac_cv_lib_png_png_create_info_struct=${ac_cv_lib_png_png_create_info_struct=yes}
-# mono
-cv_mono_sizeof_sunpath=108
-
# mysql
mysql_cv_func_atomic_sub=${mysql_cv_func_atomic_sub=no}
mysql_cv_func_atomic_add=${mysql_cv_func_atomic_add=no}
diff --git a/meta/site/arm-linux b/meta/site/arm-linux
index 22b455a..87b45eb 100644
--- a/meta/site/arm-linux
+++ b/meta/site/arm-linux
@@ -154,9 +154,6 @@
ac_cv_have_abstract_sockets=${ac_cv_have_abstract_sockets=yes}
# lftp
ac_cv_file___dev_ptc_=yes
-#mono
-mono_cv_uscore=${mono_cv_uscore=no}
-
# guile
ac_cv_func_pthread_attr_getstack=${ac_cv_func_pthread_attr_getstack=yes}
diff --git a/meta/site/common-glibc b/meta/site/common-glibc
index baca5f8..258f9ad 100644
--- a/meta/site/common-glibc
+++ b/meta/site/common-glibc
@@ -38,9 +38,6 @@ ac_cv_have_abstract_sockets=${ac_cv_have_abstract_sockets=yes}
# gnucash
am_cv_scanf_lld=${am_cv_scanf_lld=yes}
-# mono
-mono_cv_uscore=${mono_cv_uscore=no}
-
# guile
ac_cv_func_pthread_attr_getstack=${ac_cv_func_pthread_attr_getstack=yes}
diff --git a/meta/site/ix86-common b/meta/site/ix86-common
index 122eb14..141ef3a 100644
--- a/meta/site/ix86-common
+++ b/meta/site/ix86-common
@@ -137,9 +137,6 @@
ac_libnet_have_packet_socket=${ac_libnet_have_packet_socket=yes}
# libxfce4util
with_broken_putenv=${with_broken_putenv=no}
-# mono
-cv_mono_sizeof_sunpath=108
-
# mysql
mysql_cv_func_atomic_sub=${mysql_cv_func_atomic_sub=yes}
mysql_cv_func_atomic_add=${mysql_cv_func_atomic_add=yes}
diff --git a/meta/site/mips-linux b/meta/site/mips-linux
index 212c3ad..b99633b 100644
--- a/meta/site/mips-linux
+++ b/meta/site/mips-linux
@@ -85,11 +85,6 @@ ac_cv_uint=${ac_cv_unit=yes}
# D-BUS
ac_cv_func_posix_getpwnam_r=${ac_cv_func_posix_getpwnam_r=yes}
-# mono
-cv_mono_sizeof_sunpath=108
-mono_cv_sizeof_sunpath=108
-mono_cv_uscore=${mono_cv_uscore=no}
-
# popt
ac_cv_va_copy=${ac_cv_va_copy=yes}
ac_cv___va_copy=${ac_cv___va_copy=yes}
diff --git a/meta/site/mips-linux-uclibc b/meta/site/mips-linux-uclibc
index 212c3ad..b99633b 100644
--- a/meta/site/mips-linux-uclibc
+++ b/meta/site/mips-linux-uclibc
@@ -85,11 +85,6 @@ ac_cv_uint=${ac_cv_unit=yes}
# D-BUS
ac_cv_func_posix_getpwnam_r=${ac_cv_func_posix_getpwnam_r=yes}
-# mono
-cv_mono_sizeof_sunpath=108
-mono_cv_sizeof_sunpath=108
-mono_cv_uscore=${mono_cv_uscore=no}
-
# popt
ac_cv_va_copy=${ac_cv_va_copy=yes}
ac_cv___va_copy=${ac_cv___va_copy=yes}
diff --git a/meta/site/mipsel-linux b/meta/site/mipsel-linux
index a9032ac..3347914 100644
--- a/meta/site/mipsel-linux
+++ b/meta/site/mipsel-linux
@@ -85,11 +85,6 @@ ac_cv_uint=${ac_cv_unit=yes}
# D-BUS
ac_cv_func_posix_getpwnam_r=${ac_cv_func_posix_getpwnam_r=yes}
-
-#mono
-cv_mono_sizeof_sunpath=108
-mono_cv_uscore=${mono_cv_uscore=no}
-
# popt
ac_cv_va_copy=${ac_cv_va_copy=yes}
ac_cv___va_copy=${ac_cv___va_copy=yes}
diff --git a/meta/site/powerpc32-linux b/meta/site/powerpc32-linux
index 8a10111..c0e3804 100644
--- a/meta/site/powerpc32-linux
+++ b/meta/site/powerpc32-linux
@@ -272,10 +272,6 @@ samba_cv_have_longlong=${samba_cv_have_longlong=yes}
samba_cv_have_setresgid=${samba_cv_have_setresgid=yes}
samba_cv_have_setresuid=${samba_cv_have_setresuid=yes}
-#monotone
-ac_cv_sync_with_stdio=${ac_cv_sync_with_stdio=yes}
-ac_cv_sync_with_stdio_2=${ac_cv_sync_with_stdio_2=yes}
-
# mysql
mysql_cv_func_atomic_sub=${mysql_cv_func_atomic_sub=no}
mysql_cv_func_atomic_add=${mysql_cv_func_atomic_add=no}
diff --git a/meta/site/sh-common b/meta/site/sh-common
index 63abe57..bbf98a5 100644
--- a/meta/site/sh-common
+++ b/meta/site/sh-common
@@ -201,9 +201,6 @@ cvs_cv_func_printf_ptr=${cvs_cv_func_printf_ptr=yes}
ac_cv_c_long_double=${ac_cv_c_long_double=yes}
bash_cv_func_sigsetjmp=${bash_cv_func_sigsetjmp=missing}
-# mono
-cv_mono_sizeof_sunpath=108
-
# mysql
mysql_cv_func_atomic_sub=${mysql_cv_func_atomic_sub=no}
mysql_cv_func_atomic_add=${mysql_cv_func_atomic_add=no}
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 24/33] Various siteinfo files: Consolidate ac_cv_func_getaddrinfo
From: Tom Rini tom_r...@mentor.com
This is a libc feature, move there. Drop the ipsec-tools specific
test as ipsec-tools (a) assumes fine on cross-compile and (b) doesn't
support buggy getaddrinfo now.
Signed-off-by: Tom Rini tom_r...@mentor.com
---
meta/site/arm-common |2 --
meta/site/common-glibc|1 +
meta/site/common-uclibc |1 +
meta/site/ix86-common |2 --
meta/site/mips-linux |1 -
meta/site/mips-linux-uclibc |1 -
meta/site/mipsel-linux|1 -
meta/site/mipsel-linux-uclibc |1 -
meta/site/powerpc32-linux |1 -
meta/site/sh-common |2 --
meta/site/x86_64-linux-uclibc |1 -
11 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/meta/site/arm-common b/meta/site/arm-common
index 7317a13..65ebd06 100644
--- a/meta/site/arm-common
+++ b/meta/site/arm-common
@@ -87,7 +87,6 @@ ac_cv_strerror_r_SUSv3=${ac_cv_strerror_r_SUSv3=no}
ac_cv_va_copy=${ac_cv_va_copy=yes}
ac_cv___va_copy=${ac_cv___va_copy=yes}
ac_cv_va_val_copy=${ac_cv_va_val_copy=yes}
-racoon_cv_bug_getaddrinfo=${racoon_cv_bug_getaddrinfo=no}
# jikes
ac_cv_sizeof_wchar_t=4
@@ -137,7 +136,6 @@ ac_cv_alignof_CORBA_pointer=4
ac_cv_alignof_CORBA_short=2
ac_cv_alignof_CORBA_struct=1
ac_cv_alignof_CORBA_wchar=2
-ac_cv_func_getaddrinfo=${ac_cv_func_getaddrinfo=yes}
# php
ac_cv_pread=${ac_cv_pread=no}
diff --git a/meta/site/common-glibc b/meta/site/common-glibc
index 258f9ad..8cb8b8e 100644
--- a/meta/site/common-glibc
+++ b/meta/site/common-glibc
@@ -13,6 +13,7 @@ ac_cv_func_getpwuid_r=${ac_cv_func_getpwuid_r=yes}
ac_cv_func_posix_getpwuid_r=${ac_cv_func_posix_getpwuid_r=yes}
ac_cv_func_posix_getgrgid_r=${ac_cv_func_posix_getgrgid_r=yes}
ac_cv_type_uid_t={ac_cv_type_uid_t=yes}
+ac_cv_func_getaddrinfo=${ac_cv_func_getaddrinfo=yes}
# bash
bash_cv_under_sys_siglist=${bash_cv_under_sys_siglist=yes}
diff --git a/meta/site/common-uclibc b/meta/site/common-uclibc
index 002a559..d8a66a6 100644
--- a/meta/site/common-uclibc
+++ b/meta/site/common-uclibc
@@ -11,6 +11,7 @@ ac_cv_func_getgrgid_r=${ac_cv_func_getgrgid_r=yes}
ac_cv_func_getpwuid_r=${ac_cv_func_getpwuid_r=yes}
ac_cv_func_posix_getpwuid_r=${ac_cv_func_posix_getpwuid_r=yes}
ac_cv_func_posix_getgrgid_r=${ac_cv_func_posix_getgrgid_r=yes}
+ac_cv_func_getaddrinfo=${ac_cv_func_getaddrinfo=yes}
# glib
glib_cv_strlcpy=${glib_cv_strlcpy=no}
diff --git a/meta/site/ix86-common b/meta/site/ix86-common
index 141ef3a..c663466 100644
--- a/meta/site/ix86-common
+++ b/meta/site/ix86-common
@@ -117,7 +117,6 @@ ac_cv_func_fnmatch_works=${ac_cv_func_fnmatch_works=yes}
ac_cv_va_copy=${ac_cv_va_copy=no}
ac_cv___va_copy=${ac_cv___va_copy=yes}
ac_cv_va_val_copy=${ac_cv_va_val_copy=yes}
-racoon_cv_bug_getaddrinfo=${racoon_cv_bug_getaddrinfo=no}
# jikes-native
ac_cv_sizeof_wchar_t=4
@@ -154,7 +153,6 @@ ac_cv_alignof_CORBA_pointer=4
ac_cv_alignof_CORBA_short=2
ac_cv_alignof_CORBA_struct=4
ac_cv_alignof_CORBA_wchar=2
-ac_cv_func_getaddrinfo=${ac_cv_func_getaddrinfo=yes}
# php
ac_cv_pread=${ac_cv_pread=no}
diff --git a/meta/site/mips-linux b/meta/site/mips-linux
index b99633b..e90b983 100644
--- a/meta/site/mips-linux
+++ b/meta/site/mips-linux
@@ -36,7 +36,6 @@ glib_cv_use_pid_surrogate=${glib_cv_use_pid_surrogate=yes}
# libpcap
ac_cv_linux_vers=${ac_cv_linux_vers=2}
-ac_cv_func_getaddrinfo=${ac_cv_func_getaddrinfo=yes}
# slrn
slrn_cv___va_copy=${slrn_cv___va_copy=yes}
diff --git a/meta/site/mips-linux-uclibc b/meta/site/mips-linux-uclibc
index b99633b..e90b983 100644
--- a/meta/site/mips-linux-uclibc
+++ b/meta/site/mips-linux-uclibc
@@ -36,7 +36,6 @@ glib_cv_use_pid_surrogate=${glib_cv_use_pid_surrogate=yes}
# libpcap
ac_cv_linux_vers=${ac_cv_linux_vers=2}
-ac_cv_func_getaddrinfo=${ac_cv_func_getaddrinfo=yes}
# slrn
slrn_cv___va_copy=${slrn_cv___va_copy=yes}
diff --git a/meta/site/mipsel-linux b/meta/site/mipsel-linux
index 3347914..7292f6f 100644
--- a/meta/site/mipsel-linux
+++ b/meta/site/mipsel-linux
@@ -37,7 +37,6 @@ glib_cv_use_pid_surrogate=${glib_cv_use_pid_surrogate=yes}
# libpcap
ac_cv_linux_vers=${ac_cv_linux_vers=2}
-ac_cv_func_getaddrinfo=${ac_cv_func_getaddrinfo=yes}
# slrn
slrn_cv___va_copy=${slrn_cv___va_copy=yes}
diff --git a/meta/site/mipsel-linux-uclibc b/meta/site/mipsel-linux-uclibc
index 3c8f41e..ed426a9 100644
--- a/meta/site/mipsel-linux-uclibc
+++ b/meta/site/mipsel-linux-uclibc
@@ -31,7 +31,6 @@ glib_cv_va_val_copy=${glib_cv_va_val_copy=yes}
# libpcap
ac_cv_linux_vers=${ac_cv_linux_vers=2}
-ac_cv_func_getaddrinfo=${ac_cv_func_getaddrinfo=yes}
# slrn
slrn_cv___va_copy=${slrn_cv___va_copy=yes}
diff --git a/meta/site/powerpc32-linux b/meta/site/powerpc32-linux
index c0e3804..60dad35 100644
--- a/meta/site/powerpc32-linux
+++ b/meta/site/powerpc32-linux
@@ -180,7 +180,6 @@ ac_cv_alignof_CORBA_pointer=4
ac_cv_alignof_CORBA_short=2
ac_cv_alignof_CORBA_struct=4
ac_cv_alignof_CORBA_wchar=2
[OE-core] [CONSOLIDATED PULL 28/33] siteinfo: Add posix_getpwuid_r posix_getgrgid_r posix_getpwnam_r to uclibc
From: Tom Rini tom_r...@mentor.com
This comes from oe.dev and while at this, drop from powerpc-linux as the
common-libc files set them.
Signed-off-by: Tom Rini tom_r...@mentor.com
---
meta/site/common-uclibc |5 +
meta/site/powerpc-linux |1 -
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/meta/site/common-uclibc b/meta/site/common-uclibc
index b4a313e..b77eec6 100644
--- a/meta/site/common-uclibc
+++ b/meta/site/common-uclibc
@@ -34,5 +34,10 @@ ac_cv___va_copy=${ac_cv___va_copy=yes}
ac_cv_func_va_copy=${ac_cv_func_va_copy=yes}
ac_cv_func___va_copy=${ac_cv_func___va_copy=yes}
+# posix_getpwuid_r posix_getgrgid_r posix_getpwnam_r
+ac_cv_func_posix_getpwuid_r=${ac_cv_func_posix_getpwuid_r=yes}
+ac_cv_func_posix_getgrgid_r=${ac_cv_func_posix_getgrgid_r=yes}
+ac_cv_func_posix_getpwnam_r=${ac_cv_func_posix_getpwnam_r=yes}
+
# TCL
tcl_cv_api_serial=${tcl_cv_api_serial=termios}
diff --git a/meta/site/powerpc-linux b/meta/site/powerpc-linux
index ac681b2..a9f89cb 100644
--- a/meta/site/powerpc-linux
+++ b/meta/site/powerpc-linux
@@ -8,7 +8,6 @@ lf_cv_sane_realloc=yes
glib_cv_stack_grows=${glib_cv_stack_grows=no}
glib_cv_uscore=${glib_cv_uscore=no}
glib_cv_va_val_copy=${glib_cv_va_val_copy=yes}
-ac_cv_func_getpwuid_r=${ac_cv_func_getpwuid_r=yes}
# lftp
lftp_cv_va_val_copy=${lftp_cv_va_val_copy=yes}
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 26/33] Various siteinfo files: Consolidate va_copy/__va_copy/va_val_copy
From: Tom Rini tom_r...@mentor.com
Providing va_copy / __va_copy come down to the libc. va_val_copy
comes down to the architecture. Unfortunately it's assumed true
if not set, so we need to make sure to set this to false for
x86_64 where it is not true.
Signed-off-by: Tom Rini tom_r...@mentor.com
---
meta/site/arm-common | 17 ++---
meta/site/common-glibc|6 ++
meta/site/common-uclibc |6 ++
meta/site/ix86-common | 17 +++--
meta/site/mips-common | 18 +-
meta/site/mips-linux | 12 +---
meta/site/mips-linux-uclibc | 12 +---
meta/site/mipsel-linux| 12 +---
meta/site/mipsel-linux-uclibc |8 +---
meta/site/powerpc-linux | 12 +---
meta/site/powerpc32-linux |9 -
meta/site/sh-common | 13 ++---
meta/site/x86_64-linux| 13 +++--
meta/site/x86_64-linux-uclibc | 11 ---
14 files changed, 60 insertions(+), 106 deletions(-)
diff --git a/meta/site/arm-common b/meta/site/arm-common
index 65ebd06..d5a55b6 100644
--- a/meta/site/arm-common
+++ b/meta/site/arm-common
@@ -1,3 +1,5 @@
+# general
+ac_cv_va_val_copy=${ac_cv_va_val_copy=yes}
ac_cv_func_lstat_dereferences_slashed_symlink=${ac_cv_func_lstat_dereferences_slashed_symlink=yes}
ac_cv_func_lstat_empty_string_bug=${ac_cv_func_lstat_empty_string_bug=no}
ac_cv_func_stat_empty_string_bug=${ac_cv_func_stat_empty_string_bug=no}
@@ -60,9 +62,7 @@ glib_cv_hasinline=${glib_cv_hasinline=yes}
glib_cv_sane_realloc=${glib_cv_sane_realloc=yes}
glib_cv_sizeof_gmutex=${glib_cv_sizeof_gmutex=24}
glib_cv_uscore=${glib_cv_uscore=no}
-glib_cv_va_copy=${glib_cv_va_copy=yes}
glib_cv_va_val_copy=${glib_cv_va_val_copy=yes}
-glib_cv___va_copy=${glib_cv___va_copy=yes}
glib_cv_rtldglobal_broken=${glib_cv_rtldglobal_broken=no}
glib_cv_sys_pthread_mutex_trylock_posix=${glib_cv_sys_pthread_mutex_trylock_posix=yes}
glib_cv_sys_pthread_getspecific_posix=${glib_cv_sys_pthread_getspecific_posix=yes}
@@ -83,19 +83,12 @@ as_cv_unaligned_access=${as_cv_unaligned_access=no}
# httppc
ac_cv_strerror_r_SUSv3=${ac_cv_strerror_r_SUSv3=no}
-# ipsec-tools
-ac_cv_va_copy=${ac_cv_va_copy=yes}
-ac_cv___va_copy=${ac_cv___va_copy=yes}
-ac_cv_va_val_copy=${ac_cv_va_val_copy=yes}
-
# jikes
ac_cv_sizeof_wchar_t=4
# lftp
ac_cv_need_trio=${ac_cv_need_trio=no}
-lftp_cv_va_copy=${lftp_cv_va_copy=yes}
lftp_cv_va_val_copy=${lftp_cv_va_val_copy=yes}
-lftp_cv___va_copy=${lftp_cv___va_copy=yes}
# libesmtp
acx_working_snprintf=${acx_working_snprintf=yes}
@@ -168,8 +161,6 @@
screen_cv_sys_sockets_usable=${screen_cv_sys_sockets_usable=yes}
screen_cv_sys_terminfo_used=${screen_cv_sys_terminfo_used=yes}
# slrn
-slrn_cv___va_copy=${slrn_cv___va_copy=yes}
-slrn_cv_va_copy=${slrn_cv_va_copy=yes}
slrn_cv_va_val_copy=${slrn_cv_va_val_copy=yes}
# socat
@@ -189,9 +180,5 @@ lf_cv_sane_realloc=yes
# xffm
jm_cv_func_working_readdir=yes
-# dpkg
-dpkg_cv_va_copy=${ac_cv_va_copy=yes}
-dpkg_cv___va_copy=${ac_cv___va_copy=yes}
-
# eds-dbus
ac_cv_libiconv_utf8=${ac_cv_libiconv_utf8=yes}
diff --git a/meta/site/common-glibc b/meta/site/common-glibc
index 8cb8b8e..d2e70ed 100644
--- a/meta/site/common-glibc
+++ b/meta/site/common-glibc
@@ -67,5 +67,11 @@
gl_cv_func_mbrtowc_null_arg=${gl_cv_func_mbrtowc_null_arg=yes}
gl_cv_func_mbrtowc_retval=${gl_cv_func_mbrtowc_retval=yes}
gl_cv_func_mbrtowc_nul_retval=${gl_cv_func_mbrtowc_nul_retval=yes}
+# va_copy and _va_copy
+ac_cv_va_copy=${ac_cv_va_copy=yes}
+ac_cv___va_copy=${ac_cv___va_copy=yes}
+ac_cv_func_va_copy=${ac_cv_func_va_copy=yes}
+ac_cv_func___va_copy=${ac_cv_func___va_copy=yes}
+
# TCL
tcl_cv_api_serial=${tcl_cv_api_serial=termios}
diff --git a/meta/site/common-uclibc b/meta/site/common-uclibc
index d8a66a6..b4a313e 100644
--- a/meta/site/common-uclibc
+++ b/meta/site/common-uclibc
@@ -28,5 +28,11 @@
ac_cv_have_abstract_sockets=${ac_cv_have_abstract_sockets=yes}
bash_cv_under_sys_siglist=${bash_cv_under_sys_siglist=no}
bash_cv_sys_siglist=${bash_cv_sys_siglist=no}
+# va_copy and _va_copy
+ac_cv_va_copy=${ac_cv_va_copy=yes}
+ac_cv___va_copy=${ac_cv___va_copy=yes}
+ac_cv_func_va_copy=${ac_cv_func_va_copy=yes}
+ac_cv_func___va_copy=${ac_cv_func___va_copy=yes}
+
# TCL
tcl_cv_api_serial=${tcl_cv_api_serial=termios}
diff --git a/meta/site/ix86-common b/meta/site/ix86-common
index f89835d..0aa54c7 100644
--- a/meta/site/ix86-common
+++ b/meta/site/ix86-common
@@ -1,3 +1,4 @@
+# general
ac_cv_sizeof_char=${ac_cv_sizeof_char=1}
ac_cv_sizeof_unsigned_char=${ac_cv_sizeof_unsigned_int=1}
ac_cv_sizeof_char_p=${ac_cv_sizeof_char_p=4}
@@ -27,6 +28,7 @@
ac_cv_func_pthread_key_delete=${ac_cv_func_pthread_key_delete=yes}
ac_cv_func_setvbuf_reversed=${ac_cv_func_setvbuf_reversed=no}
ac_cv_func_stat_empty_string_bug=${ac_cv_func_stat_empty_string_bug=no}
