We switch to using os.lchown in order to avoid following a symlink.
We also now check if an item is a symlink, if so we avoid the
os.chmod as a symlink inherits the mode of it's target.
Signed-off-by: Mark Hatle
---
meta/classes/package.bbclass | 10 +-
1 files changed, 5 inser
beecrypt/gnu.h conflicts between 32-bit and 64-bit versions.
Signed-off-by: Mark Hatle
---
meta/recipes-support/beecrypt/beecrypt_4.2.1.bb |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-support/beecrypt/beecrypt_4.2.1.bb
b/meta/recipes-support
bfd.h conflicts between 32-bit and 64-bit versions.
Signed-off-by: Mark Hatle
---
meta/recipes-devtools/binutils/binutils.inc |4 +++-
meta/recipes-devtools/binutils/binutils_2.21.1.bb |2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools
We found a minor bug in the patch since it was first sent out:
On 7/26/11 5:50 PM, Richard Purdie wrote:
> From: Mark Hatle
>
> This is a first pass at adding multilib support to the RPM package
> and image handling code.
>
> Signed-off-by: Mark Hatle
> ---
> meta/cla
On 7/27/11 8:33 AM, Richard Purdie wrote:
> On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
>> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
>>> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
>>
>> This seems a bit backwards. Shouldn't TARGET_FPU be the
On 7/27/11 9:29 AM, Richard Purdie wrote:
> This means if PKGARCHCOMPAT_ARMV7A is set, "armv7a-vfp-neon" is renamed
> to be "armv7a". Other compatibility mappings can be added as needed.
There are multiple armv7 cores without neon... I think there might even be one
or two custom cores w/o VFP. (
On 7/27/11 9:33 AM, Koen Kooi wrote:
>
> Op 27 jul. 2011, om 16:27 heeft Mark Hatle het volgende geschreven:
>
>> On 7/27/11 8:33 AM, Richard Purdie wrote:
>>> On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
>>>> On Tue, 2011-07-26 at 13:44 +0100, Ric
On 7/27/11 9:34 AM, Phil Blundell wrote:
> I just looked at this again and here are a few more comments:
>
> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
>> +PACKAGE_EXTRA_ARCHS_tune-armv4tb = "${PACKAGE_EXTRA_ARCHS_tune-armv4}
>> armv4tb"
>
> That should be "${PACKAGE_EXTRA_ARCHS_tu
On 7/27/11 9:44 AM, Phil Blundell wrote:
> On Wed, 2011-07-27 at 09:27 -0500, Mark Hatle wrote:
>> On 7/27/11 8:33 AM, Richard Purdie wrote:
>>> On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
>>>> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
&g
On 7/27/11 10:02 AM, Phil Blundell wrote:
> On Wed, 2011-07-27 at 09:44 -0500, Mark Hatle wrote:
>> On 7/27/11 9:29 AM, Richard Purdie wrote:
>>> This means if PKGARCHCOMPAT_ARMV7A is set, "armv7a-vfp-neon" is renamed
>>> to be "armv7a". Othe
On 7/27/11 10:25 AM, Phil Blundell wrote:
> On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
>> For the tune names.. armv5 means I want classic ARM instructions, while
>> armv5t
>> means I was thumb instructions.
>>
>> So armv5 and armv5t are distinct in the
On 7/27/11 2:31 PM, Phil Blundell wrote:
> On Wed, 2011-07-27 at 12:19 -0500, Mark Hatle wrote:
>> On 7/27/11 10:25 AM, Phil Blundell wrote:
>>> On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
>>>> For the tune names.. armv5 means I want classic ARM in
Sorry I was gone much of yesterday and not able to comment. I'm going to break
this down into the two problems that I see people having.
1) "interworking". I was recently told EABI requires interworking to be
enabled, and in OE-core we only support EABI. So we should always have the
interworkin
On 7/29/11 3:23 PM, Phil Blundell wrote:
> On Fri, 2011-07-29 at 13:08 -0500, Mark Hatle wrote:
>> Sorry I was gone much of yesterday and not able to comment. I'm going to
>> break
>> this down into the two problems that I see people having.
>>
>> 1) &qu
On 8/1/11 4:09 AM, Phil Blundell wrote:
> On Mon, 2011-08-01 at 00:36 -0700, Saul Wold wrote:
>> From: Mark Hatle
>>
>> We need to add the tune-* override in order for more complicated tune
>> features to function properly.
>>
>> Signed-off-by: Mark Hatle
&
acked-by: Mark Hatle
On 8/1/11 6:54 AM, Yu Ke wrote:
> fix the MLPREFIX referrence typo which cause multilib rpm
> do_rootfs failure
>
> CC: Mark Hatle
>
> Signed-off-by: Yu Ke
> ---
> meta/classes/package_rpm.bbclass |2 +-
> 1 files changed, 1 insertions(+
On 8/1/11 8:06 AM, Richard Purdie wrote:
> On Mon, 2011-08-01 at 00:36 -0700, Saul Wold wrote:
>> From: Mark Hatle
>>
>> The sdknative packages were not being introduced into the list of available
>> packages properly. Fix this by always introducing it and avoid
On 8/1/11 9:13 AM, Kumar Gala wrote:
>
> On Aug 1, 2011, at 8:03 AM, Richard Purdie wrote:
>
>> On Mon, 2011-08-01 at 00:36 -0700, Saul Wold wrote:
>>> From: Kumar Gala
>>>
>>> Its more likely that we explicitly set soft-floating point support for a
>>> given target than hard. So use 'fpu-soft'
On 8/1/11 9:26 AM, Kumar Gala wrote:
> Some of powerpc's dont support the fsqrt[s] instructions so we need an
> implementation of the library functions for those processors.
>
> Signed-off-by: Kumar Gala
> ---
> .../recipes-core/eglibc/eglibc-2.13/ppc-sqrt.patch | 538
>
>
On 8/1/11 9:56 AM, Kumar Gala wrote:
>
> On Aug 1, 2011, at 9:53 AM, Mark Hatle wrote:
>
>> On 8/1/11 9:26 AM, Kumar Gala wrote:
>>> Some of powerpc's dont support the fsqrt[s] instructions so we need an
>>> implementation of the library functions for t
On 8/1/11 11:15 AM, Kumar Gala wrote:
> I'm trying to build a powerpc 64-bit system and for some reason everything is
> still in /lib instead of /lib64.
>
> I'd expect things in /lib64 based on how arch-powerpc64.inc has:
>
> BASE_LIB_tune-powerpc64 = "lib64"
>
> any ideas on what to look at fo
In order for things to be easier to maintain in the future, sync up
the sdk and rootfs versions.
Signed-off-by: Mark Hatle
---
meta/classes/populate_sdk_deb.bbclass | 24
meta/classes/populate_sdk_rpm.bbclass | 68
meta/classes
"target_rootfs", this fixes a problem
with the SDK case.
in rootfs_rpm.bbclass:
Minor re-order of the values, and avoid multiple uses of IMAGE_ROOTFS in order
to make the merge with the SDK behavior easier.
Signed-off-by: Mark Hatle
---
meta/classes/package_rpm.bbcl
dependency.
NOTE: THIS BREAKS IPK AND DEB PACKAGE GENERATION! IT SHOULD NOT BE
MERGED!
Signed-off-by: Mark Hatle
---
meta/classes/update-alternatives.bbclass |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/meta/classes/update-alternatives.bbclass
b/meta/classes/upd
During SDK generation the multilib_sanity_check function is being called,
however it is not available unless we've been called from the image.bbclass.
Disable the check if MULTILIB_CHECK_FILE (also set in image.bbclass) doesn't
exist or is empty.
Signed-off-by: Mark Hatle
---
me
-neon -> armv7a compat case (2011-08-01
16:49:03 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib mhatle/oecore/sdk-fix-WIP
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/oecore/sdk-fix-WIP
Mark Hatle (5):
rootfs_rpm: Cleanup and minor b
value was being set,
noticed while working on this change.
Signed-off-by: Mark Hatle
---
meta/classes/package_deb.bbclass |6 +
meta/classes/package_ipk.bbclass | 37 +++-
meta/classes/package_rpm.bbclass | 10 +
meta/classes
On 8/2/11 5:11 AM, Richard Purdie wrote:
> On Tue, 2011-08-02 at 07:28 +, James Limbouris wrote:
>> Hi,
>>
>> I've just switched to oe-core from -dev, and I'm finding that my root
>> images are showing incorrect permissions on files, randomly. From one
>> build to the next, different subsets of
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 pat
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
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 wi
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.
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 r
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:
>
>
ion
results in a working -- non-conflicting -- install solution.)
--Mark
> CC: Mark Hatle
> Signed-off-by: Dongxiao Xu
> ---
> meta/classes/package_rpm.bbclass | 13 ++---
> meta/classes/populate_sdk_rpm.bbclass |3 ---
> meta/classes/rootfs_rpm.bbclas
b prefix.
>
> CC: Mark Hatle
> Signed-off-by: Dongxiao Xu
> ---
> 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
> ind
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 8/3/11 11:03 PM, Kumar Gala wrote:
> We might redefine ${base_libdir} from being set to just /lib.
>
> Signed-off-by: Kumar Gala
Only tangentially related to this patch.. It doesn't appear mklibs has knowledge
of multilibs.. but I don't think anyone would use mklibs with a multilib
environmen
On 8/4/11 12:37 AM, Kumar Gala wrote:
>
> On Aug 3, 2011, at 10:09 AM, Mark Hatle wrote:
>
>> 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:
>>
On 8/4/11 1:05 AM, Kumar Gala wrote:
> Handle multlib or cases that baselib is lib64.
>
> Signed-off-by: Kumar Gala
Acked-by: Mark Hatle
(BTW I think as we move more into the multilib stuff, we'll likely want to
generate this list from the final multilib configuration.. bu
On 8/4/11 9:03 AM, Kumar Gala wrote:
>
> On Aug 4, 2011, at 12:37 AM, Kumar Gala wrote:
>
>>
>> On Aug 3, 2011, at 10:09 AM, Mark Hatle wrote:
>>
>>> On 8/3/11 9:53 AM, Kumar Gala wrote:
>>>>
>>>> On Aug 3, 2011, at 9:37 AM, Mark
On 8/4/11 10:58 AM, Kumar Gala wrote:
> | error: Failed dependencies:
> | hicolor-icon-theme is needed by tasks-0.19-r0.ppc603e
> | hicolor-icon-theme is needed by connman-gnome-0.5-r6.ppc603e
The actual failure is above... the items below are indicating circular
dependencies within t
pseudo currently only works on IA32 hosts. It was never really intended to work
on the target system, but should.
If you think you want pseudo on the target.. you'll have to verify that all of
the calls are being trapped properly on ARM, as well as modify the build
instructions to not worry about
On 8/9/11 7:32 PM, Scott Garman wrote:
> On 08/08/2011 07:04 PM, James Limbouris wrote:
>> The pseudo executable sets the PSEUDO_LOCALSTATEDIR environment variable
>> to point to a sysroot location. During an initial cache build, in which
>> pseudo is not used as it is being built, the PSEUDO_LOCAL
I don't think the patch is correct. If these tune files are included, the
GLIBC_EXTRA_OECONF is set unconditionally. It is possible to include the tune
files, but not actually use the tunings. (There are cases where you might want
to inherit specific tunings, etc.)
Instead, I'd suggest you do:
On 8/10/11 3:06 PM, Kumar Gala wrote:
> Why?
>
> - k
>
> On Aug 10, 2011, at 2:19 PM, Mark Hatle wrote:
>
>> I don't think the patch is correct. If these tune files are included, the
>> GLIBC_EXTRA_OECONF is set unconditionally. It is possible to inc
:
package_rpm.bbclass: Update the platform config and --target (2011-08-11
10:42:02 -0500)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib mhatle/fix_1352
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/fix_1352
Mark Hatle (2):
rpm: Fix the
canonical arch via the --target=
parameter. This allows us to define the proper platform settings
for all packages.
Signed-off-by: Mark Hatle
---
meta/classes/package_rpm.bbclass | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/meta/classes/package_rpm.bbcl
[YOCTO #1352]
Fix the canonical arch --target processor to work with the way OE
handles the GNU canonical arch.
Also cleanup a number of files that are no longer used, and refactor
the no-loop patch into the "no-loopmsg" patch.
Signed-off-by: Mark Hatle
---
.../recipes-devtools/rpm/
ed.org
>>> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
>> Of
>>> Mark Hatle
>>> Sent: Wednesday, August 03, 2011 11:32 PM
>>> To: openembedded-core@lists.openembedded.org
>>> Subject: Re: [OE-core] [PATCH 5/7] multilib: remove
>
On 8/11/11 6:25 AM, Phil Blundell wrote:
> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
>> +# MIPS Architecture definition
>> +# 12 defined ABIs, all combinations of:
>> +# *) Big/Little Endian
>> +# *) Hardware/Software Floating Point
>> +# *) o32, n32, n64 ABI
>> +
>> +DEFAULTTUNE ?=
I have a similar fix coming. This one is close, but there are a few other
changes that are needed still.
--Mark
On 8/11/11 7:09 PM, Saul Wold wrote:
> Richard:
>
> This issue was introduced with the recent IMAGE_FEATURES changes,
> since the ATTEMPTONLY was not really being used it had not bee
:
gnome-doc-utils: respect python-dir setting EXTRA_OECONF (2011-08-11 19:13:38
+0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib mhatle/fix_1366
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/fix_1366
Mark Hatle (3):
rpm: Fix the canonical arch
is as the names
are munged when creating the packages.)
Signed-off-by: Mark Hatle
---
meta/classes/package_rpm.bbclass | 25 -
1 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index 5c
On 8/12/11 7:49 AM, Richard Purdie wrote:
> local.conf is the first thing anyone new to the project sees. Over time it
> has built up a ton cruft and isn't even accurate in places.
>
> This patch:
>
> * Moves things to local.conf.sample.extended if a new user is unlikely
> to need to imme
On 8/12/11 9:35 AM, Phil Blundell wrote:
> On Fri, 2011-08-12 at 15:33 +0100, Richard Purdie wrote:
>>> Should patch resolution be noop by default? (I suspect due to my above
>>> concern
>>> w/ ipkg, changing the behavior now is likely a bad idea.)
>>
>> Good question. I suspect most people prefe
b.
> 4) Add a new patch "gtk-icon-cache: Adding MLPREFIX when dynamically set
>RDEPENDS" to fix the dynamic setting of RDEPENDS in multilib case.
>
> [YOCTO #1368]
I assume this has been tests...
It looks fine here..
Acked-by: Mark Hatle
> Thanks,
> Dongx
I've been getting reports that people are experiencing crashed with the
cross-prelinker on 64-bit only filesystems. This includes both x86_64 and
PPC64.
In the case of the PPC64, there is one or more bug in the cross-prelinker rtld
emulation which I'm currently working on.
x86_64 however seems
On 9/1/11 11:41 AM, Phil Blundell wrote:
> On Thu, 2011-09-01 at 15:46 +0100, Phil Blundell wrote:
>> I just tried using useradd.bbclass for the first time (in an effort to
>> make dbus installable on a readonly-rootfs) and it doesn't seem to be
>> working very well for me.
>>
>> The root of my pro
On 9/1/11 11:58 AM, Phil Blundell wrote:
> On Thu, 2011-09-01 at 11:54 -0500, Mark Hatle wrote:
>> What is it depending on for the target? Is the shadow-utils or something now
>> required? That doesn't seem to make sense to me -- other then we need a
>> passwd/group/s
On 9/1/11 4:59 PM, Richard Purdie wrote:
> On Thu, 2011-09-01 at 20:44 +0100, Phil Blundell wrote:
>> On Thu, 2011-09-01 at 12:25 -0500, Mark Hatle wrote:
>>> On 9/1/11 11:58 AM, Phil Blundell wrote:
>>>> And, I guess, if you want to support online package manageme
On 9/2/11 1:43 PM, Phil Blundell wrote:
> On Fri, 2011-09-02 at 15:03 +0100, Richard Purdie wrote:
>> Seriously, does opkg have the logic in it to run this stuff? If so
>> perhaps we need to teach opkg about offline postinstalls since it should
>> already know about dependencies?
>
> Yeah, that mi
41b7c955cfdc7b4d5c667c8a8742237d5edaca4f:
icu-3.6: fix building with big make -j (2011-09-05 20:38:50 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib mhatle/prelink
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/prelink
Mark Hatle (1):
prelink
underlying problem is
within the toolchain, however prelink was making it worse leaving the
problem undetected.
Signed-off-by: Mark Hatle
---
meta/recipes-devtools/prelink/prelink_git.bb |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/prelink
Which architecture?
I know of a few issues on MIPS, but they should simply prevent prelinking
instead of causing problems.
Also, can you check your log.do_rootfs for the failed image. Look for any
prelinker warnings or errors. (Easiest way is to search for "prelink". There
should be two hits,
tion between
the two could point to an alternative cause to the QT failure as well.
--Mark
On 9/11/11 8:39 PM, James Limbouris wrote:
>> -Original Message-
>> From: openembedded-core-boun...@lists.openembedded.org
>> [mailto:openembedded-core-boun...@lists.openembedded.o
This patch is incorrect. Architectural information should not be in the
dependencies within RPM packages.
RPM is expected to find the proper version of a package to install based on the
existing dependency information. I'm in the process of investigating why
certain items are not found properly.
On 9/12/11 3:34 AM, Dongxiao Xu wrote:
> Currently MACHINE_ARCH deploy folder is unique in multilib system, thus
> a lib32 version of rpm package will override a normal rpm package if
> its PACKAGE_ARCH is ${MACHINE_ARCH}.
>
> Define different deploy folder for multilib architectures to avoid the
On 9/12/11 10:07 AM, Xu, Dongxiao wrote:
> Hi Mark,
>
>> -Original Message-
>> From: openembedded-core-boun...@lists.openembedded.org
>> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
>> Mark Hatle
>> Sent: Monday, September 1
On 9/12/11 9:39 PM, Xu, Dongxiao wrote:
> Hi Mark,
>
>> -Original Message-
>> From: openembedded-core-boun...@lists.openembedded.org
>> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
>> Mark Hatle
>> Sent: Tuesday, September
On 9/12/11 9:24 PM, Xu, Dongxiao wrote:
> Hi Mark,
>
>> -Original Message-
>> From: openembedded-core-boun...@lists.openembedded.org
>> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
>> Mark Hatle
>> Sent: Monday, September 1
On 9/13/11 10:41 AM, Xu, Dongxiao wrote:
> Hi Mark,
>
>> -Original Message-----
>> From: Mark Hatle [mailto:mark.ha...@windriver.com]
>> Sent: Tuesday, September 13, 2011 11:29 PM
>> To: Xu, Dongxiao
>> Cc: Patches and discussions about the oe-core layer
x86 (32-bit) targets and arm
targets.
Signed-off-by: Mark Hatle
---
meta/recipes-devtools/prelink/prelink_git.bb |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/prelink/prelink_git.bb
b/meta/recipes-devtools/prelink/prelink_git.bb
index 1565
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/prelink
Mark Hatle (1):
Uprev to latest version of prelink_git, fixing TLS issues
meta/recipes-devtools/prelink/prelink_git.bb |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--
1.
Please try the new version of the prelinker. I just sent a pull request for it,
but there was a missing typecast on a printf. This was causing problems on
various systems, and likely could be causing the issue that you observed on ARM
as well.
I did build the latest version for the ARM target, a
printf (" TLS(0x%Zx, 0x%0*Zx)\n", l->l_tls_modid,
+printf (" TLS(0x%Zx, 0x%0*Zx)\n", (size_t) l->l_tls_modid,
(int) size_pointer,
(size_t) l->l_tls_offset);
else
l->l_tls_modid is a uint64_t
On 9/13/11 7:46 PM, Joshua Lock wrote:
> Our patch submission policy[1]
>
> "Optionally, you may include pointers to defects this change corrects.
> Unless the defect format is specified by the component you are
> modifying, it is suggested that you use a full URL to specify the
> reference to th
On 9/13/11 8:33 PM, James Limbouris wrote:
>> -Original Message-
>> From: openembedded-core-boun...@lists.openembedded.org
>> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
>> Mark Hatle
>> Sent: Wednesday, 14 September 2011 8:
On 9/13/11 8:03 PM, Xu, Dongxiao wrote:
> Hi Mark,
>
...trimming the thread a bit...
>> This patch is incorrect. Architectural information should not be
>> in the dependencies within RPM packages.
>>
>> RPM is expected to find the proper version of a package to install
>> ba
On 9/13/11 9:56 PM, Xu, Dongxiao wrote:
> Hi Mark,
>
>> -Original Message-
>> From: openembedded-core-boun...@lists.openembedded.org
>> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
>> Mark Hatle
>> Sent: Tuesday, September 1
I still don't think this is what we want. Let me look into the library issues
that you mentioned in the other thread and I'll see if we can deal with it that
way.
(Note, we may need to use something like this in non-RPM cases.. but I'm not
sure about that either.)
--Mark
On 9/14/11 1:08 AM, Do
This looks fine. The do_archgen() function within the libzypp_git.bb will need
to be updated to look for the multilib machine type as well.
--Mark
On 9/14/11 1:08 AM, Dongxiao Xu wrote:
> Currently MACHINE_ARCH deploy folder is unique in multilib system, thus
> a lib32 version of rpm package wil
On 9/16/11 4:32 AM, Richard Purdie wrote:
> Hi Mark/Dongxaio,
>
> We really need to get the remainder of the multilib bugs wrapped up. I
> think there is some confusion about the exact approach to take to fix
> some of them so I'm hoping to try and summarise the problems here so we
> can work out
On 9/16/11 10:21 AM, Xu, Dongxiao wrote:
>> -Original Message-
>> From: Mark Hatle [mailto:mark.ha...@windriver.com]
>> Sent: Friday, September 16, 2011 10:51 PM
>> To: Richard Purdie
>> Cc: Xu, Dongxiao; openembedded-core
>> Subject: Re: Multilib stat
large set of problems that I didn't realize we
had
Will do a more formal pull request as soon as I get things working again.
--Mark
On 9/16/11 10:26 AM, Mark Hatle wrote:
> On 9/16/11 10:21 AM, Xu, Dongxiao wrote:
>>> >> -Original Message-
>>> >&
On 9/16/11 2:06 PM, Otavio Salvador wrote:
> On Fri, Sep 16, 2011 at 14:49, Paul Eggleton
> wrote:
>> On Friday 16 September 2011 18:18:43 you wrote:
>>> They all ended up in oe-core the problem is when they're not yet
>>> merged but I want to merge them into my tree for use, test or
>>> anything.
On 9/17/11 11:13 AM, Denis 'GNUtoo' Carikli wrote:
> hi,
> I've an HTC Dream, it has an armv6 CPU but lack a vfp unit.
> I want to add correct support for it in meta-smartphone/meta-htc.
> In order to have a correct machine config that works a tune inc file
> must be required in it.
>
> In openemb
On 9/19/11 12:55 PM, Saul Wold wrote:
> [YOCTO #1492]
>
> Since the non-GPLv3 build does not want gnome, which this will pull in
> by the default DISTRO_FEATURE x11 being set and enabling gtk for avahi,
> we filter x11 out of DISTRO_FEATURES here when INCOMPATIBLE_LICENSE is
> set to GPLv3.
If th
On 9/20/11 10:01 AM, Xu, Dongxiao wrote:
> Hi Mark,
>
>> -Original Message-----
>> From: Mark Hatle [mailto:mark.ha...@windriver.com]
>> Sent: Saturday, September 17, 2011 2:19 AM
>> To: Mark Hatle
>> Cc: Xu, Dongxiao; Richard Purdie; openembedded-
gt; -Original Message-
>>>> From: Mark Hatle [mailto:mark.ha...@windriver.com]
>>>> Sent: Saturday, September 17, 2011 2:19 AM
>>>> To: Mark Hatle
>>>> Cc: Xu, Dongxiao; Richard Purdie; openembedded-core
>>>> Subject: Re: Multilib statu
On 9/20/11 12:34 PM, Xu, Dongxiao wrote:
>> -Original Message-
>> From: Mark Hatle [mailto:mark.ha...@windriver.com]
>> Sent: Wednesday, September 21, 2011 1:06 AM
>> To: Xu, Dongxiao
>> Cc: Richard Purdie; openembedded-core
>> Subject:
On 9/20/11 2:03 PM, Daniel Lazzari wrote:
> I noticed a problem with the alsa-utils package where the alsa-utils package
> does not depend on all of the little extra packages it's supposed to pull in.
> I'm not sure what the best way to fix this is though. Can anyone give me a
> little guidance
On 9/20/11 2:04 PM, Dmitry Eremin-Solenikov wrote:
> Hello, colleagues,
>
> While debugging some stuff in oe-core & company I've noticed that
> lot's of packages
> either don't use INC_PR, or misuse it (e.g. .inc has INC_PR, but then
> .bb just defines PR = "rX").
I've noticed similar things. I'
REFIX, therefore we need to enumerate the possible
multilib prefixes and compare them with package prefixes.
Signed-off-by: Dongxiao Xu
Signed-off-by: Mark Hatle
---
meta/classes/package_rpm.bbclass | 42 +
meta/classes/rootfs_rpm.bbclass |4 +++
2 files change
RCH to fix this
issue.
Signed-off-by: Dongxiao Xu
Signed-off-by: Mark Hatle
---
meta/classes/rootfs_rpm.bbclass |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/meta/classes/rootfs_rpm.bbclass b/meta/classes/rootfs_rpm.bbclass
index 135ca75..56c1a85 100644
--- a/me
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/rpm.deps
Dongxiao Xu (2):
rootfs_rpm: Use specific MACHINE_ARCH for multilib recipes
multilib: install MULTILIB_IMAGE_INSTALL
Mark Hatle (5):
Fix RPM dependencies
Add a run-time dependency that eglibc support GNU_HASH
Upda
RPM checks to see if binaries require GNU_HASH, if they do it adds
an automatic dependency of "rtld(GNU_HASH)". We need to satisfy
this dependency, and we do it by providing rtld(GNU_HASH) in the
package(s) that provide a runtime-linker.
Signed-off-by: Mark Hatle
---
meta/recipes-c
Since pythondeps changed, the
output of rpmdeps changes, which causes the per-file dependency
information to change thus we need to invalidate the cache!
Signed-off-by: Mark Hatle
---
meta/classes/package.bbclass|6 ++
meta/recipes-devtools/rpm/rpm/pythondeps.sh |
When packaging for RPM, dependencies were not being properly added
to the packages. Only the "providing" dependencies were added due
to a typo.
Signed-off-by: Mark Hatle
---
meta/classes/package_rpm.bbclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/me
e suddenly providing all variants of an object.
Signed-off-by: Mark Hatle
---
meta/classes/multilib_global.bbclass | 30 +-
1 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/meta/classes/multilib_global.bbclass
b/meta/classes/multilib_global.bbclass
ind
101 - 200 of 1466 matches
Mail list logo
