* Re: [PATCH] bind 9.8.1: fix build after recent update
From: Saul Wold @ 2011-10-20 17:21 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi
In-Reply-To: <1318865134-4380-1-git-send-email-koen@dominion.thruhere.net>
On 10/17/2011 08:25 AM, Koen Kooi wrote:
> | checking linking as -lgssapi -lkrb5 -ldes -lcrypt -lasn1 -lroken -lcom_err... no
> | checking linking as -lgssapi -lkrb5 -lcrypto -lcrypt -lasn1 -lroken -lcom_err... no
> | checking linking as -lgss -lkrb5... no
> | configure: error: could not determine proper GSSAPI linkage
> | + bbfatal 'oe_runconf failed'
> | + echo 'ERROR: oe_runconf failed'
>
> Signed-off-by: Koen Kooi<koen@dominion.thruhere.net>
> ---
> meta/recipes-connectivity/bind/bind_9.8.1.bb | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-connectivity/bind/bind_9.8.1.bb b/meta/recipes-connectivity/bind/bind_9.8.1.bb
> index 330acdb..af473e9 100644
> --- a/meta/recipes-connectivity/bind/bind_9.8.1.bb
> +++ b/meta/recipes-connectivity/bind/bind_9.8.1.bb
> @@ -6,10 +6,10 @@ LICENSE = "ISC& BSD"
> LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=0fbe2a3ab3c68ac3fea3cad13093877c"
>
> DEPENDS = "openssl"
> -PR = "r0"
> +PR = "r1"
>
> SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
> - file://conf.patch \
> + file://conf.patch \
> file://cross-build-fix.patch \
> "
>
> @@ -19,6 +19,7 @@ SRC_URI[sha256sum] = "02285dc429cb2a6687a1b2446e9ee22c1df27f2577225b05be5092395e
> # --enable-exportlib is necessary for building dhcp
> EXTRA_OECONF = " --enable-ipv6=no --with-randomdev=/dev/random --disable-threads \
> --disable-devpoll --disable-epoll --with-gost=no \
> + --with-gssapi=no \
> --sysconfdir=${sysconfdir}/bind \
> --with-openssl=${STAGING_LIBDIR}/.. --with-libxml2=${STAGING_LIBDIR}/.. \
> --enable-exportlib --with-export-includedir=${includedir} --with-export-libdir=${libdir} \
Merged into OE-Core
Thanks
Sau!
^ permalink raw reply
* Re: [PATCH 0/3] gcc update and bug fix
From: Saul Wold @ 2011-10-20 17:19 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <cover.1318901607.git.raj.khem@gmail.com>
On 10/17/2011 06:38 PM, Khem Raj wrote:
> This patchset does two things for gcc
> 1. Updates to latest from FSF gcc-4_6-branch
> 2. Backport the fix for PR46934
>
> The changes that come from FSF gcc are listed here
> http://sakrah.homelinux.org/files/gcc-4.6-ChangeLog-r180099_r180099.txt
>
> 3. Bluez4 needed glib.h therefore depend on glib-2.0
>
> The following changes since commit 8bc098475f58b60bfb24ec0fd338e49ac2387c50:
>
> gcc-4.6: Backport PR46934 fix (2011-10-17 18:00:29 -0700)
>
> are available in the git repository at:
> git://git.openembedded.org/openembedded-core-contrib kraj/gcc-update
> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/gcc-update
>
> Khem Raj (3):
> bluez4: Add glib-2.0 to DEPENDS
> gcc-4.6: Upgrade SRCREV to latest FSF 4.6 branch
> gcc-4.6: Backport PR46934 fix
>
> meta/recipes-connectivity/bluez/bluez4.inc | 2 +-
> meta/recipes-connectivity/bluez/bluez4_4.96.bb | 2 +-
> meta/recipes-devtools/gcc/gcc-4.6.inc | 5 +-
> meta/recipes-devtools/gcc/gcc-4.6/pr46934.patch | 392 +++++++++++++++++++++++
> 4 files changed, 397 insertions(+), 4 deletions(-)
> create mode 100644 meta/recipes-devtools/gcc/gcc-4.6/pr46934.patch
>
Merged into OE-Core
Thanks
Sau!
^ permalink raw reply
* Re: [PATCH] insane.bbclass: print full path on invalid LICENSE_FILES_CHKSUM
From: Saul Wold @ 2011-10-20 17:19 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Darren Hart
In-Reply-To: <4E9DCCE8.8090009@linux.intel.com>
On 10/18/2011 12:00 PM, Darren Hart wrote:
> Currently only the basename is printed when os.path.isfile() returns a failure
> for the license file. If the file is present, but in the wrong directory, this
> can be non-obvious to debug. Use the full path instead.
>
> Make a minor grammatical correction in the error message while we're at it.
>
> Signed-off-by: Darren Hart<dvhart@linux.intel.com>
> ---
> meta/classes/insane.bbclass | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
> index b861e85..017f7be 100644
> --- a/meta/classes/insane.bbclass
> +++ b/meta/classes/insane.bbclass
> @@ -330,7 +330,7 @@ def package_qa_check_license(workdir, d):
> (type, host, path, user, pswd, parm) = bb.decodeurl(url)
> srclicfile = os.path.join(srcdir, path)
> if not os.path.isfile(srclicfile):
> - raise bb.build.FuncFailed( pn + ": LIC_FILES_CHKSUM points to invalid file: " + path)
> + raise bb.build.FuncFailed( pn + ": LIC_FILES_CHKSUM points to an invalid file: " + srclicfile)
>
> if 'md5' not in parm:
> bb.error(pn + ": md5 checksum is not specified for ", url)
Merged into OE-Core
Thanks
Sau!
^ permalink raw reply
* Re: [PATCH 0/5] Update packages V3
From: Saul Wold @ 2011-10-20 17:18 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <cover.1318995438.git.kai.kang@windriver.com>
On 10/18/2011 10:45 PM, Kang Kai wrote:
> Hi Saul,
>
> Version 3: remove obsolete patches, and add distro tracking information.
>
> Version 2: only add libsdl update
>
> Update ghostscript, libxml-sax-perl and liburi-perl to latest version.
>
> Regards,
>
>
> The following changes since commit 3c517bfe6c6d7781658f65bda4e0fdb499ca2b62:
>
> bind 9.8.1: fix build after recent update (2011-10-17 16:58:14 +0100)
>
> are available in the git repository at:
> git://git.pokylinux.org/poky-contrib kangkai/update-pkgs
> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kangkai/update-pkgs
>
> Kang Kai (5):
> ghostscript: update to 9.04
> libxml-sax-perl: update to 0.99
> liburi-perl: update to 1.59
> libsdl: update to 1.2.14
> distro_tracking_fields: update packages tracking fields
>
> .../conf/distro/include/distro_tracking_fields.inc | 24 ++
> .../{liburi-perl_1.58.bb => liburi-perl_1.59.bb} | 6 +-
> .../ghostscript/ghostscript/arm/soobjarch.h | 40 ---
> .../ghostscript-9.02-prevent_recompiling.patch | 74 +++---
> .../ghostscript/ghostscript/i586/soobjarch.h | 41 ---
> .../ghostscript/ghostscript/mips/soobjarch.h | 40 ---
> .../ghostscript/ghostscript/powerpc/soobjarch.h | 40 ---
> .../ghostscript/ghostscript/powerpc64/soobjarch.h | 40 ---
> .../ghostscript/ghostscript/x86_64/soobjarch.h | 40 ---
> .../{ghostscript_9.02.bb => ghostscript_9.04.bb} | 24 +-
> ...ml-sax-perl_0.96.bb => libxml-sax-perl_0.99.bb} | 7 +-
> meta/recipes-graphics/libsdl/files/acinclude.m4 | 189 -------------
> .../libsdl/files/configure_tweak.patch | 281 +++++++++-----------
> .../libsdl/files/kernel-asm-page.patch | 15 -
> .../libsdl/{libsdl_1.2.11.bb => libsdl_1.2.14.bb} | 17 +-
> 15 files changed, 219 insertions(+), 659 deletions(-)
> rename meta/recipes-devtools/perl/{liburi-perl_1.58.bb => liburi-perl_1.59.bb} (81%)
> delete mode 100644 meta/recipes-extended/ghostscript/ghostscript/arm/soobjarch.h
> delete mode 100644 meta/recipes-extended/ghostscript/ghostscript/i586/soobjarch.h
> delete mode 100644 meta/recipes-extended/ghostscript/ghostscript/mips/soobjarch.h
> delete mode 100644 meta/recipes-extended/ghostscript/ghostscript/powerpc/soobjarch.h
> delete mode 100644 meta/recipes-extended/ghostscript/ghostscript/powerpc64/soobjarch.h
> delete mode 100644 meta/recipes-extended/ghostscript/ghostscript/x86_64/soobjarch.h
> rename meta/recipes-extended/ghostscript/{ghostscript_9.02.bb => ghostscript_9.04.bb} (81%)
> rename meta/recipes-extended/perl/{libxml-sax-perl_0.96.bb => libxml-sax-perl_0.99.bb} (85%)
> delete mode 100644 meta/recipes-graphics/libsdl/files/acinclude.m4
> delete mode 100644 meta/recipes-graphics/libsdl/files/kernel-asm-page.patch
> rename meta/recipes-graphics/libsdl/{libsdl_1.2.11.bb => libsdl_1.2.14.bb} (81%)
>
Merged into OE-Core
Thanks
Sau!
^ permalink raw reply
* Re: useradd class not working
From: Otavio Salvador @ 2011-10-20 17:17 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4EA0485F.3080307@windriver.com>
On Thu, Oct 20, 2011 at 14:12, Mark Hatle <mark.hatle@windriver.com> wrote:
...
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb
>
> That is the recipe that was used when testing this feature. If it no longer
> works properly then something has recently broken in the groupadd functionality.
Yes and I used it and openssh as base to my package but it seem to do nothing.
I tried to debug it and changed rootfs_ipk class to use "sh -x" when
running the preinst scripts of the packages and all seems fine however
it keeps not adding the group into rootfs/etc/group
I do appreciate help here since I am lost right now.
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply
* Re: [PATCH 0/1] Fix race while building external modules
From: Saul Wold @ 2011-10-20 17:17 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Anders Darander
In-Reply-To: <cover.1319022793.git.anders@chargestorm.se>
On 10/19/2011 04:15 AM, Anders Darander wrote:
>
> When building an image with several external modules, a race is likely to
> occur. This race is when building scripts in the staged kernel tree (sysroot).
>
> To prevent this, we promote the do_make_scripts() function to a task, which we
> protect by a lock. Tip on how to make this work was received by Richard in
> [1]. To avoid new problems, introduced by this promotion, we make this new
> task depend on do_populate_sysroot from the modules dependencies
> (i.e. virtual/kernel).
>
> This patch has been extensively tested on the 2011-1 release branch, on a
> custom ARM-machine and distro with several external modules.
>
> [1] http://lists.linuxtogo.org/pipermail/openembedded-core/2011-October/011163.html
>
> The following changes since commit e31dd9b65f3b03f79cabab25eca157532de3bd9c:
>
> fontconfig: fix fix-pkgconfig.patch (2011-10-18 18:13:47 +0100)
>
> are available in the git repository at:
> git://github.com/darander/oe-core ext-mod-race
> https://github.com/darander/oe-core/tree/ext-mod-race
>
> Anders Darander (1):
> module.bbclass: add lock to prevent error bulding ext modules
>
> meta/classes/module.bbclass | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
Merged into OE-Core
Thanks
Sau!
^ permalink raw reply
* Re: [PATCH 0/4] Update tzdata and gst-plugins-good v2
From: Saul Wold @ 2011-10-20 17:15 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <cover.1319064436.git.josh@linux.intel.com>
On 10/19/2011 03:49 PM, Joshua Lock wrote:
> Upgraded tzdata, tzcode-native and gst-plugins-good per mailing list
> requests.
>
> Updated gst-plugins-good recipe to install and correctly handle its
> gconf schema.
>
> Cheers,
> Joshua
>
> The following changes since commit e31dd9b65f3b03f79cabab25eca157532de3bd9c:
>
> fontconfig: fix fix-pkgconfig.patch (2011-10-18 18:13:47 +0100)
>
> are available in the git repository at:
> git://git.openembedded.org/openembedded-core-contrib josh/work
> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=josh/work
>
> Joshua Lock (4):
> gst-plugins-good: update to 0.10.30
> tzdata: updated SRC_URI and update to 2011k
> tzcode-native: update SRC_URI to new IANA location
> gst-plugins-good: correctly handle gconf schema
>
> .../recipes-extended/tzcode/tzcode-native_2011i.bb | 4 ++--
> .../tzdata/{tzdata_2011k.bb => tzdata_2011l.bb} | 6 +++---
> ...good_0.10.28.bb => gst-plugins-good_0.10.30.bb} | 10 ++++++----
> 3 files changed, 11 insertions(+), 9 deletions(-)
> rename meta/recipes-extended/tzdata/{tzdata_2011k.bb => tzdata_2011l.bb} (96%)
> rename meta/recipes-multimedia/gstreamer/{gst-plugins-good_0.10.28.bb => gst-plugins-good_0.10.30.bb} (75%)
>
Merged the tz* patches and the first gst-plugin.
Second gst-plugin patch got some feedback, I missed.
Thanks
Sau!
^ permalink raw reply
* Re: [PATCH 0/3 v2] Update packages
From: Saul Wold @ 2011-10-20 17:13 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <cover.1319090166.git.wenzong.fan@windriver.com>
On 10/19/2011 11:04 PM, wenzong.fan@windriver.com wrote:
> From: Wenzong Fan<wenzong.fan@windriver.com>
>
> v2 add the patch to distro_tracking_fields.inc file.
>
> The following changes since commit b4757833c3548b5ee3a1cce58e2f059b3f63cb09:
> Martin Jansa (1):
> fontconfig: fix fix-pkgconfig.patch
>
> are available in the git repository at:
>
> git://git.pokylinux.org/poky-contrib wenzong/update_pkgs
> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/update_pkgs
>
> Wenzong Fan (3):
> ccache: update to 3.1.6
> chkconfig: Update to 1.3.55
> distro_tracking_fields: update packages tracking fields
>
> .../conf/distro/include/distro_tracking_fields.inc | 12 ++++++++++++
> .../ccache/{ccache_3.1.5.bb => ccache_3.1.6.bb} | 4 ++--
> .../{chkconfig_1.3.52.bb => chkconfig_1.3.55.bb} | 6 +++---
> 3 files changed, 17 insertions(+), 5 deletions(-)
> rename meta/recipes-devtools/ccache/{ccache_3.1.5.bb => ccache_3.1.6.bb} (47%)
> rename meta/recipes-extended/chkconfig/{chkconfig_1.3.52.bb => chkconfig_1.3.55.bb} (83%)
>
Merged the updates into OE-Core, but not the distro_tracking since it
was not correct.
Thanks
Sau!
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply
* Re: [PATCH 0/6] recipe upgrades + some fixes
From: Saul Wold @ 2011-10-20 17:12 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <cover.1318984111.git.nitin.a.kamble@intel.com>
On 10/18/2011 05:30 PM, nitin.a.kamble@intel.com wrote:
> From: Nitin A Kamble<nitin.a.kamble@intel.com>
>
> More information in the commit log bellow.
> Thanks,
> Nitin
>
> The following changes since commit b4757833c3548b5ee3a1cce58e2f059b3f63cb09:
>
> fontconfig: fix fix-pkgconfig.patch (2011-10-18 18:18:36 +0100)
>
> are available in the git repository at:
> git://git.pokylinux.org/poky-contrib nitin/upgrades
> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=nitin/upgrades
>
> Nitin A Kamble (6):
> x86 tune files: set baselib for x32 tune as libx32
> gmp: also generate the libgmpcxx library
> python-scons: upgrade from 2.0.1 to 2.1.0
> python-dbus: upgrade from 0.83.2 to 0.84.0
> libxml-parser-perl: upgrade from 2.40 to 2.41
> distro-tracking: update data for some toolchain recipes
>
> .../conf/distro/include/distro_tracking_fields.inc | 42 ++++++++++++--------
> meta/conf/machine/include/ia32/arch-ia32.inc | 2 +-
> meta/conf/machine/include/tune-core2.inc | 2 +-
> ...ser-perl_2.40.bb => libxml-parser-perl_2.41.bb} | 6 +-
> ...python-dbus_0.83.2.bb => python-dbus_0.84.0.bb} | 4 +-
> ...ative_2.0.1.bb => python-scons-native_2.1.0.bb} | 3 +-
> ...python-scons_2.0.1.bb => python-scons_2.1.0.bb} | 6 +-
> meta/recipes-support/gmp/gmp.inc | 2 +
> meta/recipes-support/gmp/gmp_4.2.1.bb | 2 +-
> meta/recipes-support/gmp/gmp_5.0.2.bb | 2 +-
> 10 files changed, 40 insertions(+), 31 deletions(-)
> rename meta/recipes-devtools/perl/{libxml-parser-perl_2.40.bb => libxml-parser-perl_2.41.bb} (82%)
> rename meta/recipes-devtools/python/{python-dbus_0.83.2.bb => python-dbus_0.84.0.bb} (83%)
> rename meta/recipes-devtools/python/{python-scons-native_2.0.1.bb => python-scons-native_2.1.0.bb} (89%)
> rename meta/recipes-devtools/python/{python-scons_2.0.1.bb => python-scons_2.1.0.bb} (51%)
>
Nitin,
We merged 5 of the 6 patches above, as noted in the thread, there is a
problem with the gmp packaging. Please review that and try to resolve it.
Thanks
Sau!
^ permalink raw reply
* Re: sdk path problem
From: Richard Purdie @ 2011-10-20 16:54 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <840A81C1B782724A8EB52725BD519EFF1A8633@MBX20.4emm.local>
On Thu, 2011-10-20 at 08:22 +0000, James Limbouris wrote:
> Hi,
>
> I have been using meta-toolchain-qte in the past to cross compile a Qt app, and the Linux kernel.
> Recently I replaced my old SDK image with a fresh one, and found that I could not link vmlinux anymore.
>
> When building the kernel, I use the following ('rica' is the distribution name):
> export PATH=$PATH:/usr/local/rica-eglibc-i686-armv5te/sysroots/i686-ricasdk-linux/usr/bin/armv5te-rica-linux-gnueabi/
> make ARCH=arm CROSS_COMPILE=arm-rica-linux-gnueabi- zImage
>
> The new error message is:
>
> Kernel: arch/arm/boot/Image is ready
> AS arch/arm/boot/compressed/head.o
> GZIP arch/arm/boot/compressed/piggy.gz
> CC arch/arm/boot/compressed/misc.o
> AS arch/arm/boot/compressed/piggy.o
> LD arch/arm/boot/compressed/vmlinux
> arm-rica-linux-gnueabi-ld: cannot find libgcc.a: No such file or directory
>
> Comparing the build with the old sdk to the build with the new one, I find that the command line for linking has changed from:
>
> arm-rica-linux-gnueabi-ld -EL --defsym zreladdr=0x80008000 --defsym initrd_phys=0x80800000 --defsym params_phys=0x80000100 -p --no-undefined -X /usr/local/rica-eglibc-i686-armv5te/sysroots/arm-rica-linux-gnueabi/usr/lib/arm-rica-linux-gnueabi/4.5.4/libgcc.a -T arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/head.o arch/arm/boot/compressed/piggy.o arch/arm/boot/compressed/misc.o -o arch/arm/boot/compressed/vmlinux
>
> to:
>
> arm-rica-linux-gnueabi-ld -EL --defsym zreladdr=0x80008000 --defsym initrd_phys=0x80800000 --defsym params_phys=0x80000100 -p --no-undefined -X libgcc.a -T arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/head.o arch/arm/boot/compressed/piggy.o arch/arm/boot/compressed/misc.o -o arch/arm/boot/compressed/vmlinux
>
> So libgcc.a has lost its path qualification.
> I also straced the two linker commands, and found that they differed in one sequence.
>
> Old:
> lstat64("/usr/local/rica-eglibc-i686-armv5te", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat64("/usr/local/rica-eglibc-i686-armv5te/sysroots", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat64("/usr/local/rica-eglibc-i686-armv5te/sysroots/arm-rica-linux-gnueabi", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>
> New:
> lstat64("/usr/local/rica-eglibc-i686-armv5te", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat64("/usr/local/rica-eglibc-i686-armv5te/sysroots", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat64("/usr/local/rica-eglibc-i686-armv5te/sysroots/arm-rica-linux-gnueabi", 0xbffe67cc) = -1 ENOENT (No such file or directory)
>
> Both toolchains are looking for a sysroot at 'arm-rica-linux-gnueabi', but the new toolchain should be looking at 'armv5te-rica-linux-gnueabi', as the names have changed.
> I'm not yet acquainted with the darker arts of toolchain generation. Can anyone help with this?
There should be a --sysroot option being passed to the compiler/linker
to tell which sysroot to look at. We did recently change the sysroot
location to reflect the target architecture it was optimized for but
this does mean the compiler and other tools need the correct sysroot
path to be specified. The environment script that ships with the
toolchain should do this?
Cheers,
Richard
^ permalink raw reply
* Re: sdk path problem
From: Tom Rini @ 2011-10-20 16:38 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAMKF1spFtH+40uCMJO1nfV2h90n1FnEusooOHq3gBmrA5L+zDw@mail.gmail.com>
On Thu, Oct 20, 2011 at 9:27 AM, Khem Raj <raj.khem@gmail.com> wrote:
> On Thu, Oct 20, 2011 at 1:22 AM, James Limbouris
> <james@digitalmatter.com.au> wrote:
>> Hi,
>>
>> I have been using meta-toolchain-qte in the past to cross compile a Qt app, and the Linux kernel.
>> Recently I replaced my old SDK image with a fresh one, and found that I could not link vmlinux anymore.
>>
>> When building the kernel, I use the following ('rica' is the distribution name):
>> export PATH=$PATH:/usr/local/rica-eglibc-i686-armv5te/sysroots/i686-ricasdk-linux/usr/bin/armv5te-rica-linux-gnueabi/
>> make ARCH=arm CROSS_COMPILE=arm-rica-linux-gnueabi- zImage
>>
>> The new error message is:
>>
>> Kernel: arch/arm/boot/Image is ready
>> AS arch/arm/boot/compressed/head.o
>> GZIP arch/arm/boot/compressed/piggy.gz
>> CC arch/arm/boot/compressed/misc.o
>> AS arch/arm/boot/compressed/piggy.o
>> LD arch/arm/boot/compressed/vmlinux
>> arm-rica-linux-gnueabi-ld: cannot find libgcc.a: No such file or directory
>>
>> Comparing the build with the old sdk to the build with the new one, I find that the command line for linking has changed from:
>>
>> arm-rica-linux-gnueabi-ld -EL --defsym zreladdr=0x80008000 --defsym initrd_phys=0x80800000 --defsym params_phys=0x80000100 -p --no-undefined -X /usr/local/rica-eglibc-i686-armv5te/sysroots/arm-rica-linux-gnueabi/usr/lib/arm-rica-linux-gnueabi/4.5.4/libgcc.a -T arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/head.o arch/arm/boot/compressed/piggy.o arch/arm/boot/compressed/misc.o -o arch/arm/boot/compressed/vmlinux
>>
>> to:
>>
>> arm-rica-linux-gnueabi-ld -EL --defsym zreladdr=0x80008000 --defsym initrd_phys=0x80800000 --defsym params_phys=0x80000100 -p --no-undefined -X libgcc.a -T arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/head.o arch/arm/boot/compressed/piggy.o arch/arm/boot/compressed/misc.o -o arch/arm/boot/compressed/vmlinux
>>
>> So libgcc.a has lost its path qualification.
>> I also straced the two linker commands, and found that they differed in one sequence.
>>
>> Old:
>> lstat64("/usr/local/rica-eglibc-i686-armv5te", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>> lstat64("/usr/local/rica-eglibc-i686-armv5te/sysroots", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>> lstat64("/usr/local/rica-eglibc-i686-armv5te/sysroots/arm-rica-linux-gnueabi", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>>
>> New:
>> lstat64("/usr/local/rica-eglibc-i686-armv5te", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>> lstat64("/usr/local/rica-eglibc-i686-armv5te/sysroots", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>> lstat64("/usr/local/rica-eglibc-i686-armv5te/sysroots/arm-rica-linux-gnueabi", 0xbffe67cc) = -1 ENOENT (No such file or directory)
>>
>> Both toolchains are looking for a sysroot at 'arm-rica-linux-gnueabi', but the new toolchain should be looking at 'armv5te-rica-linux-gnueabi', as the names have changed.
>> I'm not yet acquainted with the darker arts of toolchain generation. Can anyone help with this?
>>
>
> can you post the build logs and configure logs of
> binutils sdk
I've seen the same problem with just plain old meta-toolchain and
trying to build something simple like u-boot. Hadn't had the time to
dig at it tho.
--
Tom
^ permalink raw reply
* Re: sdk path problem
From: Khem Raj @ 2011-10-20 16:27 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <840A81C1B782724A8EB52725BD519EFF1A8633@MBX20.4emm.local>
On Thu, Oct 20, 2011 at 1:22 AM, James Limbouris
<james@digitalmatter.com.au> wrote:
> Hi,
>
> I have been using meta-toolchain-qte in the past to cross compile a Qt app, and the Linux kernel.
> Recently I replaced my old SDK image with a fresh one, and found that I could not link vmlinux anymore.
>
> When building the kernel, I use the following ('rica' is the distribution name):
> export PATH=$PATH:/usr/local/rica-eglibc-i686-armv5te/sysroots/i686-ricasdk-linux/usr/bin/armv5te-rica-linux-gnueabi/
> make ARCH=arm CROSS_COMPILE=arm-rica-linux-gnueabi- zImage
>
> The new error message is:
>
> Kernel: arch/arm/boot/Image is ready
> AS arch/arm/boot/compressed/head.o
> GZIP arch/arm/boot/compressed/piggy.gz
> CC arch/arm/boot/compressed/misc.o
> AS arch/arm/boot/compressed/piggy.o
> LD arch/arm/boot/compressed/vmlinux
> arm-rica-linux-gnueabi-ld: cannot find libgcc.a: No such file or directory
>
> Comparing the build with the old sdk to the build with the new one, I find that the command line for linking has changed from:
>
> arm-rica-linux-gnueabi-ld -EL --defsym zreladdr=0x80008000 --defsym initrd_phys=0x80800000 --defsym params_phys=0x80000100 -p --no-undefined -X /usr/local/rica-eglibc-i686-armv5te/sysroots/arm-rica-linux-gnueabi/usr/lib/arm-rica-linux-gnueabi/4.5.4/libgcc.a -T arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/head.o arch/arm/boot/compressed/piggy.o arch/arm/boot/compressed/misc.o -o arch/arm/boot/compressed/vmlinux
>
> to:
>
> arm-rica-linux-gnueabi-ld -EL --defsym zreladdr=0x80008000 --defsym initrd_phys=0x80800000 --defsym params_phys=0x80000100 -p --no-undefined -X libgcc.a -T arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/head.o arch/arm/boot/compressed/piggy.o arch/arm/boot/compressed/misc.o -o arch/arm/boot/compressed/vmlinux
>
> So libgcc.a has lost its path qualification.
> I also straced the two linker commands, and found that they differed in one sequence.
>
> Old:
> lstat64("/usr/local/rica-eglibc-i686-armv5te", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat64("/usr/local/rica-eglibc-i686-armv5te/sysroots", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat64("/usr/local/rica-eglibc-i686-armv5te/sysroots/arm-rica-linux-gnueabi", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>
> New:
> lstat64("/usr/local/rica-eglibc-i686-armv5te", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat64("/usr/local/rica-eglibc-i686-armv5te/sysroots", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat64("/usr/local/rica-eglibc-i686-armv5te/sysroots/arm-rica-linux-gnueabi", 0xbffe67cc) = -1 ENOENT (No such file or directory)
>
> Both toolchains are looking for a sysroot at 'arm-rica-linux-gnueabi', but the new toolchain should be looking at 'armv5te-rica-linux-gnueabi', as the names have changed.
> I'm not yet acquainted with the darker arts of toolchain generation. Can anyone help with this?
>
can you post the build logs and configure logs of
binutils sdk
> Regards,
> James Limbouris
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
From: Koen Kooi @ 2011-10-20 16:24 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1319126135.2410.51.camel@ted>
Op 20 okt. 2011, om 17:55 heeft Richard Purdie het volgende geschreven:
> On Thu, 2011-10-20 at 16:36 +0200, Martin Jansa wrote:
>> On Thu, Oct 20, 2011 at 03:25:52PM +0100, Richard Purdie wrote:
>>> On Wed, 2011-10-19 at 16:33 -0700, Saul Wold wrote:
>>>> On 10/19/2011 12:00 PM, Otavio Salvador wrote:
>>>>> On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com> wrote:
>>>>> ...
>>>>>>>>> Many upstreams we can't track if updates are required automagically, so
>>>>>>>>> we
>>>>>>>>> need a place to record when the last manual check was, also possible
>>>>>>>>> reasons
>>>>>>>>> why we should not update to newer versions, ...
>>>>>>
>>>>>> hmm manual check means it has to be done manually is there any thing
>>>>>> that needs it ?
>>>>>>
>>>>>> I think unless they are distro specific which seems not since they are
>>>>>> in oe-core
>>>>>> they could exist in recipes thats my opinion.
>>>>>
>>>>> I agree that this should be put into the recipes. Besides this allows
>>>>> for checking if it was updated when the version has been updated.
>>>>>
>>>>> If done right, when updating the version this data will be updated
>>>>> together. I see no change in the amount of changes.
>>>>>
>>>>> A plus of this choice is it will be more difficult to forget to update
>>>>> that info. This happened in last qt update for an example.
>>>>>
>>>>
>>>> This may need to be something that the TSC brings up, possibly we can
>>>> talk about it in Prague next week.
>>>
>>> So just to give some background here, the information in those files was
>>> added by Yocto people to give some idea of the update status of various
>>> recipes. This included when the version was last checked/updated for
>>> recipes which we can't automate that process for, when certain cleanup
>>> checks were made, what the general state of the recipe was and who on
>>> the Yocto team was specifically looking after given recipes.
>>>
>>> When it was discussed, some of it was Yocto specific, some of it wasn't
>>> and popular opinion was against it going into the recipes themselves. I
>>> was ok with that given we have the pn- overrides and can handle the
>>> problem that way just fine.
>>>
>>> OE-Core happened and we kept the data with OE-Core at least for now. We
>>> have several options:
>>>
>>> a) Keep the data where it is
>>> b) Merge the data into the recipes
>>> c) Move the data out of OE-Core
>>>
>>> Since a lot of that data is fairly Yocto process specific, it may make
>>> sense to move it over to meta-yocto...
>>
>> I don't like "global" files where many people should maintain their info
>> and it's so easy to forgot when it's somewhere else then real changes
>> (like it was with checksums.ini and sane-src*.ini).
>
> Some data does make sense to be maintained globally and I don't think we
> should automatically say its bad. It depends what the use case is and
> how its intended to be used.
>
>> So I vote for b) Merge the data into the recipes, only problem with this
>> is that if we have 2 versions of foo (foo_1.0.bb, foo_git.bb) without
>> any foo.inc, will we create foo.inc just for distro-tracking info? Maybe
>> we should and move at least DESCRIPTION and similar variables too.
>>
>> c) moving it to meta-yocto will probably make distro-tracking info even
>> more outdated as sometimes different people then who did upgrade in
>> oe-core will have to update distro-tracking info in this layer (this is
>> also the case now sometimes, but with distro-tracking info in recipe we
>> can try better to update it with upgrades).
>
> I'd actually like Saul's view on this since he generally looks after
> that data. There as been discussion about whether it is "internal" yocto
> tracking stuff or whether its more general OE focused and I don't know
> what the answer is there. I think there is a mixture of uses. I'm also
> wary of "pushing" Yocto policy into OE which I think this might amount
> to.
>
> As a specific example, we've moved away from wanting MAINTAINER info in
> the recipes in the past and this gets us back there again. I don't
> really want to loop over adding data and then removing it again
> repeatedly so this needs thought/discussion. Who gets their name in the
> MAINTAINER field exactly? What is the process for that and what
> responsibilities does that person have?
The problem wasn't with MAINTAINER being in the recipe, the problem was MAINTAINER ending up in the ipk data. The 'abiword crashes' bugs we had years ago illustrated the problem clearly. Abiword only crashed if you used code sourcery binutils, but not with stock binutils. Graeme couldn't get the message thru that he was indeed maintaining abi in OE but wasn't responsible for people using broken toolchains. The specific abiword issue was resolved when the distro in question stopped using CSL stuff (familiar or angstrom, I forget).
I'm in favour of having info in the recipe (or bbappend!) who is looking after it if it doesn't end up in the output package.
Regardless of where to put the info, I would like to propose to orphan every recipe in OE-core and ask for volunteers. There's a ton of stuff I want to look after (bluez, gstreamer, pulse, avahi, X) which already has a maintainer from its yocto/poky/whatever legacy, but I feel is not being looked after with much attention. And adding to the problem is that most yocto people aren't using OE-core, but poky.
regards,
Koen
^ permalink raw reply
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
From: Khem Raj @ 2011-10-20 16:18 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Phil Blundell
In-Reply-To: <1319120752.2410.34.camel@ted>
On Thu, Oct 20, 2011 at 7:25 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> a) Keep the data where it is
> b) Merge the data into the recipes
We once had maintainers and then backed out of it
this would reintroduce that and bitbake might have
to eat more memory to parse this information.
> c) Move the data out of OE-Core
For now this would be a better solution IMO
>
> Since a lot of that data is fairly Yocto process specific, it may make
> sense to move it over to meta-yocto...
>
Yes it seems to be apt.
^ permalink raw reply
* Re: useradd class not working
From: Mark Hatle @ 2011-10-20 16:12 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <CAP9ODKp+c9sXx6A7Bw9VnRXOKgNP_3q2uJmJEpvBwWT=dgXdBQ@mail.gmail.com>
On 10/19/11 11:26 PM, Otavio Salvador wrote:
> Hello,
>
> I am using useradd in a recipe and it needs to add a group in the
> rootfs at build time. This doesn't work.
>
> it seems groupadd does nothing.
>
> Has someone used or tried it?
>
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb
That is the recipe that was used when testing this feature. If it no longer
works properly then something has recently broken in the groupadd functionality.
--Mark
^ permalink raw reply
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
From: Eric Bénard @ 2011-10-20 16:02 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAP9ODKoFRiVnimZ3MDvK9S2v8JLykpR2-pWmmwz_2ua0pr-HfA@mail.gmail.com>
Hi,
Le 19/10/2011 21:00, Otavio Salvador a écrit :
> A plus of this choice is it will be more difficult to forget to update
> that info. This happened in last qt update for an example.
>
in fact that was in the first patch submitted but got lost in the v2 :-(
Eric
^ permalink raw reply
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
From: Richard Purdie @ 2011-10-20 15:55 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111020143631.GJ3522@jama.jama.net>
On Thu, 2011-10-20 at 16:36 +0200, Martin Jansa wrote:
> On Thu, Oct 20, 2011 at 03:25:52PM +0100, Richard Purdie wrote:
> > On Wed, 2011-10-19 at 16:33 -0700, Saul Wold wrote:
> > > On 10/19/2011 12:00 PM, Otavio Salvador wrote:
> > > > On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com> wrote:
> > > > ...
> > > >>>>> Many upstreams we can't track if updates are required automagically, so
> > > >>>>> we
> > > >>>>> need a place to record when the last manual check was, also possible
> > > >>>>> reasons
> > > >>>>> why we should not update to newer versions, ...
> > > >>
> > > >> hmm manual check means it has to be done manually is there any thing
> > > >> that needs it ?
> > > >>
> > > >> I think unless they are distro specific which seems not since they are
> > > >> in oe-core
> > > >> they could exist in recipes thats my opinion.
> > > >
> > > > I agree that this should be put into the recipes. Besides this allows
> > > > for checking if it was updated when the version has been updated.
> > > >
> > > > If done right, when updating the version this data will be updated
> > > > together. I see no change in the amount of changes.
> > > >
> > > > A plus of this choice is it will be more difficult to forget to update
> > > > that info. This happened in last qt update for an example.
> > > >
> > >
> > > This may need to be something that the TSC brings up, possibly we can
> > > talk about it in Prague next week.
> >
> > So just to give some background here, the information in those files was
> > added by Yocto people to give some idea of the update status of various
> > recipes. This included when the version was last checked/updated for
> > recipes which we can't automate that process for, when certain cleanup
> > checks were made, what the general state of the recipe was and who on
> > the Yocto team was specifically looking after given recipes.
> >
> > When it was discussed, some of it was Yocto specific, some of it wasn't
> > and popular opinion was against it going into the recipes themselves. I
> > was ok with that given we have the pn- overrides and can handle the
> > problem that way just fine.
> >
> > OE-Core happened and we kept the data with OE-Core at least for now. We
> > have several options:
> >
> > a) Keep the data where it is
> > b) Merge the data into the recipes
> > c) Move the data out of OE-Core
> >
> > Since a lot of that data is fairly Yocto process specific, it may make
> > sense to move it over to meta-yocto...
>
> I don't like "global" files where many people should maintain their info
> and it's so easy to forgot when it's somewhere else then real changes
> (like it was with checksums.ini and sane-src*.ini).
Some data does make sense to be maintained globally and I don't think we
should automatically say its bad. It depends what the use case is and
how its intended to be used.
> So I vote for b) Merge the data into the recipes, only problem with this
> is that if we have 2 versions of foo (foo_1.0.bb, foo_git.bb) without
> any foo.inc, will we create foo.inc just for distro-tracking info? Maybe
> we should and move at least DESCRIPTION and similar variables too.
>
> c) moving it to meta-yocto will probably make distro-tracking info even
> more outdated as sometimes different people then who did upgrade in
> oe-core will have to update distro-tracking info in this layer (this is
> also the case now sometimes, but with distro-tracking info in recipe we
> can try better to update it with upgrades).
I'd actually like Saul's view on this since he generally looks after
that data. There as been discussion about whether it is "internal" yocto
tracking stuff or whether its more general OE focused and I don't know
what the answer is there. I think there is a mixture of uses. I'm also
wary of "pushing" Yocto policy into OE which I think this might amount
to.
As a specific example, we've moved away from wanting MAINTAINER info in
the recipes in the past and this gets us back there again. I don't
really want to loop over adding data and then removing it again
repeatedly so this needs thought/discussion. Who gets their name in the
MAINTAINER field exactly? What is the process for that and what
responsibilities does that person have?
Cheers,
Richard
^ permalink raw reply
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
From: Koen Kooi @ 2011-10-20 14:48 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111020143631.GJ3522@jama.jama.net>
Op 20 okt. 2011, om 16:36 heeft Martin Jansa het volgende geschreven:
> On Thu, Oct 20, 2011 at 03:25:52PM +0100, Richard Purdie wrote:
>> On Wed, 2011-10-19 at 16:33 -0700, Saul Wold wrote:
>>> On 10/19/2011 12:00 PM, Otavio Salvador wrote:
>>>> On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com> wrote:
>>>> ...
>>>>>>>> Many upstreams we can't track if updates are required automagically, so
>>>>>>>> we
>>>>>>>> need a place to record when the last manual check was, also possible
>>>>>>>> reasons
>>>>>>>> why we should not update to newer versions, ...
>>>>>
>>>>> hmm manual check means it has to be done manually is there any thing
>>>>> that needs it ?
>>>>>
>>>>> I think unless they are distro specific which seems not since they are
>>>>> in oe-core
>>>>> they could exist in recipes thats my opinion.
>>>>
>>>> I agree that this should be put into the recipes. Besides this allows
>>>> for checking if it was updated when the version has been updated.
>>>>
>>>> If done right, when updating the version this data will be updated
>>>> together. I see no change in the amount of changes.
>>>>
>>>> A plus of this choice is it will be more difficult to forget to update
>>>> that info. This happened in last qt update for an example.
>>>>
>>>
>>> This may need to be something that the TSC brings up, possibly we can
>>> talk about it in Prague next week.
>>
>> So just to give some background here, the information in those files was
>> added by Yocto people to give some idea of the update status of various
>> recipes. This included when the version was last checked/updated for
>> recipes which we can't automate that process for, when certain cleanup
>> checks were made, what the general state of the recipe was and who on
>> the Yocto team was specifically looking after given recipes.
>>
>> When it was discussed, some of it was Yocto specific, some of it wasn't
>> and popular opinion was against it going into the recipes themselves. I
>> was ok with that given we have the pn- overrides and can handle the
>> problem that way just fine.
>>
>> OE-Core happened and we kept the data with OE-Core at least for now. We
>> have several options:
>>
>> a) Keep the data where it is
>> b) Merge the data into the recipes
>> c) Move the data out of OE-Core
>>
>> Since a lot of that data is fairly Yocto process specific, it may make
>> sense to move it over to meta-yocto...
>
> I don't like "global" files where many people should maintain their info
> and it's so easy to forgot when it's somewhere else then real changes
> (like it was with checksums.ini and sane-src*.ini).
>
> So I vote for b) Merge the data into the recipes, only problem with this
> is that if we have 2 versions of foo (foo_1.0.bb, foo_git.bb) without
> any foo.inc, will we create foo.inc just for distro-tracking info? Maybe
> we should and move at least DESCRIPTION and similar variables too.
>
> c) moving it to meta-yocto will probably make distro-tracking info even
> more outdated as sometimes different people then who did upgrade in
> oe-core will have to update distro-tracking info in this layer (this is
> also the case now sometimes, but with distro-tracking info in recipe we
> can try better to update it with upgrades).
I agree completely with Martin.
regards,
Koen
^ permalink raw reply
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
From: Martin Jansa @ 2011-10-20 14:36 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1319120752.2410.34.camel@ted>
[-- Attachment #1: Type: text/plain, Size: 3286 bytes --]
On Thu, Oct 20, 2011 at 03:25:52PM +0100, Richard Purdie wrote:
> On Wed, 2011-10-19 at 16:33 -0700, Saul Wold wrote:
> > On 10/19/2011 12:00 PM, Otavio Salvador wrote:
> > > On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com> wrote:
> > > ...
> > >>>>> Many upstreams we can't track if updates are required automagically, so
> > >>>>> we
> > >>>>> need a place to record when the last manual check was, also possible
> > >>>>> reasons
> > >>>>> why we should not update to newer versions, ...
> > >>
> > >> hmm manual check means it has to be done manually is there any thing
> > >> that needs it ?
> > >>
> > >> I think unless they are distro specific which seems not since they are
> > >> in oe-core
> > >> they could exist in recipes thats my opinion.
> > >
> > > I agree that this should be put into the recipes. Besides this allows
> > > for checking if it was updated when the version has been updated.
> > >
> > > If done right, when updating the version this data will be updated
> > > together. I see no change in the amount of changes.
> > >
> > > A plus of this choice is it will be more difficult to forget to update
> > > that info. This happened in last qt update for an example.
> > >
> >
> > This may need to be something that the TSC brings up, possibly we can
> > talk about it in Prague next week.
>
> So just to give some background here, the information in those files was
> added by Yocto people to give some idea of the update status of various
> recipes. This included when the version was last checked/updated for
> recipes which we can't automate that process for, when certain cleanup
> checks were made, what the general state of the recipe was and who on
> the Yocto team was specifically looking after given recipes.
>
> When it was discussed, some of it was Yocto specific, some of it wasn't
> and popular opinion was against it going into the recipes themselves. I
> was ok with that given we have the pn- overrides and can handle the
> problem that way just fine.
>
> OE-Core happened and we kept the data with OE-Core at least for now. We
> have several options:
>
> a) Keep the data where it is
> b) Merge the data into the recipes
> c) Move the data out of OE-Core
>
> Since a lot of that data is fairly Yocto process specific, it may make
> sense to move it over to meta-yocto...
I don't like "global" files where many people should maintain their info
and it's so easy to forgot when it's somewhere else then real changes
(like it was with checksums.ini and sane-src*.ini).
So I vote for b) Merge the data into the recipes, only problem with this
is that if we have 2 versions of foo (foo_1.0.bb, foo_git.bb) without
any foo.inc, will we create foo.inc just for distro-tracking info? Maybe
we should and move at least DESCRIPTION and similar variables too.
c) moving it to meta-yocto will probably make distro-tracking info even
more outdated as sometimes different people then who did upgrade in
oe-core will have to update distro-tracking info in this layer (this is
also the case now sometimes, but with distro-tracking info in recipe we
can try better to update it with upgrades).
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
From: Richard Purdie @ 2011-10-20 14:25 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Phil Blundell
In-Reply-To: <4E9F5E5A.6040002@intel.com>
On Wed, 2011-10-19 at 16:33 -0700, Saul Wold wrote:
> On 10/19/2011 12:00 PM, Otavio Salvador wrote:
> > On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com> wrote:
> > ...
> >>>>> Many upstreams we can't track if updates are required automagically, so
> >>>>> we
> >>>>> need a place to record when the last manual check was, also possible
> >>>>> reasons
> >>>>> why we should not update to newer versions, ...
> >>
> >> hmm manual check means it has to be done manually is there any thing
> >> that needs it ?
> >>
> >> I think unless they are distro specific which seems not since they are
> >> in oe-core
> >> they could exist in recipes thats my opinion.
> >
> > I agree that this should be put into the recipes. Besides this allows
> > for checking if it was updated when the version has been updated.
> >
> > If done right, when updating the version this data will be updated
> > together. I see no change in the amount of changes.
> >
> > A plus of this choice is it will be more difficult to forget to update
> > that info. This happened in last qt update for an example.
> >
>
> This may need to be something that the TSC brings up, possibly we can
> talk about it in Prague next week.
So just to give some background here, the information in those files was
added by Yocto people to give some idea of the update status of various
recipes. This included when the version was last checked/updated for
recipes which we can't automate that process for, when certain cleanup
checks were made, what the general state of the recipe was and who on
the Yocto team was specifically looking after given recipes.
When it was discussed, some of it was Yocto specific, some of it wasn't
and popular opinion was against it going into the recipes themselves. I
was ok with that given we have the pn- overrides and can handle the
problem that way just fine.
OE-Core happened and we kept the data with OE-Core at least for now. We
have several options:
a) Keep the data where it is
b) Merge the data into the recipes
c) Move the data out of OE-Core
Since a lot of that data is fairly Yocto process specific, it may make
sense to move it over to meta-yocto...
Cheers,
Richard
^ permalink raw reply
* Re: [CONSOLIDATED PULL - v2 00/26] More Updates and Fixes
From: Richard Purdie @ 2011-10-20 14:18 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <cover.1319096633.git.sgw@linux.intel.com>
On Thu, 2011-10-20 at 00:50 -0700, Saul Wold wrote:
> Richard,
>
> This adds on to yesterday's Consolidated Pull with more patches for
> both updates and fixes.
>
> a couple of note: Anders' module.bbclass change
> Otavio's distubute_src, this change looks good,
> but needs your eyes.
>
> The rest are mostly straight forward updates, I held off Nitin's gmp change
> on this round do to a failure I was seeing when images failed to work.
>
> Sau!
>
>
> The following changes since commit e31dd9b65f3b03f79cabab25eca157532de3bd9c:
>
> fontconfig: fix fix-pkgconfig.patch (2011-10-18 18:13:47 +0100)
>
> are available in the git repository at:
> git://git.openembedded.org/openembedded-core-contrib sgw/stage2
> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/stage2
>
> Anders Darander (1):
> module.bbclass: add lock to prevent error bulding ext modules
>
> Darren Hart (1):
> insane.bbclass: print full path on invalid LICENSE_FILES_CHKSUM
>
> Joshua Lock (5):
> gst-plugins-good: update to 0.10.30
> tzdata: updated SRC_URI and update to 2011k
> tzcode-native: update SRC_URI to new IANA location
> gst-plugins-good: correctly handle gconf schema
> distro-tracking-fields: update fields for tzdata and gst-plugins-good
>
> Kang Kai (5):
> ghostscript: update to 9.04
> libxml-sax-perl: update to 0.99
> liburi-perl: update to 1.59
> libsdl: update to 1.2.14
> distro_tracking_fields: update packages tracking fields
>
> Khem Raj (3):
> bluez4: Add glib-2.0 to DEPENDS
> gcc-4.6: Upgrade SRCREV to latest FSF 4.6 branch
> gcc-4.6: Backport PR46934 fix
>
> Lauri Hintsala (1):
> poky: fix broken ubifs link in deploy folder
>
> Nitin A Kamble (5):
> x86 tune files: set baselib for x32 tune as libx32
> python-scons: upgrade from 2.0.1 to 2.1.0
> python-dbus: upgrade from 0.83.2 to 0.84.0
> libxml-parser-perl: upgrade from 2.40 to 2.41
> distro-tracking: update data for some toolchain recipes
>
> Otavio Salvador (1):
> src_distribute.bbclass, src_distribute_local.bbclass: mostly
> rewritten
>
> Saul Wold (2):
> ghostscript: Disable parallel make due to install issues
> ghostscript: renamed x86_64 to x86-64 for patch to work
>
> Wenzong Fan (2):
> ccache: update to 3.1.6
> chkconfig: Update to 1.3.55
I merged these apart from the second gst-good-plugin patch from Joshua
which Koen had feedback about. I tweaked the message for Nitin's x32
commit.
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR
From: Richard Purdie @ 2011-10-20 13:56 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <7D5D6BF3-6F21-4CE5-8A30-F9154CDB9449@dominion.thruhere.net>
On Thu, 2011-10-20 at 14:54 +0200, Koen Kooi wrote:
> Op 20 okt. 2011, om 14:38 heeft Richard Purdie het volgende geschreven:
>
> > On Thu, 2011-10-20 at 13:29 +0200, Koen Kooi wrote:
> >> Op 20 okt. 2011, om 13:21 heeft Richard Purdie het volgende geschreven:
> >>
> >>> On Thu, 2011-10-20 at 08:23 +0200, Koen Kooi wrote:
> >>>> Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
> >>>>
> >>>>> On Wed, Sep 28, 2011 at 16:50, Richard Purdie
> >>>>> <richard.purdie@linuxfoundation.org> wrote:
> >>>>>>> This patch improves the current situation and I don't foresee the
> >>>>>>> autoPR code working soon
> >>>>>>
> >>>>>> Which is why we need to switch to that model and shake out the issues
> >>>>>> sooner than later. Enough is enough with the PR madness and we need to
> >>>>>> get to grips and fix it.
> >>>>>
> >>>>> I fully agree this is the way to go but this doesn't mean we ought to
> >>>>> hold this patch until all this happens. This patch allows the removal
> >>>>> of the kernel.bbclass from meta-oe so reducing the delta between
> >>>>> oe-core and meta-oe.
> >>>>
> >>>> So a month later and no sign of the mythical working
> >>>> auto-PR-incrementer or work on it.
> >>>
> >>> A month where we were stabilising for a release. Its on the 1.2 feature
> >>> list and as it happens I've been hearing questions about what is needed
> >>> here.
> >>>
> >>>> So can this patch go in? It would mean we can drop kernel.bbclass
> >>>> from meta-oe.
> >>>
> >>> I *HATE* this PR bumping stuff. I've just been told we likely need to
> >>> bump the PR for anything using libGL which once again shows that build
> >>> system basically failing to automate building things.
> >>>
> >>> So I'm drawing a line here and no, we can't take this. If its fine to
> >>> expect people to bump PR values manually for lib* changes, its fine for
> >>> kernels too. I'd suggest you do drop this from meta-oe and we start
> >>> building up pressure for the problem to get fixed properly rather than
> >>> letting people wallpaper over the cracks.
> >>
> >> I have products to ship, so treating meta-oe as a plaything and break
> >> this for the sake of breaking it is unacceptable. I'll let oe-core
> >> have the monopoly on high-qualitily, but broken metadata.
> >
> > Its not as if there isn't another way to handle this, it is a little
> > harder work I agree. This isn't breaking for the sake of breaking
> > either, its applying a bit of pressure to ensure we fix an underlying
> > problem we've had for a long time. I don't think fixing it will be easy,
> > I do think we need to though.
> >
> > Also, the idea never was to have everyone using bleeding edge for
> > shipping products. This is what stable releases are for?
>
> That's what stable releases are for, but I don't see a release for
> OE-core, do you? I see a poky release, but not an OE-core release.
As you are no doubt aware, that got discussed at the last TSC meeting.
Khem did volunteer to help with that, there is a branch there ready to
be tagged too and I was planning to raise progress with this at
tonight's TSC meeting.
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR
From: Otavio Salvador @ 2011-10-20 13:02 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <7D5D6BF3-6F21-4CE5-8A30-F9154CDB9449@dominion.thruhere.net>
On Thu, Oct 20, 2011 at 10:54, Koen Kooi <koen@dominion.thruhere.net> wrote:
...
>> Also, the idea never was to have everyone using bleeding edge for
>> shipping products. This is what stable releases are for?
>
> That's what stable releases are for, but I don't see a release for OE-core, do you? I see a poky release, but not an OE-core release.
People, let's calm down.
I think since Richard disagree about pushing this patch and more then
one person disagree with Richard, TSC is the way to go.
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply
* Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR
From: Koen Kooi @ 2011-10-20 12:54 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1319114339.2410.5.camel@ted>
Op 20 okt. 2011, om 14:38 heeft Richard Purdie het volgende geschreven:
> On Thu, 2011-10-20 at 13:29 +0200, Koen Kooi wrote:
>> Op 20 okt. 2011, om 13:21 heeft Richard Purdie het volgende geschreven:
>>
>>> On Thu, 2011-10-20 at 08:23 +0200, Koen Kooi wrote:
>>>> Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
>>>>
>>>>> On Wed, Sep 28, 2011 at 16:50, Richard Purdie
>>>>> <richard.purdie@linuxfoundation.org> wrote:
>>>>>>> This patch improves the current situation and I don't foresee the
>>>>>>> autoPR code working soon
>>>>>>
>>>>>> Which is why we need to switch to that model and shake out the issues
>>>>>> sooner than later. Enough is enough with the PR madness and we need to
>>>>>> get to grips and fix it.
>>>>>
>>>>> I fully agree this is the way to go but this doesn't mean we ought to
>>>>> hold this patch until all this happens. This patch allows the removal
>>>>> of the kernel.bbclass from meta-oe so reducing the delta between
>>>>> oe-core and meta-oe.
>>>>
>>>> So a month later and no sign of the mythical working
>>>> auto-PR-incrementer or work on it.
>>>
>>> A month where we were stabilising for a release. Its on the 1.2 feature
>>> list and as it happens I've been hearing questions about what is needed
>>> here.
>>>
>>>> So can this patch go in? It would mean we can drop kernel.bbclass
>>>> from meta-oe.
>>>
>>> I *HATE* this PR bumping stuff. I've just been told we likely need to
>>> bump the PR for anything using libGL which once again shows that build
>>> system basically failing to automate building things.
>>>
>>> So I'm drawing a line here and no, we can't take this. If its fine to
>>> expect people to bump PR values manually for lib* changes, its fine for
>>> kernels too. I'd suggest you do drop this from meta-oe and we start
>>> building up pressure for the problem to get fixed properly rather than
>>> letting people wallpaper over the cracks.
>>
>> I have products to ship, so treating meta-oe as a plaything and break
>> this for the sake of breaking it is unacceptable. I'll let oe-core
>> have the monopoly on high-qualitily, but broken metadata.
>
> Its not as if there isn't another way to handle this, it is a little
> harder work I agree. This isn't breaking for the sake of breaking
> either, its applying a bit of pressure to ensure we fix an underlying
> problem we've had for a long time. I don't think fixing it will be easy,
> I do think we need to though.
>
> Also, the idea never was to have everyone using bleeding edge for
> shipping products. This is what stable releases are for?
That's what stable releases are for, but I don't see a release for OE-core, do you? I see a poky release, but not an OE-core release.
^ permalink raw reply
* Re: [CONSOLIDATED PULL - v2 09/26] x86 tune files: set baselib for x32 tune as libx32
From: Richard Purdie @ 2011-10-20 12:44 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1319101363.22985.259.camel@phil-desktop>
On Thu, 2011-10-20 at 10:02 +0100, Phil Blundell wrote:
> On Thu, 2011-10-20 at 00:50 -0700, Saul Wold wrote:
> > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> >
> > Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
>
> Why is this a good thing? There is no explanation in the commit
> message.
Agreed, we need to improve the commit messages. I've merged this one
with some additional comments but can people please keep good commit
messages in mind.
Cheers,
Richard
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox