Re: [OE-core] [PATCH 0/2] fix multilib issues with UEFI bootloaders
Hello, пт, 1 нояб. 2019 г. в 17:32, : > > Last UEFI patchset that went in broke building not-native multilib > images (like lib32-core-image-minimal). Fix this issue by listing > systemd-boot as non-multilib recipe and by fixing UEFI app naming in > multilib cases. We'd like to unbreak such build. Is there anything wrong with these two patches? No feedback received up to this point. -- With best wishes Dmitry -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3 1/5] conf/image-uefi: fix building images for multilib case
Hello, вт, 15 окт. 2019 г. в 00:50, : > > From: Dmitry Eremin-Solenikov > > Building live images for lib32-core-minimal-image will fail because > image target override won't match grub's override. Fix this by > introducing anonymous python function. A proper fix should be to > introduce multilib overrides, but it will be more intrusive. Any updates on these patches? I think all build issues should be fixed now. -- With best wishes Dmitry -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [warrior][PATCH] kernel.bbclass: fix installation of modules signing certificates
сб, 12 окт. 2019 г. в 19:57, akuster808 :
>
>
>
> On 10/11/19 1:16 AM, Nicolas Dechesne wrote:
> > From: Dmitry Eremin-Solenikov
> >
> > If one has provided external key/certificate for modules signing, Kbuild
> > will skip creating signing_key.pem and will write only signing_key.x509
> > certificate. Thus we have to check for .x509 file existence rather than
> > .pem one.
>
> Is this true for all the kernel versions supported by warrior?
Answer to both questions is "yes".
>
> - armin
> >
> > Signed-off-by: Dmitry Eremin-Solenikov
> > Signed-off-by: Richard Purdie
> > (cherry picked from commit 2527e731eba43bd36d0ea268aca6b03155376134)
> > Signed-off-by: Nicolas Dechesne
> > ---
> > meta/classes/kernel.bbclass | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> > index 111a0b2eeb..fb1f49327c 100644
> > --- a/meta/classes/kernel.bbclass
> > +++ b/meta/classes/kernel.bbclass
> > @@ -453,7 +453,7 @@ do_shared_workdir () {
> > cp .config $kerneldir/
> > mkdir -p $kerneldir/include/config
> > cp include/config/kernel.release
> > $kerneldir/include/config/kernel.release
> > - if [ -e certs/signing_key.pem ]; then
> > + if [ -e certs/signing_key.x509 ]; then
> > # The signing_key.* files are stored in the certs/ dir in
> > # newer Linux kernels
> > mkdir -p $kerneldir/certs
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
With best wishes
Dmitry
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3 1/9] uefi.conf: add config file holding configuration for UEFI applications
Hello, ср, 18 сент. 2019 г. в 01:16, Richard Purdie : > > On Tue, 2019-09-17 at 18:36 +0300, dbarysh...@gmail.com wrote: > > From: Dmitry Eremin-Solenikov > > > > Create new config file defining common variables for all UEFI-related > > packages (bootloaders, test applications, etc). > > > > Signed-off-by: Dmitry Eremin-Solenikov < > > dmitry_eremin-soleni...@mentor.com> > > --- > > meta/conf/uefi.conf | 16 > > 1 file changed, 16 insertions(+) > > create mode 100644 meta/conf/uefi.conf > > This is heading in the right direction however if we're going to try > and clean things up I've concluded we need to do it properly and get it > right. > > Now I understand more about how this configuration file is being used, > should it be called image-uefi.conf ? Fine, I will rename the conf file > I feel really strongly that we do not want an uefi.bbclass, its simply > not warranted and will just continue to expand the current mess of > classes. If all we need it for is some functions, those functions > should be added elsewhere. As those EFI_PROVIDER bootloader classes are called only form live-vm-common, maybe I should just add them to live-vm-common and make individual classes _append those functions? > I'm also on the lookout for tests of these kinds of codepaths. Code is > much more likely to be accepted if tests are added for it. I'm not > quite sure what would make most sense here in this case buts its a > general point I will be pushing for going forward. What kind of tests would you like? This code already exists and is called as a part of any live image generation. -- With best wishes Dmitry -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 1/9] uefi.bbclass: add bbclass holding configuration for UEFI applications
вт, 17 сент. 2019 г. в 01:17, Richard Purdie : > > On Fri, 2019-09-13 at 18:44 +0300, dbarysh...@gmail.com wrote: > > From: Dmitry Eremin-Solenikov > > > > Create new bbclass defining common variables for all UEFI-related > > packages (bootloaders, test applications, etc). > > > > Signed-off-by: Dmitry Eremin-Solenikov < > > dmitry_eremin-soleni...@mentor.com> > > --- > > meta/classes/uefi.bbclass | 26 ++ > > 1 file changed, 26 insertions(+) > > create mode 100644 meta/classes/uefi.bbclass > > I really want to get away from the proliferation of bbclass files we > have. Wouldn't this make more sense as a .conf file? Moving configuration to .conf file might make sense. I even can implement anonymous function as per-arch override. However there are still functions like efi_populate_common() and efi_iso_populate_common(), which can not be moved to .conf file. Would you prefer separate uefi.conf file and uefi-bootloader.bbclass files? > The anonymous function could be done with overrides, or an appropriate > function from lib/oe/. > > I appreciate we don't use conf files so much but we need to start > somewhere and I think this is a good candidate for it. -- With best wishes Dmitry -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/9] uefi.bbclass: add bbclass holding configuration for UEFI applications
пт, 13 сент. 2019 г. в 05:14, Ang, Chin Huat :
>
> > +image = "bootUNKNOWN.efi"
>
> It might be better to raise an error here.
Fine, I can change in v2.
>
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> On Behalf Of
> dbarysh...@gmail.com
> Sent: Wednesday, September 11, 2019 5:30 PM
> To: openembedded-core@lists.openembedded.org
> Cc: Dmitry Eremin-Solenikov
> Subject: [OE-core] [PATCH 1/9] uefi.bbclass: add bbclass holding
> configuration for UEFI applications
>
> From: Dmitry Eremin-Solenikov
>
> Create new bbclass defining common variables for all UEFI-related packages
> (bootloaders, test applications, etc).
>
> Signed-off-by: Dmitry Eremin-Solenikov
> ---
> meta/classes/uefi.bbclass | 26 ++
> 1 file changed, 26 insertions(+)
> create mode 100644 meta/classes/uefi.bbclass
>
> diff --git a/meta/classes/uefi.bbclass b/meta/classes/uefi.bbclass new file
> mode 100644 index ..d3fc4b686676
> --- /dev/null
> +++ b/meta/classes/uefi.bbclass
> @@ -0,0 +1,26 @@
> +# Location of EFI files inside EFI System Partition EFIDIR ?=
> +"/EFI/BOOT"
> +
> +# Prefix where ESP is mounted inside rootfs. Set to empty if package is
> +going # to be installed to ESP directly EFI_PREFIX ?= "/boot"
> +
> +# Location inside rootfs.
> +EFI_FILES_PATH = "${EFI_PREFIX}${EFIDIR}"
> +
> +# Determine name of bootloader image
> +python __anonymous () {
> +import re
> +target = d.getVar('TARGET_ARCH')
> +if target == "x86_64":
> +image = "bootx64.efi"
> +elif re.match('i.86', target):
> +image = "bootia32.efi"
> +elif re.match('aarch64', target):
> +image = "bootaa64.efi"
> +elif re.match('arm', target):
> +image = "bootarm.efi"
> +else:
> +image = "bootUNKNOWN.efi"
> +d.setVar("EFI_BOOT_IMAGE", image)
> +}
> --
> 2.23.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
With best wishes
Dmitry
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/9] uefi.bbclass: add bbclass holding configuration for UEFI applications
пт, 13 сент. 2019 г. в 02:12, Mittal, Anuj : > > Hello, > > On Wed, 2019-09-11 at 12:29 +0300, dbarysh...@gmail.com wrote: > > From: Dmitry Eremin-Solenikov > > > > Create new bbclass defining common variables for all UEFI-related > > packages (bootloaders, test applications, etc). > > Have these changes been tested using wic as well with non default > values? There are places in there in EFI plugins where EFI/BOOT is > hardcoded. They might have to be changed as well ... This would be the next step. For now I wanted to consolidate code in recipes, so that it won't be duplicated all over the repo. -- With best wishes Dmitry -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] module.bbclass: do not strip packages if modules signing is enabled
чт, 8 авг. 2019 г. в 14:44, Mittal, Anuj : > > On Thu, 2019-08-08 at 12:57 +0300, dbarysh...@gmail.com wrote: > > From: Dmitry Eremin-Solenikov > > > > Stripping kernel modules will also remove signature, thus we have to > > inhibit package striping in case modules signatures are enabled. > > > > Isn't this already being taken care of here: > > https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=8fc56faa5d76927f42a4e7cca2418556e231938f Hmm, true. I missed that commit. -- With best wishes Dmitry -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] kernel.bbclass: fix installation of modules signing certificates
From: Dmitry Eremin-Solenikov
If one has provided external key/certificate for modules signing, Kbuild
will skip creating signing_key.pem and will write only signing_key.x509
certificate. Thus we have to check for .x509 file existence rather than
.pem one.
Signed-off-by: Dmitry Eremin-Solenikov
---
meta/classes/kernel.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index a60e15b57814..bf3674238f02 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -454,7 +454,7 @@ do_shared_workdir () {
cp .config $kerneldir/
mkdir -p $kerneldir/include/config
cp include/config/kernel.release
$kerneldir/include/config/kernel.release
- if [ -e certs/signing_key.pem ]; then
+ if [ -e certs/signing_key.x509 ]; then
# The signing_key.* files are stored in the certs/ dir in
# newer Linux kernels
mkdir -p $kerneldir/certs
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] gcc-4.9: import patch fixing compilation in thumb mode
Import patch fixing a bug that caused ICE when compiling some packages
(e.g. ICU) in Thumb-1 model.
Signed-off-by: Dmitry Eremin-Solenikov <dbarysh...@gmail.com>
---
meta/recipes-devtools/gcc/gcc-4.9.inc | 1 +
.../gcc/gcc-4.9/0067-fix-arm-thumb.patch | 39 ++
2 files changed, 40 insertions(+)
create mode 100644 meta/recipes-devtools/gcc/gcc-4.9/0067-fix-arm-thumb.patch
diff --git a/meta/recipes-devtools/gcc/gcc-4.9.inc
b/meta/recipes-devtools/gcc/gcc-4.9.inc
index 6ac3685..d62e801 100644
--- a/meta/recipes-devtools/gcc/gcc-4.9.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.9.inc
@@ -82,6 +82,7 @@ SRC_URI = "\
file://0064-handle-target-sysroot-multilib.patch \
file://0065-gcc-483-universal-initializer-no-warning.patch \
file://0066-cxxflags-for-build.patch \
+file://0067-fix-arm-thumb.patch \
"
SRC_URI[md5sum] = "6f831b4d251872736e8e9cc09746f327"
SRC_URI[sha256sum] =
"2332b2a5a321b57508b9031354a8503af6fdfb868b8c1748d33028d100a8b67e"
diff --git a/meta/recipes-devtools/gcc/gcc-4.9/0067-fix-arm-thumb.patch
b/meta/recipes-devtools/gcc/gcc-4.9/0067-fix-arm-thumb.patch
new file mode 100644
index 000..2f262e3
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-4.9/0067-fix-arm-thumb.patch
@@ -0,0 +1,39 @@
+Upstream-Status: Accepted
+
+Signed-off-by: Dmitry Eremin-Solenikov <dbarysh...@gmail.com>
+---
+
+2015-11-25 Vladimir Makarov <vmaka...@redhat.com>
+
+ PR rtl-optimization/67954
+ * lra-constraints.c (curr_insn_transform): Add check on scratch
+ pseudo when change class to NO_REGS. Add an assert.
+
+
+
+git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@230894
138bc75d-0d04-0410-961f-82ee72b054a4
+---
+
+diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
+index 4670e81..c62bf6a 100644
+--- a/gcc/lra-constraints.c
b/gcc/lra-constraints.c
+@@ -3725,7 +3725,8 @@ curr_insn_transform (bool check_only_p)
+assigment pass and the scratch pseudo will be
+spilled. Spilled scratch pseudos are transformed
+back to scratches at the LRA end. */
+-&& lra_former_scratch_operand_p (curr_insn, i))
++&& lra_former_scratch_operand_p (curr_insn, i)
++&& lra_former_scratch_p (REGNO (op)))
+ {
+ int regno = REGNO (op);
+ lra_change_class (regno, NO_REGS, " Change to", true);
+@@ -3734,6 +3735,8 @@ curr_insn_transform (bool check_only_p)
+ spilled pseudo as there is only one such insn, the
+ current one. */
+ reg_renumber[regno] = -1;
++lra_assert (bitmap_single_bit_set_p
++(_reg_info[REGNO (op)].insn_bitmap));
+ }
+ /* We can do an optional reload. If the pseudo got a hard
+reg, we might improve the code through inheritance. If
--
2.6.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] gcc-5.2: import patch fixing compilation in thumb mode
Import patch fixing a bug that caused ICE when compiling some packages
(e.g. ICU) in Thumb-1 model.
Signed-off-by: Dmitry Eremin-Solenikov <dbarysh...@gmail.com>
---
meta/recipes-devtools/gcc/gcc-5.2.inc | 1 +
.../gcc/gcc-5.2/0043-fix-arm-thumb.patch | 39 ++
2 files changed, 40 insertions(+)
create mode 100644 meta/recipes-devtools/gcc/gcc-5.2/0043-fix-arm-thumb.patch
diff --git a/meta/recipes-devtools/gcc/gcc-5.2.inc
b/meta/recipes-devtools/gcc/gcc-5.2.inc
index a6b385a..e5e92e9 100644
--- a/meta/recipes-devtools/gcc/gcc-5.2.inc
+++ b/meta/recipes-devtools/gcc/gcc-5.2.inc
@@ -74,6 +74,7 @@ SRC_URI = "\
file://0040-nativesdk-gcc-support.patch \
file://0041-handle-target-sysroot-multilib.patch \
file://0042-cxxflags-for-build.patch \
+ file://0043-fix-arm-thumb.patch \
"
BACKPORTS = ""
diff --git a/meta/recipes-devtools/gcc/gcc-5.2/0043-fix-arm-thumb.patch
b/meta/recipes-devtools/gcc/gcc-5.2/0043-fix-arm-thumb.patch
new file mode 100644
index 000..2f262e3
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-5.2/0043-fix-arm-thumb.patch
@@ -0,0 +1,39 @@
+Upstream-Status: Accepted
+
+Signed-off-by: Dmitry Eremin-Solenikov <dbarysh...@gmail.com>
+---
+
+2015-11-25 Vladimir Makarov <vmaka...@redhat.com>
+
+ PR rtl-optimization/67954
+ * lra-constraints.c (curr_insn_transform): Add check on scratch
+ pseudo when change class to NO_REGS. Add an assert.
+
+
+
+git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@230894
138bc75d-0d04-0410-961f-82ee72b054a4
+---
+
+diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
+index 4670e81..c62bf6a 100644
+--- a/gcc/lra-constraints.c
b/gcc/lra-constraints.c
+@@ -3725,7 +3725,8 @@ curr_insn_transform (bool check_only_p)
+assigment pass and the scratch pseudo will be
+spilled. Spilled scratch pseudos are transformed
+back to scratches at the LRA end. */
+-&& lra_former_scratch_operand_p (curr_insn, i))
++&& lra_former_scratch_operand_p (curr_insn, i)
++&& lra_former_scratch_p (REGNO (op)))
+ {
+ int regno = REGNO (op);
+ lra_change_class (regno, NO_REGS, " Change to", true);
+@@ -3734,6 +3735,8 @@ curr_insn_transform (bool check_only_p)
+ spilled pseudo as there is only one such insn, the
+ current one. */
+ reg_renumber[regno] = -1;
++lra_assert (bitmap_single_bit_set_p
++(_reg_info[REGNO (op)].insn_bitmap));
+ }
+ /* We can do an optional reload. If the pseudo got a hard
+reg, we might improve the code through inheritance. If
--
2.6.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] libsdl: support native compilation
Hello,
2015-10-19 17:44 GMT+03:00 Mark Hatle <mark.ha...@windriver.com>:
> On 10/19/15 9:17 AM, Dmitry Eremin-Solenikov wrote:
>> qemu-native can use SDL backend for graphical output. Currently it is
>> expected to use libsdl provided by the host. However this can lead to
>> library incompatibilities between host and target. Make libsdl recipe
>> support native compilation.
>
> I don't object to the patch.. but we did have multiple problems in the past
> where libsdl (native) did not work with the host systems X11 or what-ever.
>
> Various failure conditions about not linking, linking to the wrong libsdl, or
> execution failing are what made us prefer the host system's libsdl -- or
> simply
> disabling libsdl altogether.
The issue that get me to this patch was an issue with linking of qemu.
Debian provides versioned symbols in libdbus, OE does not. Libdbus
from sysroot overrode system one. So system libsdl which used system-wide
libpulse* (which expected libdbus with versioned symbols) could not be linked
to the qemu.
Richard: this was tested on my system only. If you don't want to break things
before release, what about merging them after next Yocto/OE-Core release?
>
> --Mark
>
>> Signed-off-by: Dmitry Eremin-Solenikov <dbarysh...@gmail.com>
>> ---
>> meta/recipes-graphics/libsdl/libsdl_1.2.15.bb | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
>> b/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
>> index c0d5c6a..c9f3e00 100644
>> --- a/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
>> +++ b/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
>> @@ -17,6 +17,7 @@ DEPENDS = "${@bb.utils.contains('DISTRO_FEATURES',
>> 'directfb', 'directfb', '', d
>> ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'virtual/libx11
>> libxext libxrandr libxrender', '', d)} \
>> ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'libglu',
>> '', d)} \
>> tslib"
>> +DEPENDS_class-native = "${@bb.utils.contains('DISTRO_FEATURES', 'x11',
>> 'virtual/libx11-native libxrandr-native libxrender-native libxext-native',
>> '', d)}"
>> DEPENDS_class-nativesdk = "${@bb.utils.contains('DISTRO_FEATURES', 'x11',
>> 'virtual/nativesdk-libx11 nativesdk-libxrandr nativesdk-libxrender
>> nativesdk-libxext', '', d)}"
>>
>> PR = "r3"
>> @@ -65,4 +66,4 @@ do_configure_prepend() {
>> export SYSROOT=$PKG_CONFIG_SYSROOT_DIR
>> }
>>
>> -BBCLASSEXTEND = "nativesdk"
>> +BBCLASSEXTEND = "native nativesdk"
>>
>
--
With best wishes
Dmitry
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] apr: remove conflict with ccache
If ccache is enabled, compiling apr-utils fails with the following error
messages because libtool is confused by the "ccache gcc" appearing on
the command line. Disable ccache for apr, so that ccache don't get
enabled in all software using apr's rules.mk.
The error message from apr-utils-native:
Signed-off-by: Dmitry Eremin-Solenikov <dbarysh...@gmail.com>
---
meta/recipes-support/apr/apr_1.5.2.bb | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-support/apr/apr_1.5.2.bb
b/meta/recipes-support/apr/apr_1.5.2.bb
index e12a176..1c61e84 100644
--- a/meta/recipes-support/apr/apr_1.5.2.bb
+++ b/meta/recipes-support/apr/apr_1.5.2.bb
@@ -32,6 +32,11 @@ CACHED_CONFIGUREVARS += "apr_cv_mutex_recursive=yes"
#
CACHED_CONFIGUREVARS += "ac_cv_header_netinet_sctp_h=no
ac_cv_header_netinet_sctp_uio_h=no"
+# Otherwise libtool fails to compile apr-utils
+# x86_64-linux-libtool: compile: unable to infer tagged configuration
+# x86_64-linux-libtool: error: specify a tag with '--tag'
+CCACHE = ""
+
do_configure_prepend() {
# Avoid absolute paths for grep since it causes failures
# when using sstate between different hosts with different
--
2.6.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] local.conf.sample: stop adding libsdl-native to ASSUME_PROVIDED
Signed-off-by: Dmitry Eremin-Solenikov <dbarysh...@gmail.com> --- meta/conf/local.conf.sample | 1 - 1 file changed, 1 deletion(-) diff --git a/meta/conf/local.conf.sample b/meta/conf/local.conf.sample index 3ae24ab..dfdb912 100644 --- a/meta/conf/local.conf.sample +++ b/meta/conf/local.conf.sample @@ -205,7 +205,6 @@ BB_DISKMON_DIRS = "\ # libsdl library available on your build system. PACKAGECONFIG_append_pn-qemu-native = " sdl" PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl" -ASSUME_PROVIDED += "libsdl-native" # CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to -- 2.6.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] qemu: drop hooking of libsdl from the host
Now as libsdl recipe provides libsdl-native, there is no need to hook in
extra library paths from host to compile qemu-native.
Signed-off-by: Dmitry Eremin-Solenikov <dbarysh...@gmail.com>
---
meta/recipes-devtools/qemu/qemu.inc | 8
1 file changed, 8 deletions(-)
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index abbace8..4320031 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -35,14 +35,6 @@ EXTRA_OECONF_class-nativesdk =
"--target-list=${@get_qemu_target_list(d)} --disa
"
export LIBTOOL="${HOST_SYS}-libtool"
-do_configure_prepend_class-native() {
- # Append build host pkg-config paths for native target since the host
may provide sdl
- BHOST_PKGCONFIG_PATH=$(PATH=/usr/bin:/bin pkg-config --variable pc_path
pkg-config || echo "")
- if [ ! -z "$BHOST_PKGCONFIG_PATH" ]; then
- export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$BHOST_PKGCONFIG_PATH
- fi
-}
-
KVMENABLE = "--enable-kvm"
KVMENABLE_darwin = "--disable-kvm"
KVMENABLE_mingw32 = "--disable-kvm"
--
2.6.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] libsdl: support native compilation
qemu-native can use SDL backend for graphical output. Currently it is
expected to use libsdl provided by the host. However this can lead to
library incompatibilities between host and target. Make libsdl recipe
support native compilation.
Signed-off-by: Dmitry Eremin-Solenikov <dbarysh...@gmail.com>
---
meta/recipes-graphics/libsdl/libsdl_1.2.15.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
b/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
index c0d5c6a..c9f3e00 100644
--- a/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
+++ b/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
@@ -17,6 +17,7 @@ DEPENDS = "${@bb.utils.contains('DISTRO_FEATURES',
'directfb', 'directfb', '', d
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'virtual/libx11
libxext libxrandr libxrender', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'libglu', '',
d)} \
tslib"
+DEPENDS_class-native = "${@bb.utils.contains('DISTRO_FEATURES', 'x11',
'virtual/libx11-native libxrandr-native libxrender-native libxext-native', '',
d)}"
DEPENDS_class-nativesdk = "${@bb.utils.contains('DISTRO_FEATURES', 'x11',
'virtual/nativesdk-libx11 nativesdk-libxrandr nativesdk-libxrender
nativesdk-libxext', '', d)}"
PR = "r3"
@@ -65,4 +66,4 @@ do_configure_prepend() {
export SYSROOT=$PKG_CONFIG_SYSROOT_DIR
}
-BBCLASSEXTEND = "nativesdk"
+BBCLASSEXTEND = "native nativesdk"
--
2.6.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] tune-octeon.inc: correct packaging suffix
Octeon II/III binaries can contain instructions that are not compatible
with MIPS64 processors. Thus Octeon II/III packages should go to
separate directories. Set MIPSPKGSFX_VARIANT_tune-* to Octeon-specific
values and update PACKAGE_EXTRA_ARCHS_tune-* accordingly.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
meta/conf/machine/include/tune-octeon.inc | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/meta/conf/machine/include/tune-octeon.inc
b/meta/conf/machine/include/tune-octeon.inc
index f80f970..fdd48b5 100644
--- a/meta/conf/machine/include/tune-octeon.inc
+++ b/meta/conf/machine/include/tune-octeon.inc
@@ -6,12 +6,13 @@ AVAILTUNES += octeon2 octeon2_64 octeon3 octeon3_64
TUNEVALID[octeon2] = Enable optimization related to octeon2 support
TUNE_CCARGS .= ${@bb.utils.contains(TUNE_FEATURES, octeon2,
-march=octeon2 , ,d)}
+
TUNE_FEATURES_tune-octeon2 = ${TUNE_FEATURES_tune-mips64-n32} octeon2
-MIPSPKGSFX_VARIANT_tune-octeon2 = ${TUNE_ARCH}
-PACKAGE_EXTRA_ARCHS_tune-octeon2 = mips64-n32 octeon2 octeon2_64-n32
+MIPSPKGSFX_VARIANT_tune-octeon2 = octeon2
+PACKAGE_EXTRA_ARCHS_tune-octeon2 = mips64-n32 octeon2-n32
TUNE_FEATURES_tune-octeon2_64 = ${TUNE_FEATURES_tune-mips64} octeon2
-MIPSPKGSFX_VARIANT_tune-octeon2_64 = ${TUNE_ARCH}
+MIPSPKGSFX_VARIANT_tune-octeon2_64 = octeon2_64
PACKAGE_EXTRA_ARCHS_tune-octeon2_64 = mips64 octeon2_64
@@ -19,9 +20,9 @@ TUNEVALID[octeon3] = Enable optimization related to octeon3
support
TUNE_CCARGS .= ${@bb.utils.contains(TUNE_FEATURES, octeon3,
-march=octeon3 , ,d)}
TUNE_FEATURES_tune-octeon3 = ${TUNE_FEATURES_tune-mips64-n32} octeon3
-MIPSPKGSFX_VARIANT_tune-octeon3 = ${TUNE_ARCH}
-PACKAGE_EXTRA_ARCHS_tune-octeon3 = mips64-n32 octeon3 octeon3_64-n32
+MIPSPKGSFX_VARIANT_tune-octeon3 = octeon3
+PACKAGE_EXTRA_ARCHS_tune-octeon3 = mips64-n32 octeon3-n32
TUNE_FEATURES_tune-octeon3_64 = ${TUNE_FEATURES_tune-mips64} octeon3
-MIPSPKGSFX_VARIANT_tune-octeon3_64 = ${TUNE_ARCH}
+MIPSPKGSFX_VARIANT_tune-octeon3_64 = octeon3_64
PACKAGE_EXTRA_ARCHS_tune-octeon3_64 = mips64 octeon3_64
--
2.5.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] tune-octeon.inc: add BASE_LIB settings
Provide BASE_LIB settings for octeon* tunes that follow the practice of
mips64/mips64-n32 tunes (lib64 for N64 ABI, lib32 for N32 ABI).
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
meta/conf/machine/include/tune-octeon.inc | 4
1 file changed, 4 insertions(+)
diff --git a/meta/conf/machine/include/tune-octeon.inc
b/meta/conf/machine/include/tune-octeon.inc
index fdd48b5..f24d9db 100644
--- a/meta/conf/machine/include/tune-octeon.inc
+++ b/meta/conf/machine/include/tune-octeon.inc
@@ -8,10 +8,12 @@ TUNEVALID[octeon2] = Enable optimization related to octeon2
support
TUNE_CCARGS .= ${@bb.utils.contains(TUNE_FEATURES, octeon2,
-march=octeon2 , ,d)}
TUNE_FEATURES_tune-octeon2 = ${TUNE_FEATURES_tune-mips64-n32} octeon2
+BASE_LIB_tune-octeon2 = lib32
MIPSPKGSFX_VARIANT_tune-octeon2 = octeon2
PACKAGE_EXTRA_ARCHS_tune-octeon2 = mips64-n32 octeon2-n32
TUNE_FEATURES_tune-octeon2_64 = ${TUNE_FEATURES_tune-mips64} octeon2
+BASE_LIB_tune-octeon2_64 = lib64
MIPSPKGSFX_VARIANT_tune-octeon2_64 = octeon2_64
PACKAGE_EXTRA_ARCHS_tune-octeon2_64 = mips64 octeon2_64
@@ -20,9 +22,11 @@ TUNEVALID[octeon3] = Enable optimization related to octeon3
support
TUNE_CCARGS .= ${@bb.utils.contains(TUNE_FEATURES, octeon3,
-march=octeon3 , ,d)}
TUNE_FEATURES_tune-octeon3 = ${TUNE_FEATURES_tune-mips64-n32} octeon3
+BASE_LIB_tune-octeon3 = lib32
MIPSPKGSFX_VARIANT_tune-octeon3 = octeon3
PACKAGE_EXTRA_ARCHS_tune-octeon3 = mips64-n32 octeon3-n32
TUNE_FEATURES_tune-octeon3_64 = ${TUNE_FEATURES_tune-mips64} octeon3
+BASE_LIB_tune-octeon3_64 = lib64
MIPSPKGSFX_VARIANT_tune-octeon3_64 = octeon3_64
PACKAGE_EXTRA_ARCHS_tune-octeon3_64 = mips64 octeon3_64
--
2.5.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/4] glibc: don't override TUNE_CCARGS for MIPS
2015-08-17 18:30 GMT+03:00 Dmitry Eremin-Solenikov dbarysh...@gmail.com: 2015-08-16 3:29 GMT+03:00 Khem Raj raj.k...@gmail.com: On Sat, Aug 15, 2015 at 4:15 PM, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote: 2015-08-15 22:34 GMT+03:00 Khem Raj raj.k...@gmail.com: On Jul 1, 2015, at 7:02 AM, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote: Overriding TUNE_CCARGS this way breaks MULTILIB setup for MIPS. This override disables multilib handling of tunes for TUNE_CCARGS, thus enforcing glibc's TUNE_CCARGS to the TUNE_CCARGS of main DEFAULTTUNE. Glibc perfectly build without this override for both simple and multilib cases. this patch has been applied however we should reopen it. This has to be fixed differently. its not a build time issue but a runtime one. So find alternative way of passing these options to glibc build to accommodate your changes. What is the issue that you are facing with the current OE-Core? systemd remount segfaults in glibc. The problems will be more where it will use wrong syscall headers. Hmm. N32 and N64 packages seem to work for me. O32 programs segfault with illegal instruction. I'll take a look. It looks like something is broken wrt. MIPS64 kernel or QEMU. Because N64 kernel causes segfaults with plain O32 rootfs. O32 kernel + O32 rootfs work w/o any issues on emulated mips32. Emulated MIPS64 boots 32-bit kernel just fine, but then the rootfs segfaults (?). -- With best wishes Dmitry -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/4] glibc: don't override TUNE_CCARGS for MIPS
2015-08-16 3:29 GMT+03:00 Khem Raj raj.k...@gmail.com: On Sat, Aug 15, 2015 at 4:15 PM, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote: 2015-08-15 22:34 GMT+03:00 Khem Raj raj.k...@gmail.com: On Jul 1, 2015, at 7:02 AM, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote: Overriding TUNE_CCARGS this way breaks MULTILIB setup for MIPS. This override disables multilib handling of tunes for TUNE_CCARGS, thus enforcing glibc's TUNE_CCARGS to the TUNE_CCARGS of main DEFAULTTUNE. Glibc perfectly build without this override for both simple and multilib cases. this patch has been applied however we should reopen it. This has to be fixed differently. its not a build time issue but a runtime one. So find alternative way of passing these options to glibc build to accommodate your changes. What is the issue that you are facing with the current OE-Core? systemd remount segfaults in glibc. The problems will be more where it will use wrong syscall headers. Hmm. N32 and N64 packages seem to work for me. O32 programs segfault with illegal instruction. I'll take a look. -- With best wishes Dmitry -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/4] glibc: don't override TUNE_CCARGS for MIPS
2015-08-15 22:34 GMT+03:00 Khem Raj raj.k...@gmail.com: On Jul 1, 2015, at 7:02 AM, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote: Overriding TUNE_CCARGS this way breaks MULTILIB setup for MIPS. This override disables multilib handling of tunes for TUNE_CCARGS, thus enforcing glibc's TUNE_CCARGS to the TUNE_CCARGS of main DEFAULTTUNE. Glibc perfectly build without this override for both simple and multilib cases. this patch has been applied however we should reopen it. This has to be fixed differently. its not a build time issue but a runtime one. So find alternative way of passing these options to glibc build to accommodate your changes. What is the issue that you are facing with the current OE-Core? -- With best wishes Dmitry -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH][RESEND] adt-installer: use DEPLOY_DIR in ANT_DEPLOY expansion
Currently adt-installer uses ${TMPDIR}/deploy/sdk/ as a deployment dir.
This doesn't interact well with DEPLOY_DIR reassignment. So let's use
${DEPLOY_DIR}/sdk/ instead.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
meta/recipes-devtools/installer/adt-installer_1.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/installer/adt-installer_1.0.bb
b/meta/recipes-devtools/installer/adt-installer_1.0.bb
index c871e42..346fd9e 100644
--- a/meta/recipes-devtools/installer/adt-installer_1.0.bb
+++ b/meta/recipes-devtools/installer/adt-installer_1.0.bb
@@ -33,7 +33,7 @@ INHIBIT_DEFAULT_DEPS = 1
PR = r11
-ADT_DEPLOY = ${TMPDIR}/deploy/sdk/
+ADT_DEPLOY = ${DEPLOY_DIR}/sdk/
ADT_DIR = ${WORKDIR}/adt-installer/
S = ${WORKDIR}/opkg-${PV}
--
2.5.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Fix builds for MIPS64 N32
2015-07-31 13:59 GMT+03:00 Richard Purdie richard.pur...@linuxfoundation.org: On Wed, 2015-07-29 at 18:00 +0300, Dmitry Eremin-Solenikov wrote: Recent check-ins have changed some things. The compile side was working for a while, but not the compilation side (using it). I've been working with RP on IRC, and he's come up with some additional patches. (including this set of 4..) So I think the set is fine, it's up to the other pieces that need to mesh with this to produce the working SDK. Ok. So what would be the plan then? If you need any additional tests from my side, I can provide them. Sorry for the delays on this. I found several issues and ended up with some quite subtle gcc changes to make all this work. I've put both our changes into master-next. The local.conf testing setup I've been using is: MACHINE = qemumips64 require conf/multilib.conf DEFAULTTUNE = mips64-n32 MULTILIBS = multilib:lib64 multilib:lib32 DEFAULTTUNE_virtclass-multilib-lib64 = mips64 DEFAULTTUNE_virtclass-multilib-lib32 = mips32r2 then the build/test commands: bitbake core-image-minimal -c populate_sdk bitbake core-image-minimal -c testsdk The nice thing is the latter automated test part now passes for this configuration (and its tests all three multilibs). What remains is to run these changes through the autobuilder and make sure nothing else breaks as a result of this patchset. I'm about to do some business travel which means my ability to debug any further issues will be limited, compiling toolchains on the laptop isn't realistic. I may therefore need help in ironing out any further wrinkles or we'll have to wait until I get back in a couple of weeks. I should be able to test your changes in a more or less timely manner, so feel free to ping me if the need arises. -- With best wishes Dmitry -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] cross-canadian.bbclass: support n32 OS variant
Add support for -gnun32 OS variant which is used by MIPS64 N32.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
meta/classes/cross-canadian.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/cross-canadian.bbclass
b/meta/classes/cross-canadian.bbclass
index a4ce5c7..976a545 100644
--- a/meta/classes/cross-canadian.bbclass
+++ b/meta/classes/cross-canadian.bbclass
@@ -30,7 +30,7 @@ python () {
tos = d.getVar(TARGET_OS, True)
whitelist = []
-for variant in [, spe, x32, eabi]:
+for variant in [, spe, x32, eabi, n32]:
for libc in [, uclibc, musl]:
entry = linux
if variant and libc:
--
2.4.6
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] adt-installer: use DEPLOY_DIR in ANT_DEPLOY expansion
Currently adt-installer uses ${TMPDIR}/deploy/sdk/ as a deployment dir.
This doesn't interact well with DEPLOY_DIR reassignment. So let's use
${DEPLOY_DIR}/sdk/ instead.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
meta/recipes-devtools/installer/adt-installer_1.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/installer/adt-installer_1.0.bb
b/meta/recipes-devtools/installer/adt-installer_1.0.bb
index 07070b5..8d31ae5 100644
--- a/meta/recipes-devtools/installer/adt-installer_1.0.bb
+++ b/meta/recipes-devtools/installer/adt-installer_1.0.bb
@@ -33,7 +33,7 @@ INHIBIT_DEFAULT_DEPS = 1
PR = r11
-ADT_DEPLOY = ${TMPDIR}/deploy/sdk/
+ADT_DEPLOY = ${DEPLOY_DIR}/sdk/
ADT_DIR = ${WORKDIR}/adt-installer/
S = ${WORKDIR}/opkg-${PV}
--
2.4.6
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Fix builds for MIPS64 N32
2015-07-29 17:58 GMT+03:00 Mark Hatle mark.ha...@windriver.com: On 7/28/15 12:26 PM, Dmitry Eremin-Solenikov wrote: 2015-07-21 18:26 GMT+03:00 Mark Hatle mark.ha...@windriver.com: On 7/21/15 9:31 AM, Mark Hatle wrote: On 7/21/15 3:23 AM, Dmitry Eremin-Solenikov wrote: Hello, 2015-07-20 18:47 GMT+03:00 Mark Hatle mark.ha...@windriver.com: Between customer escalations, other work and vacation.. I didn't happen. No problem, really. I just wanted to be sure that the patches aren't going to be lost. I've started testing it this morning and should have results tomorrow.. (US time). Thank you very much! With master and the four patches I got an error trying to construct the SDK. I'm still investigating the error: Collected errors: * satisfy_dependencies_for: Cannot satisfy the following dependencies for packagegroup-cross-canadian-qemumips64: * gcc-cross-canadian-mips * binutils-cross-canadian-mips * gdb-cross-canadian-mips * * opkg_install_cmd: Cannot install package packagegroup-cross-canadian-qemumips64. My configuration for this particular test was: (oe-init-build-env stock w/ the following changes) I've narrowed down the reproducer to just: MACHINE = qemumips64 require conf/multilib.conf DEFAULTTUNE = mips64-n32 MULTILIBS = (If you remove the require conf/multilib.conf then things work.) I'm going to continue to investigate. Any progress on your side? As I failed to reproduce the issue on my side, could you please specify: 1) what is the exact bitbake command that failed? 2) what additional layers do you have enabled in your build? 3) is it a cleanroom build, or you have an sstate cache populated with previous build results? 4) any additional information that I can use to reproduce the issue on my side? Recent check-ins have changed some things. The compile side was working for a while, but not the compilation side (using it). I've been working with RP on IRC, and he's come up with some additional patches. (including this set of 4..) So I think the set is fine, it's up to the other pieces that need to mesh with this to produce the working SDK. Ok. So what would be the plan then? If you need any additional tests from my side, I can provide them. --Mark --Mark MACHINE = qemumips64 require conf/multilib.conf DEFAULTTUNE = mips64-n32 MULTILIBS = multilib:lib64 multilib:lib32 DEFAULTTUNE_virtclass-multilib-lib64 = mips64 DEFAULTTUNE_virtclass-multilib-lib32 = mips32r2 # Set RPM_PREFER_ELF_ARCH to configure preferred ABI when using rpm packaging # backend to generate a rootfs, choices are: # 1: ELF32 wins # 2: ELF64 wins # 4: ELF64 N32 wins (for mips64 or mips64el only) RPM_PREFER_ELF_ARCH = 4 --Mark On 7/20/15 7:11 AM, Dmitry Eremin-Solenikov wrote: 2015-07-08 15:42 GMT+03:00 Mark Hatle mark.ha...@windriver.com: On 7/8/15 7:00 AM, Dmitry Eremin-Solenikov wrote: Hello, 2015-07-01 17:02 GMT+03:00 Dmitry Eremin-Solenikov dbarysh...@gmail.com: Quite simple configuration (MIPS64 N32 image) fails to build (see below). I have verified these patches in both single lib and in multilib cases. Tri-lib images and SDK for MIPS build fine with these patches. Any comments on this patchset? It would be nice to have N32 ubroken in the current master tree. Sorry, I'm traveling right now and haven't had time to review this. I should be able to get back to the office and test it by the end of the week. I visually reviewed the patches and I don't object to them going in -- but I'm still not sure they are all correct. Re-ping. I'd like to receive a confirmation from you (and thus get the patches merged) or to discuss, what seems wrong to you. --Mark Current situation: lumag@nexs:~/OE$ MACHINE=qemumips64n32 bitbake core-image-base NOTE: Started PRServer with DBfile: /home/lumag/OE/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 46391, PID: 15895 Loading cache: 100% || ETA: 00:00:00 Loaded 1302 entries from dependency cache. NOTE: Resolving any missing task queue dependencies ERROR: Nothing RPROVIDES 'binutils-cross-canadian-mips64' (but /home/lumag/OE/sources/openembedded-core/meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb RDEPENDS on or otherwise requires it) NOTE: Runtime target 'binutils-cross-canadian-mips64' is unbuildable, removing... Missing or unbuildable dependency chain was: ['binutils-cross-canadian-mips64'] NOTE: Runtime target 'packagegroup-cross-canadian-qemumips64n32' is unbuildable, removing... Missing or unbuildable dependency chain was: ['packagegroup-cross-canadian-qemumips64n32', 'binutils-cross-canadian-mips64'] ERROR: Required build target 'core-image-base' has no buildable providers. Missing or unbuildable dependency chain was: ['core-image-base', 'packagegroup-cross-canadian-qemumips64n32
Re: [OE-core] [PATCH 0/4] Fix builds for MIPS64 N32
2015-07-21 18:26 GMT+03:00 Mark Hatle mark.ha...@windriver.com: On 7/21/15 9:31 AM, Mark Hatle wrote: On 7/21/15 3:23 AM, Dmitry Eremin-Solenikov wrote: Hello, 2015-07-20 18:47 GMT+03:00 Mark Hatle mark.ha...@windriver.com: Between customer escalations, other work and vacation.. I didn't happen. No problem, really. I just wanted to be sure that the patches aren't going to be lost. I've started testing it this morning and should have results tomorrow.. (US time). Thank you very much! With master and the four patches I got an error trying to construct the SDK. I'm still investigating the error: Collected errors: * satisfy_dependencies_for: Cannot satisfy the following dependencies for packagegroup-cross-canadian-qemumips64: * gcc-cross-canadian-mips * binutils-cross-canadian-mips * gdb-cross-canadian-mips * * opkg_install_cmd: Cannot install package packagegroup-cross-canadian-qemumips64. My configuration for this particular test was: (oe-init-build-env stock w/ the following changes) I've narrowed down the reproducer to just: MACHINE = qemumips64 require conf/multilib.conf DEFAULTTUNE = mips64-n32 MULTILIBS = (If you remove the require conf/multilib.conf then things work.) I'm going to continue to investigate. I fail to reproduce this on my side. What is your exact bitbake command that fails? All my attempts to build an SDK/toolchains/etc succeeded. --Mark MACHINE = qemumips64 require conf/multilib.conf DEFAULTTUNE = mips64-n32 MULTILIBS = multilib:lib64 multilib:lib32 DEFAULTTUNE_virtclass-multilib-lib64 = mips64 DEFAULTTUNE_virtclass-multilib-lib32 = mips32r2 # Set RPM_PREFER_ELF_ARCH to configure preferred ABI when using rpm packaging # backend to generate a rootfs, choices are: # 1: ELF32 wins # 2: ELF64 wins # 4: ELF64 N32 wins (for mips64 or mips64el only) RPM_PREFER_ELF_ARCH = 4 --Mark On 7/20/15 7:11 AM, Dmitry Eremin-Solenikov wrote: 2015-07-08 15:42 GMT+03:00 Mark Hatle mark.ha...@windriver.com: On 7/8/15 7:00 AM, Dmitry Eremin-Solenikov wrote: Hello, 2015-07-01 17:02 GMT+03:00 Dmitry Eremin-Solenikov dbarysh...@gmail.com: Quite simple configuration (MIPS64 N32 image) fails to build (see below). I have verified these patches in both single lib and in multilib cases. Tri-lib images and SDK for MIPS build fine with these patches. Any comments on this patchset? It would be nice to have N32 ubroken in the current master tree. Sorry, I'm traveling right now and haven't had time to review this. I should be able to get back to the office and test it by the end of the week. I visually reviewed the patches and I don't object to them going in -- but I'm still not sure they are all correct. Re-ping. I'd like to receive a confirmation from you (and thus get the patches merged) or to discuss, what seems wrong to you. --Mark Current situation: lumag@nexs:~/OE$ MACHINE=qemumips64n32 bitbake core-image-base NOTE: Started PRServer with DBfile: /home/lumag/OE/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 46391, PID: 15895 Loading cache: 100% || ETA: 00:00:00 Loaded 1302 entries from dependency cache. NOTE: Resolving any missing task queue dependencies ERROR: Nothing RPROVIDES 'binutils-cross-canadian-mips64' (but /home/lumag/OE/sources/openembedded-core/meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb RDEPENDS on or otherwise requires it) NOTE: Runtime target 'binutils-cross-canadian-mips64' is unbuildable, removing... Missing or unbuildable dependency chain was: ['binutils-cross-canadian-mips64'] NOTE: Runtime target 'packagegroup-cross-canadian-qemumips64n32' is unbuildable, removing... Missing or unbuildable dependency chain was: ['packagegroup-cross-canadian-qemumips64n32', 'binutils-cross-canadian-mips64'] ERROR: Required build target 'core-image-base' has no buildable providers. Missing or unbuildable dependency chain was: ['core-image-base', 'packagegroup-cross-canadian-qemumips64n32', 'binutils-cross-canadian-mips64'] -- With best wishes Dmitry -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Fix builds for MIPS64 N32
Hello, 2015-07-20 18:47 GMT+03:00 Mark Hatle mark.ha...@windriver.com: Between customer escalations, other work and vacation.. I didn't happen. No problem, really. I just wanted to be sure that the patches aren't going to be lost. I've started testing it this morning and should have results tomorrow.. (US time). Thank you very much! --Mark On 7/20/15 7:11 AM, Dmitry Eremin-Solenikov wrote: 2015-07-08 15:42 GMT+03:00 Mark Hatle mark.ha...@windriver.com: On 7/8/15 7:00 AM, Dmitry Eremin-Solenikov wrote: Hello, 2015-07-01 17:02 GMT+03:00 Dmitry Eremin-Solenikov dbarysh...@gmail.com: Quite simple configuration (MIPS64 N32 image) fails to build (see below). I have verified these patches in both single lib and in multilib cases. Tri-lib images and SDK for MIPS build fine with these patches. Any comments on this patchset? It would be nice to have N32 ubroken in the current master tree. Sorry, I'm traveling right now and haven't had time to review this. I should be able to get back to the office and test it by the end of the week. I visually reviewed the patches and I don't object to them going in -- but I'm still not sure they are all correct. Re-ping. I'd like to receive a confirmation from you (and thus get the patches merged) or to discuss, what seems wrong to you. --Mark Current situation: lumag@nexs:~/OE$ MACHINE=qemumips64n32 bitbake core-image-base NOTE: Started PRServer with DBfile: /home/lumag/OE/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 46391, PID: 15895 Loading cache: 100% || ETA: 00:00:00 Loaded 1302 entries from dependency cache. NOTE: Resolving any missing task queue dependencies ERROR: Nothing RPROVIDES 'binutils-cross-canadian-mips64' (but /home/lumag/OE/sources/openembedded-core/meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb RDEPENDS on or otherwise requires it) NOTE: Runtime target 'binutils-cross-canadian-mips64' is unbuildable, removing... Missing or unbuildable dependency chain was: ['binutils-cross-canadian-mips64'] NOTE: Runtime target 'packagegroup-cross-canadian-qemumips64n32' is unbuildable, removing... Missing or unbuildable dependency chain was: ['packagegroup-cross-canadian-qemumips64n32', 'binutils-cross-canadian-mips64'] ERROR: Required build target 'core-image-base' has no buildable providers. Missing or unbuildable dependency chain was: ['core-image-base', 'packagegroup-cross-canadian-qemumips64n32', 'binutils-cross-canadian-mips64'] -- With best wishes Dmitry -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Fix builds for MIPS64 N32
2015-07-08 15:42 GMT+03:00 Mark Hatle mark.ha...@windriver.com: On 7/8/15 7:00 AM, Dmitry Eremin-Solenikov wrote: Hello, 2015-07-01 17:02 GMT+03:00 Dmitry Eremin-Solenikov dbarysh...@gmail.com: Quite simple configuration (MIPS64 N32 image) fails to build (see below). I have verified these patches in both single lib and in multilib cases. Tri-lib images and SDK for MIPS build fine with these patches. Any comments on this patchset? It would be nice to have N32 ubroken in the current master tree. Sorry, I'm traveling right now and haven't had time to review this. I should be able to get back to the office and test it by the end of the week. I visually reviewed the patches and I don't object to them going in -- but I'm still not sure they are all correct. Re-ping. I'd like to receive a confirmation from you (and thus get the patches merged) or to discuss, what seems wrong to you. --Mark Current situation: lumag@nexs:~/OE$ MACHINE=qemumips64n32 bitbake core-image-base NOTE: Started PRServer with DBfile: /home/lumag/OE/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 46391, PID: 15895 Loading cache: 100% || ETA: 00:00:00 Loaded 1302 entries from dependency cache. NOTE: Resolving any missing task queue dependencies ERROR: Nothing RPROVIDES 'binutils-cross-canadian-mips64' (but /home/lumag/OE/sources/openembedded-core/meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb RDEPENDS on or otherwise requires it) NOTE: Runtime target 'binutils-cross-canadian-mips64' is unbuildable, removing... Missing or unbuildable dependency chain was: ['binutils-cross-canadian-mips64'] NOTE: Runtime target 'packagegroup-cross-canadian-qemumips64n32' is unbuildable, removing... Missing or unbuildable dependency chain was: ['packagegroup-cross-canadian-qemumips64n32', 'binutils-cross-canadian-mips64'] ERROR: Required build target 'core-image-base' has no buildable providers. Missing or unbuildable dependency chain was: ['core-image-base', 'packagegroup-cross-canadian-qemumips64n32', 'binutils-cross-canadian-mips64'] -- With best wishes Dmitry -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Fix builds for MIPS64 N32
Hello, 2015-07-01 17:02 GMT+03:00 Dmitry Eremin-Solenikov dbarysh...@gmail.com: Quite simple configuration (MIPS64 N32 image) fails to build (see below). I have verified these patches in both single lib and in multilib cases. Tri-lib images and SDK for MIPS build fine with these patches. Any comments on this patchset? It would be nice to have N32 ubroken in the current master tree. Current situation: lumag@nexs:~/OE$ MACHINE=qemumips64n32 bitbake core-image-base NOTE: Started PRServer with DBfile: /home/lumag/OE/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 46391, PID: 15895 Loading cache: 100% || ETA: 00:00:00 Loaded 1302 entries from dependency cache. NOTE: Resolving any missing task queue dependencies ERROR: Nothing RPROVIDES 'binutils-cross-canadian-mips64' (but /home/lumag/OE/sources/openembedded-core/meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb RDEPENDS on or otherwise requires it) NOTE: Runtime target 'binutils-cross-canadian-mips64' is unbuildable, removing... Missing or unbuildable dependency chain was: ['binutils-cross-canadian-mips64'] NOTE: Runtime target 'packagegroup-cross-canadian-qemumips64n32' is unbuildable, removing... Missing or unbuildable dependency chain was: ['packagegroup-cross-canadian-qemumips64n32', 'binutils-cross-canadian-mips64'] ERROR: Required build target 'core-image-base' has no buildable providers. Missing or unbuildable dependency chain was: ['core-image-base', 'packagegroup-cross-canadian-qemumips64n32', 'binutils-cross-canadian-mips64'] -- With best wishes Dmitry -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/4] glibc: don't override TUNE_CCARGS for MIPS
Overriding TUNE_CCARGS this way breaks MULTILIB setup for MIPS. This
override disables multilib handling of tunes for TUNE_CCARGS, thus
enforcing glibc's TUNE_CCARGS to the TUNE_CCARGS of main DEFAULTTUNE.
Glibc perfectly build without this override for both simple and multilib
cases.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
meta/recipes-core/glibc/glibc_2.21.bb | 10 --
1 file changed, 10 deletions(-)
diff --git a/meta/recipes-core/glibc/glibc_2.21.bb
b/meta/recipes-core/glibc/glibc_2.21.bb
index 8197c29..52252b3 100644
--- a/meta/recipes-core/glibc/glibc_2.21.bb
+++ b/meta/recipes-core/glibc/glibc_2.21.bb
@@ -95,16 +95,6 @@ do_patch_append() {
bb.build.exec_func('do_fix_readlib_c', d)
}
-# for mips glibc now builds syscall tables for all abi's
-# so we make sure that we choose right march option which is
-# compatible with o32,n32 and n64 abi's
-# e.g. -march=mips32 is not compatible with n32 and n64 therefore
-# we filter it out in such case -march=from-abi which will be
-# mips1 when using o32 and mips3 when using n32/n64
-
-TUNE_CCARGS_mips := ${@oe_filter_out('-march=mips32', '${TUNE_CCARGS}', d)}
-TUNE_CCARGS_mipsel := ${@oe_filter_out('-march=mips32', '${TUNE_CCARGS}', d)}
-
do_fix_readlib_c () {
sed -i -e
's#OECORE_KNOWN_INTERPRETER_NAMES#${EGLIBC_KNOWN_INTERPRETER_NAMES}#'
${S}/elf/readlib.c
}
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/4] cross.bbclass: override MULTIMACH_TARGET_SYS
Cross packages are built for BUILD_VENDOR/BUILD_OS, rather than
TARGET_VENDOR/TARGET_OS. E.g. there is no point in hardcoding the
target's LIBCEXTENSION and ABIEXTENSION into the STAMPDIR/WORKDIR
variables (set using MULTIMACH_TARGET_SYS).
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
meta/classes/cross.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/cross.bbclass b/meta/classes/cross.bbclass
index 28fd211..5ee32b2 100644
--- a/meta/classes/cross.bbclass
+++ b/meta/classes/cross.bbclass
@@ -21,6 +21,8 @@ STAGING_DIR_HOST =
${STAGING_DIR}/${HOST_ARCH}${HOST_VENDOR}-${HOST_OS}
PACKAGE_ARCH = ${BUILD_ARCH}
+MULTIMACH_TARGET_SYS = ${PACKAGE_ARCH}${BUILD_VENDOR}-${BUILD_OS}
+
export PKG_CONFIG_DIR = ${exec_prefix}/lib/pkgconfig
export PKG_CONFIG_SYSROOT_DIR =
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/4] packagegroups-cross-canadian: don't override TRANSLATED_TARGET_ARCH
There is no point in overriding TRANSLATED_TARGET_ARCH in
packagegroups-cross-canadian recipe. The cross-canadian class sets the
PACKAGE_ARCH variable, thus allarch class (inherited through
packagegroup class) doesn't change variables.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb | 3 ---
1 file changed, 3 deletions(-)
diff --git a/meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb
b/meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb
index e3b1c18..34e6e2b 100644
--- a/meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb
@@ -2,9 +2,6 @@ SUMMARY = Host SDK package for cross canadian toolchain
PN = packagegroup-cross-canadian-${MACHINE}
LICENSE = MIT
-# Save TRANSLATED_TARGET_ARCH before allarch tramples it
-TRANSLATED_TARGET_ARCH = ${@d.getVar('TUNE_ARCH', True).replace('_', '-')}
-
inherit cross-canadian packagegroup
PACKAGEGROUP_DISABLE_COMPLEMENTARY = 1
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/4] Fix builds for MIPS64 N32
Quite simple configuration (MIPS64 N32 image) fails to build (see below). I have verified these patches in both single lib and in multilib cases. Tri-lib images and SDK for MIPS build fine with these patches. Current situation: lumag@nexs:~/OE$ MACHINE=qemumips64n32 bitbake core-image-base NOTE: Started PRServer with DBfile: /home/lumag/OE/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 46391, PID: 15895 Loading cache: 100% || ETA: 00:00:00 Loaded 1302 entries from dependency cache. NOTE: Resolving any missing task queue dependencies ERROR: Nothing RPROVIDES 'binutils-cross-canadian-mips64' (but /home/lumag/OE/sources/openembedded-core/meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb RDEPENDS on or otherwise requires it) NOTE: Runtime target 'binutils-cross-canadian-mips64' is unbuildable, removing... Missing or unbuildable dependency chain was: ['binutils-cross-canadian-mips64'] NOTE: Runtime target 'packagegroup-cross-canadian-qemumips64n32' is unbuildable, removing... Missing or unbuildable dependency chain was: ['packagegroup-cross-canadian-qemumips64n32', 'binutils-cross-canadian-mips64'] ERROR: Required build target 'core-image-base' has no buildable providers. Missing or unbuildable dependency chain was: ['core-image-base', 'packagegroup-cross-canadian-qemumips64n32', 'binutils-cross-canadian-mips64'] -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/4] arch-mips.inc: don't override TRANSLATED_TARGET_ARCH
Currently MIPS64 N32 is broken. There is internal disagreement
between TARGET_ARCH (which doesn't contain ABIEXTENSION) and
TRANSLATED_TARGET_ARCH (which contains ABIEXTENSION). ABI is already
encoded into the TARGET_OS. ARM tunes in the same situation override
neither the TARGET_ARCH nor the TRANSLATED_TARGET_ARCH. So let's drop
this override.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
meta/conf/machine/include/mips/arch-mips.inc | 4
1 file changed, 4 deletions(-)
diff --git a/meta/conf/machine/include/mips/arch-mips.inc
b/meta/conf/machine/include/mips/arch-mips.inc
index c41fa5e..02626d3 100644
--- a/meta/conf/machine/include/mips/arch-mips.inc
+++ b/meta/conf/machine/include/mips/arch-mips.inc
@@ -100,7 +100,3 @@ TUNE_FEATURES_tune-mips64el-nf = n64
BASE_LIB_tune-mips64el-nf = lib64
MIPSPKGSFX_VARIANT_tune-mips64el-nf = ${TUNE_ARCH}
PACKAGE_EXTRA_ARCHS_tune-mips64el-nf = mips64el-nf
-
-# On mips we need to redefine this to include the ABIEXTENSION
-# we can avoid the python bit as there are no _ or - to translate
-TRANSLATED_TARGET_ARCH = ${TARGET_ARCH}${ABIEXTENSION}
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] arch-mips.inc: don't override TRANSLATED_TARGET_ARCH
2015-06-19 20:47 GMT+03:00 Dmitry Eremin-Solenikov dbarysh...@gmail.com: Hello, 2015-06-19 17:01 GMT+03:00 Mark Hatle mark.ha...@windriver.com: On 6/19/15 4:23 AM, Dmitry Eremin-Solenikov wrote: On 6/18/15 8:13 AM, Dmitry Eremin-Solenikov wrote: Currently MIPS64 N32 is broken. There is internal disagreement between TARGET_ARCH (which doesn't contain ABIEXTENSION) and TRANSLATED_TARGET_ARCH (which contains ABIEXTENSION). ABI is already encoded into the TARGET_OS. ARM tunes in the same situation override neither the TARGET_ARCH nor the TRANSLATED_TARGET_ARCH. So let's drop this override. This series won't work properly, unless I'm reading something incorrectly. You won't be able to build/install a tri-lib system after this change, as something needs to be there to differential between MIPS32 (o32), MIPS64 (n32) and MIPS64 (n64). Currently this is done via the ABIEXTENSION value. Why do you need this differentiation in the TARGET_ARCH? We have TARGET_SYS (triplets) for that, don't we? And the compilers for the N64/N32 (the only thing IIRC that is really dependent on the TARGET_ARCH) should be interchangeable, AFAIU. The triplet for o32 is: mips-os-linux The triplet to n64 is: mips64-os-linux The triplet to n32 is: mips64-os-linux thus w/o the ABI extension there is no mechanism to distinguish between n64 and n32. Can you point me, please, how to create a tri-ABI SDK and/or image? Configure with a MIPS64 capable machine (yes qemumips64 is adequate). Then add the following to your local.conf: require conf/multilib.conf DEFAULTTUNE = mips32r2 MULTILIBS = multilib:lib32 multilib:lib64 DEFAULTTUNE_virtclass-multilib-lib32 = mips64-n32 DEFAULTTUNE_virtclass-multilib-lib64 = mips64 This will set the default ABI to 'o32', with optional n32 and n64 support. (You can switch around the defaulttune values to change which is default and which is optional. A common config is n32 default, o32 / n64 optional.) I tried adding these settings to a special machine config (but there should be no difference with adding them to local.conf) and got a lot of errors from QA on linux-yocto (because of 32 vs 64 bitness missmatch on kernel objects). Are you sure that this config works out of box for you? Got the tri-ABI image built. Had to change default to N32, fix the glibc recipe not to override the TUNE_CCARGS, etc. Here is a summary: 1) My patches do not break building multilib images/SDK. 2) They are required to build images, defaulting to N32 ABI 3) Building tri-lib images does not work out of box anyway, thanks to glibc (I'll send a patch). 4) Multilib SDK for MIPS build, but the build is quite questionable anyway (see below). Thus I'd ask for my patches to be merged. WARNING: gcc multilib setup is not supported for TARGET_ARCH=mips64 WARNING: gcc multilib setup is not supported for TARGET_ARCH=mips64 WARNING: gcc multilib setup is not supported for TARGET_ARCH=mips64 WARNING: QA Issue: gcc-cross-canadian-mips64: Files/directories were installed but not shipped in any package: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/lib /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/mips64-oemllib64-linux/gcc/mips64-oemllib64-linux/5.1.0/plugin/libcc1plugin.so.0.0.0 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/mips64-oemllib64-linux/gcc/mips64-oemllib64-linux/5.1.0/plugin/libcc1plugin.so.0 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/mips64-oemllib64-linux/gcc/mips64-oemllib64-linux/5.1.0/plugin/libcc1plugin.la /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/mips64-oemllib64-linux/gcc/mips64-oemllib64-linux/5.1.0/plugin/libcc1plugin.so /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/mips64-oemllib64-linux/gcc/mips64-oemllib64-linux/5.1.0/plugin/.debug /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/mips64-oemllib64-linux/gcc/mips64-oemllib64-linux/5.1.0/plugin/.debug/libcc1plugin.so.0.0.0 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/lib/libcc1.la /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/lib/libcc1.so /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/lib/libcc1.so.0.0.0 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/lib/libcc1.so.0 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/lib/.debug /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/lib/.debug/libcc1.so.0.0.0 Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install. [installed-vs-shipped] WARNING: QA Issue: gcc-cross-canadian-mips: Files/directories were installed but not shipped in any package: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/lib /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/lib/libcc1.la /usr/local/oecore-x86_64
Re: [OE-core] [PATCH 1/3] arch-mips.inc: don't override TRANSLATED_TARGET_ARCH
On 6/18/15 8:13 AM, Dmitry Eremin-Solenikov wrote: Currently MIPS64 N32 is broken. There is internal disagreement between TARGET_ARCH (which doesn't contain ABIEXTENSION) and TRANSLATED_TARGET_ARCH (which contains ABIEXTENSION). ABI is already encoded into the TARGET_OS. ARM tunes in the same situation override neither the TARGET_ARCH nor the TRANSLATED_TARGET_ARCH. So let's drop this override. This series won't work properly, unless I'm reading something incorrectly. You won't be able to build/install a tri-lib system after this change, as something needs to be there to differential between MIPS32 (o32), MIPS64 (n32) and MIPS64 (n64). Currently this is done via the ABIEXTENSION value. Why do you need this differentiation in the TARGET_ARCH? We have TARGET_SYS (triplets) for that, don't we? And the compilers for the N64/N32 (the only thing IIRC that is really dependent on the TARGET_ARCH) should be interchangeable, AFAIU. Can you point me, please, how to create a tri-ABI SDK and/or image? What is currently broken w/ MIPS64 N32? We put in a number of fixes for this problem and SDK generation in the YP 1.8 time frame. Perhaps something has changed since then or maybe the fixes were not as complete as we thought? Quite simple configuration (MIPS64 N32 image) fails to build. lumag@nexs:~/OE$ MACHINE=qemumips64n32 bitbake core-image-base NOTE: Started PRServer with DBfile: /home/lumag/OE/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 46391, PID: 15895 Loading cache: 100% || ETA: 00:00:00 Loaded 1302 entries from dependency cache. NOTE: Resolving any missing task queue dependencies ERROR: Nothing RPROVIDES 'binutils-cross-canadian-mips64' (but /home/lumag/OE/sources/openembedded-core/meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb RDEPENDS on or otherwise requires it) NOTE: Runtime target 'binutils-cross-canadian-mips64' is unbuildable, removing... Missing or unbuildable dependency chain was: ['binutils-cross-canadian-mips64'] NOTE: Runtime target 'packagegroup-cross-canadian-qemumips64n32' is unbuildable, removing... Missing or unbuildable dependency chain was: ['packagegroup-cross-canadian-qemumips64n32', 'binutils-cross-canadian-mips64'] ERROR: Required build target 'core-image-base' has no buildable providers. Missing or unbuildable dependency chain was: ['core-image-base', 'packagegroup-cross-canadian-qemumips64n32', 'binutils-cross-canadian-mips64'] -- With best wishes Dmitry -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] arch-mips.inc: don't override TRANSLATED_TARGET_ARCH
Hello, 2015-06-19 17:01 GMT+03:00 Mark Hatle mark.ha...@windriver.com: On 6/19/15 4:23 AM, Dmitry Eremin-Solenikov wrote: On 6/18/15 8:13 AM, Dmitry Eremin-Solenikov wrote: Currently MIPS64 N32 is broken. There is internal disagreement between TARGET_ARCH (which doesn't contain ABIEXTENSION) and TRANSLATED_TARGET_ARCH (which contains ABIEXTENSION). ABI is already encoded into the TARGET_OS. ARM tunes in the same situation override neither the TARGET_ARCH nor the TRANSLATED_TARGET_ARCH. So let's drop this override. This series won't work properly, unless I'm reading something incorrectly. You won't be able to build/install a tri-lib system after this change, as something needs to be there to differential between MIPS32 (o32), MIPS64 (n32) and MIPS64 (n64). Currently this is done via the ABIEXTENSION value. Why do you need this differentiation in the TARGET_ARCH? We have TARGET_SYS (triplets) for that, don't we? And the compilers for the N64/N32 (the only thing IIRC that is really dependent on the TARGET_ARCH) should be interchangeable, AFAIU. The triplet for o32 is: mips-os-linux The triplet to n64 is: mips64-os-linux The triplet to n32 is: mips64-os-linux No. It is mips64-oe-linux-gnun32! Even with my patches. thus w/o the ABI extension there is no mechanism to distinguish between n64 and n32. See, the arch is the same (MIPS64), it should not encode the ABI. The multiplet differs (mips64-oe-linux vs. mips64-oe-linux-gnun32) and this also looks correct. Can you point me, please, how to create a tri-ABI SDK and/or image? Configure with a MIPS64 capable machine (yes qemumips64 is adequate). Then add the following to your local.conf: require conf/multilib.conf DEFAULTTUNE = mips32r2 MULTILIBS = multilib:lib32 multilib:lib64 DEFAULTTUNE_virtclass-multilib-lib32 = mips64-n32 DEFAULTTUNE_virtclass-multilib-lib64 = mips64 This will set the default ABI to 'o32', with optional n32 and n64 support. (You can switch around the defaulttune values to change which is default and which is optional. A common config is n32 default, o32 / n64 optional.) I'll try with this with my patches. What is currently broken w/ MIPS64 N32? We put in a number of fixes for this problem and SDK generation in the YP 1.8 time frame. Perhaps something has changed since then or maybe the fixes were not as complete as we thought? Quite simple configuration (MIPS64 N32 image) fails to build. lumag@nexs:~/OE$ MACHINE=qemumips64n32 bitbake core-image-base NOTE: Started PRServer with DBfile: /home/lumag/OE/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 46391, PID: 15895 Loading cache: 100% || ETA: 00:00:00 Loaded 1302 entries from dependency cache. NOTE: Resolving any missing task queue dependencies ERROR: Nothing RPROVIDES 'binutils-cross-canadian-mips64' (but /home/lumag/OE/sources/openembedded-core/meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb RDEPENDS on or otherwise requires it) NOTE: Runtime target 'binutils-cross-canadian-mips64' is unbuildable, removing... Looks to me that when binutils was upgraded, the rename of the arch component broke in some way. The arch renaming used by the cross-canadian toolchain components SHOULD have changed things to me mips64-n32 in the n32 case. This is the purpose of the ABIEXTENSION being added to the 'TRANSLATED_TARGET_ARCH' in arch-mips.conf. See commit: 0bcc01121e928d0be7a0550e500425852c63cf98 for additional details. (The commit msg includes the configuration listed above as well.) -- With best wishes Dmitry -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] arch-mips.inc: don't override TRANSLATED_TARGET_ARCH
Hello, 2015-06-19 17:01 GMT+03:00 Mark Hatle mark.ha...@windriver.com: On 6/19/15 4:23 AM, Dmitry Eremin-Solenikov wrote: On 6/18/15 8:13 AM, Dmitry Eremin-Solenikov wrote: Currently MIPS64 N32 is broken. There is internal disagreement between TARGET_ARCH (which doesn't contain ABIEXTENSION) and TRANSLATED_TARGET_ARCH (which contains ABIEXTENSION). ABI is already encoded into the TARGET_OS. ARM tunes in the same situation override neither the TARGET_ARCH nor the TRANSLATED_TARGET_ARCH. So let's drop this override. This series won't work properly, unless I'm reading something incorrectly. You won't be able to build/install a tri-lib system after this change, as something needs to be there to differential between MIPS32 (o32), MIPS64 (n32) and MIPS64 (n64). Currently this is done via the ABIEXTENSION value. Why do you need this differentiation in the TARGET_ARCH? We have TARGET_SYS (triplets) for that, don't we? And the compilers for the N64/N32 (the only thing IIRC that is really dependent on the TARGET_ARCH) should be interchangeable, AFAIU. The triplet for o32 is: mips-os-linux The triplet to n64 is: mips64-os-linux The triplet to n32 is: mips64-os-linux thus w/o the ABI extension there is no mechanism to distinguish between n64 and n32. Can you point me, please, how to create a tri-ABI SDK and/or image? Configure with a MIPS64 capable machine (yes qemumips64 is adequate). Then add the following to your local.conf: require conf/multilib.conf DEFAULTTUNE = mips32r2 MULTILIBS = multilib:lib32 multilib:lib64 DEFAULTTUNE_virtclass-multilib-lib32 = mips64-n32 DEFAULTTUNE_virtclass-multilib-lib64 = mips64 This will set the default ABI to 'o32', with optional n32 and n64 support. (You can switch around the defaulttune values to change which is default and which is optional. A common config is n32 default, o32 / n64 optional.) I tried adding these settings to a special machine config (but there should be no difference with adding them to local.conf) and got a lot of errors from QA on linux-yocto (because of 32 vs 64 bitness missmatch on kernel objects). Are you sure that this config works out of box for you? -- With best wishes Dmitry -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] arch-mips.inc: don't override TRANSLATED_TARGET_ARCH
Currently MIPS64 N32 is broken. There is internal disagreement
between TARGET_ARCH (which doesn't contain ABIEXTENSION) and
TRANSLATED_TARGET_ARCH (which contains ABIEXTENSION). ABI is already
encoded into the TARGET_OS. ARM tunes in the same situation override
neither the TARGET_ARCH nor the TRANSLATED_TARGET_ARCH. So let's drop
this override.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
meta/conf/machine/include/mips/arch-mips.inc | 4
1 file changed, 4 deletions(-)
diff --git a/meta/conf/machine/include/mips/arch-mips.inc
b/meta/conf/machine/include/mips/arch-mips.inc
index c41fa5e..02626d3 100644
--- a/meta/conf/machine/include/mips/arch-mips.inc
+++ b/meta/conf/machine/include/mips/arch-mips.inc
@@ -100,7 +100,3 @@ TUNE_FEATURES_tune-mips64el-nf = n64
BASE_LIB_tune-mips64el-nf = lib64
MIPSPKGSFX_VARIANT_tune-mips64el-nf = ${TUNE_ARCH}
PACKAGE_EXTRA_ARCHS_tune-mips64el-nf = mips64el-nf
-
-# On mips we need to redefine this to include the ABIEXTENSION
-# we can avoid the python bit as there are no _ or - to translate
-TRANSLATED_TARGET_ARCH = ${TARGET_ARCH}${ABIEXTENSION}
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] cross.bbclass: override MULTIMACH_TARGET_SYS
Cross packages are built for BUILD_VENDOR/BUILD_OS, rather than
TARGET_VENDOR/TARGET_OS. E.g. there is no point in hardcoding the
target's LIBCEXTENSION and ABIEXTENSION into the STAMPDIR/WORKDIR
variables (set using MULTIMACH_TARGET_SYS).
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
meta/classes/cross.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/cross.bbclass b/meta/classes/cross.bbclass
index 28fd211..5ee32b2 100644
--- a/meta/classes/cross.bbclass
+++ b/meta/classes/cross.bbclass
@@ -21,6 +21,8 @@ STAGING_DIR_HOST =
${STAGING_DIR}/${HOST_ARCH}${HOST_VENDOR}-${HOST_OS}
PACKAGE_ARCH = ${BUILD_ARCH}
+MULTIMACH_TARGET_SYS = ${PACKAGE_ARCH}${BUILD_VENDOR}-${BUILD_OS}
+
export PKG_CONFIG_DIR = ${exec_prefix}/lib/pkgconfig
export PKG_CONFIG_SYSROOT_DIR =
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] packagegroups-cross-canadian: don't override TRANSLATED_TARGET_ARCH
There is no point in overriding TRANSLATED_TARGET_ARCH in
packagegroups-cross-canadian recipe. The cross-canadian class sets the
PACKAGE_ARCH variable, thus allarch class (inherited through
packagegroup class) doesn't change variables.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb | 3 ---
1 file changed, 3 deletions(-)
diff --git a/meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb
b/meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb
index e3b1c18..34e6e2b 100644
--- a/meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb
@@ -2,9 +2,6 @@ SUMMARY = Host SDK package for cross canadian toolchain
PN = packagegroup-cross-canadian-${MACHINE}
LICENSE = MIT
-# Save TRANSLATED_TARGET_ARCH before allarch tramples it
-TRANSLATED_TARGET_ARCH = ${@d.getVar('TUNE_ARCH', True).replace('_', '-')}
-
inherit cross-canadian packagegroup
PACKAGEGROUP_DISABLE_COMPLEMENTARY = 1
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Cortex-A9 vs Thumb configuration
Hello, I was hit by one of changes in the package arch/tune/etc. naming. I'm building an image for the qemuarma9 (well, the error will be applicable to any ARMv7-based machine). After enabling ARM_INSTRUCTION_SET=thumb in the config, I received the following error: ERROR: OE-core's config sanity checker detected a potential misconfiguration. Either fix the cause of this error or at your own risk disable the checker (see sanity.conf). Following is the list of potential problems / advisories: Error, the PACKAGE_ARCHS variable does not contain TUNE_PKGARCH (armv7at2-vfp-neon). -- With best wishes Dmitry -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] OpenEmbedded e.V. membership status announcement
Hello, 2015-05-05 1:27 GMT+03:00 Denys Dmytriyenko de...@denix.org: All, In accordance with OpenEmbedded e.V. statutes, members that were absent from two or more consecutive annual General Assembly meetings and didn't have anyone representing them by proxy, forfeit their active membership status and can no longer vote in any OE e.V. election. Thus, the current up-to-date membership roster is one of the blocking items for any election process. After collating the attendance records and all gathered proxy forms from past years GA meetings, the Board of Directors came up with the following list of inactive members - see below. Realizing, that some people may still be active in other capacities in the OpenEmbedded e.V. organization, or just wish to renew their active status, the Board of Directors would like to open up a two-week period for inactive members to state their intent to become active, after which we should be able to vote for reinstating them back. The Board will make an effort to contact inactive members directly by email, or please feel free to reply to this announcement with your intent. Thanks. The list of e.V. members to become inactive, based on GA attendance: [skipped a list with my name in it] While I'm an active user and sporadically active contributor to OE, I'm not a frequent visitor to the conferences, where GA take place :( I tried using proxies for GA attendance, but it did not work for various reasons. So I'm OK with being listed as an 'inactive' member. Hoping that I will be able to become formally 'active' again, if I become active wrt. e.V in real life. -- With best wishes Dmitry -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RESEND][PATCH 1/3] meta: add new qemuarma9 machine definition
On 05/14/2015 05:37 PM, Bruce Ashfield wrote: On 2015-05-14 09:46 AM, Richard Purdie wrote: On Wed, 2015-05-13 at 18:17 -0700, Andre McCurdy wrote: On Tue, May 12, 2015 at 7:47 AM, Martin Jansa martin.ja...@gmail.com wrote: On Tue, May 12, 2015 at 03:25:43PM +0100, Burton, Ross wrote: On 11 May 2015 at 20:52, Dmitry Eremin-Solenikov dmitry_ere...@mentor.com wrote: Currently qemuarm is limited to 256 Mb of RAM. Sometimes this is too little to run necessary applications. Add a new arm configuration based on Versatile Express board, Cortex-A9 CPU, allowing up to 1Gb of RAM. Not sure I'm keen on oe-core having two almost-identical qemuarm machines. Why not just change the qemuarm machine to use the A9? Then we should officially drop thumb1 support, because current qemuarm builds are quite broken when thumb is enabled and dropping current qemuarm or replacing it with A9 variant will prevent oe-core to be testable on autobuilder. See https://bugzilla.yoctoproject.org/show_bug.cgi?id=7717 +1 for updating qemuarm to an ARMv7 CPU. One thing I did notice about the new proposed arm machine was the lack of graphics support. We really do need a machine with graphics. If we could get a machine which had graphics and more memory that would be much more attractive to switch to. This also has implications on the kernel support (cc Bruce). I've been using the qemuarma9 machine in some different contexts for a while now, and in fact, there's a BSP definition in linux-yocto already for it. So from that point of view, the kernel impacts are understood. But not only does the qemuarma9 lack graphics, it also has issues with disk and USB, so generally it isn't as usable as the arm926 qemu variant. I ended up enabling virtio to get disc working in qemuarma9. Such setup is used in provided runqemu patches. However I did not include a patch to linux-yocto recipe/git tree. There are other options that have newer CPUs, or just changing the cpu .. but a wholesale switch to the qemuarma9 machine tends to bring some new challenges. Yes, that is why in the patches I proposed qemuarma9 as an alternative (rather then a replacement) to plain qemuarm. -- With best wishes Dmitry -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RESEND][PATCH 3/3] scripts/runqemu: add qemuarma9 support
Support new qemuarma9 machine type. It mostly reuses existing qemuarm
setup, but the virtio-based network and disk devices.
Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
---
scripts/runqemu | 9 ++---
scripts/runqemu-internal | 35 +++
2 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index 84ece4d..87834f9 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -108,7 +108,7 @@ process_filename() {
while true; do
arg=${1}
case $arg in
-qemux86 | qemux86-64 | qemuarm | qemuarm64 | qemumips |
qemumipsel | \
+qemux86 | qemux86-64 | qemuarm | qemuarma9 | qemuarm64 |
qemumips | qemumipsel | \
qemumips64 | qemush4 | qemuppc | qemumicroblaze | qemuzynq)
[ -z $MACHINE ] MACHINE=$arg || \
error conflicting MACHINE types [$MACHINE] and [$arg]
@@ -232,13 +232,13 @@ fi
if [ -z $MACHINE ]; then
if [ x$FSTYPE = xvmdk ]; then
-MACHINE=`basename $VM | sed -n
's/.*\(qemux86-64\|qemux86\|qemuarm\|qemumips64\|qemumips\|qemuppc\|qemush4\).*/\1/p'`
+MACHINE=`basename $VM | sed -n
's/.*\(qemux86-64\|qemux86\|qemuarma9\|qemuarm\|qemumips64\|qemumips\|qemuppc\|qemush4\).*/\1/p'`
if [ -z $MACHINE ]; then
error Unable to set MACHINE from vmdk filename [$VM]
fi
echo Set MACHINE to [$MACHINE] based on vmdk [$VM]
else
-MACHINE=`basename $KERNEL | sed -n
's/.*\(qemux86-64\|qemux86\|qemuarm\|qemumips64\|qemumips\|qemuppc\|qemush4\).*/\1/p'`
+MACHINE=`basename $KERNEL | sed -n
's/.*\(qemux86-64\|qemux86\|qemuarma9\|qemuarm\|qemumips64\|qemumips\|qemuppc\|qemush4\).*/\1/p'`
if [ -z $MACHINE ]; then
error Unable to set MACHINE from kernel filename [$KERNEL]
fi
@@ -304,6 +304,9 @@ QEMUX86_64_DEFAULT_FSTYPE=ext4
QEMUARM_DEFAULT_KERNEL=zImage-qemuarm.bin
QEMUARM_DEFAULT_FSTYPE=ext4
+QEMUARMA9_DEFAULT_KERNEL=zImage-qemuarma9.bin
+QEMUARMA9_DEFAULT_FSTYPE=ext4
+
QEMUARM64_DEFAULT_KERNEL=Image-qemuarm64.bin
QEMUARM64_DEFAULT_FSTYPE=ext4
diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal
index f17bb05..a70c2cc 100755
--- a/scripts/runqemu-internal
+++ b/scripts/runqemu-internal
@@ -50,6 +50,9 @@ else
qemuarm)
mem_size=128
;;
+qemuarma9)
+mem_size=512
+;;
qemuarm64)
mem_size=512
;;
@@ -128,6 +131,11 @@ if [ $SLIRP_ENABLED = yes ]; then
QEMU_NETWORK_CMD=
DROOT=/dev/sda
ROOTFS_OPTIONS=-hda $ROOTFS
+elif [ $MACHINE = qemuarma9 ]; then
+QEMU_UI_OPTIONS=-nographic
+QEMU_NETWORK_CMD=
+DROOT=/dev/vda
+ROOTFS_OPTIONS=-drive id=disk0,file=$ROOTFS -device
virtio-blk-device,drive=disk0
else
QEMU_NETWORK_CMD=
DROOT=/dev/hda
@@ -276,6 +284,11 @@ else
DROOT=/dev/sda
ROOTFS_OPTIONS=-hda $ROOTFS
fi
+if [ $MACHINE = qemuarma9 ]; then
+QEMU_NETWORK_CMD=-netdev
tap,id=net0,ifname=$TAP,script=no,downscript=no -device
virtio-net-device,netdev=net0
+DROOT=/dev/vda
+ROOTFS_OPTIONS=-drive id=disk0,file=$ROOTFS -device
virtio-blk-device,drive=disk0
+fi
if [ $MACHINE = qemuarm64 ]; then
QEMU_NETWORK_CMD=-netdev
tap,id=net0,ifname=$TAP,script=no,downscript=no -device
virtio-net-device,netdev=net0
DROOT=/dev/vda
@@ -284,7 +297,7 @@ else
KERNCMDLINE=mem=$QEMU_MEMORY
QEMU_UI_OPTIONS=-show-cursor -usb -usbdevice wacom-tablet
-if [ $MACHINE = 'qemuarm64' ]; then
+if [ $MACHINE = 'qemuarm64' -o $MACHINE = 'qemuarma9' ]; then
QEMU_UI_OPTIONS=-nographic
fi
@@ -308,6 +321,7 @@ case $MACHINE in
qemuppc) ;;
qemuarmv6) ;;
qemuarmv7) ;;
+qemuarma9) ;;
qemux86) ;;
qemux86-64) ;;
qemuzynq) ;;
@@ -361,14 +375,23 @@ if [ $FSTYPE = nfs ]; then
NFSRUNNING=true
fi
-if [ $MACHINE = qemuarm -o $MACHINE = qemuarmv6 -o $MACHINE =
qemuarmv7 ]; then
+if [ $MACHINE = qemuarm -o $MACHINE = qemuarmv6 -o $MACHINE =
qemuarmv7 -o $MACHINE = qemuarma9 ]; then
QEMU=qemu-system-arm
-MACHINE_SUBTYPE=versatilepb
+if [ $MACHINE = qemuarma9 ]; then
+MACHINE_SUBTYPE=vexpress-a9
+else
+MACHINE_SUBTYPE=versatilepb
+fi
export QEMU_AUDIO_DRV=none
QEMU_UI_OPTIONS=$QEMU_UI_OPTIONS
# QEMU_UI_OPTIONS=$QEMU_UI_OPTIONS -force-pointer
+if [ $MACHINE = qemuarma9 ]; then
+TTYCONSOLE=
+else
+TTYCONSOLE=console=tty
+fi
if [ ${FSTYPE:0:3} = ext -o $FSTYPE = btrfs ]; then
-KERNCMDLINE=root=$DROOT rw console=ttyAMA0,115200 console=tty
$KERNEL_NETWORK_CMD mem=$QEMU_MEMORY highres=off
+KERNCMDLINE=root=$DROOT rw console=ttyAMA0,115200 $TTYCONSOLE
$KERNEL_NETWORK_CMD mem=$QEMU_MEMORY highres=off
[OE-core] [PATCH] libevent: add ptest
Use provided regression testing as a ptest for libevent package.
Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
---
meta/recipes-support/libevent/libevent/run-ptest | 18 ++
meta/recipes-support/libevent/libevent_2.0.22.bb | 17 -
2 files changed, 34 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-support/libevent/libevent/run-ptest
diff --git a/meta/recipes-support/libevent/libevent/run-ptest
b/meta/recipes-support/libevent/libevent/run-ptest
new file mode 100644
index 000..d521688
--- /dev/null
+++ b/meta/recipes-support/libevent/libevent/run-ptest
@@ -0,0 +1,18 @@
+#!/bin/sh
+
+fail=0
+for test in ./test/*
+do
+ $test
+ if [ $? -eq 0 ]
+ then
+ fail=1
+ fi
+done
+
+if [ $fail -eq 0 ]
+then
+ echo PASS: libevent
+else
+ echo FAIL: libevent
+fi
diff --git a/meta/recipes-support/libevent/libevent_2.0.22.bb
b/meta/recipes-support/libevent/libevent_2.0.22.bb
index 3f9475e..2f49293 100644
--- a/meta/recipes-support/libevent/libevent_2.0.22.bb
+++ b/meta/recipes-support/libevent/libevent_2.0.22.bb
@@ -6,7 +6,10 @@ SECTION = libs
LICENSE = BSD
LIC_FILES_CHKSUM = file://LICENSE;md5=45c5316ff684bcfe2f9f86d8b1279559
-SRC_URI = ${SOURCEFORGE_MIRROR}/levent/${BP}-stable.tar.gz
+SRC_URI = \
+${SOURCEFORGE_MIRROR}/levent/${BP}-stable.tar.gz \
+file://run-ptest \
+
SRC_URI[md5sum] = c4c56f986aa985677ca1db89630a2e11
SRC_URI[sha256sum] =
71c2c49f0adadacfdbe6332a372c38cf9c8b7895bb73dabeaa53cdcc1d4e1fa3
@@ -20,3 +23,15 @@ inherit autotools
# Needed for Debian packaging
LEAD_SONAME = libevent-2.0.so
+
+inherit ptest
+
+DEPENDS = zlib
+
+do_install_ptest() {
+ install -d ${D}${PTEST_PATH}/test
+ for file in ${B}/test/.libs/regress ${B}/test/.libs/test*
+ do
+ install -m 0755 $file ${D}${PTEST_PATH}/test
+ done
+}
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RESEND][PATCH 2/3] scripts/runqemu: factor out some qemuarm configuration options
In preparation of adding qemuarma9 support to runqemu scripts, factor
out some qemuarm-related options to be handled in a more generic way.
Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
---
scripts/runqemu-internal | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal
index bc2a355..f17bb05 100755
--- a/scripts/runqemu-internal
+++ b/scripts/runqemu-internal
@@ -124,6 +124,10 @@ if [ $SLIRP_ENABLED = yes ]; then
QEMU_NETWORK_CMD=
DROOT=/dev/vda
ROOTFS_OPTIONS=-drive file=$ROOTFS,if=virtio,format=raw
+elif [ $MACHINE = qemuarm -o $MACHINE = qemuarmv6 -o $MACHINE =
qemuarmv7 ]; then
+QEMU_NETWORK_CMD=
+DROOT=/dev/sda
+ROOTFS_OPTIONS=-hda $ROOTFS
else
QEMU_NETWORK_CMD=
DROOT=/dev/hda
@@ -267,6 +271,11 @@ else
DROOT=/dev/hda
ROOTFS_OPTIONS=-hda $ROOTFS
fi
+if [ $MACHINE = qemuarm -o $MACHINE = qemuarmv6 -o $MACHINE
= qemuarmv7 ]; then
+QEMU_NETWORK_CMD=-net nic,vlan=0 $QEMU_TAP_CMD
+DROOT=/dev/sda
+ROOTFS_OPTIONS=-hda $ROOTFS
+fi
if [ $MACHINE = qemuarm64 ]; then
QEMU_NETWORK_CMD=-netdev
tap,id=net0,ifname=$TAP,script=no,downscript=no -device
virtio-net-device,netdev=net0
DROOT=/dev/vda
@@ -359,8 +368,8 @@ if [ $MACHINE = qemuarm -o $MACHINE = qemuarmv6 -o
$MACHINE = qemuarm
QEMU_UI_OPTIONS=$QEMU_UI_OPTIONS
# QEMU_UI_OPTIONS=$QEMU_UI_OPTIONS -force-pointer
if [ ${FSTYPE:0:3} = ext -o $FSTYPE = btrfs ]; then
-KERNCMDLINE=root=/dev/sda rw console=ttyAMA0,115200 console=tty
$KERNEL_NETWORK_CMD mem=$QEMU_MEMORY highres=off
-QEMUOPTIONS=$QEMU_NETWORK_CMD -M ${MACHINE_SUBTYPE} -hda $ROOTFS
-no-reboot $QEMU_UI_OPTIONS
+KERNCMDLINE=root=$DROOT rw console=ttyAMA0,115200 console=tty
$KERNEL_NETWORK_CMD mem=$QEMU_MEMORY highres=off
+QEMUOPTIONS=$QEMU_NETWORK_CMD -M ${MACHINE_SUBTYPE} $ROOTFS_OPTIONS
-no-reboot $QEMU_UI_OPTIONS
fi
if [ $FSTYPE = nfs ]; then
if [ $NFS_SERVER = 192.168.7.1 -a ! -d $NFS_DIR ]; then
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RESEND][PATCH 1/3] meta: add new qemuarma9 machine definition
Currently qemuarm is limited to 256 Mb of RAM. Sometimes this is too little to run necessary applications. Add a new arm configuration based on Versatile Express board, Cortex-A9 CPU, allowing up to 1Gb of RAM. Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com --- meta/conf/machine/qemuarma9.conf | 11 +++ 1 file changed, 11 insertions(+) create mode 100644 meta/conf/machine/qemuarma9.conf diff --git a/meta/conf/machine/qemuarma9.conf b/meta/conf/machine/qemuarma9.conf new file mode 100644 index 000..119d172 --- /dev/null +++ b/meta/conf/machine/qemuarma9.conf @@ -0,0 +1,11 @@ +#@TYPE: Machine +#@NAME: arm_versatile_cortexa9 +#@DESCRIPTION: arm_versatile_cortexa9 + +require conf/machine/include/qemu.inc +require conf/machine/include/tune-cortexa9.inc + +KERNEL_IMAGETYPE = zImage +KERNEL_DEVICETREE = vexpress-v2p-ca9.dtb + +SERIAL_CONSOLE = 115200 ttyAMA0 -- 2.1.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] systemd.bbclass: drop has_exactly_one_service setting
The has_exactly_one_service variable was used in now deleted code. Drop
this part to make code cleaner.
Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
---
meta/classes/systemd.bbclass | 3 ---
1 file changed, 3 deletions(-)
diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
index c34884b..cfe1eb5 100644
--- a/meta/classes/systemd.bbclass
+++ b/meta/classes/systemd.bbclass
@@ -139,9 +139,6 @@ python systemd_populate_packages() {
searchpaths.append(oe.path.join(d.getVar(nonarch_base_libdir, True),
systemd, system))
searchpaths.append(oe.path.join(d.getVar(exec_prefix, True),
d.getVar(nonarch_base_libdir, True), systemd, system))
systemd_packages = d.getVar('SYSTEMD_PACKAGES', True)
-has_exactly_one_service = len(systemd_packages.split()) == 1
-if has_exactly_one_service:
-has_exactly_one_service = len(get_package_var(d,
'SYSTEMD_SERVICE', systemd_packages).split()) == 1
keys = 'Also'
# scan for all in SYSTEMD_SERVICE[]
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] qt4-x11-free: make virtual/libgl dependecy conditional
Make qt4-x11-free depend on virtual/libgl only if the DISTRO_FEATURES
contain opengl. Otherwise there will be no package to fullfil this
dependency.
Using PACKAGECONFIG for this seems to be unreasonable: it is not used by
qt4-x11-free to track other dependencies. Also QT_GLFLAGS variable
properly tracks passing -opengl or -no-opengl to configure script.
Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
---
meta/recipes-qt/qt4/qt4-x11-free.inc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-qt/qt4/qt4-x11-free.inc
b/meta/recipes-qt/qt4/qt4-x11-free.inc
index 3b1e0fe..835fc96 100644
--- a/meta/recipes-qt/qt4/qt4-x11-free.inc
+++ b/meta/recipes-qt/qt4/qt4-x11-free.inc
@@ -4,7 +4,8 @@ SUMMARY = Cross-platform UI toolkit and application framework
(X11 version)
DESCRIPTION = Qt is a versatile cross-platform application framework -- this
is the X11 version.
HOMEPAGE = http://qt-project.org/;
SECTION = x11/libs
-DEPENDS += virtual/libgl virtual/libx11 fontconfig libxft libxext libxrender
libxrandr libxcursor
+DEPENDS += virtual/libx11 fontconfig libxft libxext libxrender libxrandr
libxcursor
+DEPENDS += ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl',
'', d)}
PROVIDES += qt4-x11
QT4DEPENDS =
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] qt4-x11-free: make virtual/libgl dependecy conditional
On 04/25/2015 12:20 AM, Martin Jansa wrote:
On Fri, Apr 24, 2015 at 11:02:21PM +0300, Dmitry Eremin-Solenikov wrote:
Make qt4-x11-free depend on virtual/libgl only if the DISTRO_FEATURES
contain opengl. Otherwise there will be no package to fullfil this
dependency.
Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
---
meta/recipes-qt/qt4/qt4-x11-free.inc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-qt/qt4/qt4-x11-free.inc
b/meta/recipes-qt/qt4/qt4-x11-free.inc
index 3b1e0fe..835fc96 100644
--- a/meta/recipes-qt/qt4/qt4-x11-free.inc
+++ b/meta/recipes-qt/qt4/qt4-x11-free.inc
@@ -4,7 +4,8 @@ SUMMARY = Cross-platform UI toolkit and application framework (X11
version)
DESCRIPTION = Qt is a versatile cross-platform application framework -- this is
the X11 version.
HOMEPAGE = http://qt-project.org/;
SECTION = x11/libs
-DEPENDS += virtual/libgl virtual/libx11 fontconfig libxft libxext libxrender
libxrandr libxcursor
+DEPENDS += virtual/libx11 fontconfig libxft libxext libxrender libxrandr
libxcursor
+DEPENDS += ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl', '',
d)}
That still leaves opengl support to be autodetected from sysroot for
distributions without opengl in DISTRO_FEATURES but where someone built
virtual/libgl provider before qt4-x11-free.
You need to use PACKAGECONFIG to explicitly disable it when it should be
disabled based on DISTRO_FEATURES.
I have checked the qt4-x11-free.inc file. It correctly sets QT_GLFLAGS
depending on the presence of 'opengl' in DISTRO_FEATURES. So my patch is
correct.
--
With best wishes
Dmitry
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] qt4-x11-free: make virtual/libgl dependecy conditional
Make qt4-x11-free depend on virtual/libgl only if the DISTRO_FEATURES
contain opengl. Otherwise there will be no package to fullfil this
dependency.
Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
---
meta/recipes-qt/qt4/qt4-x11-free.inc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-qt/qt4/qt4-x11-free.inc
b/meta/recipes-qt/qt4/qt4-x11-free.inc
index 3b1e0fe..835fc96 100644
--- a/meta/recipes-qt/qt4/qt4-x11-free.inc
+++ b/meta/recipes-qt/qt4/qt4-x11-free.inc
@@ -4,7 +4,8 @@ SUMMARY = Cross-platform UI toolkit and application framework
(X11 version)
DESCRIPTION = Qt is a versatile cross-platform application framework -- this
is the X11 version.
HOMEPAGE = http://qt-project.org/;
SECTION = x11/libs
-DEPENDS += virtual/libgl virtual/libx11 fontconfig libxft libxext libxrender
libxrandr libxcursor
+DEPENDS += virtual/libx11 fontconfig libxft libxext libxrender libxrandr
libxcursor
+DEPENDS += ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl',
'', d)}
PROVIDES += qt4-x11
QT4DEPENDS =
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] icecc.bbclass: blacklist libgcc-initial
Building libgcc-initial with IceCC enabled can fail with the CPP sanity
check error in the following case (using ARM for example):
* sysroot contains cross gcc built for another ARM variant
* sysroot contains initial cross gcc built to suit the target machine
* bitbake tries to configure libgcc-initial
* libgcc-initial calls icecc wrapper
* icecc wrapper calls non-initial cross gcc via the full path
* non-initial cross gcc looks for the headers in the wrong place
* BOOM
Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
---
meta/classes/icecc.bbclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/classes/icecc.bbclass b/meta/classes/icecc.bbclass
index 2f9e3cf..529b097 100644
--- a/meta/classes/icecc.bbclass
+++ b/meta/classes/icecc.bbclass
@@ -117,7 +117,8 @@ def use_icc(bb,d):
# system_package_blacklist = [ uclibc, glibc, gcc, bind, u-boot,
dhcp-forwarder, enchant, connman, orbit2 ]
# when adding new entry, please document why (how it failed) so that we
can re-evaluate it later
# e.g. when there is new version
-system_package_blacklist = []
+# building libgcc-initial with icecc fails with CPP sanity check error if
host sysroot contains cross gcc built for another target tune/variant
+system_package_blacklist = [libgcc-initial]
user_package_blacklist = (d.getVar('ICECC_USER_PACKAGE_BL') or ).split()
user_package_whitelist = (d.getVar('ICECC_USER_PACKAGE_WL') or ).split()
package_blacklist = system_package_blacklist + user_package_blacklist
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] scripts/runqemu: factor out some qemuarm configuration options
In preparation of adding qemuarma9 support to runqemu scripts, factor
out some qemuarm-related options to be handled in a more generic way.
Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
---
scripts/runqemu-internal | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal
index 2db5566..65dbf21 100755
--- a/scripts/runqemu-internal
+++ b/scripts/runqemu-internal
@@ -124,6 +124,10 @@ if [ $SLIRP_ENABLED = yes ]; then
QEMU_NETWORK_CMD=
DROOT=/dev/vda
ROOTFS_OPTIONS=-drive file=$ROOTFS,if=virtio
+elif [ $MACHINE = qemuarm -o $MACHINE = qemuarmv6 -o $MACHINE =
qemuarmv7 ]; then
+QEMU_NETWORK_CMD=
+DROOT=/dev/sda
+ROOTFS_OPTIONS=-hda $ROOTFS
else
QEMU_NETWORK_CMD=
DROOT=/dev/hda
@@ -267,6 +271,11 @@ else
DROOT=/dev/hda
ROOTFS_OPTIONS=-hda $ROOTFS
fi
+if [ $MACHINE = qemuarm -o $MACHINE = qemuarmv6 -o $MACHINE
= qemuarmv7 ]; then
+QEMU_NETWORK_CMD=-net nic,vlan=0 $QEMU_TAP_CMD
+DROOT=/dev/sda
+ROOTFS_OPTIONS=-hda $ROOTFS
+fi
if [ $MACHINE = qemuarm64 ]; then
QEMU_NETWORK_CMD=-netdev
tap,id=net0,ifname=$TAP,script=no,downscript=no -device
virtio-net-device,netdev=net0
DROOT=/dev/vda
@@ -359,8 +368,8 @@ if [ $MACHINE = qemuarm -o $MACHINE = qemuarmv6 -o
$MACHINE = qemuarm
QEMU_UI_OPTIONS=$QEMU_UI_OPTIONS
# QEMU_UI_OPTIONS=$QEMU_UI_OPTIONS -force-pointer
if [ ${FSTYPE:0:3} = ext -o $FSTYPE = btrfs ]; then
-KERNCMDLINE=root=/dev/sda rw console=ttyAMA0,115200 console=tty
$KERNEL_NETWORK_CMD mem=$QEMU_MEMORY highres=off
-QEMUOPTIONS=$QEMU_NETWORK_CMD -M ${MACHINE_SUBTYPE} -hda $ROOTFS
-no-reboot $QEMU_UI_OPTIONS
+KERNCMDLINE=root=$DROOT rw console=ttyAMA0,115200 console=tty
$KERNEL_NETWORK_CMD mem=$QEMU_MEMORY highres=off
+QEMUOPTIONS=$QEMU_NETWORK_CMD -M ${MACHINE_SUBTYPE} $ROOTFS_OPTIONS
-no-reboot $QEMU_UI_OPTIONS
fi
if [ $FSTYPE = nfs ]; then
if [ $NFS_SERVER = 192.168.7.1 -a ! -d $NFS_DIR ]; then
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] scripts/runqemu: add qemuarma9 support
Support new qemuarma9 machine type. It mostly reuses existing qemuarm
setup, but the virtio-based network and disk devices.
Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
---
scripts/runqemu | 9 ++---
scripts/runqemu-internal | 35 +++
2 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index 84ece4d..87834f9 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -108,7 +108,7 @@ process_filename() {
while true; do
arg=${1}
case $arg in
-qemux86 | qemux86-64 | qemuarm | qemuarm64 | qemumips |
qemumipsel | \
+qemux86 | qemux86-64 | qemuarm | qemuarma9 | qemuarm64 |
qemumips | qemumipsel | \
qemumips64 | qemush4 | qemuppc | qemumicroblaze | qemuzynq)
[ -z $MACHINE ] MACHINE=$arg || \
error conflicting MACHINE types [$MACHINE] and [$arg]
@@ -232,13 +232,13 @@ fi
if [ -z $MACHINE ]; then
if [ x$FSTYPE = xvmdk ]; then
-MACHINE=`basename $VM | sed -n
's/.*\(qemux86-64\|qemux86\|qemuarm\|qemumips64\|qemumips\|qemuppc\|qemush4\).*/\1/p'`
+MACHINE=`basename $VM | sed -n
's/.*\(qemux86-64\|qemux86\|qemuarma9\|qemuarm\|qemumips64\|qemumips\|qemuppc\|qemush4\).*/\1/p'`
if [ -z $MACHINE ]; then
error Unable to set MACHINE from vmdk filename [$VM]
fi
echo Set MACHINE to [$MACHINE] based on vmdk [$VM]
else
-MACHINE=`basename $KERNEL | sed -n
's/.*\(qemux86-64\|qemux86\|qemuarm\|qemumips64\|qemumips\|qemuppc\|qemush4\).*/\1/p'`
+MACHINE=`basename $KERNEL | sed -n
's/.*\(qemux86-64\|qemux86\|qemuarma9\|qemuarm\|qemumips64\|qemumips\|qemuppc\|qemush4\).*/\1/p'`
if [ -z $MACHINE ]; then
error Unable to set MACHINE from kernel filename [$KERNEL]
fi
@@ -304,6 +304,9 @@ QEMUX86_64_DEFAULT_FSTYPE=ext4
QEMUARM_DEFAULT_KERNEL=zImage-qemuarm.bin
QEMUARM_DEFAULT_FSTYPE=ext4
+QEMUARMA9_DEFAULT_KERNEL=zImage-qemuarma9.bin
+QEMUARMA9_DEFAULT_FSTYPE=ext4
+
QEMUARM64_DEFAULT_KERNEL=Image-qemuarm64.bin
QEMUARM64_DEFAULT_FSTYPE=ext4
diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal
index 65dbf21..570c28e 100755
--- a/scripts/runqemu-internal
+++ b/scripts/runqemu-internal
@@ -50,6 +50,9 @@ else
qemuarm)
mem_size=128
;;
+qemuarma9)
+mem_size=512
+;;
qemuarm64)
mem_size=512
;;
@@ -128,6 +131,11 @@ if [ $SLIRP_ENABLED = yes ]; then
QEMU_NETWORK_CMD=
DROOT=/dev/sda
ROOTFS_OPTIONS=-hda $ROOTFS
+elif [ $MACHINE = qemuarma9 ]; then
+QEMU_UI_OPTIONS=-nographic
+QEMU_NETWORK_CMD=
+DROOT=/dev/vda
+ROOTFS_OPTIONS=-drive id=disk0,file=$ROOTFS -device
virtio-blk-device,drive=disk0
else
QEMU_NETWORK_CMD=
DROOT=/dev/hda
@@ -276,6 +284,11 @@ else
DROOT=/dev/sda
ROOTFS_OPTIONS=-hda $ROOTFS
fi
+if [ $MACHINE = qemuarma9 ]; then
+QEMU_NETWORK_CMD=-netdev
tap,id=net0,ifname=$TAP,script=no,downscript=no -device
virtio-net-device,netdev=net0
+DROOT=/dev/vda
+ROOTFS_OPTIONS=-drive id=disk0,file=$ROOTFS -device
virtio-blk-device,drive=disk0
+fi
if [ $MACHINE = qemuarm64 ]; then
QEMU_NETWORK_CMD=-netdev
tap,id=net0,ifname=$TAP,script=no,downscript=no -device
virtio-net-device,netdev=net0
DROOT=/dev/vda
@@ -284,7 +297,7 @@ else
KERNCMDLINE=mem=$QEMU_MEMORY
QEMU_UI_OPTIONS=-show-cursor -usb -usbdevice wacom-tablet
-if [ $MACHINE = 'qemuarm64' ]; then
+if [ $MACHINE = 'qemuarm64' -o $MACHINE = 'qemuarma9' ]; then
QEMU_UI_OPTIONS=-nographic
fi
@@ -308,6 +321,7 @@ case $MACHINE in
qemuppc) ;;
qemuarmv6) ;;
qemuarmv7) ;;
+qemuarma9) ;;
qemux86) ;;
qemux86-64) ;;
qemuzynq) ;;
@@ -361,14 +375,23 @@ if [ $FSTYPE = nfs ]; then
NFSRUNNING=true
fi
-if [ $MACHINE = qemuarm -o $MACHINE = qemuarmv6 -o $MACHINE =
qemuarmv7 ]; then
+if [ $MACHINE = qemuarm -o $MACHINE = qemuarmv6 -o $MACHINE =
qemuarmv7 -o $MACHINE = qemuarma9 ]; then
QEMU=qemu-system-arm
-MACHINE_SUBTYPE=versatilepb
+if [ $MACHINE = qemuarma9 ]; then
+MACHINE_SUBTYPE=vexpress-a9
+else
+MACHINE_SUBTYPE=versatilepb
+fi
export QEMU_AUDIO_DRV=none
QEMU_UI_OPTIONS=$QEMU_UI_OPTIONS
# QEMU_UI_OPTIONS=$QEMU_UI_OPTIONS -force-pointer
+if [ $MACHINE = qemuarma9 ]; then
+TTYCONSOLE=
+else
+TTYCONSOLE=console=tty
+fi
if [ ${FSTYPE:0:3} = ext -o $FSTYPE = btrfs ]; then
-KERNCMDLINE=root=$DROOT rw console=ttyAMA0,115200 console=tty
$KERNEL_NETWORK_CMD mem=$QEMU_MEMORY highres=off
+KERNCMDLINE=root=$DROOT rw console=ttyAMA0,115200 $TTYCONSOLE
$KERNEL_NETWORK_CMD mem=$QEMU_MEMORY highres=off
[OE-core] [PATCH 1/3] meta: add new qemuarma9 machine definition
Currently qemuarm is limited to 256 Mb of RAM. Sometimes this is too little to run necessary applications. Add a new arm configuration based on Versatile Express board, Cortex-A9 CPU, allowing up to 1Gb of RAM. Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com --- meta/conf/machine/qemuarma9.conf | 11 +++ 1 file changed, 11 insertions(+) create mode 100644 meta/conf/machine/qemuarma9.conf diff --git a/meta/conf/machine/qemuarma9.conf b/meta/conf/machine/qemuarma9.conf new file mode 100644 index 000..119d172 --- /dev/null +++ b/meta/conf/machine/qemuarma9.conf @@ -0,0 +1,11 @@ +#@TYPE: Machine +#@NAME: arm_versatile_cortexa9 +#@DESCRIPTION: arm_versatile_cortexa9 + +require conf/machine/include/qemu.inc +require conf/machine/include/tune-cortexa9.inc + +KERNEL_IMAGETYPE = zImage +KERNEL_DEVICETREE = vexpress-v2p-ca9.dtb + +SERIAL_CONSOLE = 115200 ttyAMA0 -- 2.1.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libevent: add ptest
Use provided regression testing as a ptest for libevent package.
Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
---
meta/recipes-support/libevent/libevent/run-ptest | 18 ++
meta/recipes-support/libevent/libevent_2.0.22.bb | 17 -
2 files changed, 34 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-support/libevent/libevent/run-ptest
diff --git a/meta/recipes-support/libevent/libevent/run-ptest
b/meta/recipes-support/libevent/libevent/run-ptest
new file mode 100644
index 000..d521688
--- /dev/null
+++ b/meta/recipes-support/libevent/libevent/run-ptest
@@ -0,0 +1,18 @@
+#!/bin/sh
+
+fail=0
+for test in ./test/*
+do
+ $test
+ if [ $? -eq 0 ]
+ then
+ fail=1
+ fi
+done
+
+if [ $fail -eq 0 ]
+then
+ echo PASS: libevent
+else
+ echo FAIL: libevent
+fi
diff --git a/meta/recipes-support/libevent/libevent_2.0.22.bb
b/meta/recipes-support/libevent/libevent_2.0.22.bb
index 3f9475e..2f49293 100644
--- a/meta/recipes-support/libevent/libevent_2.0.22.bb
+++ b/meta/recipes-support/libevent/libevent_2.0.22.bb
@@ -6,7 +6,10 @@ SECTION = libs
LICENSE = BSD
LIC_FILES_CHKSUM = file://LICENSE;md5=45c5316ff684bcfe2f9f86d8b1279559
-SRC_URI = ${SOURCEFORGE_MIRROR}/levent/${BP}-stable.tar.gz
+SRC_URI = \
+${SOURCEFORGE_MIRROR}/levent/${BP}-stable.tar.gz \
+file://run-ptest \
+
SRC_URI[md5sum] = c4c56f986aa985677ca1db89630a2e11
SRC_URI[sha256sum] =
71c2c49f0adadacfdbe6332a372c38cf9c8b7895bb73dabeaa53cdcc1d4e1fa3
@@ -20,3 +23,15 @@ inherit autotools
# Needed for Debian packaging
LEAD_SONAME = libevent-2.0.so
+
+inherit ptest
+
+DEPENDS = zlib
+
+do_install_ptest() {
+ install -d ${D}${PTEST_PATH}/test
+ for file in ${B}/test/.libs/regress ${B}/test/.libs/test*
+ do
+ install -m 0755 $file ${D}${PTEST_PATH}/test
+ done
+}
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] e2fsprogs: add ptest
Enable ptest for e2fsprogs by reusing provided testsuite.
Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
---
.../e2fsprogs/e2fsprogs/ptest.patch| 66 ++
.../recipes-devtools/e2fsprogs/e2fsprogs/run-ptest | 11
.../recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb | 17 ++
3 files changed, 94 insertions(+)
create mode 100644 meta/recipes-devtools/e2fsprogs/e2fsprogs/ptest.patch
create mode 100644 meta/recipes-devtools/e2fsprogs/e2fsprogs/run-ptest
diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs/ptest.patch
b/meta/recipes-devtools/e2fsprogs/e2fsprogs/ptest.patch
new file mode 100644
index 000..b8a53e9
--- /dev/null
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs/ptest.patch
@@ -0,0 +1,66 @@
+Index: e2fsprogs-1.42.9/tests/Makefile.in
+===
+--- e2fsprogs-1.42.9.orig/tests/Makefile.in
e2fsprogs-1.42.9/tests/Makefile.in
+@@ -18,7 +18,7 @@ test_one: $(srcdir)/test_one.in Makefile
+ @echo #!/bin/sh test_one
+ @HTREE_CMT@ @echo HTREE=y test_one
+ @QUOTA_CMT@ @echo QUOTA=y test_one
+- @echo SRCDIR=@srcdir@ test_one
++ @echo SRCDIR=/usr/lib/e2fsprogs/ptest/test test_one
+ @echo DIFF_OPTS=@UNI_DIFF_OPTS@ test_one
+ @cat $(srcdir)/test_one.in test_one
+ @chmod +x test_one
+@@ -26,7 +26,7 @@ test_one: $(srcdir)/test_one.in Makefile
+ test_script: test_one test_script.in Makefile mke2fs.conf
+ @echo Creating test_script...
+ @echo #!/bin/sh test_script
+- @echo SRCDIR=@srcdir@ test_script
++ @echo SRCDIR=/usr/lib/e2fsprogs/ptest/test test_script
+ @cat $(srcdir)/test_script.in test_script
+ @chmod +x test_script
+
+Index: e2fsprogs-1.42.9/tests/test_config
+===
+--- e2fsprogs-1.42.9.orig/tests/test_config
e2fsprogs-1.42.9/tests/test_config
+@@ -3,23 +3,23 @@
+ #
+
+ unset LANG LANGUAGE LC_ADDRESS LC_ALL LC_COLLATE LC_CTYPE LC_IDENTIFICATION
LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE
LC_TIME PAGER
+-FSCK=$USE_VALGRIND ../e2fsck/e2fsck
+-MKE2FS=$USE_VALGRIND ../misc/mke2fs
+-DUMPE2FS=$USE_VALGRIND ../misc/dumpe2fs
+-TUNE2FS=$USE_VALGRIND ../misc/tune2fs
+-CHATTR=$USE_VALGRIND../misc/chattr
+-LSATTR=$USE_VALGRIND ../misc/lsattr
+-E2IMAGE=$USE_VALGRIND ../misc/e2image
+-E2IMAGE_EXE=../misc/e2image
+-DEBUGFS=$USE_VALGRIND ../debugfs/debugfs
+-DEBUGFS_EXE=../debugfs/debugfs
+-TEST_BITS=../debugfs/debugfs
+-RESIZE2FS_EXE=../resize/resize2fs
++FSCK=$USE_VALGRIND e2fsck
++MKE2FS=$USE_VALGRIND mke2fs
++DUMPE2FS=$USE_VALGRIND dumpe2fs
++TUNE2FS=$USE_VALGRIND tune2fs
++CHATTR=$USE_VALGRIND chattr
++LSATTR=$USE_VALGRIND lsattr
++E2IMAGE=$USE_VALGRIND e2image
++E2IMAGE_EXE=/sbin/e2image
++DEBUGFS=$USE_VALGRIND debugfs
++DEBUGFS_EXE=/sbin/debugfs
++TEST_BITS=/sbin/debugfs
++RESIZE2FS_EXE=/sbin/resize2fs
+ RESIZE2FS=$USE_VALGRIND $RESIZE2FS_EXE
+-E2UNDO_EXE=../misc/e2undo
+-TEST_REL=../tests/progs/test_rel
+-TEST_ICOUNT=../tests/progs/test_icount
+-CRCSUM=../tests/progs/crcsum
++E2UNDO_EXE=/sbin/e2undo
++TEST_REL=./progs/test_rel
++TEST_ICOUNT=./progs/test_icount
++CRCSUM=./progs/crcsum
+ LD_LIBRARY_PATH=../lib:../lib/ext2fs:../lib/e2p:../lib/et:../lib/ss
+ DYLD_LIBRARY_PATH=../lib:../lib/ext2fs:../lib/e2p:../lib/et:../lib/ss
+ export LD_LIBRARY_PATH
diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs/run-ptest
b/meta/recipes-devtools/e2fsprogs/e2fsprogs/run-ptest
new file mode 100644
index 000..1ac2513
--- /dev/null
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs/run-ptest
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+cd ./test
+./test_script ../test.log
+if [ $? -eq 0 ]
+then
+ echo PASS: e2fsprogs
+ rm test.log
+else
+ echo FAIL: e2fsprogs
+fi
diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb
b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb
index 66065bc..67a5ea7 100644
--- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb
@@ -87,3 +87,20 @@ ALTERNATIVE_${PN} = chattr
ALTERNATIVE_PRIORITY = 100
ALTERNATIVE_LINK_NAME[chattr] = ${base_bindir}/chattr
ALTERNATIVE_TARGET[chattr] = ${base_bindir}/chattr.e2fsprogs
+
+inherit ptest
+SRC_URI += file://run-ptest
+SRC_URI += file://ptest.patch
+
+RDEPENDS_${PN}-ptest += ${PN} ${PN}-tune2fs coreutils procps
+#RDEPENDS_${PN}-ptest += expect
+
+do_compile_ptest() {
+ oe_runmake -C ${B}/tests
+}
+
+do_install_ptest() {
+ cp -a ${B}/tests ${D}${PTEST_PATH}/test
+ cp -a ${S}/tests/* ${D}${PTEST_PATH}/test
+ sed -e 's!../e2fsck/e2fsck!e2fsck!g' -i ${D}${PTEST_PATH}/test/*/expect*
+}
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] mdadm: add ptest
Enable ptest for mdadm, by reusing internal testsuite.
Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
---
meta/recipes-extended/mdadm/files/run-ptest | 10 ++
meta/recipes-extended/mdadm/mdadm_3.3.2.bb | 29 +
2 files changed, 39 insertions(+)
create mode 100644 meta/recipes-extended/mdadm/files/run-ptest
diff --git a/meta/recipes-extended/mdadm/files/run-ptest
b/meta/recipes-extended/mdadm/files/run-ptest
new file mode 100644
index 000..5b27609
--- /dev/null
+++ b/meta/recipes-extended/mdadm/files/run-ptest
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+./test ./test.log
+if [ $? -eq 0 ]
+then
+ echo PASS: mdadm
+ rm test.log
+else
+ echo FAIL: mdadm
+fi
diff --git a/meta/recipes-extended/mdadm/mdadm_3.3.2.bb
b/meta/recipes-extended/mdadm/mdadm_3.3.2.bb
index c6a5635..0742d73 100644
--- a/meta/recipes-extended/mdadm/mdadm_3.3.2.bb
+++ b/meta/recipes-extended/mdadm/mdadm_3.3.2.bb
@@ -12,6 +12,7 @@ SRC_URI =
${KERNELORG_MIRROR}/linux/utils/raid/mdadm/${BPN}-${PV}.tar.xz \
file://mdadm-3.2.2_fix_for_x32.patch \
file://gcc-4.9.patch \
file://mdadm-3.3.2_x32_abi_time_t.patch \
+ file://run-ptest \
SRC_URI[md5sum] = 44698d351501cac6a89072dc877eb220
@@ -45,3 +46,31 @@ do_install() {
}
FILES_${PN} += ${base_libdir}/udev/rules.d/*.rules
+
+inherit ptest
+
+do_compile_ptest() {
+ oe_runmake test
+}
+
+do_install_ptest() {
+ cp -a ${S}/tests ${D}${PTEST_PATH}/tests
+ cp ${S}/test ${D}${PTEST_PATH}
+ sed -e 's!sleep 0.*!sleep 1!g; s!/var/tmp!/!g' -i ${D}${PTEST_PATH}/test
+ ln -s /sbin/mdadm ${D}${PTEST_PATH}/mdadm
+ for prg in test_stripe swap_super raid6check
+ do
+ install -D -m 755 $prg ${D}${PTEST_PATH}/
+ done
+}
+RDEPENDS_${PN}-ptest += bash
+RRECOMMENDS_${PN}-ptest += \
+coreutils \
+util-linux \
+kernel-module-loop \
+kernel-module-linear \
+kernel-module-raid0 \
+kernel-module-raid1 \
+kernel-module-raid10 \
+kernel-module-raid456 \
+
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] groff: fix RDEPENDS
RDEPENDS_${PN} is appended with sed and on the following line it's fixed
to just perl. Merge both lines to have correct RDEPENDS.
Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
---
meta/recipes-extended/groff/groff_1.22.3.bb | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/meta/recipes-extended/groff/groff_1.22.3.bb
b/meta/recipes-extended/groff/groff_1.22.3.bb
index 7955a5c..dac0fdf 100644
--- a/meta/recipes-extended/groff/groff_1.22.3.bb
+++ b/meta/recipes-extended/groff/groff_1.22.3.bb
@@ -16,9 +16,7 @@ SRC_URI[sha256sum] =
3a48a9d6c97750bfbd535feeb5be0111db6406ddb7bb79fc680809cda6
DEPENDS = groff-native
DEPENDS_class-native =
-RDEPENDS_${PN} += sed
-
-RDEPENDS_${PN} = perl
+RDEPENDS_${PN} += perl sed
inherit autotools texinfo
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] lsb: provide lsb-core-ARCH
Some lsb packages depend on correct lsb-core-ARCH package being
installed (or rather provided) on the target file system. Provide this
package name by main lsb package.
Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
---
meta/recipes-extended/lsb/lsb_4.1.bb | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-extended/lsb/lsb_4.1.bb
b/meta/recipes-extended/lsb/lsb_4.1.bb
index 1ae1e26..7b2ee78 100644
--- a/meta/recipes-extended/lsb/lsb_4.1.bb
+++ b/meta/recipes-extended/lsb/lsb_4.1.bb
@@ -4,6 +4,11 @@ HOMEPAGE = http://prdownloads.sourceforge.net/lsb;
LICENSE = GPLv2+
PR = r2
+LSB_CORE = lsb-core-${TARGET_ARCH}
+LSB_CORE_x86 = lsb-core-ia32
+LSB_CORE_x86-64 = lsb-core-amd64
+RPROVIDES_${PN} += ${LSB_CORE}
+
# lsb_release needs getopt
RDEPENDS_${PN} += ${VIRTUAL-RUNTIME_getopt}
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] security_flags.inc: add more exceptions
On 04/10/2015 03:28 AM, Khem Raj wrote:
On Apr 9, 2015, at 12:58 PM, Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
wrote:
Add few more exceptions from other layers as noted during custom image
builds.
you can put it in respective layer.conf its seems a bit auxiliary to have it in
OE-Core
Would it be better to fix the layer.conf or individual recipes?
Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
---
meta/conf/distro/include/security_flags.inc | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/meta/conf/distro/include/security_flags.inc
b/meta/conf/distro/include/security_flags.inc
index 21e1a53..f977c8e 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -58,8 +58,10 @@ SECURITY_CFLAGS_pn-libglu = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-libpcap = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-libpcre = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-libproxy = ${SECURITY_NO_PIE_CFLAGS}
+SECURITY_CFLAGS_pn-libvirt = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-ltp = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-lttng-ust = ${SECURITY_NO_PIE_CFLAGS}
+SECURITY_CFLAGS_pn-lvm2 = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-mesa = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-mesa-gl = ${SECURITY_NO_PIE_CFLAGS}
[ skipped the rest]
--
With best wishes
Dmitry
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/4] groff: add runtime dependency on sed
This is to suppress the following QA warning:
groff-1.22.2: groff requires /bin/sed, but no providers in its RDEPENDS
[file-rdeps]
Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
---
meta/recipes-extended/groff/groff_1.22.2.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-extended/groff/groff_1.22.2.bb
b/meta/recipes-extended/groff/groff_1.22.2.bb
index 6e84587..dd345b7 100644
--- a/meta/recipes-extended/groff/groff_1.22.2.bb
+++ b/meta/recipes-extended/groff/groff_1.22.2.bb
@@ -17,6 +17,7 @@ SRC_URI[sha256sum] =
380864dac4772e0c0d7b1282d25d0c5fd7f63baf45c87c4657afed22a1
DEPENDS = groff-native
DEPENDS_class-native =
+RDEPENDS_${PN} += sed
inherit autotools texinfo
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/4] bitbake.conf: add sed-native to ASSUME_PROVIDED
There is no reason to build sed for the host, however now: ERROR: Nothing RPROVIDES 'sed-native' (but virtual:native:/OE/sources/openembedded-core/meta/recipes-extended/groff/groff_1.22.2.bb RDEPENDS on or otherwise requires it) Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com --- meta/conf/bitbake.conf | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index f3586da..2b3c110 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -171,6 +171,7 @@ ASSUME_PROVIDED = \ virtual/libintl-native \ texinfo-native \ bash-native \ +sed-native \ # gzip-native should be listed above? -- 2.1.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/4] lsb: provide lsb-core-ARCH
Some lsb packages depend on correct lsb-core-ARCH package being
installed (or rather provided) on the target file system. Provide this
package name by main lsb package.
Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
---
meta/recipes-extended/lsb/lsb_4.1.bb | 4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-extended/lsb/lsb_4.1.bb
b/meta/recipes-extended/lsb/lsb_4.1.bb
index 1ae1e26..c3a79c0 100644
--- a/meta/recipes-extended/lsb/lsb_4.1.bb
+++ b/meta/recipes-extended/lsb/lsb_4.1.bb
@@ -4,6 +4,10 @@ HOMEPAGE = http://prdownloads.sourceforge.net/lsb;
LICENSE = GPLv2+
PR = r2
+LSB_CORE = lsb-core-${TARGET_ARCH}
+LSB_CORE_i586 = lsb-core-ia32
+RPROVIDES_${PN} += ${LSB_CORE}
+
# lsb_release needs getopt
RDEPENDS_${PN} += ${VIRTUAL-RUNTIME_getopt}
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/4] security_flags.inc: add more exceptions
Add few more exceptions from other layers as noted during custom image
builds.
Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
---
meta/conf/distro/include/security_flags.inc | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/meta/conf/distro/include/security_flags.inc
b/meta/conf/distro/include/security_flags.inc
index 21e1a53..f977c8e 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -58,8 +58,10 @@ SECURITY_CFLAGS_pn-libglu = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-libpcap = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-libpcre = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-libproxy = ${SECURITY_NO_PIE_CFLAGS}
+SECURITY_CFLAGS_pn-libvirt = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-ltp = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-lttng-ust = ${SECURITY_NO_PIE_CFLAGS}
+SECURITY_CFLAGS_pn-lvm2 = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-mesa = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-mesa-gl = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-openssl = ${SECURITY_NO_PIE_CFLAGS}
@@ -69,14 +71,18 @@ SECURITY_CFLAGS_pn-python = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-python-imaging = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-python-pycurl = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-python-smartpm = ${SECURITY_NO_PIE_CFLAGS}
+SECURITY_CFLAGS_pn-rrdtool = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-tcl = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-tiff = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-valgrind = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-webkit-gtk = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-zlib = ${SECURITY_NO_PIE_CFLAGS}
-# These 2 have text relco errors with the pie options enabled
+# These have text relco errors with the pie options enabled
SECURITY_CFLAGS_pn-ltp = ${SECURITY_NO_PIE_CFLAGS}
+SECURITY_CFLAGS_pn-lxc = ${SECURITY_NO_PIE_CFLAGS}
+SECURITY_CFLAGS_pn-mozjs = ${SECURITY_NO_PIE_CFLAGS}
+SECURITY_CFLAGS_pn-openldap = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-pulseaudio = ${SECURITY_NO_PIE_CFLAGS}
TARGET_CFLAGS_append = ${SECURITY_CFLAGS}
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] icecc.bbclass: properly handle disabling of icecc
Always use use_icc to check if IceCC should be enabled. Move
ICECC_DISABLED variable checking to use_icc function. Also while we are
at it, fix condition in icc_is_allarch function.
Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
---
meta/classes/icecc.bbclass | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/meta/classes/icecc.bbclass b/meta/classes/icecc.bbclass
index 3ec8c06..2f9e3cf 100644
--- a/meta/classes/icecc.bbclass
+++ b/meta/classes/icecc.bbclass
@@ -91,6 +91,10 @@ def create_path(compilers, bb, d):
return staging
def use_icc(bb,d):
+if d.getVar('ICECC_DISABLED') == 1:
+# don't even try it, when explicitly disabled
+return no
+
# allarch recipes don't use compiler
if icc_is_allarch(bb, d):
return no
@@ -133,8 +137,7 @@ def use_icc(bb,d):
return yes
def icc_is_allarch(bb, d):
-return \
-bb.data.inherits_class(allarch, d);
+return d.getVar(PACKAGE_ARCH) == all
def icc_is_kernel(bb, d):
return \
@@ -148,10 +151,6 @@ def icc_is_native(bb, d):
# Don't pollute allarch signatures with TARGET_FPU
icc_version[vardepsexclude] += TARGET_FPU
def icc_version(bb, d):
-if d.getVar('ICECC_DISABLED') == 1:
-# don't even try it, when explicitly disabled
-return
-
if use_icc(bb, d) == no:
return
@@ -179,7 +178,7 @@ def icc_version(bb, d):
return tar_file
def icc_path(bb,d):
-if d.getVar('ICECC_DISABLED') == 1:
+if use_icc(bb, d) == no:
# don't create unnecessary directories when icecc is disabled
return
@@ -246,7 +245,7 @@ def set_icecc_env():
return
set_icecc_env() {
-if [ ${ICECC_DISABLED} = 1 ]
+if [ ${@use_icc(bb, d)} = no ]
then
return
fi
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] image_types bbclass: use compression framework for jffs2 sum images
I got hit by a missing dependency in generation of sum.jffs2 images - at
runtime, when images are generated using bitbake pool, it is possible
for sum.jffs2 image to be scheduled for generation before jffs2 image is
fully generated.
Insted of adding additional hacks, reimplement sum.jffs2 generation as a
compression scheme on top of plain jffs2 images. For now support for
sum.jffs2 images is left in, it will be removed by the subsequent
commit.
Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
---
meta/classes/image_types.bbclass | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 393bfa8..be56abb 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -33,6 +33,7 @@ XZ_COMPRESSION_LEVEL ?= -e -6
XZ_INTEGRITY_CHECK ?= crc32
XZ_THREADS ?= -T 0
+JFFS2_SUM_EXTRA_ARGS ?=
IMAGE_CMD_jffs2 = mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime
--output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 ${EXTRA_IMAGECMD}
IMAGE_CMD_sum.jffs2 = sumtool -i
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 -o
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.sum.jffs2 ${EXTRA_IMAGECMD}
@@ -128,19 +129,21 @@ IMAGE_DEPENDS_ubi = mtd-utils-native
IMAGE_DEPENDS_ubifs = mtd-utils-native
# This variable is available to request which values are suitable for
IMAGE_FSTYPES
-IMAGE_TYPES = jffs2 sum.jffs2 cramfs ext2 ext2.gz ext2.bz2 ext3 ext3.gz
ext2.lzma btrfs iso hddimg squashfs squashfs-xz ubi ubifs tar tar.gz tar.bz2
tar.xz tar.lz4 cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 vmdk elf
+IMAGE_TYPES = jffs2 jffs2.sum sum.jffs2 cramfs ext2 ext2.gz ext2.bz2 ext3
ext3.gz ext2.lzma btrfs iso hddimg squashfs squashfs-xz ubi ubifs tar tar.gz
tar.bz2 tar.xz tar.lz4 cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 vmdk elf
-COMPRESSIONTYPES = gz bz2 lzma xz lz4
+COMPRESSIONTYPES = gz bz2 lzma xz lz4 sum
COMPRESS_CMD_lzma = lzma -k -f -7 ${IMAGE_NAME}.rootfs.${type}
COMPRESS_CMD_gz = gzip -f -9 -c ${IMAGE_NAME}.rootfs.${type}
${IMAGE_NAME}.rootfs.${type}.gz
COMPRESS_CMD_bz2 = bzip2 -f -k ${IMAGE_NAME}.rootfs.${type}
COMPRESS_CMD_xz = xz -f -k -c ${XZ_COMPRESSION_LEVEL} ${XZ_THREADS}
--check=${XZ_INTEGRITY_CHECK} ${IMAGE_NAME}.rootfs.${type}
${IMAGE_NAME}.rootfs.${type}.xz
COMPRESS_CMD_lz4 = lz4c -9 -c ${IMAGE_NAME}.rootfs.${type}
${IMAGE_NAME}.rootfs.${type}.lz4
+COMPRESS_CMD_sum = sumtool -i ${IMAGE_NAME}.rootfs.${type} -o
${IMAGE_NAME}.rootfs.${type}.sum ${JFFS2_SUM_EXTRA_ARGS}
COMPRESS_DEPENDS_lzma = xz-native
COMPRESS_DEPENDS_gz =
COMPRESS_DEPENDS_bz2 =
COMPRESS_DEPENDS_xz = xz-native
COMPRESS_DEPENDS_lz4 = lz4-native
+COMPRESS_DEPENDS_sum = mtd-utils-native
RUNNABLE_IMAGE_TYPES ?= ext2 ext3
RUNNABLE_MACHINE_PATTERNS ?= qemu
--
1.8.5.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] image_types: sum.jffs2 is replaced by jffs2.sum
Previous commit added support for sum 'compression' (rather
postprocessing) of jffs2 images. Drop support for sum.jffs2 image type.
Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
---
meta/classes/image_types.bbclass | 4 +---
meta/lib/oe/image.py | 3 ---
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index be56abb..0467abd 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -35,7 +35,6 @@ XZ_THREADS ?= -T 0
JFFS2_SUM_EXTRA_ARGS ?=
IMAGE_CMD_jffs2 = mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime
--output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 ${EXTRA_IMAGECMD}
-IMAGE_CMD_sum.jffs2 = sumtool -i
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 -o
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.sum.jffs2 ${EXTRA_IMAGECMD}
IMAGE_CMD_cramfs = mkfs.cramfs ${IMAGE_ROOTFS}
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cramfs ${EXTRA_IMAGECMD}
@@ -116,7 +115,6 @@ EXTRA_IMAGECMD_elf ?=
IMAGE_DEPENDS =
IMAGE_DEPENDS_jffs2 = mtd-utils-native
-IMAGE_DEPENDS_sum.jffs2 = mtd-utils-native
IMAGE_DEPENDS_cramfs = util-linux-native
IMAGE_DEPENDS_ext2 = e2fsprogs-native
IMAGE_DEPENDS_ext3 = e2fsprogs-native
@@ -129,7 +127,7 @@ IMAGE_DEPENDS_ubi = mtd-utils-native
IMAGE_DEPENDS_ubifs = mtd-utils-native
# This variable is available to request which values are suitable for
IMAGE_FSTYPES
-IMAGE_TYPES = jffs2 jffs2.sum sum.jffs2 cramfs ext2 ext2.gz ext2.bz2 ext3
ext3.gz ext2.lzma btrfs iso hddimg squashfs squashfs-xz ubi ubifs tar tar.gz
tar.bz2 tar.xz tar.lz4 cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 vmdk elf
+IMAGE_TYPES = jffs2 jffs2.sum cramfs ext2 ext2.gz ext2.bz2 ext3 ext3.gz
ext2.lzma btrfs iso hddimg squashfs squashfs-xz ubi ubifs tar tar.gz tar.bz2
tar.xz tar.lz4 cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 vmdk elf
COMPRESSIONTYPES = gz bz2 lzma xz lz4 sum
COMPRESS_CMD_lzma = lzma -k -f -7 ${IMAGE_NAME}.rootfs.${type}
diff --git a/meta/lib/oe/image.py b/meta/lib/oe/image.py
index 54f7c84..c15296f 100644
--- a/meta/lib/oe/image.py
+++ b/meta/lib/oe/image.py
@@ -102,9 +102,6 @@ class Image(object):
# been created, so we add that explicit ordering here.
addtypedepends(elf, cpio.gz)
-# jffs2 sumtool'd images need jffs2
-addtypedepends(sum.jffs2, jffs2)
-
# Filter out all the compressed images from alltypes
for type in alltypes:
basetype = None
--
1.8.5.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-toolchain-qte and wrong paths to QT tools
On 12/22/2011 03:35 AM, Eric Bénard wrote:
Hi Dmitry,
Le 21/12/2011 19:22, Dmitry Eremin-Solenikov a écrit :
On 12/21/2011 06:56 PM, Juraj Hercek wrote:
Hello list,
I've two questions:
1) When I build meta-toolchain-qte (c2de8d4 metadata revision) and
install the resulting sdk, I see two directories in /usr/local/:
oecore-i686-arm and oecore-i686-i686. What is a rationale behind having
these two directories instead of one i.e.: oecore-i686-arm?
Because oecore-i686-i686 holds files that are created on i686 to be
used on
i686. They will be common for arm meta-toolchain-qte, mips
meta-toolchain-qte,
powerpc meta-toolchain-qte, etc.
2) The oecore-i686-arm/environment-setup-armv5te-oe-linux-gnueabi script
sets paths to the QT tools which should be installed in oecore-i686-arm
directory, but they are not. These tools are installed under
oecore-i686-i686 directory. Changing the path in
environment-setup-armv5te-oe-linux-gnueabi after toolchain installation
is easy, but I do not consider it to be a correct fix (assuming that
oecore-i686-{arm,i686} directories represents proper toolchain
structure). What is a proper fix for this issue?
I have the attached patch in my patch queue. Hope this helps.
there seems to be something wrong here :
- (cd ${SDK_OUTPUT}/${QT_TOOLS_PREFIX}/..; ln -s
${SDKTARGETSYSROOT}/usr/share/qtopia/mkspecs mkspecs;)
+ (cd ${SDK_NATIVE_OUTPUT}/${QT_TOOLS_PREFIX}/..; ln -s
${SDKTARGETSYSROOT}/usr/share/qtopia/mkspecs mkspecs;)
${SDK_NATIVE_OUTPUT} seems undefined.
My fault. I think you can ignore this part of the patch.
Eric
--
With best wishes
Dmitry
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] meta-toolchain-qte and wrong paths to QT tools
On 12/21/2011 06:56 PM, Juraj Hercek wrote:
Hello list,
I've two questions:
1) When I build meta-toolchain-qte (c2de8d4 metadata revision) and
install the resulting sdk, I see two directories in /usr/local/:
oecore-i686-arm and oecore-i686-i686. What is a rationale behind having
these two directories instead of one i.e.: oecore-i686-arm?
Because oecore-i686-i686 holds files that are created on i686 to be used
on i686. They will be common for arm meta-toolchain-qte, mips
meta-toolchain-qte, powerpc meta-toolchain-qte, etc.
2) The oecore-i686-arm/environment-setup-armv5te-oe-linux-gnueabi script
sets paths to the QT tools which should be installed in oecore-i686-arm
directory, but they are not. These tools are installed under
oecore-i686-i686 directory. Changing the path in
environment-setup-armv5te-oe-linux-gnueabi after toolchain installation
is easy, but I do not consider it to be a correct fix (assuming that
oecore-i686-{arm,i686} directories represents proper toolchain
structure). What is a proper fix for this issue?
I have the attached patch in my patch queue. Hope this helps.
--
With best wishes
Dmitry
From 80adbc460fa3abd595f1e4c37e402fb2ba51cba4 Mon Sep 17 00:00:00 2001
From: Dmitry Eremin-Solenikov dbarysh...@gmail.com
Date: Sun, 18 Dec 2011 22:27:49 +0400
Subject: [PATCH] SDK generation: fixup paths
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
meta/conf/bitbake.conf |3 ++-
meta/recipes-qt/meta/meta-toolchain-qte.bb |2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 1c21616..9af6faa 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -359,8 +359,9 @@ DEPLOY_DIR_TOOLS = ${DEPLOY_DIR}/tools
PKGDATA_DIR = ${TMPDIR}/pkgdata/${MULTIMACH_TARGET_SYS}
SDK_NAME = oecore-${SDK_ARCH}-${TARGET_ARCH}
+SDK_NATIVE_NAME = oecore-${SDK_ARCH}-${BUILD_ARCH}
SDKPATH = /usr/local/${SDK_NAME}
-SDKPATHNATIVE = ${SDKPATH}/sysroots/${SDK_SYS}
+SDKPATHNATIVE = /usr/local/${SDK_NATIVE_NAME}/sysroots/${SDK_SYS}
##
# Kernel info.
diff --git a/meta/recipes-qt/meta/meta-toolchain-qte.bb b/meta/recipes-qt/meta/meta-toolchain-qte.bb
index 735ccd1..a0d13bd 100644
--- a/meta/recipes-qt/meta/meta-toolchain-qte.bb
+++ b/meta/recipes-qt/meta/meta-toolchain-qte.bb
@@ -30,5 +30,5 @@ toolchain_create_sdk_env_script_append() {
# make a symbolic link to mkspecs for compatibility with Nokia's SDK
# and QTCreator
-(cd ${SDK_OUTPUT}/${QT_TOOLS_PREFIX}/..; ln -s ${SDKTARGETSYSROOT}/usr/share/qtopia/mkspecs mkspecs;)
+(cd ${SDK_NATIVE_OUTPUT}/${QT_TOOLS_PREFIX}/..; ln -s ${SDKTARGETSYSROOT}/usr/share/qtopia/mkspecs mkspecs;)
}
--
1.7.7.3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/5] kernel.bbclass: move uImage handling to separate task
On 12/19/2011 12:13 AM, Koen Kooi wrote: Op 18 dec. 2011, om 20:47 heeft Dmitry Eremin-Solenikov het volgende geschreven: As per org.oe.dev and meta-oe's kernel.bbclass move uImage creation to separate task from do_deploy. This way the do_install task can also benefit from generated uImage. The only major feature of oe-core's version (not to recreate uImage if it exists) is retained in this patch. I still don't agree with that behaviour. The in-kernel uImage code is just like the in-kernel defconfigs: useless for people who aren't kernel developers. Koen, that was addressed with KERNEL_RECREATE_UIMAGE variable. Probably I should document it somewhere (in the commit message? documentation.conf? smwh. else?). Would you agree with this patch + docs? On the contra, as this version was merged from meta-oe/org.oe.dev, new function has another feature: it permits overriding the u-boot entrypoint via u-boot symbol. No it doesn't, since it doesn't recreate uImage. It does. BTW: I don't have much experience of uImage usage on ARM SoCs (I used them only on Atmel boards, where things usually 'just worked' regarding Kernel load address Ko). On PowerPC I also didn't have too much problems with upstream kernels (both from Linus'es tree and from Freescale's one). I understand your concern, that for your tasks, you have to recreate uImage using your sane values. However for some people sane values are ones present in upstream tree. Moreover, if you care about history, it was specially changed in oe-core not to recreate uImage, as it caused problems for some of the users. -- With best wishes Dmitry ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/5] kernel.bbclass: move uImage handling to separate task
On 12/19/2011 04:54 PM, Koen Kooi wrote: Op 19 dec. 2011, om 13:47 heeft Dmitry Eremin-Solenikov het volgende geschreven: On 12/19/2011 12:13 AM, Koen Kooi wrote: Op 18 dec. 2011, om 20:47 heeft Dmitry Eremin-Solenikov het volgende geschreven: As per org.oe.dev and meta-oe's kernel.bbclass move uImage creation to separate task from do_deploy. This way the do_install task can also benefit from generated uImage. The only major feature of oe-core's version (not to recreate uImage if it exists) is retained in this patch. I still don't agree with that behaviour. The in-kernel uImage code is just like the in-kernel defconfigs: useless for people who aren't kernel developers. Koen, that was addressed with KERNEL_RECREATE_UIMAGE variable. Probably I should document it somewhere (in the commit message? documentation.conf? smwh. else?). Would you agree with this patch + docs? No. If the machine.conf sets the UBOOT_* variables I should not need some magic unbreak-me variable to get kernel.bbclass to use them. I see your point. I'll redo it so. -- With best wishes Dmitry ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/5] libatomics-ops: move docs to correct directory
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
.../pulseaudio/libatomics-ops_1.2.bb |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-multimedia/pulseaudio/libatomics-ops_1.2.bb
b/meta/recipes-multimedia/pulseaudio/libatomics-ops_1.2.bb
index 184c167..d0162e6 100644
--- a/meta/recipes-multimedia/pulseaudio/libatomics-ops_1.2.bb
+++ b/meta/recipes-multimedia/pulseaudio/libatomics-ops_1.2.bb
@@ -6,7 +6,7 @@ LICENSE = GPLv2 MIT
LIC_FILES_CHKSUM = file://doc/COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
file://doc/LICENSING.txt;md5=607073e04548eac7d1f763e480477bab \
-PR = r8
+PR = r9
SRC_URI =
http://www.hpl.hp.com/research/linux/atomic_ops/download/libatomic_ops-${PV}.tar.gz
\
file://fedora/libatomic_ops-1.2-ppclwzfix.patch \
@@ -26,5 +26,7 @@ ARM_INSTRUCTION_SET = arm
inherit autotools pkgconfig
do_install_append() {
- mv ${D}${datadir}/libatomic_ops ${D}${datadir}/libatomic-ops || true
+ # those contain only docs, not necessary for now.
+ install -m 0755 -d ${D}${docdir}
+ mv ${D}${datadir}/libatomic_ops ${D}${docdir}/${PN}
}
--
1.7.7.3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/5] Move check that all installed files are shipped into insane.bbclass
Checking that all installed files are shipped is in reality a QA check.
It would benefit from mechanisms like ERROR_QA/WARNING_QA. So move it
into insane.bbclass. If some of the files are installed but should not
be shipped for some reasons, one can add them to the variable
IGNORE_UNSHIPPED_FILES.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
meta/classes/insane.bbclass | 50 -
meta/classes/package.bbclass | 15
2 files changed, 48 insertions(+), 17 deletions(-)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 5726e69..41b815c 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -100,7 +100,7 @@ def package_qa_get_machine_dict():
# Currently not being used by default desktop
-WARN_QA ?= ldflags useless-rpaths rpaths
+WARN_QA ?= ldflags useless-rpaths rpaths unshipped
ERROR_QA ?= dev-so debug-deps dev-deps debug-files arch la2 pkgconfig la
perms
def package_qa_clean_path(path,d):
@@ -485,6 +485,49 @@ def package_qa_check_rdepends(pkg, pkgdest, skip, d):
return sane
+IGNORE_UNSHIPPED_FILES ??=
+
+def packages_qa_unshipped_files(d):
+warn = (d.getVar('WARN_QA', True) or ).split()
+err = (d.getVar('ERROR_QA', True) or ).split()
+if not unshipped in warn + err:
+return True
+
+seen = d.getVar('IGNORE_UNSHIPPED_FILES', True).split()
+unshipped = []
+dvar = d.getVar('PKGD', True)
+destvar = d.getVar('PKGDEST', True)
+packages = d.getVar('PACKAGES', True).split()
+for p in packages:
+pdir = os.path.join(destvar, p)
+for root, dirs, files in os.walk(pdir):
+dir = root[len(pdir):]
+if not dir:
+dir = os.sep
+for f in (files + dirs):
+path = os.path.join(dir, f)
+if path not in seen:
+seen.append(path)
+
+for root, dirs, files in os.walk(dvar):
+dir = root[len(dvar):]
+if not dir:
+dir = os.sep
+for f in (files + dirs):
+path = os.path.join(dir, f)
+if path not in seen:
+unshipped.append(path)
+
+pn = d.getVar('PN', True)
+
+if unshipped == []:
+return True
+
+ret = package_qa_handle_error(unshipped, For recipe %s, the following
files/directories were installed but not shipped in any package: % pn, d)
+for f in unshipped:
+package_qa_handle_error(unshipped, f, d)
+return ret
+
# The PACKAGE FUNC to scan each package
python do_package_qa () {
bb.note(DO PACKAGE QA)
@@ -522,6 +565,7 @@ python do_package_qa () {
g = globals()
walk_sane = True
rdepends_sane = True
+shipped_sane = True
for package in packages.split():
skip = (d.getVar('INSANE_SKIP_' + package, True) or ).split()
if skip:
@@ -546,8 +590,10 @@ python do_package_qa () {
if not package_qa_check_rdepends(package, pkgdest, skip, d):
rdepends_sane = False
+if not packages_qa_unshipped_files(d):
+shipped_sane = False
-if not walk_sane or not rdepends_sane:
+if not walk_sane or not rdepends_sane or not shipped_sane:
bb.fatal(QA run found fatal errors. Please consider fixing them.)
bb.note(DONE with PACKAGE QA)
}
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 39c1d4b..fbea9c6 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -957,21 +957,6 @@ python populate_packages () {
del localdata
os.chdir(workdir)
- unshipped = []
- for root, dirs, files in os.walk(dvar):
- dir = root[len(dvar):]
- if not dir:
- dir = os.sep
- for f in (files + dirs):
- path = os.path.join(dir, f)
- if ('.' + path) not in seen:
- unshipped.append(path)
-
- if unshipped != []:
- bb.warn(For recipe %s, the following files/directories were
installed but not shipped in any package: % pn)
- for f in unshipped:
- bb.warn( + f)
-
bb.build.exec_func(package_name_hook, d)
for pkg in package_list:
--
1.7.7.3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/5] ncurses: drop compatibility symlink to remove QA warning
ncurses doesn't use ${libdir}/terminfo. It is a backwards-compatibility
symlink to ${datadir}/terminfo. It is not installed by ncurses recipe.
Drop it to drop QA warning.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
meta/recipes-core/ncurses/ncurses.inc |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-core/ncurses/ncurses.inc
b/meta/recipes-core/ncurses/ncurses.inc
index 98f45a4..1449f34 100644
--- a/meta/recipes-core/ncurses/ncurses.inc
+++ b/meta/recipes-core/ncurses/ncurses.inc
@@ -171,6 +171,8 @@ do_install() {
echo 'INPUT(AS_NEEDED(-ltinfo))' $f
oe_multilib_header curses.h
+
+ rm ${D}${libdir}/terminfo
}
python populate_packages_prepend () {
--
1.7.7.3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/5] icecc.bbclass: also use icecc for kernel modules compilation
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
meta/classes/icecc.bbclass |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/meta/classes/icecc.bbclass b/meta/classes/icecc.bbclass
index 7e3676a..a14e02d 100644
--- a/meta/classes/icecc.bbclass
+++ b/meta/classes/icecc.bbclass
@@ -211,6 +211,10 @@ do_compile_prepend() {
set_icecc_env
}
+do_compile_kernelmodules_prepend() {
+set_icecc_env
+}
+
#do_install_prepend() {
#set_icecc_env
#}
--
1.7.7.3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/5] kernel.bbclass: move uImage handling to separate task
As per org.oe.dev and meta-oe's kernel.bbclass move uImage creation to
separate task from do_deploy. This way the do_install task can also
benefit from generated uImage.
The only major feature of oe-core's version (not to recreate uImage
if it exists) is retained in this patch. On the contra, as this version
was merged from meta-oe/org.oe.dev, new function has another feature:
it permits overriding the u-boot entrypoint via u-boot symbol.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
meta/classes/kernel.bbclass | 43 +++
1 files changed, 27 insertions(+), 16 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 3f2f75a..8832a77 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -489,6 +489,33 @@ do_sizecheck() {
addtask sizecheck before do_install after do_compile
+# Define to 1 to force kernel.bbclass to recreate uImage for you
+KERNEL_RECREATE_UIMAGE ?= 0
+
+do_uboot_mkimage() {
+test x${KERNEL_IMAGETYPE} = xuImage || return 0
+test x${KERNEL_RECREATE_UIMAGE} = x1 -o ! -e arch/${ARCH}/boot/uImage
|| return 0
+
+ENTRYPOINT=${UBOOT_ENTRYPOINT}
+if test -n ${UBOOT_ENTRYSYMBOL}; then
+ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \
+ awk '$3==${UBOOT_ENTRYSYMBOL} {print $1}'`
+fi
+if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
+${OBJCOPY} -O binary -R .note -R .comment -S
arch/${ARCH}/boot/compressed/vmlinux linux.bin
+uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C none -a
${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n ${DISTRO_NAME}/${PV}/${MACHINE} -d
linux.bin arch/${ARCH}/boot/uImage
+rm -f linux.bin
+else
+${OBJCOPY} -O binary -R .note -R .comment -S vmlinux linux.bin
+rm -f linux.bin.gz
+gzip -9 linux.bin
+uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C gzip -a
${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n ${DISTRO_NAME}/${PV}/${MACHINE} -d
linux.bin.gz arch/${ARCH}/boot/uImage
+rm -f linux.bin.gz
+fi
+}
+
+addtask uboot_mkimage before do_install after do_compile
+
KERNEL_IMAGE_BASE_NAME ?=
${KERNEL_IMAGETYPE}-${PV}-${PR}-${MACHINE}-${DATETIME}
# Don't include the DATETIME variable in the sstate package signatures
KERNEL_IMAGE_BASE_NAME[vardepsexclude] = DATETIME
@@ -500,22 +527,6 @@ kernel_do_deploy() {
tar -cvzf
${DEPLOYDIR}/modules-${KERNEL_VERSION}-${PR}-${MACHINE}.tgz -C ${D} lib
fi
- if test x${KERNEL_IMAGETYPE} = xuImage ; then
- if test -e arch/${ARCH}/boot/uImage ; then
- cp arch/${ARCH}/boot/uImage
${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
- elif test -e arch/${ARCH}/boot/compressed/vmlinux ; then
- ${OBJCOPY} -O binary -R .note -R .comment -S
arch/${ARCH}/boot/compressed/vmlinux linux.bin
- uboot-mkimage -A ${ARCH} -O linux -T kernel -C none -a
${UBOOT_ENTRYPOINT} -e ${UBOOT_ENTRYPOINT} -n ${DISTRO_NAME}/${PV}/${MACHINE}
-d linux.bin ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
- rm -f linux.bin
- else
- ${OBJCOPY} -O binary -R .note -R .comment -S vmlinux
linux.bin
- rm -f linux.bin.gz
- gzip -9 linux.bin
- uboot-mkimage -A ${ARCH} -O linux -T kernel -C gzip -a
${UBOOT_ENTRYPOINT} -e ${UBOOT_ENTRYPOINT} -n ${DISTRO_NAME}/${PV}/${MACHINE}
-d linux.bin.gz ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
- rm -f linux.bin.gz
- fi
- fi
-
cd ${DEPLOYDIR}
rm -f ${KERNEL_IMAGE_SYMLINK_NAME}.bin
ln -sf ${KERNEL_IMAGE_BASE_NAME}.bin ${KERNEL_IMAGE_SYMLINK_NAME}.bin
--
1.7.7.3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/9] consolekit: fix sdk generation issues
Koen, On 12/15/2011 07:06 PM, Koen Kooi wrote: Op 15 dec. 2011, om 15:58 heeft Richard Purdie het volgende geschreven: On Tue, 2011-12-13 at 20:19 +0400, Dmitry Eremin-Solenikov wrote: Currently sdk generation might fail with the following error: | Collected errors: | * extract_archive: Cannot create symlink from ./var/log to 'volatile/log': File exists. ERROR: Function 'do_populate_sdk' failed This happens as consolekit package will include both /var/log/ConsoleKit and /var/volatile/log/ConsoleKit files: lumag@fangorn:~/OE-scripts$ dpkg-deb -c build/tmp--eglibc/deploy/ipk/core2/consolekit_0.4.5-r7_core2.ipk | grep var drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/ drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/log/ drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/log/ConsoleKit/ lrwxrwxrwx root/root 0 2011-12-07 22:12 ./var/run - volatile/run drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/volatile/ drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/volatile/log/ drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/volatile/log/ConsoleKit/ drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/volatile/run/ drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/volatile/run/ConsoleKit/ Inclusion of both log directories causes this error. Drop the /var/log/ConsoleKit in favour of /var/volatile/log Signed-off-by: Dmitry Eremin-Solenikovdbarysh...@gmail.com This effectively reverts: http://git.openembedded.org/openembedded-core/commit/?id=5608a748af2c754f60137ab7c3010ccce6bf9e40 so I think this fixes one problem at the expense of causing another. Koen: Any comments? If you revert it consolekit won't work at runtime because it fails to start. In your usecase, do you have a /var/volatile? /var/volatile/log/ConsoleKit? Could you please be more specific in the layout of your /var and in the error/trace of consolekit on your side? I'd really like to solve this somehow as for now I have a broken SDK generation (at it seems it's not my fault as other people on ML suggested that they experienced errors with meta-toolchain-gmae). -- With best wishes Dmitry ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/9] consolekit: fix sdk generation issues
On 12/15/2011 08:20 PM, Cui, Dexuan wrote:
Richard Purdie wrote on 2011-12-15:
On Tue, 2011-12-13 at 20:19 +0400, Dmitry Eremin-Solenikov wrote:
Currently sdk generation might fail with the following error:
| Collected errors:
| * extract_archive: Cannot create symlink from ./var/log to
'volatile/log': File exists.
ERROR: Function 'do_populate_sdk' failed
This happens as consolekit package will include both
/var/log/ConsoleKit and /var/volatile/log/ConsoleKit files:
lumag@fangorn:~/OE-scripts$ dpkg-deb -c
build/tmp--eglibc/deploy/ipk/core2/consolekit_0.4.5-r7_core2.ipk |
grep var
drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/ drwxr-xr-x
root/root 0 2011-12-07 22:12 ./var/log/ drwxr-xr-x root/root
0 2011-12-07 22:12 ./var/log/ConsoleKit/ lrwxrwxrwx root/root
0 2011-12-07 22:12 ./var/run - volatile/run drwxr-xr-x root/root
0 2011-12-07 22:12 ./var/volatile/ drwxr-xr-x root/root 0
2011-12-07 22:12 ./var/volatile/log/ drwxr-xr-x root/root 0
2011-12-07 22:12 ./var/volatile/log/ConsoleKit/ drwxr-xr-x root/root
0 2011-12-07 22:12 ./var/volatile/run/ drwxr-xr-x root/root
0 2011-12-07 22:12 ./var/volatile/run/ConsoleKit/
Inclusion of both log directories causes this error. Drop the
/var/log/ConsoleKit in favour of /var/volatile/log
Hi Dmitry,
Could you please explain how and where the extract_archive error is caused?
Where is /var/log linked to /var/volatile/log?
I have tried building meta-toolchain-qte... and I got exactly the error
from my original message.
Do you mean RP's patch consolekit: Fix ${localstatedir} race didn't fix the
issue?
(I suspect so)
Yes, I still had the issues even after PR's patch.
This effectively reverts:
http://git.openembedded.org/openembedded-core/commit/?id=5608a748
af2c754f60137ab7c3010ccce6bf9e40 so I think this fixes one problem at
the expense of causing another. Koen: Any comments?
Thanks,
-- Dexuan
--
With best wishes
Dmitry
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/9] consolekit: fix sdk generation issues
On 12/16/2011 07:25 PM, Richard Purdie wrote:
On Fri, 2011-12-16 at 16:42 +0400, Dmitry Eremin-Solenikov wrote:
On 12/15/2011 08:20 PM, Cui, Dexuan wrote:
Richard Purdie wrote on 2011-12-15:
On Tue, 2011-12-13 at 20:19 +0400, Dmitry Eremin-Solenikov wrote:
Currently sdk generation might fail with the following error:
| Collected errors:
| * extract_archive: Cannot create symlink from ./var/log to
'volatile/log': File exists.
ERROR: Function 'do_populate_sdk' failed
This happens as consolekit package will include both
/var/log/ConsoleKit and /var/volatile/log/ConsoleKit files:
lumag@fangorn:~/OE-scripts$ dpkg-deb -c
build/tmp--eglibc/deploy/ipk/core2/consolekit_0.4.5-r7_core2.ipk |
grep var
drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/ drwxr-xr-x
root/root 0 2011-12-07 22:12 ./var/log/ drwxr-xr-x root/root
0 2011-12-07 22:12 ./var/log/ConsoleKit/ lrwxrwxrwx root/root
0 2011-12-07 22:12 ./var/run - volatile/run drwxr-xr-x root/root
0 2011-12-07 22:12 ./var/volatile/ drwxr-xr-x root/root 0
2011-12-07 22:12 ./var/volatile/log/ drwxr-xr-x root/root 0
2011-12-07 22:12 ./var/volatile/log/ConsoleKit/ drwxr-xr-x root/root
0 2011-12-07 22:12 ./var/volatile/run/ drwxr-xr-x root/root
0 2011-12-07 22:12 ./var/volatile/run/ConsoleKit/
Inclusion of both log directories causes this error. Drop the
/var/log/ConsoleKit in favour of /var/volatile/log
Hi Dmitry,
Could you please explain how and where the extract_archive error is caused?
Where is /var/log linked to /var/volatile/log?
I have tried building meta-toolchain-qte... and I got exactly the error
from my original message.
Do you mean RP's patch consolekit: Fix ${localstatedir} race didn't fix the
issue?
(I suspect so)
Yes, I still had the issues even after PR's patch.
This effectively reverts:
http://git.openembedded.org/openembedded-core/commit/?id=5608a748
af2c754f60137ab7c3010ccce6bf9e40 so I think this fixes one problem at
the expense of causing another. Koen: Any comments?
Thanks,
-- Dexuan
I believe this is an installation ordering problem in opkg. If you apply
my opkg patch (and the nativesdk one I just posted), I don't see this
problem with meta-toolchain-gmae.
I still see one problem. Without my patch I have both
/var/volatile/log/ConsoleKit and /var/log/ConsoleKit in consolekit
package. Won't that cause troubles?
--
With best wishes
Dmitry
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/9] consolekit: fix sdk generation issues
On 12/16/2011 08:46 PM, Richard Purdie wrote:
On Fri, 2011-12-16 at 20:07 +0400, Dmitry Eremin-Solenikov wrote:
On 12/16/2011 07:25 PM, Richard Purdie wrote:
On Fri, 2011-12-16 at 16:42 +0400, Dmitry Eremin-Solenikov wrote:
On 12/15/2011 08:20 PM, Cui, Dexuan wrote:
Richard Purdie wrote on 2011-12-15:
On Tue, 2011-12-13 at 20:19 +0400, Dmitry Eremin-Solenikov wrote:
Currently sdk generation might fail with the following error:
| Collected errors:
| * extract_archive: Cannot create symlink from ./var/log to
'volatile/log': File exists.
ERROR: Function 'do_populate_sdk' failed
This happens as consolekit package will include both
/var/log/ConsoleKit and /var/volatile/log/ConsoleKit files:
lumag@fangorn:~/OE-scripts$ dpkg-deb -c
build/tmp--eglibc/deploy/ipk/core2/consolekit_0.4.5-r7_core2.ipk |
grep var
drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/ drwxr-xr-x
root/root 0 2011-12-07 22:12 ./var/log/ drwxr-xr-x root/root
0 2011-12-07 22:12 ./var/log/ConsoleKit/ lrwxrwxrwx root/root
0 2011-12-07 22:12 ./var/run -volatile/run drwxr-xr-x root/root
0 2011-12-07 22:12 ./var/volatile/ drwxr-xr-x root/root 0
2011-12-07 22:12 ./var/volatile/log/ drwxr-xr-x root/root 0
2011-12-07 22:12 ./var/volatile/log/ConsoleKit/ drwxr-xr-x root/root
0 2011-12-07 22:12 ./var/volatile/run/ drwxr-xr-x root/root
0 2011-12-07 22:12 ./var/volatile/run/ConsoleKit/
Inclusion of both log directories causes this error. Drop the
/var/log/ConsoleKit in favour of /var/volatile/log
Hi Dmitry,
Could you please explain how and where the extract_archive error is caused?
Where is /var/log linked to /var/volatile/log?
I have tried building meta-toolchain-qte... and I got exactly the error
from my original message.
Do you mean RP's patch consolekit: Fix ${localstatedir} race didn't fix the
issue?
(I suspect so)
Yes, I still had the issues even after PR's patch.
This effectively reverts:
http://git.openembedded.org/openembedded-core/commit/?id=5608a748
af2c754f60137ab7c3010ccce6bf9e40 so I think this fixes one problem at
the expense of causing another. Koen: Any comments?
Thanks,
-- Dexuan
I believe this is an installation ordering problem in opkg. If you apply
my opkg patch (and the nativesdk one I just posted), I don't see this
problem with meta-toolchain-gmae.
I still see one problem. Without my patch I have both
/var/volatile/log/ConsoleKit and /var/log/ConsoleKit in consolekit
package. Won't that cause troubles?
No, that wasn't the problem opkg was reporting. The problem opkg was
reporting was that base-files hadn't installed first and its responsible
for setting up the var symlinks.
That is not the problem that was reported by opkg. That is what I saw in
the built package - /var/volatile/log/ConsoleKit and /var/log/ConsoleKit.
BTW, Koen. I've just built a consolekit package in Angstrom environment
with my patch applied and here is the interesting part:
lumag@fangorn:~/OE-scripts$ dpkg-deb -c
build/tmp-angstrom-eglibc/deploy/ipk/armv5te/consolekit_0.4.5-r8_armv5te.ipk
| grep var
drwxr-xr-x root/root 0 2011-12-16 21:32 ./var/
drwxr-xr-x root/root 0 2011-12-16 21:32 ./var/run/
drwxr-xr-x root/root 0 2011-12-16 21:32 ./var/run/ConsoleKit/
drwxr-xr-x root/root 0 2011-12-16 21:32 ./var/log/
drwxr-xr-x root/root 0 2011-12-16 21:32 ./var/log/ConsoleKit/
So the package does include the /var/log/ConsoleKit even without
explicit note on it. Could you please recheck your environment and try
building/checking consolekit package with my patch applied?
--
With best wishes
Dmitry
___
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] kernel.bbclass: move uImage handling to separate task
On 12/15/2011 01:20 AM, Koen Kooi wrote:
Op 13 dec. 2011, om 16:19 heeft Dmitry Eremin-Solenikov het volgende geschreven:
As per org.oe.dev and meta-oe's kernel.bbclass move uImage creation to
separate task from do_deploy. This way the do_install task can also
benefit from generated uImage.
The only major feature of oe-core's version (not to recreate uImage
if it exists) is retained in this patch
The whole point of the OE uImage handling is that in general we know better
than the kernel and can apply fixups if needed (turning on/off compression, etc)
Please check the history of OE-core uImage handling. Initially uImage
was always recreated (as it's currently done in meta-oe). Then
(422a017e6 on Oct 29, 2010) OE-core kernel.bbclass was changed to
default to not to recreate uImage if it was created by kbuild (IIRC it
was done so, because recreated uImages weren't always booting as they
required more setup). I don't know which way is correct. Maybe we should
add a hook that will tell if kernel.bbclass should prefer to recreate
uImage or to use kernel one. Would you like such variable?
Another point (that I probably failed to emphasize): currently
do_install and do_deploy will use different uImages. The image in /boot
on rootfs might be different from uImage really in deploy dir. I would
assume that this is not the expected way to do things.
. On the contra, as this version
was merged from meta-oe/org.oe.dev, new function has another feature:
it permits overriding the u-boot entrypoint via u-boot symbol.
Not if uimage exists, see above
Of course.
Signed-off-by: Dmitry Eremin-Solenikovdbarysh...@gmail.com
---
meta/classes/kernel.bbclass | 40
1 files changed, 24 insertions(+), 16 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index a75c199..db00d2d 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -485,6 +485,30 @@ do_sizecheck() {
addtask sizecheck before do_install after do_compile
+do_uboot_mkimage() {
+if test x${KERNEL_IMAGETYPE} = xuImage -a \
+! -e arch/${ARCH}/boot/uImage ; then
+ENTRYPOINT=${UBOOT_ENTRYPOINT}
+if test -n ${UBOOT_ENTRYSYMBOL}; then
+ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \
+ awk '$3==${UBOOT_ENTRYSYMBOL} {print $1}'`
+fi
+if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
+${OBJCOPY} -O binary -R .note -R .comment -S
arch/${ARCH}/boot/compressed/vmlinux linux.bin
+uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C none -a
${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n ${DISTRO_NAME}/${PV}/${MACHINE} -d
linux.bin arch/${ARCH}/boot/uImage
+rm -f linux.bin
+else
+${OBJCOPY} -O binary -R .note -R .comment -S vmlinux linux.bin
+rm -f linux.bin.gz
+gzip -9 linux.bin
+uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C gzip -a
${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n ${DISTRO_NAME}/${PV}/${MACHINE} -d
linux.bin.gz arch/${ARCH}/boot/uImage
+rm -f linux.bin.gz
+fi
+fi
+}
+
+addtask uboot_mkimage before do_install after do_compile
+
KERNEL_IMAGE_BASE_NAME ?=
${KERNEL_IMAGETYPE}-${PV}-${PR}-${MACHINE}-${DATETIME}
# Don't include the DATETIME variable in the sstate package signatures
KERNEL_IMAGE_BASE_NAME[vardepsexclude] = DATETIME
@@ -496,22 +520,6 @@ kernel_do_deploy() {
tar -cvzf
${DEPLOYDIR}/modules-${KERNEL_VERSION}-${PR}-${MACHINE}.tgz -C ${D} lib
fi
- if test x${KERNEL_IMAGETYPE} = xuImage ; then
- if test -e arch/${ARCH}/boot/uImage ; then
- cp arch/${ARCH}/boot/uImage
${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
- elif test -e arch/${ARCH}/boot/compressed/vmlinux ; then
- ${OBJCOPY} -O binary -R .note -R .comment -S
arch/${ARCH}/boot/compressed/vmlinux linux.bin
- uboot-mkimage -A ${ARCH} -O linux -T kernel -C none -a
${UBOOT_ENTRYPOINT} -e ${UBOOT_ENTRYPOINT} -n ${DISTRO_NAME}/${PV}/${MACHINE}
-d linux.bin ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
- rm -f linux.bin
- else
- ${OBJCOPY} -O binary -R .note -R .comment -S vmlinux
linux.bin
- rm -f linux.bin.gz
- gzip -9 linux.bin
- uboot-mkimage -A ${ARCH} -O linux -T kernel -C gzip -a
${UBOOT_ENTRYPOINT} -e ${UBOOT_ENTRYPOINT} -n ${DISTRO_NAME}/${PV}/${MACHINE}
-d linux.bin.gz ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
- rm -f linux.bin.gz
- fi
- fi
-
cd ${DEPLOYDIR}
rm -f ${KERNEL_IMAGE_SYMLINK_NAME}.bin
ln -sf ${KERNEL_IMAGE_BASE_NAME}.bin ${KERNEL_IMAGE_SYMLINK_NAME}.bin
--
1.7.7.3
___
Openembedded-core mailing list
Openembedded-core
[OE-core] [PATCH 1/9] kernel.bbclass: compile kernel and modules in a single task
There is no point in compiling kernel modules in a separate task, run
right after do_compile. On the other hand merging those tasks will e.g.
make icecc used also for modules compilation, etc.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
meta/classes/kernel.bbclass |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 3f2f75a..a75c199 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -89,17 +89,13 @@ kernel_do_compile() {
if test ${KERNEL_IMAGETYPE_FOR_MAKE}.gz = ${KERNEL_IMAGETYPE}; then
gzip -9c ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_OUTPUT}
fi
-}
-do_compile_kernelmodules() {
- unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
- oe_runmake ${PARALLEL_MAKE} modules CC=${KERNEL_CC}
LD=${KERNEL_LD}
+ oe_runmake modules CC=${KERNEL_CC} LD=${KERNEL_LD}
else
bbnote no modules to compile
fi
}
-addtask compile_kernelmodules after do_compile before do_install
kernel_do_install() {
#
--
1.7.7.3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/9] consolekit: fix sdk generation issues
Currently sdk generation might fail with the following error:
| Collected errors:
| * extract_archive: Cannot create symlink from ./var/log to
'volatile/log': File exists.
ERROR: Function 'do_populate_sdk' failed
This happens as consolekit package will include both /var/log/ConsoleKit
and /var/volatile/log/ConsoleKit files:
lumag@fangorn:~/OE-scripts$ dpkg-deb -c
build/tmp--eglibc/deploy/ipk/core2/consolekit_0.4.5-r7_core2.ipk | grep var
drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/
drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/log/
drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/log/ConsoleKit/
lrwxrwxrwx root/root 0 2011-12-07 22:12 ./var/run - volatile/run
drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/volatile/
drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/volatile/log/
drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/volatile/log/ConsoleKit/
drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/volatile/run/
drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/volatile/run/ConsoleKit/
Inclusion of both log directories causes this error. Drop the
/var/log/ConsoleKit
in favour of /var/volatile/log
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
.../recipes-support/consolekit/consolekit_0.4.5.bb |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-support/consolekit/consolekit_0.4.5.bb
b/meta/recipes-support/consolekit/consolekit_0.4.5.bb
index 45f6ad3..9406d88 100644
--- a/meta/recipes-support/consolekit/consolekit_0.4.5.bb
+++ b/meta/recipes-support/consolekit/consolekit_0.4.5.bb
@@ -2,7 +2,7 @@ DESCRIPTION = ConsoleKit is a framework for defining and
tracking users, login
HOMEPAGE=http://www.freedesktop.org/wiki/Software/ConsoleKit;
BUGTRACKER=https://bugs.freedesktop.org/buglist.cgi?query_format=specificproduct=ConsoleKit;
-PR = r7
+PR = r8
LICENSE = GPLv2+
LIC_FILES_CHKSUM = file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \
@@ -24,7 +24,7 @@ EXTRA_OECONF =
--with-systemdsystemunitdir=${base_libdir}/systemd/system/ \
${@base_contains('DISTRO_FEATURES', 'pam',
'--enable-pam-module --with-pam-module-dir=${base_libdir}/security',
'--disable-pam-module', d)} \
-FILES_${PN} += ${localstatedir}/log/ConsoleKit ${libdir}/ConsoleKit
${base_libdir} ${datadir}/dbus-1 ${datadir}/PolicyKit ${datadir}/polkit*
+FILES_${PN} += ${libdir}/ConsoleKit ${base_libdir} ${datadir}/dbus-1
${datadir}/PolicyKit ${datadir}/polkit*
FILES_${PN}-dbg += ${base_libdir}/security/.debug
PACKAGES =+ pam-plugin-ck-connector
--
1.7.7.3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 6/9] libgcc: reintroduce debug package, containing symbols
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
meta/recipes-devtools/gcc/libgcc_4.6.bb |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-devtools/gcc/libgcc_4.6.bb
b/meta/recipes-devtools/gcc/libgcc_4.6.bb
index 6ba0339..dd0a7be 100644
--- a/meta/recipes-devtools/gcc/libgcc_4.6.bb
+++ b/meta/recipes-devtools/gcc/libgcc_4.6.bb
@@ -6,6 +6,7 @@ DEPENDS = virtual/${TARGET_PREFIX}gcc
virtual/${TARGET_PREFIX}g++
PACKAGES = \
${PN} \
${PN}-dev \
+ ${PN}-dbg \
FILES_${PN} = ${base_libdir}/libgcc*.so.*
@@ -15,6 +16,8 @@ FILES_${PN}-dev = \
${libdir}/${TARGET_SYS}/${BINV}/libgcov.a \
${libdir}/${TARGET_SYS}/${BINV}/libgcc*
+FILES_${PN}-dbg += ${base_libdir}/.debug/
+
do_configure[noexec] = 1
do_compile[noexec] = 1
--
1.7.7.3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 9/9] libatomic-ops: drop directory with documentation to remove QA warning
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
.../pulseaudio/libatomics-ops_1.2.bb |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-multimedia/pulseaudio/libatomics-ops_1.2.bb
b/meta/recipes-multimedia/pulseaudio/libatomics-ops_1.2.bb
index 184c167..f81aeb6 100644
--- a/meta/recipes-multimedia/pulseaudio/libatomics-ops_1.2.bb
+++ b/meta/recipes-multimedia/pulseaudio/libatomics-ops_1.2.bb
@@ -26,5 +26,6 @@ ARM_INSTRUCTION_SET = arm
inherit autotools pkgconfig
do_install_append() {
- mv ${D}${datadir}/libatomic_ops ${D}${datadir}/libatomic-ops || true
+ # those contain only docs, not necessary for now.
+ rm -rf ${D}${datadir}/libatomic_ops || true
}
--
1.7.7.3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/9] Move check that all installed files are shipped into insane.bbclass
Checking that all installed files are shipped is in reality a QA check.
It would benefit from mechanisms like ERROR_QA/WARNING_QA. So move it
into insane.bbclass. If some of the files are installed but should not
be shipped for some reasons, one can add them to the variable
IGNORE_UNSHIPPED_FILES.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
meta/classes/insane.bbclass | 49 -
meta/classes/package.bbclass | 15
2 files changed, 47 insertions(+), 17 deletions(-)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 5726e69..7a8643a 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -100,7 +100,7 @@ def package_qa_get_machine_dict():
# Currently not being used by default desktop
-WARN_QA ?= ldflags useless-rpaths rpaths
+WARN_QA ?= ldflags useless-rpaths rpaths unshipped
ERROR_QA ?= dev-so debug-deps dev-deps debug-files arch la2 pkgconfig la
perms
def package_qa_clean_path(path,d):
@@ -485,6 +485,48 @@ def package_qa_check_rdepends(pkg, pkgdest, skip, d):
return sane
+IGNORE_UNSHIPPED_FILES ??=
+
+def packages_qa_unshipped_files(d):
+skip = (d.getVar('INSANE_SKIP_${PN}', True) or ).split()
+if unshipped in skip:
+return False
+
+seen = d.getVar('IGNORE_UNSHIPPED_FILES', True).split()
+unshipped = []
+dvar = d.getVar('PKGD', True)
+destvar = d.getVar('PKGDEST', True)
+packages = d.getVar('PACKAGES', True).split()
+for p in packages:
+pdir = os.path.join(destvar, p)
+for root, dirs, files in os.walk(pdir):
+dir = root[len(pdir):]
+if not dir:
+dir = os.sep
+for f in (files + dirs):
+path = os.path.join(dir, f)
+if path not in seen:
+seen.append(path)
+
+for root, dirs, files in os.walk(dvar):
+dir = root[len(dvar):]
+if not dir:
+dir = os.sep
+for f in (files + dirs):
+path = os.path.join(dir, f)
+if path not in seen:
+unshipped.append(path)
+
+pn = d.getVar('PN', True)
+
+if unshipped == []:
+return True
+
+ret = package_qa_handle_error(unshipped, For recipe %s, the following
files/directories were installed but not shipped in any package: % pn, d)
+for f in unshipped:
+package_qa_handle_error(unshipped, f, d)
+return ret
+
# The PACKAGE FUNC to scan each package
python do_package_qa () {
bb.note(DO PACKAGE QA)
@@ -522,6 +564,7 @@ python do_package_qa () {
g = globals()
walk_sane = True
rdepends_sane = True
+shipped_sane = True
for package in packages.split():
skip = (d.getVar('INSANE_SKIP_' + package, True) or ).split()
if skip:
@@ -546,8 +589,10 @@ python do_package_qa () {
if not package_qa_check_rdepends(package, pkgdest, skip, d):
rdepends_sane = False
+if not packages_qa_unshipped_files(d):
+shipped_sane = False
-if not walk_sane or not rdepends_sane:
+if not walk_sane or not rdepends_sane or not shipped_sane:
bb.fatal(QA run found fatal errors. Please consider fixing them.)
bb.note(DONE with PACKAGE QA)
}
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 39c1d4b..fbea9c6 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -957,21 +957,6 @@ python populate_packages () {
del localdata
os.chdir(workdir)
- unshipped = []
- for root, dirs, files in os.walk(dvar):
- dir = root[len(dvar):]
- if not dir:
- dir = os.sep
- for f in (files + dirs):
- path = os.path.join(dir, f)
- if ('.' + path) not in seen:
- unshipped.append(path)
-
- if unshipped != []:
- bb.warn(For recipe %s, the following files/directories were
installed but not shipped in any package: % pn)
- for f in unshipped:
- bb.warn( + f)
-
bb.build.exec_func(package_name_hook, d)
for pkg in package_list:
--
1.7.7.3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 8/9] readline: drop empty dir to shut up QA warning
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
meta/recipes-core/readline/readline.inc |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-core/readline/readline.inc
b/meta/recipes-core/readline/readline.inc
index 8fe7e8a..743d8b3 100644
--- a/meta/recipes-core/readline/readline.inc
+++ b/meta/recipes-core/readline/readline.inc
@@ -28,6 +28,8 @@ do_install_append () {
# Make install doesn't properly install these
oe_libinstall -so -C shlib libhistory ${D}${libdir}
oe_libinstall -so -C shlib libreadline ${D}${libdir}
+
+ rmdir ${D}${bindir}
}
BBCLASSEXTEND = native nativesdk
--
1.7.7.3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/9] kernel.bbclass: compile kernel and modules in a single task
On 12/13/2011 08:22 PM, Phil Blundell wrote:
On Tue, 2011-12-13 at 20:19 +0400, Dmitry Eremin-Solenikov wrote:
- oe_runmake ${PARALLEL_MAKE} modules CC=${KERNEL_CC}
LD=${KERNEL_LD}
+ oe_runmake modules CC=${KERNEL_CC} LD=${KERNEL_LD}
Why did you remove PARALLEL_MAKE?
Because PARALLEL_MAKE is already defined for do_compile() task
--
With best wishes
Dmitry
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 9/9] libatomic-ops: drop directory with documentation to remove QA warning
On 12/13/2011 11:48 PM, Richard Purdie wrote:
On Tue, 2011-12-13 at 20:19 +0400, Dmitry Eremin-Solenikov wrote:
Signed-off-by: Dmitry Eremin-Solenikovdbarysh...@gmail.com
---
.../pulseaudio/libatomics-ops_1.2.bb |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-multimedia/pulseaudio/libatomics-ops_1.2.bb
b/meta/recipes-multimedia/pulseaudio/libatomics-ops_1.2.bb
index 184c167..f81aeb6 100644
--- a/meta/recipes-multimedia/pulseaudio/libatomics-ops_1.2.bb
+++ b/meta/recipes-multimedia/pulseaudio/libatomics-ops_1.2.bb
@@ -26,5 +26,6 @@ ARM_INSTRUCTION_SET = arm
inherit autotools pkgconfig
do_install_append() {
- mv ${D}${datadir}/libatomic_ops ${D}${datadir}/libatomic-ops || true
+ # those contain only docs, not necessary for now.
+ rm -rf ${D}${datadir}/libatomic_ops || true
}
Shouldn't we move that to docdir/${PN}?
I'm thinking another way: why is the recipe called libatomicS-ops (note
the S) if the upstream source is named as libatomc_ops (so it should
become libatomic-ops). Then documentation will land in the proper place
after the mv command which is currently in place.
--
With best wishes
Dmitry
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/9] kernel.bbclass: compile kernel and modules in a single task
On Wed, Dec 14, 2011 at 4:15 AM, Darren Hart dvh...@linux.intel.com wrote:
On 12/13/2011 08:19 AM, Dmitry Eremin-Solenikov wrote:
There is no point in compiling kernel modules in a separate task, run
right after do_compile. On the other hand merging those tasks will e.g.
make icecc used also for modules compilation, etc.
This split was done intentionally to allow tasks to be inserted between
compile and compile_kernelmodules. See:
Could you (or Koen) name any tasks that have to be inserted between kernel
and modules compilation please?
commit 509364eb634cf148b6ac1fb5f51924f4eb6a8991
Author: Koen Kooi k...@dominion.thruhere.net
Date: Tue Mar 15 11:25:01 2011 +0100
kernel bbclass: split do_compile into do_compile and do_compile_modules
This allows recipes to insert a custom task in between building
*Image and modules
From OE .dev revision 615876fe218dc3feb4a3df9e6546a7b1a6376800
(From OE-Core rev: a2cc999d663407d17f41e1b0344361944993fa86)
Signed-off-by: Koen Kooi k...@openembedded.org
Acked-by: Graeme Gregory d...@xora.org.uk
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
If you want to be able to use icecc, can you pull the necessary logic
into compile_kernelmodules rather than reverting Koen's patch?
Thanks,
Darren
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
meta/classes/kernel.bbclass | 6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 3f2f75a..a75c199 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -89,17 +89,13 @@ kernel_do_compile() {
if test ${KERNEL_IMAGETYPE_FOR_MAKE}.gz = ${KERNEL_IMAGETYPE}; then
gzip -9c ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_OUTPUT}
fi
-}
-do_compile_kernelmodules() {
- unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
- oe_runmake ${PARALLEL_MAKE} modules CC=${KERNEL_CC}
LD=${KERNEL_LD}
+ oe_runmake modules CC=${KERNEL_CC} LD=${KERNEL_LD}
else
bbnote no modules to compile
fi
}
-addtask compile_kernelmodules after do_compile before do_install
kernel_do_install() {
#
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
--
With best wishes
Dmitry
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] meta-toolchain-gmae can't build: Cannot create symlink from ./var/log to 'volatile/log': File exists
On 12/05/2011 12:30 PM, Richard Purdie wrote:
On Mon, 2011-12-05 at 15:35 +0800, Cui, Dexuan wrote:
Hi, recently, I found meta-toolchain-gmae failed to build on poky master if I
use ipk packaging(I didn't try rpm/deb):
task do_populate_sdk: Failed
| Configuring avahi-dev.
| Configuring task-core-standalone-gmae-sdk-target.
| Configuring libtelepathy-dbg.
| Configuring task-core-standalone-gmae-sdk-target-dbg.
| Configuring util-linux-blkid.
| Collected errors:
| * extract_archive: Cannot create symlink from ./var/log to 'volatile/log':
File exists.
ERROR: Function 'do_populate_sdk' failed
Now I have no time to look into this issue at once. It would be great, if
somebody can give some quick hint.
Is this with the latest master?
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=f340e3937fd5ac3963de6c6b29d56dd92d962864
was added to avoid an error very like this that was showing up with
rpm...
I've stumped upon the very same problem with consolekit. Then I checked
the contents of the consolekit package:
lumag@fangorn:~/OE-scripts$ dpkg-deb -c
build/tmp--eglibc/deploy/ipk/core2/consolekit_0.4.5-r7_core2.ipk | grep var
drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/
drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/log/
drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/log/ConsoleKit/
lrwxrwxrwx root/root 0 2011-12-07 22:12 ./var/run - volatile/run
drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/volatile/
drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/volatile/log/
drwxr-xr-x root/root 0 2011-12-07 22:12
./var/volatile/log/ConsoleKit/
drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/volatile/run/
drwxr-xr-x root/root 0 2011-12-07 22:12
./var/volatile/run/ConsoleKit/
lumag@fangorn:~/OE-scripts$ ./oebb.sh bitbake -e consolekit | grep
FILES_consolekit=
# FILES_consolekit=${bindir}/* ${sbindir}/* ${libexecdir}/*
${libdir}/lib*${SOLIBS} ${sysconfdir} ${sharedstatedir} ${localstatedir}
${base_bindir}/* ${base_sbindir}/* ${base_libdir}/*${SOLIBS}
${datadir}/${BPN} ${libdir}/${BPN}/* ${datadir}/pixmaps
${datadir}/applications ${datadir}/idl ${datadir}/omf ${datadir}/sounds
${libdir}/bonobo/servers ${datadir}/application-registry
${datadir}/mime-info ${datadir}/mime/packages
${datadir}/mime/application ${datadir}/gnome-2.0 ${datadir}/polkit*
${datadir}/GConf ${datadir}/glib-2.0/schemas ${datadir}/icons/hicolor
${localstatedir}/log/ConsoleKit ${libdir}/ConsoleKit ${base_libdir}
${datadir}/dbus-1 ${datadir}/PolicyKit ${datadir}/polkit*
FILES_consolekit=/usr/bin/* /usr/sbin/* /usr/libexec/*
/usr/lib/lib*.so.* /etc /com /var /bin/* /sbin/* /lib/*.so.*
/usr/share/consolekit /usr/lib/consolekit/* /usr/share/pixmaps
/usr/share/applications /usr/share/idl /usr/share/omf /usr/share/sounds
/usr/lib/bonobo/servers /usr/share/application-registry
/usr/share/mime-info /usr/share/mime/packages
/usr/share/mime/application /usr/share/gnome-2.0 /usr/share/polkit*
/usr/share/GConf /usr/share/glib-2.0/schemas /usr/share/icons/hicolor
/var/log/ConsoleKit /usr/lib/ConsoleKit /lib /usr/share/dbus-1
/usr/share/PolicyKit /usr/share/polkit*
Not that this already includes /var, then /var/log/ConsoleKit is added.
I'm more or less sure that original inclusion of
${localstatedir}/log/ConsoleKit was en error.
Cheers,
Richard
--
With best wishes
Dmitry
___
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] core-image-minimal-initramfs: force IMAGE_FSTYPES
On 11/18/2011 05:55 PM, Paul Eggleton wrote: On Tuesday 15 November 2011 12:30:15 Dmitry Eremin-Solenikov wrote: This was merged as IMAGE_FSTYPES =+ cpio.gz Now this brings problems if I have IMAGE_FSTYPES += live in my local.conf / BSP machine.conf. 1) OE tries to generate hddimg for this initramfs image, which is strange idea 2) If OE is trying to generate bootimg (hddimg) when the kernel is not yet deployed, building fails (as bootimg can't find a deployed kernel to put into hddimg). Please revert this back to original patch as proposed by Paul. OK, so what are we going to do about this? Do we have to do some filtering of this variable? I'd propose to just set it via: IMAGE_FSTYPES = cpio.gz. It is really no point in generating other types of inititramfs images. Cheers, Paul -- With best wishes Dmitry ___ 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] core-image-minimal-initramfs: force IMAGE_FSTYPES
On 11/04/2011 10:18 PM, Koen Kooi wrote: Op 4 nov. 2011, om 18:52 heeft Paul Eggleton het volgende geschreven: If the user has set their own value for IMAGE_FSTYPES, they may have disabled the cpio.gz image type, preventing the initramfs from being produced in the format that image-live.bbclass expects; so force IMAGE_FSTYPES to cpio.gz within the initramfs image recipe. Signed-off-by: Paul Eggletonpaul.eggle...@linux.intel.com --- .../images/core-image-minimal-initramfs.bb |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/meta/recipes-core/images/core-image-minimal-initramfs.bb b/meta/recipes-core/images/core-image-minimal-initramfs.bb index 0bac27a..e4d0e51 100644 --- a/meta/recipes-core/images/core-image-minimal-initramfs.bb +++ b/meta/recipes-core/images/core-image-minimal-initramfs.bb @@ -13,3 +13,4 @@ LICENSE = MIT inherit core-image IMAGE_ROOTFS_SIZE = 8192 +IMAGE_FSTYPES = cpio.gz _append or += would give less suprises. This was merged as IMAGE_FSTYPES =+ cpio.gz Now this brings problems if I have IMAGE_FSTYPES += live in my local.conf / BSP machine.conf. 1) OE tries to generate hddimg for this initramfs image, which is strange idea 2) If OE is trying to generate bootimg (hddimg) when the kernel is not yet deployed, building fails (as bootimg can't find a deployed kernel to put into hddimg). Please revert this back to original patch as proposed by Paul. -- With best wishes Dmitry ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] gobject-introspection: update frome meta-oe
OE-Core uses very old version of gobject-introspection. The recipe says
0.10.8, but in reality it's GOBJECT_INTROSPECTION_0_6_3-41-gefa7266.
That version e.g. doesn't compile with python 2.7 (default in some
versions), etc.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
.../gnome/gobject-introspection/configure.patch| 27
.../gnome/gobject-introspection/pathfix.patch | 27
.../use-usr-bin-env-for-python.patch | 20
.../gnome/gobject-introspection_git.bb | 32 +++
4 files changed, 38 insertions(+), 68 deletions(-)
delete mode 100644
meta/recipes-gnome/gnome/gobject-introspection/configure.patch
delete mode 100644 meta/recipes-gnome/gnome/gobject-introspection/pathfix.patch
create mode 100644
meta/recipes-gnome/gnome/gobject-introspection/use-usr-bin-env-for-python.patch
diff --git a/meta/recipes-gnome/gnome/gobject-introspection/configure.patch
b/meta/recipes-gnome/gnome/gobject-introspection/configure.patch
deleted file mode 100644
index 5dcd9b0..000
--- a/meta/recipes-gnome/gnome/gobject-introspection/configure.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
-Index: git/common.mk
-===
git.orig/common.mk 2009-08-19 11:11:26.0 +0100
-+++ git/common.mk 2009-08-19 11:12:05.0 +0100
-@@ -4,7 +4,7 @@
- UNINSTALLED_INTROSPECTION_SRCDIR=$(top_srcdir) \
- UNINSTALLED_INTROSPECTION_BUILDDIR=$(top_builddir)
- SCANNER_ARGS = -v --add-include-path=$(top_builddir)/gir --add-include-path=.
--SCANNER = $(AM_V_GEN) env LPATH=.libs $(CHECK_DEBUG) $(SCANNER_ENV)
$(SCANNER_BIN) $(SCANNER_ARGS)
-+SCANNER = $(AM_V_GEN) env LPATH=.libs $(CHECK_DEBUG) $(SCANNER_ENV)
g-ir-scanner $(SCANNER_ARGS)
- SCANNER_LIBS = \
- $(top_srcdir)/giscanner/*.py \
- $(top_builddir)/giscanner/libgiscanner.la \
-Index: git/configure.ac
-===
git.orig/configure.ac 2009-08-19 11:11:26.0 +0100
-+++ git/configure.ac 2009-08-19 11:11:28.0 +0100
-@@ -201,7 +201,6 @@
- pyexecdir=`echo $pyexecdir | tr '' '/'`
- ;;
- esac
--AM_CHECK_PYTHON_HEADERS(,AC_MSG_ERROR([Python headers not found]))
-
- AC_CONFIG_FILES([
- Makefile
diff --git a/meta/recipes-gnome/gnome/gobject-introspection/pathfix.patch
b/meta/recipes-gnome/gnome/gobject-introspection/pathfix.patch
deleted file mode 100644
index a96e4b1..000
--- a/meta/recipes-gnome/gnome/gobject-introspection/pathfix.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-Upstream-Status: Pending
-
-Index: git/giscanner/dumper.py
-===
git.orig/giscanner/dumper.py 2010-11-29 15:14:35.0 -0800
-+++ git/giscanner/dumper.py2010-11-29 15:14:57.115747154 -0800
-@@ -82,7 +82,7 @@
- self._tmpdir = tempfile.mkdtemp('', 'tmp-introspect', dir=os.getcwd())
-
- self._compiler_cmd = os.environ.get('CC', 'gcc')
--self._linker_cmd = os.environ.get('LD', self._compiler_cmd)
-+self._linker_cmd = os.environ.get('CCLD', self._compiler_cmd)
- self._pkgconfig_cmd = os.environ.get('PKG_CONFIG', 'pkg-config')
-
- self._uninst_srcdir = os.environ.get(
-Index: git/giscanner/scannermain.py
-===
git.orig/giscanner/scannermain.py 2010-11-29 15:14:35.0 -0800
-+++ git/giscanner/scannermain.py 2010-11-29 15:14:57.120747321 -0800
-@@ -283,6 +283,7 @@
- shown_include_warning = False
- for include in options.includes:
- if os.sep in include:
-+continue
- raise ValueError(Invalid include path %r % (include, ))
- include_obj = Include.from_string(include)
- transformer.register_include(include_obj)
diff --git
a/meta/recipes-gnome/gnome/gobject-introspection/use-usr-bin-env-for-python.patch
b/meta/recipes-gnome/gnome/gobject-introspection/use-usr-bin-env-for-python.patch
new file mode 100644
index 000..67b8547
--- /dev/null
+++
b/meta/recipes-gnome/gnome/gobject-introspection/use-usr-bin-env-for-python.patch
@@ -0,0 +1,20 @@
+Index: gobject-introspection-0.9.10/tools/g-ir-annotation-tool.in
+===
+--- gobject-introspection-0.9.10.orig/tools/g-ir-annotation-tool.in
gobject-introspection-0.9.10/tools/g-ir-annotation-tool.in
+@@ -1,4 +1,4 @@
+-#!@PYTHON@
++#!/usr/bin/env python
+ # -*- Mode: Python -*-
+ # GObject-Introspection - a framework for introspecting GObject libraries
+ # Copyright (C) 2008 Johan Dahlin
+Index: gobject-introspection-0.9.10/tools/g-ir-scanner.in
+===
+--- gobject-introspection-0.9.10.orig/tools/g-ir-scanner.in
gobject-introspection-0.9.10
[OE-core] [PATCH 2/2] screenshot: rename to sato-screenshot
To remove a name conflict with e17's screenshot tool (and possibly other
screenshot tools, as screenshot is a generic term), rename screenshot
to sato-screenshot.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
.../sato-screenshot/files/fix_ldadd_order.patch| 15 +
.../sato-screenshot/sato-screenshot_git.bb | 23
.../screenshot/files/fix_ldadd_order.patch | 15 -
meta/recipes-sato/screenshot/screenshot_git.bb | 23
meta/recipes-sato/tasks/task-core-x11.bb |2 +-
5 files changed, 39 insertions(+), 39 deletions(-)
create mode 100644
meta/recipes-sato/sato-screenshot/files/fix_ldadd_order.patch
create mode 100644 meta/recipes-sato/sato-screenshot/sato-screenshot_git.bb
delete mode 100644 meta/recipes-sato/screenshot/files/fix_ldadd_order.patch
delete mode 100644 meta/recipes-sato/screenshot/screenshot_git.bb
diff --git a/meta/recipes-sato/sato-screenshot/files/fix_ldadd_order.patch
b/meta/recipes-sato/sato-screenshot/files/fix_ldadd_order.patch
new file mode 100644
index 000..7d9689e
--- /dev/null
+++ b/meta/recipes-sato/sato-screenshot/files/fix_ldadd_order.patch
@@ -0,0 +1,15 @@
+Fix the ordering of LDADD options to fix a compilation failure.
+
+Signed-off-by: Scott Garman scott.a.gar...@intel.com
+
+Upstream-Status: Inappropriate [configuration]
+
+diff -urN screenshot.orig//Makefile.am screenshot/Makefile.am
+--- screenshot.orig//Makefile.am 2010-06-29 11:55:00.0 -0700
screenshot/Makefile.am 2011-03-01 11:09:01.215813968 -0800
+@@ -23,4 +23,4 @@
+ # A standalone tool for running from a terminal and scripts
+ bin_PROGRAMS = screenshot
+ screenshot_SOURCES = main.c
+-screenshot_LDADD = $(GTK_LIBS) libshot.la
++screenshot_LDADD = libshot.la $(GTK_LIBS)
diff --git a/meta/recipes-sato/sato-screenshot/sato-screenshot_git.bb
b/meta/recipes-sato/sato-screenshot/sato-screenshot_git.bb
new file mode 100644
index 000..5e51d3d
--- /dev/null
+++ b/meta/recipes-sato/sato-screenshot/sato-screenshot_git.bb
@@ -0,0 +1,23 @@
+DESCRIPTION = An ultra-simple screen capture utility, aimed at handheld
devices
+HOMEPAGE = http://www.o-hand.com;
+BUGTRACKER = http://bugzilla.openedhand.com/;
+
+LICENSE = GPLv2 GPLv2+
+LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
+
file://main.c;endline=9;md5=023e14d6404d0a961eb97cbd011fc141 \
+
file://screenshot-ui.h;endline=9;md5=638d9ffa83e9325a36df224166ed6ad0
+
+DEPENDS = matchbox-panel-2
+SRCREV = c792e4edc758bab21e0b01814979eacf0b1af945
+PV = 0.1+git${SRCPV}
+PR = r0
+
+SRC_URI = git://git.yoctoproject.org/screenshot;protocol=git \
+ file://fix_ldadd_order.patch
+
+S = ${WORKDIR}/git
+
+inherit autotools pkgconfig
+
+FILES_${PN} += ${libdir}/matchbox-panel/*.so
+FILES_${PN}-dbg += ${libdir}/matchbox-panel/.debug
diff --git a/meta/recipes-sato/screenshot/files/fix_ldadd_order.patch
b/meta/recipes-sato/screenshot/files/fix_ldadd_order.patch
deleted file mode 100644
index 7d9689e..000
--- a/meta/recipes-sato/screenshot/files/fix_ldadd_order.patch
+++ /dev/null
@@ -1,15 +0,0 @@
-Fix the ordering of LDADD options to fix a compilation failure.
-
-Signed-off-by: Scott Garman scott.a.gar...@intel.com
-
-Upstream-Status: Inappropriate [configuration]
-
-diff -urN screenshot.orig//Makefile.am screenshot/Makefile.am
screenshot.orig//Makefile.am 2010-06-29 11:55:00.0 -0700
-+++ screenshot/Makefile.am 2011-03-01 11:09:01.215813968 -0800
-@@ -23,4 +23,4 @@
- # A standalone tool for running from a terminal and scripts
- bin_PROGRAMS = screenshot
- screenshot_SOURCES = main.c
--screenshot_LDADD = $(GTK_LIBS) libshot.la
-+screenshot_LDADD = libshot.la $(GTK_LIBS)
diff --git a/meta/recipes-sato/screenshot/screenshot_git.bb
b/meta/recipes-sato/screenshot/screenshot_git.bb
deleted file mode 100644
index 917a27d..000
--- a/meta/recipes-sato/screenshot/screenshot_git.bb
+++ /dev/null
@@ -1,23 +0,0 @@
-DESCRIPTION = An ultra-simple screen capture utility, aimed at handheld
devices
-HOMEPAGE = http://www.o-hand.com;
-BUGTRACKER = http://bugzilla.openedhand.com/;
-
-LICENSE = GPLv2 GPLv2+
-LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
-
file://main.c;endline=9;md5=023e14d6404d0a961eb97cbd011fc141 \
-
file://screenshot-ui.h;endline=9;md5=638d9ffa83e9325a36df224166ed6ad0
-
-DEPENDS = matchbox-panel-2
-SRCREV = c792e4edc758bab21e0b01814979eacf0b1af945
-PV = 0.1+git${SRCPV}
-PR = r0
-
-SRC_URI = git://git.yoctoproject.org/${BPN};protocol=git \
- file://fix_ldadd_order.patch
-
-S = ${WORKDIR}/git
-
-inherit autotools pkgconfig
-
-FILES_${PN} += ${libdir}/matchbox-panel/*.so
-FILES_${PN}-dbg += ${libdir}/matchbox-panel/.debug
diff --git a/meta/recipes-sato/tasks/task-core-x11.bb
b/meta/recipes-sato/tasks/task-core-x11.bb
index 106bc0f..f1b06f9 100644
--- a/meta
[OE-core] [RFC] .la files cleanup
Proposal: extend some bbclass with a task to remove unused .la files
Rationale: There are lots of recipes, which install tons of .la files
(thanks libtool),
but then do not ship them (correctly as most of them are unused in
real systems).
My proposal would be to include a special task or a
do_install_append() part that
will remove specified .la files. (like ${libdir}/xorg/modules/*/.la,
${libdir}/matchbox-panel/*.la, etc.). I see this usually done in
do_install or in special do_install_append
parts, but I think it would be better to handle this globally.
--
With best wishes
Dmitry
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] oe-core/meta-oe PN clash
Hello, I've stumbled upon two different packages with same PN (screenshot): One is a sato-related screenshoter from oe-core, second is a e17 screenshot module from meta-efl. I'd propose to rename a sato screenshot package, since e17 one depends on PN being equal to internal module name in several places. -- With best wishes Dmitry ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
