From: Xiaofeng Yan xiaofeng@windriver.com
The usability of the archiver classes can be improved, beyond the
simple addition of default values for the variables.
A user could well inherit just archiver rather than the individual
useful classes, and not realize it will do nothing.
The
From: Xiaofeng Yan xiaofeng@windriver.com
The usability of the archiver classes can be improved, beyond the
simple addition of default values for the variables. A user could
well inherit just archiver rather than the individual useful classes,
and not realize it will do nothing.
[YOCTO
From: Xiaofeng Yan xiaofeng@windriver.com
Change the usage about arhiver.bbclass due to the improvement for
usability of archiver.bbclass
[YOCTO #2472]
Signed-off-by: Xiaofeng Yan xiaofeng@windriver.com
---
meta-yocto/conf/local.conf.sample.extended | 31 ---
The os.popen function would fail (more or less) silently if the executed
program cannot be found, and here what we need is os.system not os.popen
since it doesn't use the return value, use os.unlink() and ignore
exceptions from it would be better as Chris suggested.
[YOCTO #2454]
Signed-off-by:
Unstable version 1.5.12 also supported
Signed-off-by: Radu Moisan radu.moi...@intel.com
---
.../dbus/{dbus-1.4.16 = dbus-1.4.20}/dbus-1.init |0
.../dbus/{dbus-1.4.16 = dbus-1.4.20}/tmpdir.patch |0
meta/recipes-core/dbus/dbus-1.5.12/dbus-1.init | 121
Hi Khem,
2012/5/30 Khem Raj raj.k...@gmail.com
On Wed, May 30, 2012 at 8:18 AM, Giuseppe Condorelli
giuseppe.condore...@gmail.com wrote:
It fails on undefined reference to xmalloc, xcalloc, etc... that however
are
internally defined and used as wrapper for real malloc, etc...
Please,
Op 31 mei 2012, om 11:17 heeft Radu Moisan het volgende geschreven:
Unstable version 1.5.12 also supported
This should be split into at least 2 seperate commits.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
From: Xin Ouyang xin.ouy...@windriver.com
If there is a patch to Makefile.PL, a Makefile.PL but no Makefile
will be placed in ${B}/.pc/xxx.patch/ after do_patch.
And no Makefile will be generated for *this* Makefile.PL.
While do_configure, the original code tries to sed Makefiles
matching with
A use-case would have been [1].
The following tests were performed:
* image from scratch with old buildhistory contents
* image from scratch with buildhistory contents from scratch
* decrement a PR for a test recipe and check if the message
'ERROR: Package version for xy went backwards' is
Signed-off-by: Andreas Müller schnitzelt...@googlemail.com
---
meta/lib/oe/buildhistory_analysis.py |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/meta/lib/oe/buildhistory_analysis.py
b/meta/lib/oe/buildhistory_analysis.py
index 29dc4a9..2b4582e 100644
---
2012/5/31 Giuseppe Condorelli giuseppe.condore...@gmail.com
Hi Khem,
2012/5/30 Khem Raj raj.k...@gmail.com
On Wed, May 30, 2012 at 8:18 AM, Giuseppe Condorelli
giuseppe.condore...@gmail.com wrote:
It fails on undefined reference to xmalloc, xcalloc, etc... that
however are
internally
Currently, the task just exits if something goes wrong. This adds the
ncurses-native dependency. It also adds a small delay before closing the
window so any messages displayed there can be seen.
Trying to get the kernel build system to correctly find and link with
our copy of ncurses is some kind
On Thu, May 31, 2012 at 5:35 AM, Giuseppe Condorelli
giuseppe.condore...@gmail.com wrote:
Is there some difference for uclibc? Please let me know.
opkg works well with uclibc based systems. Those functions are not
implemented in uclibc I am sure it can be fixed
by linking in other libs or may be
Thanks for the reply,
unfortunately I depend from rpm, I need just rpm packages.
So can you confirm the target rpm for uclibc is not building?
Thanks again,
Giuseppe
2012/5/31 Khem Raj raj.k...@gmail.com
On Thu, May 31, 2012 at 5:35 AM, Giuseppe Condorelli
giuseppe.condore...@gmail.com
On Thu, May 31, 2012 at 6:57 AM, Giuseppe Condorelli
giuseppe.condore...@gmail.com wrote:
unfortunately I depend from rpm, I need just rpm packages.
So can you confirm the target rpm for uclibc is not building?
yes rpm needs to be patched for building on uclibc
There is a bug if we:
1) bitbake core-image-sato-sdk MACHINE=qemux86
2) bitbake core-image-sato with MACHINE=crownbay
Then several pkgs in deploy/ipk/i586 would be installed to crownbay's
image even if there is one in deploy/ipk/core2 and we have set the
core2's priority higher than i586, when
* Changes of V2:
- Add the test plan and more explanations in the cover letter as Saul
suggested.
* Test info (PACKAGE_CLASSES = package_ipk)
- Test to make sure the bug has been fixed
1) bitbake core-image-sato-sdk with MACHINE=qemux86
2) bitbake core-image-sato with
On 2012-05-31 07:57, Giuseppe Condorelli wrote:
Thanks for the reply,
unfortunately I depend from rpm, I need just rpm packages.
Why do you need RPM?
So can you confirm the target rpm for uclibc is not building?
Thanks again,
Giuseppe
2012/5/31 Khem Raj raj.k...@gmail.com
because the current distribution I manage (not oe based) is rpm based so in
my intention I want to furnish (for a while) both installtion methods: via
oe build system and via rpm (chrooted or similar).
And to do the second I need to have the possibility to access to the dbpath
oe build system
On 05/31/2012 06:29 AM, Richard Purdie wrote:
Currently, the task just exits if something goes wrong. This adds the
ncurses-native dependency. It also adds a small delay before closing the
window so any messages displayed there can be seen.
Trying to get the kernel build system to correctly
Op 31 mei 2012, om 16:13 heeft Robert Yang het volgende geschreven:
There is a bug if we:
1) bitbake core-image-sato-sdk MACHINE=qemux86
2) bitbake core-image-sato with MACHINE=crownbay
Then several pkgs in deploy/ipk/i586 would be installed to crownbay's
image even if there is one in
On 12-05-31 09:29 AM, Richard Purdie wrote:
Currently, the task just exits if something goes wrong. This adds the
ncurses-native dependency. It also adds a small delay before closing the
window so any messages displayed there can be seen.
Trying to get the kernel build system to correctly find
On 5/31/12 9:47 AM, Giuseppe Condorelli wrote:
because the current distribution I manage (not oe based) is rpm based so in my
intention I want to furnish (for a while) both installtion methods: via oe build
system and via rpm (chrooted or similar).
And to do the second I need to have the
Hi,
I've found the following warnings while attempting to build linux-xilinx.
How can I trace which package it's originating from and what can I do to fix it?
WARNING: QA Issue: bash: Found a reference to /usr/ in
Hi,
On May 31, 2012, at 7:38 PM, Elvis Dowson wrote:
I've found the following warnings while attempting to build linux-xilinx. How
can I trace which package it's originating from and what can I do to fix it?
WARNING: QA Issue: bash: Found a reference to /usr/ in
Hi,
I noticed a situation where, when I try to bitbake linux-xilinx, it fails
a libpcre, because of an invalid python instalation.
However, after doing a bitbake -c clean linux-xilinx libpcre, and then
rebuilding libpcre, python-native gets staged correctly and the build succeeds.
Hi,
While attempting to build linux-xilinx, I get the following warning:
WARNING: linux-xilinx: No generic license file exists for: GPL in any provider
What should I do to fix this warning?
Best regards,
Elvis Dowson
___
Openembedded-core
Hi Adrian,
When I attempt to build the linux-xilinx kernel, it doesn't
find the device tree (*.dts) in the xilinx-ml507-update BSP project. Is the
device tree supposed to be generated manually? If so, could you please tell me
how to generate it?
Best regards,
Elvis Dowson
That's a second process that you need todo with xilinx EDK to export
and launch xilinx SDK
from there create a new device tree project which will parse the mhs
hardware descriptor file
and from there generate the device tree according to the hwd settings...
The only docs available to get to know
On 5/31/12 12:40 PM, Elvis Dowson wrote:
Hi,
On May 31, 2012, at 7:38 PM, Elvis Dowson wrote:
I've found the following warnings while attempting to build linux-xilinx. How
can I trace which package it's originating from and what can I do to fix it?
WARNING: QA Issue: bash: Found a reference
Hi Adrian,
On May 31, 2012, at 10:49 PM, Adrian Alonso wrote:
That's a second process that you need todo with xilinx EDK to export
and launch xilinx SDK
from there create a new device tree project which will parse the mhs
hardware descriptor file
and from there generate the device tree
Yep that could be done, just need to dig on EDK to do it :)
On Thu, May 31, 2012 at 3:56 PM, Elvis Dowson elvis.dow...@gmail.com wrote:
Hi Adrian,
On May 31, 2012, at 10:49 PM, Adrian Alonso wrote:
That's a second process that you need todo with xilinx EDK to export
and launch xilinx SDK
It occurred to me:
In theory, it's a bug if a package is configured such that it does not
actually request hash-style=gnu. In practice, though, the yocto
toolchain is configured so that it's the default.
Maybe there should be a periodic build or two that uses a compiler not
configured that way,
On Thu, May 31, 2012 at 2:14 PM, Peter Seebach
peter.seeb...@windriver.com wrote:
In theory, it's a bug if a package is configured such that it does not
actually request hash-style=gnu. In practice, though, the yocto
toolchain is configured so that it's the default.
Maybe there should be a
Rebase of the v2 changes.
Re-disabled the test chunk.. this should resolve the hang problem a
few people have observed.
v2 message follows:
Berkley DB also gets upreved, and a new package ossp-uuid gets added to
the system.
This was -heavily- tested with and without zypper on IA, and PPC.
RPM 5.4.8 requires db 5.3.x, so both are upgraded together.
Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
meta/classes/rootfs_rpm.bbclass| 22 +-
.../rpm/rpm/fix_for_automake_1.11.2.patch | 54 ---
.../rpm/rpm/fprint-pointer-fix.patch |
RPM 5.4.9 now strongly encourages you to have the ossp-uuid library available.
Add this recipe, and change RPM to use the uuid functionality.
Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
.../ossp-uuid/0001-Change-library-name.patch | 112
Beside upreving RPM, add necessary integration pathces to libzypp.
Also change the configuration of RPM to support PACKAGECONFIG flags.
RPM is highly configurable, the default configuration is good for
minimal OE-Core use.
Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
Add functionality to RPM to directly query the packageorigin (path) from
the resolver database, instead of having to do this via an indirect method.
This results in a minor performance improvement.
Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
meta/classes/package_rpm.bbclass
With the recent RPM uprev, libzypp, sat-solver and zypper should be
rebuilt to ensure they get the right BerkleyDB and rpmdb interfaces.
Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
meta/recipes-extended/libzypp/libzypp_git.bb |2 +-
On Thu, May 31, 2012 at 7:47 AM, Giuseppe Condorelli
giuseppe.condore...@gmail.com wrote:
Have new suggestions?
I found a bit of time and fixed rpm compilation on uclibc. Its only
compiling though I don't know if it will run on target. Try it out.
The patch is here
Hi,
I pulled today, started a build from scratch and ran into trouble with
systemtap:
...
| In file included from csclient.h:12:0,
| from main.cxx:24:
| cscommon.h:8:17: fatal error: ssl.h: No such file or directory
| compilation terminated.
| In file included from
On 05/31/2012 11:01 PM, Koen Kooi wrote:
Op 31 mei 2012, om 16:13 heeft Robert Yang het volgende geschreven:
There is a bug if we:
1) bitbake core-image-sato-sdk MACHINE=qemux86
2) bitbake core-image-sato with MACHINE=crownbay
Then several pkgs in deploy/ipk/i586 would be installed to
On Wed, May 30, 2012 at 12:56:27PM -0600, Gary Thomas wrote:
On 2012-05-30 10:40, Richard Purdie wrote:
I've merged this however I'm not 100% happy with this as the final fix.
I'd ask that:
a) The bug remains open (re-prioritised appropriately) about the
remaining issues that still exist
Hi list,
I was trying to build core-image-gtk-directfb and ended up with this error:
Log data follows:
| DEBUG: Executing shell function do_rootfs
| ERROR: Function failed: do_rootfs (see
/home/lau/yocto/build/tmp/work/qemux86-poky-linux/core-image-minimal-1.0-r0/temp/log.do_rootfs.4857
for
From: Christopher Larson chris_lar...@mentor.com
The following changes since commit e3113827810e98eb1b012f0b280fb917199704c1:
webkit-gtk: Use glib as unicode backend to avoid browser crash (2012-05-30
17:37:58 +0100)
are available in the git repository at:
github:kergoth/oe-core toolchain
From: Christopher Larson chris_lar...@mentor.com
This is needed to work around an issue with the toolchain search paths. It can
pick up the wrong features.h without it, it seems, even with the system32
symlink in the oe sysroot. Investigate this further in the future.
Signed-off-by: Christopher
From: Christopher Larson chris_lar...@mentor.com
If the usr/lib directory doesn't exist, the toolchain can fail to even try to
find crti.o in a completely different directory. This causes a failure for the
case where baselib is lib64.
Signed-off-by: Christopher Larson chris_lar...@mentor.com
---
From: Christopher Larson chris_lar...@mentor.com
Rather than hardcoding the multilib path in a map, and hardcoding dest sysroot
symlink creation in a hook, now we just use -print-sysroot for both, and pass
the appropriate multilib args to the toolchain for particular tunes.
Signed-off-by:
On Thu, May 31, 2012 at 7:00 PM, Christopher Larson kerg...@gmail.com wrote:
are available in the git repository at:
github:kergoth/oe-core toolchain
Erm, forgot to correct the url, my git url insteadOf adjusts this.
https://github.com/kergoth/oe-core toolchain
On Thu, 31 May 2012 19:00:04 -0700
Christopher Larson kerg...@gmail.com wrote:
+CSL_MULTILIB_ARGS[i586] = -msgxx-glibc
+CSL_MULTILIB_ARGS[i686] = -msgxx-glibc
+CSL_MULTILIB_ARGS[core2] = -msgxx-glibc
+CSL_MULTILIB_ARGS[x86] = -msgxx-glibc
+CSL_MULTILIB_ARGS[x86-64] = -msgxx-glibc
51 matches
Mail list logo
